基于微服務(wù)架構(gòu)的鐵路企業(yè)年金信息系統(tǒng)研究與實現(xiàn)

王敬林 ，朱韋橋

（1.中國鐵道科學研究院 研究生部，北京 100081；2.北京經(jīng)緯信息技術(shù)有限公司，北京 100081；3.中國鐵道科學研究院集團有限公司 電子計算技術(shù)研究所，北京 100081）

鐵路企業(yè)面對著繁雜的企業(yè)年金經(jīng)辦業(yè)務(wù)、巨額的年金基金管理和嚴格的投資監(jiān)督等日常業(yè)務(wù)管理，傳統(tǒng)的手工方式或完全依托賬管人提供的信息系統(tǒng)進行管理，已無法滿足業(yè)務(wù)發(fā)展需要，部分企業(yè)已經(jīng)建設(shè)了相關(guān)企業(yè)年金信息系統(tǒng)，用于企業(yè)年金業(yè)務(wù)管理，由于設(shè)計理念和開發(fā)技術(shù)的限制，多采用單體架構(gòu)進行系統(tǒng)的構(gòu)建[1-2]，但在運行過程中暴露了一些問題：

（1）企業(yè)年金政策性強、時效要求嚴格，鐵路企業(yè)年金業(yè)務(wù)調(diào)整頻繁，具有涉及人員廣、業(yè)務(wù)操作復(fù)雜、專業(yè)性強等特點，年金系統(tǒng)需要根據(jù)業(yè)務(wù)規(guī)則的變化，進行及時迭代與更新，而傳統(tǒng)的單體架構(gòu)信息系統(tǒng)可維護性和可擴展性較差，面對微小的調(diào)整，整體系統(tǒng)都需要經(jīng)歷開發(fā)、測試、整體打包、停機、更新、部署、啟動等實施過程，無法適應(yīng)高頻率更新升級的業(yè)務(wù)要求。

（2）年金信息系統(tǒng)涉及成員單位多、業(yè)務(wù)規(guī)則多、對口機構(gòu)多且數(shù)據(jù)交互頻繁，導(dǎo)致子系統(tǒng)和功能模塊多，單體架構(gòu)信息系統(tǒng)局部子系統(tǒng)或功能模塊的故障，將導(dǎo)致整體系統(tǒng)崩潰，無法滿足系統(tǒng)的高可用性。

（3）隨著鐵路云計算的發(fā)展，鐵路企業(yè)已基本實現(xiàn)資源虛擬化、系統(tǒng)集群化的生產(chǎn)環(huán)境，單體架構(gòu)信息系統(tǒng)面臨運行瓶頸，同時，無法充分利用云計算可伸縮性、高擴展性的優(yōu)勢和特長[3]。

本文主要研究基于微服務(wù)架構(gòu)構(gòu)建的鐵路企業(yè)年金信息系統(tǒng)（簡稱：微服務(wù)年金系統(tǒng)），解決單體年金信息系統(tǒng)的諸多問題。

1 基于微服務(wù)架構(gòu)的系統(tǒng)設(shè)計

1.1 鐵路企業(yè)年金管理需求

鐵路企業(yè)一般采用理事會受托管理模式，即鐵路企業(yè)和職工作為委托人，委托企業(yè)年金理事會(受托人)管理企業(yè)年金基金。理事會下一般會設(shè)置專門經(jīng)辦機構(gòu)（理事會辦公室），負責企業(yè)年金理事會日常工作。由受托人選擇一家同時具有賬戶管理、托管資質(zhì)的機構(gòu)作為賬戶管理人和托管人，由受托人選擇若干家具有投資管理資質(zhì)的機構(gòu)作為投資管理人[2]，企業(yè)年金各管理機構(gòu)的職責分工與信息流傳輸如圖1所示。

圖1 企業(yè)年金管理機構(gòu)職責分工及信息流傳輸示意圖

鐵路企業(yè)年金業(yè)務(wù)整體可分為計劃層和成員層，其中，計劃層包括產(chǎn)生和存續(xù)2個階段，成員層包括產(chǎn)生、存續(xù)和終止3個階段。計劃層產(chǎn)生階段主要包含計劃建立相關(guān)流程；存續(xù)階段主要包含計劃監(jiān)督、基金運作、投資監(jiān)督和信息披露4部分。成員層產(chǎn)生階段主要包含單位及職工的計劃加入相關(guān)流程；存續(xù)階段主要包含單位及職工的信息變更和年金繳費2部分；終止階段主要包含計劃退出流程。需求結(jié)構(gòu)，如圖2所示。

圖2 鐵路企業(yè)年金管理總體需求結(jié)構(gòu)圖

1.2 微服務(wù)架構(gòu)簡述

微服務(wù)架構(gòu)是一系列小的、松耦合的分布式服務(wù)，這些服務(wù)圍繞業(yè)務(wù)能力劃分構(gòu)建，具有組件化、通信協(xié)議輕量化、服務(wù)集中化、數(shù)據(jù)分散化的優(yōu)點，能夠使用不同的編程語言、不同的存儲技術(shù)在云平臺下獨立部署[4-6]。

1.3 系統(tǒng)總體架構(gòu)

1.3.1 微服務(wù)拆分

領(lǐng)域驅(qū)動設(shè)計（DDD，Domain Driven Design）是一種以領(lǐng)域為核心的設(shè)計方法與理念。系統(tǒng)采用DDD理念，結(jié)合鐵路企業(yè)年金管理業(yè)務(wù)，將企業(yè)年金業(yè)務(wù)領(lǐng)域拆分為：（1）核心域：成員領(lǐng)域；（2）支撐子域：年金計劃子域，成員單位子域，繳費子域，支付子域等；（3）通用子域：消息子域，文件子域，流程子域，報表子域等。

使用場景走查的方法，確認領(lǐng)域模型滿足領(lǐng)域中的業(yè)務(wù)場景和業(yè)務(wù)流程，根據(jù)每一個子域?qū)?yīng)的邊界上下文完成服務(wù)的拆分。業(yè)務(wù)服務(wù)主要包括：年金計劃服務(wù)，成員單位服務(wù)，成員服務(wù)，年金繳費服務(wù)，年金支付服務(wù)等；公共服務(wù)包括：消息服務(wù)，文件服務(wù)，日志服務(wù)，流程服務(wù)等。

1.3.2 微服務(wù)年金系統(tǒng)總體架構(gòu)

系統(tǒng)總體架構(gòu)分為表現(xiàn)層、接口層、實體層、業(yè)務(wù)服務(wù)層、公共服務(wù)層、服務(wù)治理與監(jiān)督、資源層等7個部分，如圖3所示。

圖3 微服務(wù)年金系統(tǒng)總體架構(gòu)圖

（1）表現(xiàn)層：使用前后端分離技術(shù)，對后臺服務(wù)進行組合，完成與用戶的交互。本系統(tǒng)中的年金日常業(yè)務(wù)管理和年金投資監(jiān)督管理等頁面功能，可以在后臺服務(wù)接口確定的情況下進行前端的獨立開發(fā)。

（2）接口層：將實體層、業(yè)務(wù)服務(wù)層、公共服務(wù)所覆蓋的內(nèi)容進行聚合，按照客戶端的需求，為表現(xiàn)層提供符合展示要求的數(shù)據(jù)，封裝成接口服務(wù)。如成員單位接口、成員接口、年金繳費接口、待遇支付接口、成交管理接口、投資轉(zhuǎn)換接口等。接口提供在線數(shù)據(jù)交互和數(shù)據(jù)文件導(dǎo)入導(dǎo)出2種方式。

（3）實體層：微服務(wù)架構(gòu)下的實體同時為業(yè)務(wù)服務(wù)和公共服務(wù)提供支持，在接口需要的情況下也可以直接調(diào)用。系統(tǒng)中，所有的數(shù)據(jù)均將封裝為接口，方便對外提供統(tǒng)一的數(shù)據(jù)服務(wù)能力，包括計劃信息、成員單位信息、成員信息、繳費信息、支付信息模型等。

（4）業(yè)務(wù)服務(wù)層：結(jié)合企業(yè)年金的實際業(yè)務(wù)，將實體和公共服務(wù)進行封裝，為接口層提供支持。本層涵蓋本系統(tǒng)的主要業(yè)務(wù)，包括年金計劃服務(wù)、成員單位服務(wù)、成員服務(wù)、年金繳費服務(wù)、待遇支付信息服務(wù)等。

（5）公共服務(wù)：將微服務(wù)年金系統(tǒng)中多處用到的功能進行統(tǒng)一封裝，以便更好地為業(yè)務(wù)服務(wù)層提供支持，包括消息服務(wù)、文件服務(wù)、日志服務(wù)、流程服務(wù)、緩存服務(wù)等。

（6）服務(wù)監(jiān)督與治理：微服務(wù)架構(gòu)下，對服務(wù)的安全、監(jiān)控、預(yù)警十分重要。服務(wù)監(jiān)督與治理貫穿公共服務(wù)層、業(yè)務(wù)服務(wù)層和接口層，主要提供服務(wù)注冊、服務(wù)監(jiān)控、服務(wù)授權(quán)、日志分析、熔斷器等功能，實現(xiàn)對微服務(wù)的治理。

（7）資源層：主要是指系統(tǒng)操作的相關(guān)資源，包括數(shù)據(jù)庫資源及各類文件資源，如計劃信息庫、成員單位信息庫、成員信息庫、繳費信息庫、待遇支付信息庫，以及相關(guān)的各類附件信息庫（業(yè)務(wù)經(jīng)辦文件、指令等）。

2 系統(tǒng)關(guān)鍵技術(shù)實現(xiàn)

2.1 微服務(wù)架構(gòu)技術(shù)實現(xiàn)

Spring Cloud 是一系列框架有序集合，其標準化的、全站式的技術(shù)方案構(gòu)成了一個生態(tài)圈，涵蓋了眾多微服務(wù)架構(gòu)實現(xiàn)所需的核心組件，例如，服務(wù)網(wǎng)關(guān)、服務(wù)注冊發(fā)現(xiàn)、配置中心、認證授權(quán)、容錯限流、調(diào)用鏈監(jiān)控、日志監(jiān)控等[7-8]。本系統(tǒng)微服務(wù)架構(gòu)實現(xiàn)主要使用的組件如圖4所示。

圖4 微服務(wù)年金系統(tǒng)技術(shù)實現(xiàn)圖

（1）服務(wù)網(wǎng)關(guān)：客戶端請求通過統(tǒng)一的服務(wù)網(wǎng)關(guān)接入后端服務(wù)。網(wǎng)關(guān)使用Zuul、Ribbon和Eureka 3個組件，實現(xiàn)智能路由和負載均衡的功能。智能路由就是依據(jù)請求策略將請求網(wǎng)關(guān)轉(zhuǎn)發(fā)到認證授權(quán)服務(wù)，按照相應(yīng)的權(quán)限分發(fā)到相應(yīng)的服務(wù)實例，防止非法請求訪問后端服務(wù)，同時，Zuul為后期規(guī)劃的灰度測試創(chuàng)造了條件。

（2）服務(wù)注冊發(fā)現(xiàn)：Eureka是一個基于REST的服務(wù)注冊中心。在微服務(wù)架構(gòu)中，服務(wù)需要集中化管理，因此，基礎(chǔ)服務(wù)、公共服務(wù)和通用服務(wù)需要通過服務(wù)治理實現(xiàn)自動化注冊和發(fā)現(xiàn)。服務(wù)注冊中心是網(wǎng)關(guān)服務(wù)路由信息存儲倉庫，也是服務(wù)之間進行交互的媒介，發(fā)揮著服務(wù)注冊和發(fā)現(xiàn)的作用。Eureka支持服務(wù)續(xù)約和服務(wù)下線，方便用戶定位服務(wù)問題以及提供中間層服務(wù)器的故障轉(zhuǎn)移。

（3）配置中心：Spring Cloud Config結(jié)合Git實現(xiàn)配置中心的搭建和配置信息的統(tǒng)一管理。配置服務(wù)通過注冊中心注冊到Eureka Server，企業(yè)年金服務(wù)可以通過注冊中心發(fā)現(xiàn)配置服務(wù)，企業(yè)年金服務(wù)從而獲取所需要的配置信息。

（4）認證授權(quán)：Spring Security、OAuth2和JWT實現(xiàn)微服務(wù)年金系統(tǒng)的認證授權(quán)?？蛻舳苏埱笸ㄟ^網(wǎng)關(guān)路由到認證鑒權(quán)服務(wù)，獲取用戶登錄信息和權(quán)限信息，客戶端攜帶Token支持跨程序調(diào)用。微服務(wù)年金系統(tǒng)存在異構(gòu)系統(tǒng)，利用JWT實現(xiàn)單點登錄。

（5）容錯限流：Hystrix實現(xiàn)微服務(wù)架構(gòu)的服務(wù)可靠性，Hystrix服務(wù)延遲和容錯庫可用來隔離服務(wù)故障，確保系統(tǒng)穩(wěn)健運行。各個服務(wù)獨立部署，且服務(wù)與服務(wù)之間存在相互依賴關(guān)系，因此，服務(wù)訪問失敗的原因和場景非常復(fù)雜，容錯限流服務(wù)可以實現(xiàn)服務(wù)隔離、服務(wù)降級和服務(wù)熔斷，從而阻止聯(lián)動故障的發(fā)生。

（6）調(diào)用鏈監(jiān)控：Spring Cloud Sleuth結(jié)合Zipkin構(gòu)建微服務(wù)的調(diào)用鏈監(jiān)控，客戶端每一個請求在調(diào)用過程需要多個服務(wù)，每個服務(wù)獨立部署在不同物理機器和不同數(shù)據(jù)存儲之間，調(diào)用鏈監(jiān)控可以跟蹤一個或多個事務(wù)，然后，拼接出服務(wù)運行的全鏈路。通過Zipkin可以查看跨多個事務(wù)的事務(wù)流。

（7）日志監(jiān)控：日志監(jiān)控通過ELK（Elastic Search、Logstash、Kibana）和Kafka實現(xiàn)日志收集與監(jiān)控，分布在不同服務(wù)器的日志收集組件，通過消息中間件Kafka傳遞給Logstash，進行過濾分析后將數(shù)據(jù)存儲在Elastic Search，通過Kibana查看所有的日志數(shù)據(jù)。

2.2 前端實現(xiàn)

微服務(wù)年金系統(tǒng)采用前后端分離，前端使用Angular和Typescript開發(fā)，實現(xiàn)MVC劃分和通道、路由等設(shè)計。前端應(yīng)用部署在Nginx組合的服務(wù)器上，通過反向代理轉(zhuǎn)發(fā)頁面請求到后端服務(wù)器，同時Nginx實現(xiàn)前端的負載均衡[9]。

應(yīng)用整體界面采用完全的響應(yīng)式編程，使得數(shù)據(jù)驅(qū)動、局部刷新容易實現(xiàn)；采用Bootstrap兼容可擴展框架，通過頁面柵格自適應(yīng)各種分辨率的顯示器，實現(xiàn)更好的用戶體驗。

2.3 認證授權(quán)實現(xiàn)

通常，微服務(wù)架構(gòu)的認證授權(quán)采用Spring Security、OAuth2和JWT的組合，該認證授權(quán)框架雖然具有一次獲取Token可以多次使用的優(yōu)勢，即不需要每次都到認證授權(quán)服務(wù)去獲取用戶信息和權(quán)限信息，但是，如果用戶權(quán)限發(fā)生改變，Token存儲的信息不能及時變更，就會造成業(yè)務(wù)的漏洞，微服務(wù)年金系統(tǒng)通過引入緩存數(shù)據(jù)庫（Redis）技術(shù)，用于存儲Token信息，當用戶權(quán)限更改時，將會自動刪除存在Redis的Token，請求再次經(jīng)過網(wǎng)關(guān)時，驗證Token不存在，提示用戶重新登錄。

微服務(wù)年金系統(tǒng)授權(quán)認證過程，如圖5所示。

（1）客戶端發(fā)送請求到服務(wù)網(wǎng)關(guān)后，網(wǎng)關(guān)會根據(jù)請求路徑過濾請求[9]。如果該路徑是登錄并獲取Token操作的路徑則直接放行，請求直接到達認證授權(quán)服務(wù)進行登錄操作；

（2）進行JWT私鑰加密，生成Token存儲到Redis；

（3）返回給客戶端。如果是其他請求，將會到Redis驗證Token是否存在，若不存在，則返回客戶端重新登錄；若Token存在，則進行Token私鑰解密校驗：如果token被篡改或者失效，則直接拒絕訪問并返回錯誤信息；如果驗證成功，經(jīng)過路由到達請求的年金業(yè)務(wù)服務(wù)，請求服務(wù)響應(yīng)并返回數(shù)據(jù)。

圖5 微服務(wù)年金系統(tǒng)授權(quán)認證過程圖

2.4 數(shù)據(jù)存儲實現(xiàn)

微服務(wù)年金系統(tǒng)將數(shù)據(jù)和服務(wù)分開，保證服務(wù)的獨立性。由于鐵路企業(yè)數(shù)據(jù)要求集中管理，數(shù)據(jù)存儲采用集中式的數(shù)據(jù)管理方式再實現(xiàn)數(shù)據(jù)的獨立性[10-11]。系統(tǒng)針對每個業(yè)務(wù)服務(wù)劃分專門的獨立空間，從邏輯上與其他服務(wù)相隔離，如圖6所示?？缙髽I(yè)年金業(yè)務(wù)的數(shù)據(jù)存儲依據(jù)BASE思想，即基本可用（Basically Available）、軟狀態(tài)（Soft state）和最終一致性（Eventually consistent）的TCC模式實現(xiàn)分布式事務(wù)。

圖6 微服務(wù)年金系統(tǒng)數(shù)據(jù)存儲實現(xiàn)圖

3 應(yīng)用效果

微服務(wù)年金系統(tǒng)已上線運行，應(yīng)用效果顯著。系統(tǒng)實現(xiàn)了鐵路企業(yè)內(nèi)部成員、年金資金、年金業(yè)務(wù)規(guī)則等基礎(chǔ)數(shù)據(jù)統(tǒng)一管理，與相關(guān)系統(tǒng)數(shù)據(jù)交換和信息共享，信息流、資金流全程監(jiān)控，為年金基金管理和投資監(jiān)督提供了保障。企業(yè)年金政策調(diào)整、業(yè)務(wù)管理變化后，利用微服務(wù)架構(gòu)的優(yōu)勢，系統(tǒng)具有橫向擴展、快速更新升級的能力，為企業(yè)年金日常經(jīng)辦提供了時效保證，提高了用戶體驗。通過微服務(wù)架構(gòu)改造的系統(tǒng)業(yè)務(wù)相對獨立，服務(wù)集群部署，日志監(jiān)控全面，運維定位迅速，為系統(tǒng)的高可用提供了技術(shù)支撐。

4 結(jié)束語

本文分析使用單體架構(gòu)進行鐵路企業(yè)年金系統(tǒng)構(gòu)建的問題，介紹了微服務(wù)架構(gòu)的概念和關(guān)鍵特性，并將微服務(wù)架構(gòu)的理念引入到鐵路企業(yè)年金信息化建設(shè)的系統(tǒng)設(shè)計中，實現(xiàn)了鐵路企業(yè)年金業(yè)務(wù)流程貫通及全過程信息化管理，提高了系統(tǒng)的負載能力、可擴展性和獨立性。

該系統(tǒng)需要進一步研究的內(nèi)容有：

（1）雖然按照領(lǐng)域驅(qū)動設(shè)計進行了服務(wù)拆分，但是，隨著日常業(yè)務(wù)的開展，服務(wù)拆分策略的合理性依然值得探討，后續(xù)繼續(xù)研究鐵路企業(yè)年金業(yè)務(wù)特點，優(yōu)化服務(wù)拆分；

（2）微服務(wù)年金系統(tǒng)服務(wù)可靠性的設(shè)計仍不夠全面，服務(wù)訪問的雪崩效應(yīng)、服務(wù)失敗應(yīng)對策略、服務(wù)容錯、服務(wù)隔離、服務(wù)限流、服務(wù)降級等問題沒有完全解決，需要繼續(xù)研究服務(wù)可靠性方案，進一步完善方案。