保險行業核心業務系統中應用微服務架構的方法

摘要：文章首先以微服務架構概述及原理為出發點，分析了微服務架構的關鍵技術、微服務的拆分與重構策略，提出微服務架構應當考慮的問題，最后主要介紹了微服務架構在保險行業核心業務系統中的應用方法，以供保險行業應用微服務架構的參考和借鑒。

關鍵詞：保險行業;核心業務系統;微服務架構;應用方法

一、引言

隨著互聯網技術和5G技術的不斷發展，保險客戶對于互聯網的訪問質量和效率提出了更高的要求，基于傳統單體架構設計理念的應用模式已無法適應當前保險“互聯網+”的高速發展需要。在保險產品快速更新迭代、保險客戶差異化和個性化需求、金融科技全面發展的背景下，保險行業針對核心業務系統提出了高并發、大流量、高業務連續性及快速迭代交付的要求，傳統單體式架構向著分布式的微服務架構已成為解決核心業務系統問題的首選途徑。

二、微服務架構概述及原理

（一）微服務架構概述

微服務架構是指將復雜的單體應用拆分成為多個子服務系統的技術架構，使用輕量的通信機制，實現不同子服務系統之間的相互通信、協調和交互。各子系統的應用、數據庫均獨立部署，根據業務及服務需要而進行通信及調用，各個子系統既保持相對獨立又相互配合。在通常情況下，每一個子系統僅代表一個獨立微小的業務模塊，通過借助全自動部署流水線機制實現快速獨立部署。

（二）微服務架構的工作原理

微服務架構是將整個系統劃分成多個子服務系統，使用分布服務的治理方式將微服務子系統注冊于服務注冊中心，通過負載均衡將各個子服務系統部署在生產環境中，通過路由器完成轉發請求，客戶端通過API網關進行后臺訪問。各個子服務系統之間可以根據業務需要進行相互訪問和數據共享，并使用服務熔斷技術，處理子服務系統的降級及熔斷問題，對異常服務進行及時的降級及熔斷處理，避免整個核心業務系統服務鏈路出現服務雪崩。

三、微服務架構的關鍵技術

（一）微服務注冊與發現

微服務注冊指的是將服務程序中的服務信息注冊至服務注冊中心，服務信息主要包括為服務程序所在的服務器地址、端口、協議以及服務狀態等。不同的實例都需要通過注冊中心獲得服務，當系統發現在注冊中心可以得到其他服務實例并請求提供對應的服務時，對于保險核心業務系統而言，可以將承保、理賠和保單查詢等的微服務程序注冊到服務中心，實現保險業務微服務功能的靈活調用，并使微服務處于高可用狀態。

服務注冊中心具有心跳檢測、健康檢查、異常處置等功能，如果未能檢測到節點在多個心跳周期內的心跳，服務注冊中心便會主動將其從服務節點中清除，以保證整個微服務系統調用鏈路的可靠性。微服務架構的注冊與發現對于保險行業來說是一次技術上的創新，可以實現靈活的包括服務注冊、服務發現及服務剔除等服務治理功能。

（二）微服務網關

微服務網關是一種特殊的服務，用于客戶端進入微服務程序的統一入口管理，負責路由請求服務、組合API服務、轉換對接協議，一般位于外部Nginx集群和內部微服務集群之間，并不直接對客戶端提供服務。在微服務架構模式中，微服務網關通過服務方式，將自己注冊到服務注冊中心，并通過負載均衡將服務請求轉發至各服務節點。

在保險行業核心業務系統中，運用微服務網關統一管理，對保險客戶及管理人員的身份認證和安全性可以通過網關識別和控制;將不同服務請求動態路由至微服務集群，保證了各個服務器之間的調用性能，并對請求進行攔截和必要的業務邏輯處理;構建動態響應處理機制，在邊緣位置處實現響應，降低和減少其轉發至內部集群，進行接口聚合，將不同的請求結果進行合并返回，大幅降低了服務調用的復雜性;可以有效解決微服務應用過程中的權限、路由、API組合、請求過濾等問題。

（三）服務通信機制

在微服務架構設計模式中，完整的應用系統由一組服務構成，為完成業務請求的完整流程處理，就需要這些服務之間進行必要的請求協助和數據交互才能實現。而這些服務實例大都獨立部署在相互獨立的服務器中，需要進行程序進程之間的通信才能完成交互。

根據交互方式的不同，微服務中存在同步與異步兩種通信方式，其中同步通信方式使用請求與響應的方式實現一對一交互，異步通信方式使用異步請求與異步相應或單向通知的方式實現一對一交互、使用發布與訂閱或發布與異步響應的方式實現一對多交互。同步通信的交互方式通常使用代理接口用于對通信協議進行封裝，常用的有REST或gRPC。異步通信的交互方式多使用消息代理，較為流行的消息代理有Apache ActiveMQ、Apache Kafka及RabbitMQ等開源軟件。

（四）微服務運維

傳統的單體架構屬于單塊應用結構，而微服務架構是一種多服務和多應用的結構。對比單體架構模式，微服務架構由于其運行節點多、部署方式多樣化，問題點往往會出現在不同的地方，加之服務產生的日志較多，因此需要在大量的日志中找到問題的所在就會變得異常困難，需要借助完善的日志管理和服務運行狀況監控，從硬件層面、系統層面以及服務訪問層面實現切入式的全鏈路管理。在保險行業核心業務系統中應用微服務架構，可以利用聚合監控組件保證監控的正常運行，對微服務架構技術平臺實現全方位、全鏈路的監控，通過設置合理的熔斷和降級調控開關，實現必要的服務降級控制和服務限流控制，自動化地調整具體的應用運行狀態。

四、微服務的拆分與重構策略

（一）微服務拆分原則

微服務架構的核心理念是對應用系統拆分為高內聚、低耦合的一組服務，進行獨立部署，實現獨立運行，并通過服務間通信進行交互。為實現微服務架構設計的最佳實踐，保險行業在進行微服務拆分時，可以從營銷管理、承保服務、理賠管理、客戶服務、再保管理及風控管理等業務能力維度入手，分析保險公司運營管理流程、抽象出保險業務能力、根據業務能力映射并定義出服務;也可以從保險業務領域的客戶投保、保單批改、報案、查勘、定損及兩核等子域入手，分析保險公司運營管理各領域、抽象出保險業務子域定義出服務。在定義和實現服務的過程中，一般以服務所承擔的業務職能盡量單一并能在一個服務中完整實現為原則，以達到良好的可維護、高容錯及易部署要求。

（二）微服務重構策略

因保險行業信息化發展的歷史原因，保險行業核心業務系統大多采用傳統的單體架構，存在產品交付慢、軟件擴展性差及版本交付質量低等問題，技術債務較大，設計全新的基于微服務架構的核心業務系統快速替代現有系統的成本較高，可以采用逐步替換的策略進行微服務重構，將新需求所延伸出來的業務能力按照微服務模式進行設計，以微服務開發新功能，并與原單體架構應用進行集成，以實現業務需求的快速交付;劃分原單體架構應用的前后端邊界，進行必要的拆分并隔離，逐步縮小其應用范圍，并實現前后端的獨立開發、部署和維護管理;主動對原單體架構應用的業務能力進行抽象和提取，按照微服務架構模式進行重新定義和實現，隨著服務的不斷被提取，微服務的業務功能不斷擴展，原單體架構將不斷縮小，直至下線。

五、應用微服務架構時需要面臨的問題

（一）運行的可靠性

微服務架構采用靈活、復雜的通信機制，如果網絡出現問題或者是某一個服務節點出現故障，就會導致服務調用失敗，當需要服務的對象和數量越來越多時，故障點也會在這樣的背景之下快速增加，為了保證系統的穩定、安全和可靠運行，需要一個健全與完善的保障機制為支撐。

（二）運維的復雜性

微服務架構的技術棧較為豐富、多采用分布式部署、服務節點多、服務之間調用和交互關系復雜，為實現快速交付的目的，應用自動化的持續交付/持續部署，使得整體部署和運行環境十分復雜，對運維的要求較高，需要建設全域環境的自動化管理體系，實現對微服務的實時監控、服務異常的自動處置、服務資源的彈性擴展，以提高微服務系統的高可用性、業務連續性和安全性。

（三）分布式事務的一致性

隨著微服務架構的流行與普及，過去需要在單體應用中執行的多個邏輯操作現已被拆分成了多個服務之間的遠程調用，各子服務一般擁有獨立數據庫，這將帶來分布式事務的一致性的問題。對習慣于傳統單體架構ACID事務的開發團隊而言，將會面臨很大的障礙。

六、微服務架構在保險核心業務業務系統中的應用

保險行業屬于金融嚴監管行業，信息化建設起步較早、力度大，保險公司大多基于傳統單體機構構建了支撐業務作業管理的核心業務系統。但隨著保險行業“互聯網+”的高速發展，對核心業務系統提出了高并發、大流量、高業務連續性及快速迭代交付的要求。現有核心業務系統的諸多問題逐步暴露，比如新產品開發上線慢、互聯網保險支撐能力弱、保險客戶體驗度低;而微服務架構天然具有業務整合能力強、產品交付速度快和用戶體驗度高的架構能力，具有高并發、高可用和彈性擴展等特點，可以有效解決保險核心業務系統所面臨突出問題。

（一）微服務框架的技術選型

技術選型從當前核心業務系統既有業務流程管理模式和技術棧入手，充分考慮核心業務的復雜程度、核心開發團隊能力、微服務技術積累以及技術棧轉換和遷移過程中的兼容性。目前微服務主流技術框架有第一代的Spring Cloud及Dubbo、第二代的有Istio，框架情況對比。微服務架構的選擇必要要與保險公司的業務、技術及團隊情況相匹配，找準合適切入點，選擇合適的開發框架;因筆者所在公司以Spring/Spring Boot框架為主，選擇基于Spring Cloud的微服務框架進行系統重構較為適宜。

（二）核心業務系統的重構與實踐

圍繞Spring Cloud微服務架構，對核心業務系統按照業務服務職責、業務活動域綜合分析，進行適應保險行業運營管理的核心業務系統微服務拆分，規劃出產品服務、定價服務、營銷服務、費控服務、承保服務、批改/保全服務、保險理賠、收付費、客戶管理及智能風控等子系統，使其對保險業務的支撐更加便捷、可靠和彈性。應用架構如圖2所示。

采用基于Spring Cloud微服務架構作為保險核心業務系統的基礎技術平臺，落地實施保險核心業務系統的應用總體架構，將服務治理、配置管理、日志管理、CI/CD、全鏈路監控等開源組件整合起來，將敏捷開發與持續交付融合起來，全面嵌入自動化運維當中。

采用新業務功能以服務方式實現、變更運行環境部署方式及存量業務功能轉換為服務方式的多維度、綜合的重構策略，按照統一規劃的核心業務系統應用架構和技術架構，在限制原核心業務系統單機架構持續擴展的基礎上，逐步以微服務模式進行持續的迭代更新，結合敏捷開發和DevOps實踐，以實現核心業務需求的快速交付和循環迭代改進，最終實現核心業務系統微服務架構整體改造，推動其業務平臺和技術架構的持續更新升級。

七、結束語

綜上所述，在保險行業核心業務系統中的應用微服務架構，對已有系統進行重構、整合和升級，可以有效提高保險產品和業務功能的迭代升級速度，適應高并發、大流量及高業務連續性的要求，但也面臨著系統安全性、穩定性及數據一致性等方面的高要求。基于當前保險科技快速發展的利好背景下，各項新技術不斷出現并快速應用于保險科技當中，如何讓微服務架構更好地應用于核心業務系統的迭代建設中，是一個需要持續研究和探討的問題。

作者單位：侯守立? ? 浙商財產保險股份有限公司

參? 考? 文? 獻

[1]王方旭.基于Spring Cloud實現業務系統微服務化的設計與實現[J].電子技術與軟件工程，2018（08）：60-61.

[2]辛園園，鈕俊，謝志軍，張開樂，毛昕怡.微服務體系結構實現框架綜述[J].計算機工程與應用，2018，54（19）：10-17.

[3]克里斯·理查森（Chris Richardson）.微服務架構設計模式[M].喻勇譯.北京：機械工業出版社，2019.

[4]王麗沙. 基于微服務架構的保險核心系統改造[D].上海交通大學，2020.