李 俊，江 海

(中國石化廣東石油分公司，廣東 廣州 510000)

0 引言

自從馬云在2016 年10 月的杭州云棲大會提出“新零售”[1]理念以來，伴隨著國家政策的不斷加持，國內(nèi)新零售業(yè)態(tài)發(fā)展如火如荼。然而線上業(yè)務(wù)出現(xiàn)了爆發(fā)式增長，用戶規(guī)模和數(shù)據(jù)量呈指數(shù)級上升，應(yīng)用復(fù)雜度急劇升高，這些都導(dǎo)致系統(tǒng)頻繁地迭代更新，傳統(tǒng)IT架構(gòu)不堪重負，必須升級改造。

與此同時，微服務(wù)的興起為傳統(tǒng)企業(yè)變革IT 架構(gòu)、提升IT 效率指明了方向[2]。微服務(wù)架構(gòu)風(fēng)格是以開發(fā)一組小型服務(wù)作為一個獨立的應(yīng)用系統(tǒng)，每個服務(wù)都運行在自己的進程中，采用分布式的去中心化管理模式。相對于單體架構(gòu)，微服務(wù)架構(gòu)具有易于開發(fā)和維護、支持高并發(fā)高可用、支持豐富技術(shù)棧、利于團隊協(xié)作及技術(shù)創(chuàng)新等顯著優(yōu)點[3]，與新零售的業(yè)務(wù)對IT架構(gòu)的內(nèi)在要求高度契合。

因此，本文針對傳統(tǒng)零售企業(yè)轉(zhuǎn)型過程中IT 架構(gòu)重塑的需要，提出一種基于Spring Cloud 微服務(wù)框架的新零售平臺技術(shù)方案，針對服務(wù)治理、服務(wù)請求認證、服務(wù)配置等給出一整套自主研發(fā)設(shè)計的體系架構(gòu)和實踐方法。最后，將此方案應(yīng)用在某大型國有企業(yè)新零售平臺建設(shè)中，從技術(shù)和業(yè)務(wù)兩個層面驗證了方案的可行性和實際效果。

1 微服務(wù)架構(gòu)實現(xiàn)

微服務(wù)體系架構(gòu)（MicroServices Architecture）是根據(jù)應(yīng)用系統(tǒng)的實際業(yè)務(wù)需求，通過對預(yù)定義的微服務(wù)進行重組而形成企業(yè)級應(yīng)用的分布式體系結(jié)構(gòu)[4]，其基本思想是將傳統(tǒng)的單體應(yīng)用按業(yè)務(wù)功能拆分為一系列可被獨立設(shè)計、開發(fā)、部署、運維的軟件服務(wù)單元，服務(wù)間彼此配合、相互協(xié)作以實現(xiàn)最終價值[5]。相比傳統(tǒng)單體架構(gòu)，微服務(wù)體系架構(gòu)解決了系統(tǒng)數(shù)據(jù)、服務(wù)呈爆炸式增長而造成的各種問題，因此逐漸成為了當前最流行的分布式系統(tǒng)架構(gòu)之一，已被應(yīng)用到很多大型公司的系統(tǒng)實踐中[6]。

微服務(wù)框架（MicroService Framework）是微服務(wù)體系架構(gòu)的具體實現(xiàn)方法，它是企業(yè)在構(gòu)建微服務(wù)架構(gòu)的實踐過程中考慮將服務(wù)注冊與配置、服務(wù)部署與管理以及服務(wù)通信等眾多關(guān)鍵技術(shù)，集成為一種高效運行的整體技術(shù)框架[7]。目前較主流的微服務(wù)框架有Spring Cloud、Motan、gRPC、Thrift 以及Dubbo 等。基于框架完整性、技術(shù)易用性以及社區(qū)活躍程度考慮，本文采用當前應(yīng)用最為廣泛的Spring Cloud構(gòu)建一套全局的微服務(wù)協(xié)調(diào)治理框架。

1.1 微服務(wù)框架設(shè)計

本文設(shè)計的微服務(wù)技術(shù)框架如圖1 所示，基于Spring Cloud Finchley SR2 版本和Spring Boot2.0.7構(gòu)建。Spring Cloud 是關(guān)注全局的微服務(wù)協(xié)調(diào)治理的框架，它對基于Spring Boot開發(fā)的一個個單體微服務(wù)進行管理協(xié)調(diào)并實現(xiàn)正?；ヂ?lián)互通，并為各個微服務(wù)之間提供服務(wù)發(fā)現(xiàn)與注冊、服務(wù)配置、負載均衡、服務(wù)熔斷及全鏈路監(jiān)控等集成服務(wù)[8-9]。

圖1 微服務(wù)技術(shù)框架圖

因在實際應(yīng)用中，Spring Cloud 原生框架自帶的標準組件在微服務(wù)運行監(jiān)控及運維、配置項權(quán)限管理、服務(wù)間調(diào)用安全認證及微服務(wù)應(yīng)用日志管理等方面存在明顯不足，本文根據(jù)微服務(wù)協(xié)調(diào)治理需要，自主研發(fā)設(shè)計部分組件，與原生組件一起構(gòu)成一套完整的微服務(wù)技術(shù)框架，包括服務(wù)網(wǎng)關(guān)、服務(wù)管理中心、配置管理中心、服務(wù)鑒權(quán)中心、日志管理中心等核心組件。

服務(wù)管理中心（Service Management Center）以Spring-Cloud-Eureka 組件為基礎(chǔ)，結(jié)合自研探針Agent 擴展微服務(wù)治理功能，在Eureka 的服務(wù)注冊與發(fā)現(xiàn)功能基礎(chǔ)上，增加服務(wù)狀態(tài)實時監(jiān)測、服務(wù)實例上下線實時通知、服務(wù)自動化部署等管理功能。

配置管理中心（Config Management Center）以Spring-Cloud-Config 組件為基礎(chǔ)，使用MySql 作為配置項存儲介質(zhì)。配置項管理功能以微服務(wù)應(yīng)用為最小粒度進行權(quán)限控制，實現(xiàn)靈活安全、操作友好的配置文件管理功能。

服務(wù)鑒權(quán)中心（Service Authentication Center）以Spring-Cloud-Feign 組件為基礎(chǔ)，進行二次封裝，設(shè)計了一種簡單高效的微服務(wù)間調(diào)用鑒權(quán)方法。既有效保障了微服務(wù)接口安全、防止未授權(quán)訪問，又不會對微服務(wù)性能造成影響。

日志管理中心（Log Management Center）使用Elastic 公司Logstash、Filebeat 組件，結(jié)合Kafka，實現(xiàn)分散在各服務(wù)器上微服務(wù)應(yīng)用日志的自動歸集、篩選查詢和壓縮歸檔，并結(jié)合Agent技術(shù)實現(xiàn)日志查看。

1.2 服務(wù)管理中心

Spring Cloud Eureka 是對Netflix 公司的Eureka的二次封裝，實現(xiàn)了服務(wù)治理的功能，提供Eureka Server 服務(wù)端與Eureka Client 客戶端，服務(wù)端即是Eureka 服務(wù)注冊中心，客戶端完成微服務(wù)向Eureka 服務(wù)的注冊與發(fā)現(xiàn)。此外，Spring Cloud 原生組件并沒有提供對微服務(wù)應(yīng)用實例進行全面管理的功能，然而在實際生產(chǎn)環(huán)境中，面對成百上千的微服務(wù)，一個集中式的微服務(wù)管理與監(jiān)控中心是必不可少的。

為了解決上述問題，本文基于Eureka+Agent架構(gòu)，自主研發(fā)了服務(wù)管理中心，其架構(gòu)原理如圖2所示。

圖2 服務(wù)管理中心架構(gòu)原理圖

服務(wù)管理中心主要由管控臺與自研探針應(yīng)用Agent 兩部分組成，管控臺采用集中部署方式，Agent則部署在微服務(wù)宿主主機上。

管控臺使用Web+Socket技術(shù)，集中管理微服務(wù)應(yīng)用的發(fā)布、啟動、停止、更新等功能，支持批量操作。此外，通過與Eureka 和即時通訊系統(tǒng)集成，實現(xiàn)微服務(wù)實例的上、下線實時通知；通過服務(wù)監(jiān)控模塊實現(xiàn)所有微服務(wù)健康狀態(tài)的可視化監(jiān)控功能。

Agent 應(yīng)用支持管理容器化和非容器化混合部署的微服務(wù)實例，通過執(zhí)行shell 命令以及調(diào)用其他系統(tǒng)接口的方式，采集宿主主機上的微服務(wù)實例信息；使用基于Netty的Socket技術(shù)與管控臺建立長鏈接通道，通過該通道接收管控臺下發(fā)的指令并反饋執(zhí)行結(jié)果，協(xié)助管控臺實現(xiàn)遠程管理和監(jiān)控。

1.3 服務(wù)配置中心

Spring Cloud Config 是目前比較成熟的配置中心組件之一，為各個不同的微服務(wù)應(yīng)用的所有環(huán)境提供了一個中心化的外部配置支持。官方推薦采用Git來存儲配置信息，支持多版本管理、分支管理等功能。但是，基于Git 的管理系統(tǒng)開發(fā)難度較大，并且Git 是基于文件的版本管理工具，對單個配置項的CRUD 操作提交會導(dǎo)致整個文件的更改，因此，在數(shù)據(jù)細粒度權(quán)限控制方面有很大的局限性。

為解決上述問題，本文提出了一種以Spring Cloud Config 為基礎(chǔ)，MySql 數(shù)據(jù)庫為配置項存儲介質(zhì)的服務(wù)配置中心實現(xiàn)方案，其架構(gòu)原理如圖3所示。在該架構(gòu)下，通過對配置項在數(shù)據(jù)庫中的存儲結(jié)構(gòu)來進行擴展，數(shù)據(jù)權(quán)限控制的最小粒度可以支持到數(shù)據(jù)庫的行記錄，同時支持按應(yīng)用、分支、部署環(huán)境多維度管理，以滿足開發(fā)、測試、灰度、生產(chǎn)等不同環(huán)境下的配置項管理需求，實現(xiàn)統(tǒng)一配置、環(huán)境隔離的效果。

圖3 服務(wù)配置中心架構(gòu)原理圖

該方案利用MySql 的mysql-udf-http 自定義函數(shù)以及數(shù)據(jù)庫觸發(fā)器技術(shù)，實現(xiàn)配置項數(shù)據(jù)變更時主動通知服務(wù)配置中心。配置中心收到變更通知后向RocketMQ 發(fā)送廣播消息，同時使用消息中的Tag屬性標記變更配置所屬微服務(wù)應(yīng)用；每個微服務(wù)實例都會收到該消息，通過消息中的Tag屬性，確定是否是當前應(yīng)用的配置項，若是則實現(xiàn)配置實時更新，反之直接丟棄該消息。

ConfigMgtUI 是配置管理端，包括公共配置和應(yīng)用配置。公共配置是各微服務(wù)應(yīng)用中統(tǒng)一使用的配置項信息，應(yīng)用配置指各微服務(wù)應(yīng)用中的個性化配置。各應(yīng)用間配置相互隔離，應(yīng)用配置優(yōu)先級高于公共配置。

1.4 服務(wù)鑒權(quán)中心

微服務(wù)鑒權(quán)是指在安全認證機制保證下，對系統(tǒng)內(nèi)部各微服務(wù)之間的調(diào)用行為進行鑒權(quán)，目的是防止微服務(wù)接口未授權(quán)調(diào)用，然而Spring Cloud 沒有直接提供微服務(wù)間安全認證的功能。

因此，本文提出了一種基于動態(tài)簽名機制構(gòu)建微服務(wù)鑒權(quán)中心的方法，以實現(xiàn)服務(wù)間的安全認證，其原理如圖4所示。

圖4 服務(wù)鑒權(quán)中心原理圖

調(diào)用方微服務(wù)實例啟動后，向鑒權(quán)中心發(fā)起包含安全認證信息的動態(tài)密鑰認證請求，認證通過后獲得動態(tài)密鑰（signkey）以及密鑰編碼（signkeycode），動態(tài)密鑰與該微服務(wù)實例所在容器的IP 綁定。調(diào)用方在每一次調(diào)用其他微服務(wù)實例之前，需對當次請求進行簽名，并將簽名結(jié)果加入到請求數(shù)據(jù)包的Header 中，用于被調(diào)用微服務(wù)實例驗證簽名使用。

被調(diào)用的微服務(wù)實例收到請求后，獲取Header 中的信息，根據(jù)密鑰編碼向鑒權(quán)中心獲取請求方的動態(tài)密鑰及IP。只有簽名驗證正確、unix_timestamp 間隔在60s 內(nèi)且請求方的IP 與Auth 中一致，才認為該請求是合法的。

2 系統(tǒng)總體設(shè)計

2.1 需求分析

傳統(tǒng)企業(yè)都有大量的舊架構(gòu)IT 系統(tǒng)，包括一些核心業(yè)務(wù)系統(tǒng)，在向微服務(wù)架構(gòu)升級過程中，完全丟掉這些歷史包袱、全部推翻重建并不現(xiàn)實。因此，基于微服務(wù)的企業(yè)IT 架構(gòu)重塑，首先需要對原有系統(tǒng)架構(gòu)進行科學(xué)評估，要在新架構(gòu)與舊系統(tǒng)之間處理好平衡關(guān)系，既要實現(xiàn)應(yīng)用模塊之間的解耦重構(gòu)，又要根據(jù)企業(yè)實際情況選擇最合適的落地roadmap[10]。

本文將前述設(shè)計和實現(xiàn)的基于Spring Cloud 的微服務(wù)框架在國內(nèi)某傳統(tǒng)零售企業(yè)進行實施。該企業(yè)原有IT 系統(tǒng)采用傳統(tǒng)的輕量級Web 框架MVC（Model-View-Controller），主要面向傳統(tǒng)線下業(yè)務(wù)和企業(yè)內(nèi)部用戶提供服務(wù)，系統(tǒng)技術(shù)瓶頸并不明顯。隨著近兩年的新零售業(yè)務(wù)轉(zhuǎn)型，線上會員數(shù)迅速突破2000 萬人，數(shù)據(jù)量對比三年前增加了十倍，業(yè)務(wù)復(fù)雜度急劇上升，開發(fā)團隊規(guī)模擴大了三倍。新零售模式下的高并發(fā)、高靈活性使得企業(yè)核心業(yè)務(wù)系統(tǒng)承受著巨大壓力，已經(jīng)嚴重制約新零售業(yè)務(wù)的持續(xù)發(fā)展。

2.2 系統(tǒng)架構(gòu)設(shè)計

為了支撐該企業(yè)轉(zhuǎn)型發(fā)展長遠需要，構(gòu)建了以微服務(wù)框架為基礎(chǔ)的新零售系統(tǒng)（New Retail System，NRS）整體架構(gòu)，如圖5所示。

圖5 NRS系統(tǒng)架構(gòu)圖

NRS 架構(gòu)保留了該企業(yè)舊IT 架構(gòu)中的部分核心業(yè)務(wù)系統(tǒng)如ERP、門店交易、IC 卡系統(tǒng)等，并對舊架構(gòu)中運算量大、并發(fā)壓力高的模塊如CRM、電子商務(wù)后臺進行拆分、解耦和重新整合，變?yōu)橐粋€個邊界清晰、相互獨立的微服務(wù)，并通過本文設(shè)計的Spring Cloud框架對這些微服務(wù)進行集中管理和協(xié)調(diào)工作[11-12]。

拆分后的微服務(wù)主要分為兩大類：一類是只關(guān)注特定業(yè)務(wù)功能，與其他微服務(wù)不存在或存在極少耦合關(guān)系的基礎(chǔ)微服務(wù)，如會員中心、賬戶中心、支付中心等；另一類是基于基礎(chǔ)微服務(wù)構(gòu)建，與其他微服務(wù)存在一定耦合關(guān)系的聚合微服務(wù)，例如訂單中心、營銷中心等。通過這種方式可以最大程度地實現(xiàn)服務(wù)間業(yè)務(wù)解耦，以及避免服務(wù)間循環(huán)依賴。

3 系統(tǒng)應(yīng)用效果

3.1 微服務(wù)可視化管理

本系統(tǒng)上線后，管理員可以通過服務(wù)管理中心的界面實現(xiàn)所有微服務(wù)運行狀態(tài)的可視化監(jiān)控，如圖6所示。經(jīng)過解耦重構(gòu)，本文設(shè)計的NRS系統(tǒng)共有52個微服務(wù)，結(jié)合業(yè)務(wù)復(fù)雜度以及高可用等因素，在實際生產(chǎn)環(huán)境中部署了313個微服務(wù)實例。

圖6 微服務(wù)監(jiān)控界面

由于分布式系統(tǒng)固有的復(fù)雜性，以及成百上千的微服務(wù)實例，使得NRS 系統(tǒng)運維復(fù)雜度較升級前成倍增長。因此服務(wù)管理中心通過建立完整的自動化體系，實現(xiàn)了微服務(wù)的智能化管理，如圖7 所示。包括單個微服務(wù)實例靈活發(fā)布、微服務(wù)集群滾動發(fā)布、實時日志監(jiān)控、歷史日志管理以及微服務(wù)狀態(tài)監(jiān)控等，大大降低了運維工作量。

圖7 微服務(wù)運維

3.2 性能對比分析

在舊架構(gòu)系統(tǒng)中，請求中任何一個環(huán)節(jié)邏輯處理的高延時都會影響整個系統(tǒng)的吞吐量，且缺乏靈活應(yīng)對措施。升級為NRS 架構(gòu)后，當某個微服務(wù)接口出現(xiàn)高延時或業(yè)務(wù)邏輯請求突增時，可以更靈活地對部分微服務(wù)進行橫向擴容，以此來提高系統(tǒng)整體性能。

本文對重構(gòu)前后系統(tǒng)性能進行對比測試，選取并發(fā)訪問量最大的交易下單和訂單查詢接口，在相同硬件條件下分別進行壓力測試。重構(gòu)前后業(yè)務(wù)邏輯未發(fā)生明顯變化，壓測并發(fā)數(shù)設(shè)定為1500，壓測時長30分鐘，測試結(jié)果如表1所示。

表1 新舊架構(gòu)性能對比分析表

測試結(jié)果顯示，NRS 架構(gòu)平均響應(yīng)時間比舊架構(gòu)降低了約50%，同時請求錯誤率從1%下降到0.01%，性能提升明顯。此外，對響應(yīng)時間按照2s、5s、10s三個階梯進行分類統(tǒng)計，結(jié)果顯示，NRS 架構(gòu)的接口性能均得到不同程度的提高，以查詢接口為例，服務(wù)響應(yīng)時間小于2s 的請求占比提高了24.1%，小于5s 的請求占比提高了22.5%。由此可見，NRS 架構(gòu)系統(tǒng)在低延時響應(yīng)方面明顯優(yōu)于舊架構(gòu)系統(tǒng)。

對重構(gòu)前后系統(tǒng)在生產(chǎn)環(huán)境中進行全鏈路壓測，結(jié)果如圖8所示，這里使用QPS（Query Per Second，每秒的響應(yīng)請求數(shù)）來考量系統(tǒng)吞吐量。

圖8 新舊架構(gòu)系統(tǒng)吞吐量對比圖

測試結(jié)果顯示，隨著并發(fā)用戶數(shù)增長，NRS 架構(gòu)平均響應(yīng)時間增長的速度明顯低于舊架構(gòu)系統(tǒng)，性能優(yōu)勢明顯。此外，從圖中QPS 隨并發(fā)用戶數(shù)的變化趨勢可以看出，NRS 架構(gòu)最大QPS 在8200 左右，舊架構(gòu)QPS在1900左右，系統(tǒng)的吞吐量提升顯著。

4 結(jié)束語

傳統(tǒng)行業(yè)向新零售轉(zhuǎn)型過程中對IT 架構(gòu)的內(nèi)在變革需求是如今微服務(wù)架構(gòu)體系炙手可熱的主要驅(qū)動因素。本文介紹了一種基于微服務(wù)架構(gòu)的NRS 設(shè)計方案，優(yōu)化、完善了微服務(wù)組件和整體框架，解決了傳統(tǒng)IT 架構(gòu)面對新零售業(yè)務(wù)模式持續(xù)創(chuàng)新和數(shù)據(jù)量爆發(fā)式增長無法支撐的問題。

通過將該方案應(yīng)用到國內(nèi)某傳統(tǒng)企業(yè)，進一步驗證了可行性和實踐效果。由此可見，對于旨在開拓新業(yè)務(wù)、轉(zhuǎn)型新零售的傳統(tǒng)企業(yè)，微服務(wù)架構(gòu)具有很好的推廣價值與廣闊的應(yīng)用前景。下一步將對ServiceMesh（服務(wù)網(wǎng)格）技術(shù)展開研究，期望搭建一種對應(yīng)用透明、更輕量級的服務(wù)發(fā)現(xiàn)和治理機制，屏蔽分布式系統(tǒng)的通信復(fù)雜性，同時滿足多語言和容器化發(fā)展的趨勢。