李 俊，江 海

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2 服務(wù)管理中心

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

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

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

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

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

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

1.3 服務(wù)配置中心

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

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

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

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

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

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

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

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

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

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

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

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

2.1 需求分析

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

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

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

為了支撐該企業(yè)轉(zhuǎn)型發(fā)展長(zhǎng)遠(yuǎn)需要，構(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)等，并對(duì)舊架構(gòu)中運(yùn)算量大、并發(fā)壓力高的模塊如CRM、電子商務(wù)后臺(tái)進(jìn)行拆分、解耦和重新整合，變?yōu)橐粋€(gè)個(gè)邊界清晰、相互獨(dú)立的微服務(wù)，并通過(guò)本文設(shè)計(jì)的Spring Cloud框架對(duì)這些微服務(wù)進(jìn)行集中管理和協(xié)調(diào)工作[11-12]。

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

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

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

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

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

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

圖7 微服務(wù)運(yùn)維

3.2 性能對(duì)比分析

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

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

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

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

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

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

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

4 結(jié)束語(yǔ)

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

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