基于微服務架構的鐵路企業年金信息系統研究與實現

王敬林 ，朱韋橋

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

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

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

（2）年金信息系統涉及成員單位多、業務規則多、對口機構多且數據交互頻繁，導致子系統和功能模塊多，單體架構信息系統局部子系統或功能模塊的故障，將導致整體系統崩潰，無法滿足系統的高可用性。

（3）隨著鐵路云計算的發展，鐵路企業已基本實現資源虛擬化、系統集群化的生產環境，單體架構信息系統面臨運行瓶頸，同時，無法充分利用云計算可伸縮性、高擴展性的優勢和特長[3]。

本文主要研究基于微服務架構構建的鐵路企業年金信息系統（簡稱：微服務年金系統），解決單體年金信息系統的諸多問題。

1 基于微服務架構的系統設計

1.1 鐵路企業年金管理需求

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

圖1 企業年金管理機構職責分工及信息流傳輸示意圖

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

圖2 鐵路企業年金管理總體需求結構圖

1.2 微服務架構簡述

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

1.3 系統總體架構

1.3.1 微服務拆分

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

使用場景走查的方法，確認領域模型滿足領域中的業務場景和業務流程，根據每一個子域對應的邊界上下文完成服務的拆分。業務服務主要包括：年金計劃服務，成員單位服務，成員服務，年金繳費服務，年金支付服務等；公共服務包括：消息服務，文件服務，日志服務，流程服務等。

1.3.2 微服務年金系統總體架構

系統總體架構分為表現層、接口層、實體層、業務服務層、公共服務層、服務治理與監督、資源層等7個部分，如圖3所示。

圖3 微服務年金系統總體架構圖

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

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

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

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

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

（6）服務監督與治理：微服務架構下，對服務的安全、監控、預警十分重要。服務監督與治理貫穿公共服務層、業務服務層和接口層，主要提供服務注冊、服務監控、服務授權、日志分析、熔斷器等功能，實現對微服務的治理。

（7）資源層：主要是指系統操作的相關資源，包括數據庫資源及各類文件資源，如計劃信息庫、成員單位信息庫、成員信息庫、繳費信息庫、待遇支付信息庫，以及相關的各類附件信息庫（業務經辦文件、指令等）。

2 系統關鍵技術實現

2.1 微服務架構技術實現

Spring Cloud 是一系列框架有序集合，其標準化的、全站式的技術方案構成了一個生態圈，涵蓋了眾多微服務架構實現所需的核心組件，例如，服務網關、服務注冊發現、配置中心、認證授權、容錯限流、調用鏈監控、日志監控等[7-8]。本系統微服務架構實現主要使用的組件如圖4所示。

圖4 微服務年金系統技術實現圖

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

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

（3）配置中心：Spring Cloud Config結合Git實現配置中心的搭建和配置信息的統一管理。配置服務通過注冊中心注冊到Eureka Server，企業年金服務可以通過注冊中心發現配置服務，企業年金服務從而獲取所需要的配置信息。

（4）認證授權：Spring Security、OAuth2和JWT實現微服務年金系統的認證授權。客戶端請求通過網關路由到認證鑒權服務，獲取用戶登錄信息和權限信息，客戶端攜帶Token支持跨程序調用。微服務年金系統存在異構系統，利用JWT實現單點登錄。

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

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

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

2.2 前端實現

微服務年金系統采用前后端分離，前端使用Angular和Typescript開發，實現MVC劃分和通道、路由等設計。前端應用部署在Nginx組合的服務器上，通過反向代理轉發頁面請求到后端服務器，同時Nginx實現前端的負載均衡[9]。

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

2.3 認證授權實現

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

微服務年金系統授權認證過程，如圖5所示。

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

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

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

圖5 微服務年金系統授權認證過程圖

2.4 數據存儲實現

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

圖6 微服務年金系統數據存儲實現圖

3 應用效果

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

4 結束語

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

該系統需要進一步研究的內容有：

（1）雖然按照領域驅動設計進行了服務拆分，但是，隨著日常業務的開展，服務拆分策略的合理性依然值得探討，后續繼續研究鐵路企業年金業務特點，優化服務拆分；

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