鐵路站車Wi-Fi運營服務(wù)平臺微服務(wù)架構(gòu)設(shè)計

翁湦元，單杏花，閻志遠(yuǎn)，王雪峰

（中國鐵道科學(xué)研究院集團有限公司 電子計算技術(shù)研究所，北京 100081）

鐵路站車Wi-Fi運營服務(wù)平臺上線以來，先后增加了設(shè)備狀態(tài)監(jiān)控、運營數(shù)據(jù)監(jiān)控、用戶行為分析以及手機App接入服務(wù)等功能。隨著系統(tǒng)功能的日益增加，系統(tǒng)應(yīng)用的數(shù)量不斷增多，原有應(yīng)用的體積不斷增長，應(yīng)用部署和維護的難度也隨之增長[1]。為實現(xiàn)業(yè)務(wù)的快速迭代，減少研發(fā)、部署和維護的復(fù)雜性，利用微服務(wù)架構(gòu)對現(xiàn)有系統(tǒng)進行改造[2]。在微服務(wù)系統(tǒng)架構(gòu)中，獨立部署在不同進程中的服務(wù)之間通過HTTP 等通信機制實現(xiàn)相互調(diào)用，從而實現(xiàn)系統(tǒng)的靈活部署和擴展[3]。本文闡述了鐵路站車Wi-Fi運營服務(wù)平臺進行微服務(wù)化改造的架構(gòu)設(shè)計、關(guān)鍵問題和實施效果。

1 微服務(wù)架構(gòu)設(shè)計改造方案

1.1 原系統(tǒng)架構(gòu)概述

原鐵路站車Wi-Fi運營服務(wù)平臺根據(jù)不同的業(yè)務(wù)需求垂直劃分為相互獨立的模塊，模塊均是單體應(yīng)用的形式，通過部署多個副本并借助Nginx負(fù)載均衡實現(xiàn)應(yīng)用服務(wù)能力的擴展。單體應(yīng)用內(nèi)部功能集中，代碼和數(shù)據(jù)中心化，運行在同一個進程中。隨著業(yè)務(wù)系統(tǒng)功能的增多，一旦出現(xiàn)缺陷，原因難以定位。修復(fù)系統(tǒng)需要花費較長的時間，項目構(gòu)建和部署的時間也會相應(yīng)加長。

1.2 服務(wù)拆分和架構(gòu)設(shè)計

通過引入微服務(wù)架構(gòu)模式，將應(yīng)用程序分解為一系列較小的互連服務(wù)，從而避免大而臃腫的單體應(yīng)用架構(gòu)。根據(jù)既有系統(tǒng)業(yè)務(wù)進行梳理，對平臺進行服務(wù)拆分，拆分結(jié)果如表1所示。

表1 平臺服務(wù)列表

鐵路站車Wi-Fi運營服務(wù)平臺可劃分為接入層、業(yè)務(wù)層、基礎(chǔ)資源層和數(shù)據(jù)層[4]，微服務(wù)架構(gòu)設(shè)計如圖1所示。

圖1 微服務(wù)架構(gòu)設(shè)計圖

（1）接入層面向用戶和外部軟件以Web頁面或API接口的方式提供服務(wù)，根據(jù)業(yè)務(wù)模塊垂直劃分，通過整合業(yè)務(wù)層內(nèi)各業(yè)務(wù)微服務(wù)的能力來為外部用戶和軟件提供最終的服務(wù)，靈活地對服務(wù)進行編排、組合，以實現(xiàn)快速迭代，滿足多變的外部需求。

（2）業(yè)務(wù)層由經(jīng)過拆分的相互獨立且松散耦合的服務(wù)組成，各服務(wù)專注于自身負(fù)責(zé)的模塊業(yè)務(wù)[5]，可快速水平擴展，同時服務(wù)的升級也不會影響平臺整體業(yè)務(wù)的正常運行。

（3）基礎(chǔ)資源層由與業(yè)務(wù)無關(guān)的組件組成，為微服務(wù)應(yīng)用提供必要的運行支撐。

（4）數(shù)據(jù)層部署的是各業(yè)務(wù)服務(wù)所需的數(shù)據(jù)庫實例，并且可以針對各業(yè)務(wù)的需求特性單獨配置數(shù)據(jù)復(fù)制和數(shù)據(jù)拆分等優(yōu)化策略。

2 微服務(wù)改造關(guān)鍵問題

微服務(wù)架構(gòu)相對于單體架構(gòu)而言更為復(fù)雜，以下針對微服務(wù)化改造中的若干關(guān)鍵問題和應(yīng)對措施進行闡述。

2.1 應(yīng)用配置統(tǒng)一管理

微服務(wù)架構(gòu)中應(yīng)用的數(shù)量比單體架構(gòu)要多出許多，各應(yīng)用配置均不相同，配置的維護和管理難度變大。為此引入配置中心，將應(yīng)用的配置信息統(tǒng)一存儲在配置中心內(nèi)。各應(yīng)用只要注冊并加入微服務(wù)體系中，即可根據(jù)自身的服務(wù)名稱獲取相應(yīng)的配置信息，有效減少了配置出錯的可能性。

圖2 微服務(wù)配置調(diào)用示意圖

如圖2所示，應(yīng)用通過注冊找到配置中心服務(wù)，讀取自己的配置信息并完成啟動流程，還可通過消息隊列監(jiān)聽配置信息的變化，完成配置的及時刷新。

2.2 日志監(jiān)控與鏈路追蹤

微服務(wù)架構(gòu)是分布式的，服務(wù)都被部署在不同的節(jié)點中，而用戶的一次操作可能涉及多個服務(wù)處理。對于研發(fā)人員而言，調(diào)試過程中如何通過日志檢查各服務(wù)的運行狀態(tài)，分析用戶一次操作請求的處理過程將變得極為困難[6]。通過建立ELK（Elastic Search, Logstash, Kibana）[7]實現(xiàn)日志的集中采集和快速搜索服務(wù)，并通過Zipkin實現(xiàn)服務(wù)調(diào)用鏈路的追蹤服務(wù)，可解決日志查詢和調(diào)用過程的追蹤問題。日志采集與鏈路追蹤系統(tǒng)部署結(jié)構(gòu)示意圖，如圖3所示。

圖3 日志采集與鏈路追蹤示意圖

服務(wù)在運行過程中的日志被Logstash采集組件搜集并通過Kafka消息隊列投送到Elastic Search集群中被索引以便快速檢索。服務(wù)之間的調(diào)用過程信息通過RabbitMq隊列投送至Zipkin鏈路追蹤服務(wù)中，Zipkin服務(wù)將信息保存至Elastic Search集群以供鏈路追蹤分析。

2.3 接入層服務(wù)安全性

與傳統(tǒng)的單體程序不同，微服務(wù)架構(gòu)下用戶使用的每一功能都有可能涉及多個服務(wù)。若將用戶身份認(rèn)證整合進每一個微服務(wù)應(yīng)用，會使得代碼出現(xiàn)大量冗余，增加代碼維護工作量。并且反復(fù)處理用戶認(rèn)證信息也是對計算資源的一種浪費。為解決上述問題，引入JWT（Json Web Tokens）[8]身份認(rèn)證機制，并將JWT的認(rèn)證與API網(wǎng)關(guān)相結(jié)合，JWT認(rèn)證流程如圖4所示。

圖4 JWT認(rèn)證機制示意圖

通過網(wǎng)關(guān)對用戶操作的統(tǒng)一攔截與處理，對于免驗證的接口請求直接放行，對于需要用戶身份認(rèn)證的接口請求，則解析并驗證JWT信息是否有效，若JWT信息有效，往下轉(zhuǎn)發(fā)用戶請求，同時將用戶信息附加在請求頭中；若JWT信息無效，則拒絕用戶的請求。通過網(wǎng)關(guān)控制和JWT認(rèn)證統(tǒng)一全平臺的用戶權(quán)限控制機制，實現(xiàn)單點登陸，減少代碼冗余。

2.4 服務(wù)調(diào)用規(guī)范

在微服務(wù)架構(gòu)內(nèi)，應(yīng)用之間通過HTTP方式進行交互[9]，相比于單體應(yīng)用體系，微服務(wù)體系服務(wù)之間的依賴更加復(fù)雜，若按照以往的開發(fā)方式常常出現(xiàn)由于缺乏接口文檔或者接口文檔更新不及時導(dǎo)致開發(fā)人員使用錯誤的方式調(diào)用服務(wù)接口的情況，研發(fā)人員不得不頻繁針對接口問題進行溝通和代碼調(diào)整，增加了開發(fā)和溝通成本。為避免以上問題，將服務(wù)接口定義體現(xiàn)在interface中，并將這些接口獨立建立為API項目。服務(wù)提供方按照interface[10]中的定義實現(xiàn)Controller，服務(wù)調(diào)用方在Http客戶端中繼承對應(yīng)的interface，從而保證了雙方通信接口定義的統(tǒng)一。部分項目代碼如下。

（1）在api項目中編寫接口約定interface

api項目中僅編寫interface代碼，約定接口的Http調(diào)用地址和參數(shù)等信息。

（2）在服務(wù)提供方的Controller中編寫接口實現(xiàn)

服務(wù)提供方中用于接收和處理請求的Controller必須實現(xiàn)api項目中的interface，以保證接口按照interface的約定提供服務(wù)。

（3）在服務(wù)調(diào)用方按照interface的約定進行調(diào)用

在調(diào)用方項目中，我們利用Spring Cloud組件中的Feign Client來進行Http調(diào)用。Feign Client通過繼承api項目中的interface即可按照interface約定的地址和參數(shù)進行調(diào)用。

綜上，通過公用interface代碼，保證了接口提供方和調(diào)用方對于某接口定義的一致性，從而避免了不必要的接口文檔編寫和溝通成本。

3 實施效果

改造后的鐵路站車Wi-Fi運營服務(wù)平臺充分利用了微服務(wù)架構(gòu)的優(yōu)勢，能夠快速響應(yīng)需求變化，穩(wěn)定運行的同時也可以實時監(jiān)控平臺各服務(wù)的運行狀態(tài)，應(yīng)用后的具體效果體現(xiàn)如下。

3.1 服務(wù)快速整合

平臺運行期間，在兩個月內(nèi)迅速地完成交易服務(wù)的研發(fā)，并通過整合原有的內(nèi)容管理與展示服務(wù)，成功上線小說收費閱讀的功能，實現(xiàn)對原有的小說閱讀功能的平滑升級。如圖5所示，通過服務(wù)整合，內(nèi)容、用戶、交易3大服務(wù)模塊共同支撐內(nèi)容管理平臺的運行。

圖5 服務(wù)整合實例圖

3.2 高效的研發(fā)調(diào)試工具

圖6展示了微服務(wù)平臺的全景調(diào)用關(guān)系圖、服務(wù)調(diào)用鏈時序圖、接口狀態(tài)監(jiān)測以及全局日志檢索功能。以上工具為研發(fā)人員快速調(diào)試、系統(tǒng)調(diào)優(yōu)提供了有力的支持。

圖6 研發(fā)調(diào)試工具實例圖

4 結(jié)束語

本文對微服務(wù)架構(gòu)進行了簡單介紹，闡述了鐵路站車Wi-Fi運營服務(wù)平臺的原架構(gòu)設(shè)計的不足之處，提出了基于Spring Cloud的微服務(wù)架構(gòu)設(shè)計與改造方案，列舉了實施架構(gòu)改造的關(guān)鍵問題，并舉例說明了微服務(wù)化改造后的實施效果。微服務(wù)架構(gòu)的引入，使平臺得以快速響應(yīng)需求的變化，同時通過服務(wù)的拆分和解耦降低了研發(fā)人員的研發(fā)難度，監(jiān)控工具的引入也降低了研發(fā)人員的運維成本。當(dāng)前架構(gòu)設(shè)計仍然存在不足，如對于Spring Cloud組件的依賴性強，不利于引入多樣化的開發(fā)語言等。