基于微服務架構的新零售系統設計與應用

李 俊，江 海

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

0 引言

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

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

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

1 微服務架構實現

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

微服務框架（MicroService Framework）是微服務體系架構的具體實現方法，它是企業在構建微服務架構的實踐過程中考慮將服務注冊與配置、服務部署與管理以及服務通信等眾多關鍵技術，集成為一種高效運行的整體技術框架[7]。目前較主流的微服務框架有Spring Cloud、Motan、gRPC、Thrift 以及Dubbo 等?；诳蚣芡暾浴⒓夹g易用性以及社區活躍程度考慮，本文采用當前應用最為廣泛的Spring Cloud構建一套全局的微服務協調治理框架。

1.1 微服務框架設計

本文設計的微服務技術框架如圖1 所示，基于Spring Cloud Finchley SR2 版本和Spring Boot2.0.7構建。Spring Cloud 是關注全局的微服務協調治理的框架，它對基于Spring Boot開發的一個個單體微服務進行管理協調并實現正?；ヂ摶ネ?，并為各個微服務之間提供服務發現與注冊、服務配置、負載均衡、服務熔斷及全鏈路監控等集成服務[8-9]。

圖1 微服務技術框架圖

因在實際應用中，Spring Cloud 原生框架自帶的標準組件在微服務運行監控及運維、配置項權限管理、服務間調用安全認證及微服務應用日志管理等方面存在明顯不足，本文根據微服務協調治理需要，自主研發設計部分組件，與原生組件一起構成一套完整的微服務技術框架，包括服務網關、服務管理中心、配置管理中心、服務鑒權中心、日志管理中心等核心組件。

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

配置管理中心（Config Management Center）以Spring-Cloud-Config 組件為基礎，使用MySql 作為配置項存儲介質。配置項管理功能以微服務應用為最小粒度進行權限控制，實現靈活安全、操作友好的配置文件管理功能。

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

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

1.2 服務管理中心

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

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

圖2 服務管理中心架構原理圖

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

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

Agent 應用支持管理容器化和非容器化混合部署的微服務實例，通過執行shell 命令以及調用其他系統接口的方式，采集宿主主機上的微服務實例信息；使用基于Netty的Socket技術與管控臺建立長鏈接通道，通過該通道接收管控臺下發的指令并反饋執行結果，協助管控臺實現遠程管理和監控。

1.3 服務配置中心

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

為解決上述問題，本文提出了一種以Spring Cloud Config 為基礎，MySql 數據庫為配置項存儲介質的服務配置中心實現方案，其架構原理如圖3所示。在該架構下，通過對配置項在數據庫中的存儲結構來進行擴展，數據權限控制的最小粒度可以支持到數據庫的行記錄，同時支持按應用、分支、部署環境多維度管理，以滿足開發、測試、灰度、生產等不同環境下的配置項管理需求，實現統一配置、環境隔離的效果。

圖3 服務配置中心架構原理圖

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

ConfigMgtUI 是配置管理端，包括公共配置和應用配置。公共配置是各微服務應用中統一使用的配置項信息，應用配置指各微服務應用中的個性化配置。各應用間配置相互隔離，應用配置優先級高于公共配置。

1.4 服務鑒權中心

微服務鑒權是指在安全認證機制保證下，對系統內部各微服務之間的調用行為進行鑒權，目的是防止微服務接口未授權調用，然而Spring Cloud 沒有直接提供微服務間安全認證的功能。

因此，本文提出了一種基于動態簽名機制構建微服務鑒權中心的方法，以實現服務間的安全認證，其原理如圖4所示。

圖4 服務鑒權中心原理圖

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

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

2 系統總體設計

2.1 需求分析

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

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

2.2 系統架構設計

為了支撐該企業轉型發展長遠需要，構建了以微服務框架為基礎的新零售系統（New Retail System，NRS）整體架構，如圖5所示。

圖5 NRS系統架構圖

NRS 架構保留了該企業舊IT 架構中的部分核心業務系統如ERP、門店交易、IC 卡系統等，并對舊架構中運算量大、并發壓力高的模塊如CRM、電子商務后臺進行拆分、解耦和重新整合，變為一個個邊界清晰、相互獨立的微服務，并通過本文設計的Spring Cloud框架對這些微服務進行集中管理和協調工作[11-12]。

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

3 系統應用效果

3.1 微服務可視化管理

本系統上線后，管理員可以通過服務管理中心的界面實現所有微服務運行狀態的可視化監控，如圖6所示。經過解耦重構，本文設計的NRS系統共有52個微服務，結合業務復雜度以及高可用等因素，在實際生產環境中部署了313個微服務實例。

圖6 微服務監控界面

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

圖7 微服務運維

3.2 性能對比分析

在舊架構系統中，請求中任何一個環節邏輯處理的高延時都會影響整個系統的吞吐量，且缺乏靈活應對措施。升級為NRS 架構后，當某個微服務接口出現高延時或業務邏輯請求突增時，可以更靈活地對部分微服務進行橫向擴容，以此來提高系統整體性能。

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

表1 新舊架構性能對比分析表

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

對重構前后系統在生產環境中進行全鏈路壓測，結果如圖8所示，這里使用QPS（Query Per Second，每秒的響應請求數）來考量系統吞吐量。

圖8 新舊架構系統吞吐量對比圖

測試結果顯示，隨著并發用戶數增長，NRS 架構平均響應時間增長的速度明顯低于舊架構系統，性能優勢明顯。此外，從圖中QPS 隨并發用戶數的變化趨勢可以看出，NRS 架構最大QPS 在8200 左右，舊架構QPS在1900左右，系統的吞吐量提升顯著。

4 結束語

傳統行業向新零售轉型過程中對IT 架構的內在變革需求是如今微服務架構體系炙手可熱的主要驅動因素。本文介紹了一種基于微服務架構的NRS 設計方案，優化、完善了微服務組件和整體框架，解決了傳統IT 架構面對新零售業務模式持續創新和數據量爆發式增長無法支撐的問題。

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