微服務架構應用于保險行業核心業務系統的探討

朱俊

【摘要】 ? ?隨著信息技術的不斷發展，傳統的單體開發架構已難以適應保險行業險種產品在核心業務系統中快速迭代上線的業務需求.微服務架構是一種將一個單體應用程序開發拆分為一系列小型服務程序開發的架構，每個服務獨立運行在各自的進程中，服務間通信采用了相對較為輕量級的通信規則并且強調服務組件化，同時支持在云中部署各類應用和服務，增強了系統的伸縮性和負載性能，系統維保人員可快速響應險種產品的開發需求，有效的縮短交付周期，并可結合微服務架構中的持續集成和持續部署工具，實現險種產品的快速上線。但該架構在系統效率、維護以及成本方面也帶來了一些新的挑戰。本文以微服務框架為基礎，以險企核心業務系統的建設為背景，探討架構應用于系統帶來的創新與問題。

【關鍵詞】 ? ?微服務架構 ? ?保險行業 ? ?核心業務系統 ? ?Spring Cloud

引言

隨著人們生活水平的不斷提高、對風險意識的不斷增強以及對自身風險保障意識的逐漸重視，帶動了各險企險種產品的不斷發展及更新。而險種業務的正常開展，除險種產品自身的特點外，核心業務系統的穩定運行及能否快速地上線險種產品起著至關重要的作用。從核心業務系統的研發和技術建設層面進行分析，傳統的單體架構（包含所有功能的應用程序，可以是JAR、WAR、EAR或其它歸檔格式包）在業務需求功能實現上呈現出一些弊端，例如復雜性高、擴展能力差、阻礙技術創新等。同時隨著業務的發展、技術的更新、計算機硬件性能的不斷提升，行業對核心業務系統的實現方式和數據服務質量上有了全新的要求，而原有的系統設計架構已不能完全滿足業務發展的需要，這就迫使行業在系統建設上需要提供一套新的軟件架構，能夠解決傳統單體架構無法解決的一些問題，例如擴展性、移植性、維護性、效率性等。

微服務架構的系統開發是將單體應用拆分成為一系列小型服務程序的過程，服務程序間可獨立部署、可控制實現的復雜度、可采用不同的技術路線且擴展方便，每個服務只需關注一個具體業務功能的實現，例如核心系統中的保單查詢微服務、理賠立案微服務等，過程實現相對簡單。由于實現可采用不同的技術路線，每個微服務可由不同的技術團隊進行獨立開發部署。微服務是獨立運行的，它區別與傳統的單體架構有兩大較為明顯的優勢：擴展性和隔離性。每個微服務程序可根據需求獨立擴展，當系統需要頻繁發布不同程序時，保證了其他系統功能模塊的可用性，是系統持續交付的基礎，是核心業務系統的不間斷運行強有力的保障。擴展性允許我們快速地添加集群服務，提升系統綜合服務能力，而傳統的單體架構如需滿足這些，往往需要在軟件及硬件上進行重新架構。隔離性將微服務程序分隔為一個個獨立運行的單元，系統運行時，某一單元自身的崩潰或失敗往往只影響自己或部分其他微服務程序，但不會造成系統整體的崩潰，在系統運維人員根據服務定位和解決問題的過程中，保證了系統其他功能的正常使用，有效的解決了系統“一崩全崩”的情況，大大地增加了系統的可用性及可靠性。

圖1 ? ?單體架構結構圖

圖2 ? ?微服務架構結構圖

一、架構創新

微服務架構的創新可從框架提供的部分組件上進行分析。微服務架構的開發框架很多，例如Dubbo、Motan等，而Spring Cloud是目前使用較多，資源相對豐富的開發框架之一，本文將以Spring Cloud框架應用于核心業務系統進行架構創新上的探討。Spring Cloud是采用Spring Boot技術實現的云應用開發框架，Spring boot專注于快速、方便地集成個體應用服務，而Spring Cloud則是關注全局的服務治理框架。它將復雜的配置進行屏蔽，提供了一套易于部署和維護的組件工具包，例如Eureka（服務發現）、Zuul（服務網關）等，并可快速對接云平臺資源。下圖3為核心業務系統基于Spring Cloud框架的技術實現。

1.1服務注冊與發現

以SpringClound中的Eureka注冊中心為例，服務注冊即微服務程序將服務信息注冊至Eureka中心，服務信息主要包括微服務程序所在服務器主機的IP地址、服務端口號、訪問協議及服務狀態等，各個實例通過注冊中心獲取依賴服務，該方式與單體架構中通過IP地址訪問服務的方式有很大的區別。服務發現即實例在注冊中心中可得到其他服務實例并請求提供對應的服務。對于核心業務系統而言，我們可將承保、理賠、再保等微服務程序注冊至服務注冊中心，為保證各個微服務程序（功能模塊）具備高可用性及靈活性，注冊中心自帶的心跳檢測、健康監控排查等技術為其實現提供了技術保障。在整個注冊中心中，由于微服務程序自身的一些問題，服務狀態都是動態變化的，如何處理一些無效的微服務實例是需要思考的問題，而在Eureka中，實例與其通過心跳的方式保持聯系，一旦發現心跳缺失，Eureka會主動將其從現有環境進行刪除，保障了整個注冊中心所有服務的可用性。這種服務注冊與發現的軟件架構設計模式是信息技術上的一次革新，它解決了諸如服務接口IP地址發生變化而導致其他應用無法調用等一系列原本需要花較大代價才能解決的問題。

1.2服務網關

服務網關的作用在微服務架構中主要體現在實現動態路由，監控，彈性以及安全性。它可以幫助我們實現以下一些功能：（1）網關的核心之一是過濾器，身份認證與安全可通過過濾器進行識別，同時可拒絕所有不滿足的請求。（2）監控和審查邊緣有意義的數據并對其進行跟蹤和統計，從而形成各類精確的視圖。（3）將各類服務請求動態的路由至微服務集群，保障了服務間的調用性能。（4）分配相應容量至各種類型的請求，當超出容量限制時，自動限制其請求。（5）建立靜態響應處理機制，在邊緣位置處直接生成部分響應，避免其轉發至內部集群。而應用于系統的架構中，其一網關可以用來做接口聚合，可將多個請求結果進行合并并將其返回，這樣外部只需要調用指定的接口就可以得到業務數據，大大降低了程序調用間的復雜性。其二通過網關可以標識當前訪問者的身份和部分權限，較為合理的解耦大部分重復代碼，而且系統中如果存在具體復雜的權限需求可以在應用中再次通過身份標識來獲取權限。在Spring Cloud框架中，一般采用Zuul組件來實現服務網關，將Zuul作為從設備及UI到系統服務后端所有請求的前門。

1.3服務監控與保護

單體架構屬于單塊應用的結構，而微服務是多服務多應用的結構。在單體架構中，要掌握單塊應用的運行情況，因其只會發生單一的故障點，要追蹤問題的發生和修訂問題相對來說比較容易和解決。而在微服務的結構中，由于其運行個體多、部署方式多樣，問題點往往會出現在不同的地方，而且服務產生的日志非常多，因此要從大量且相互隔離的日志中找到問題所在就會變得非常困難，對于多服務的監控，獲取服務的狀態相對更加復雜。系統微服務之間一般通過REST API的方式進行相互調用，為了快速定位系統的問題所在，服務監控顯得尤為重要，一般來說可以從硬件層面、網絡層面、系統層面、應用層面、服務訪問層面進行監控，從這些層面采集相應的狀態數據，然后進行匯總、存儲、并分析，一旦某項指標超出規定的閾值，則通過監控進行報警，在接收到報警通知之后做出及時應對以改變目前系統狀態不健康的局面。架構中一般可以通過預置的調控開關來調整應用的狀態，要么重啟服務或者進行服務降級。例如在Spring Cloud微服務架構中，可采用Hystrix Turbine聚合監控等監控組件來達到監控服務正常運行的目的。另外，如果要對Spring Cloud中的微服務進行完備的監控，架構可以從內部以“白盒”的形式進行監控，也可以以外部服務訪問者的視角來對微服務進行模擬訪問（即“黑盒”的形式），從而內外兼修地構建一套針對微服務的應用監控體系，達到保護系統正常運行的目的。

二、架構面臨的問題

隨著領域驅動設計、持續交付、按需虛擬化、基礎設施自動化、小型團隊自治化、大型系統集群化等實踐流行的背景下，微服務架構在軟件架構設計中帶來了一些傳統單體架構無法實現的新技術，引領軟件開發行業技術的新方向。但微服務架構在解決了該解決問題的同時，又帶來了新的一些技術問題，例如服務間通信變得比單體架構復雜，系統運維的成本大幅提升，服務“微”化之后，服務的數量大大增加了。微服務程序間的操作一般是以API的方式進行相互間的調用，該方式在數據的傳輸時長和訪問時間上相對單體架構要增加不少，而且調用方式更加復雜，對結構之間的調用效率存在不少問題，如何解決采用該架構帶來的問題是在系統架構選型時需要慎重考慮的。目前，微服務架構需要關注的問題主要圍繞以下幾個方面：（1）微服務運行的可靠性：微服務間采用了遠程調用的機制，如遇到網絡問題或者其中的一個服務節點出現故障，會導致服務間調用失敗，當微服務數量越來越多時，故障點也隨之增加，為使系統穩定運行，就需要有一個較為充分的保障機制，否則，系統的可靠性就無法保證。（2）分布式的復雜性：微服務支持分布式部署，各服務間的調用存在網絡延遲等問題，這些問題對系統部分功能來說往往是致命的，是需要提供解決方案的。（3）架構運維成本高：微服務架構是一個全新的架構，需要技術人員具備較高的知識儲備，需深入了解微服務中注冊與發現、網關、監控、負載均衡、自動化集成部署等一系列技術，提高了系統運維的成本。（4）性能方面的考慮：由于服務間采用了跨網絡、基于進程的調用方式，性能部分依賴外部條件，例如網絡帶寬、服務器硬件等，造成微服務架構較單體架構存在一定的影響。（5）數據的同步問題：分布式事務管理在微服務架構中需要經過多個節點來保障數據的同步，技術實現相對單體架構要復雜很多，成本也會增加很多。

保險行業的核心業務系統與傳統的軟件應用系統在技術架構上存在許多共同之處，但在系統安全性、穩定性、數據一致性、系統持續性、可維護性等方面有著更高的要求，如何讓微服務架構應用于保險行業的核心業務系統，架構自身存在的一些問題是需要去思考和解決的。

三、結束語

基于當前科技及互聯網經濟高速發展的時代背景下，計算機信息技術已深入廣泛的應用于各行各業中，如何讓新的信息技術更好地、及時地應用于傳統行業，是我們一直需要研究和探討的課題。而隨著中國保險業務的興起和迅猛發展，為了不斷適應現代保險工作的需求，保險公司對于現代化核心業務系統的需求越來越迫切。保險公司必須借助先進的信息IT技術構建一套規范及健全的保險管理體系，從而提高保險公司的管理效率，降低公司運維的成本。保險行業核心業務系統是屬于保險管理體系的其中一類系統，由于保險公司本身受到國家銀保監會的監管，因此對核心業務建設的各項要求相比傳統的應用軟件系統更高。保險行業所在的公司在開發一套成熟的核心業務系統后，由于其復雜性，一般不會輕易地對系統進行技術架構上的更新。但信息技術的發展日新月異，早期的技術架構或已滿足不了現代系統建設的要求。因此，如何讓一套新的技術架構更新應用于原有行業系統的開發而又不帶來新的風險是值得我們去權衡與探討的。

參 ?考 ?文 ?獻

[1] https：//spring.io/projects/spring-cloud.

[2] 方志朋. 深入理解Spring Cloud與微服務構建第2版 2020.3

[3] Sam Newman.微服務設計 2016.5