傳統保險企業基於 Dubbo 的微服務實踐

本文整理自中國人壽保險（海外）股份有限公司深圳中心技術總監家黃曉彬在 Dubbo 社區開發者日深圳站的現場分享。

中國人壽保險（海外）股份有限公司負責香港、澳門、新加坡和印尼的業務開發，和國內業務不一樣的是，海外業務面臨不一樣的法規、語言、幣種等難題，技術上對業務的支持會存在一些挑戰。經過本文，您將瞭解中國人壽保險在這方面的處理經驗。

碰見Dubbo

2013年，咱們在作整個數據庫轉換的時候，須要找一款RPC的框架。當時市場上成熟的產品不多，不像今天百花齊放，好比今天有 Spring Cloud 和 Dubbo，但咱們更傾向於有實際生產經驗的框架，Dubbo在淘寶有比較豐富的實施經驗，再加上阿里的業務形態和咱們的業務模型契合度很高，例如須要支持海外不一樣地區的請求，不一樣地區也都有一些本身的定製化業務需求。

從2013年到今年，咱們已經使用 Dubbo 6年了。2016年，業務系統上線港澳地區， 2019年5月份，在印尼上線，將來還會在新加坡以及整個東南亞，快速部署咱們的業務系統。

在部署效率和低成本方面，Dubbo 給予了咱們很大的幫助，這裏我先分享下在使用Dubbo 以前，傳統保險公司的架構。

使用Dubbo 前，傳統保險公司的架構

從服務器硬件層面去看，傳統保險的業務系統用的是小型機，例如 IBM、惠普，只有這兩個能夠選擇，他們都是基於 Unix 的操做系統。

從業務架構的層面去看，之前的軟件開發用的是 C/S 架構，在 C/S 架構下有一個很好用的中間件叫 Tuxedo，用於處理分佈式事務管理，一致性和高併發性能都很是好，可是爲何要把它替換掉它？一是由於價格過高，二是由於相關的運維人員很難找到。三是由於業務高度集成，在分佈式和跨平臺的場景下性能和調度不好。四是由於他的設計是針對單體的，致使咱們拆不開，也不敢動。

核心業務系統的改造過程

這張圖很形象的說明了微服務相比單體的優點，Dubbo 在裏面的做用至關於在各個組建之間作一個卡口的交互，相似於樂高的凸點、凹點之間，提供通信的管理和服務的治理。咱們就是經過這個設計思路，將一個龐大的傳統核心架構進行拆解的。

OneLife 是咱們的業務支撐平臺，意思是指，一個平臺可以解決全部保險業務的處理，造成內部的生態圈，提供對影像、新的業務、保全和理賠業務的支持，還有自建的一些引擎，好比工做流、產品引擎、覈保引擎、消息引擎等。以上就是一家保險公司大概要具有的業務能力。

藉助Dubbo，自主研發保險業務處理平臺

咱們藉助 Dubbo 搭建了新的保險業務處理平臺，實現了「六多」的保險業務處理。六可能是指，多業務、多產品、多監管、多引擎、多幣種和多語言。例如一個保單生成的過程當中，要考慮是生成英文仍是中文或者印尼文？這須要與業務進行配合，而後設計、開發適合本身的處理平臺。

OneLife分佈式體系的造成

由上圖可知，由基於Dubbo的微服務調用、基於 Jenkins 的持續集成、基於Rancher 的雲部署應用和基於 Pinpoint 的鏈式監控這四塊內容造成一個閉環。雲部署方面，印尼版本正在與阿里雲的團隊洽談中，將來的印尼地區可能會率先切換成阿里雲服務的版本。關於 Pinpoint 鏈式監控，它所顯示的拓普圖很是清晰，能夠很清晰的看到組建中斷或者調用不通等問題，今年咱們經過 Pinpoint 鏈式監控，在系統內找到100+ Bug，因此我認爲 Pinpoint 鏈式監控與 Dubbo 的搭配是個絕妙的組合。

Dubbo在港澳地區的分佈

Dubbo 在港澳地區擁有150+臺服務器，210+個應用，2100+個消費者，1300+個提供者。對於保險公司來講，不存在太多的高頻交易，特別是業務系統，更多的高頻交易是在前端。雖然業務系統不是一直處於高頻狀態，可是也必須保證其穩定性，確保每一條業務都可以很是準確的輸出。這也是咱們選擇 Dubbo 的緣由之一。

Dubbo在中國人壽海外的實踐

咱們70%的業務使用的是低版本的 Dubbo-2.4.9 版本，以前在 Dubbo 的基礎上作過一些代碼的修改，例如對分佈式事務的補償，後來發現會因爲改動太大，形成之後不能升級版本。剩餘的30%是用什麼呢？咱們會嘗試最新的版本，但都只是在外圍，只有通過實踐證實新版本是可行的，纔會把它運用到核心業務架構中。目前，中國人壽海外的 Dubbo 天天調用次數超過2100萬次，從上線到如今，尚未出現過宕機的狀況。

Dubbo的配置結構

這裏再分享一下咱們所用的配置，須要強調的兩點是，一是重試的機制，即服務中斷的時候利用控制平臺進行人工干預，或者特別關鍵的服務，經過反覆交易的方式進行補償。二是使用 Zookeeper 註冊中心，它是有弊端的，高峯期時期，網絡的消耗太大。Dubbo2.7 版本里面元數據的概念很是好，將來咱們也會去嘗試，看看能不能經過新版本的Dubbo去解決 Zookeeper 的弊端問題，或者優化Zookeeper。

Dubbo微服務的應用場景

Dubbo 微服務的應用如同上圖中所描述的，從線上服務頁面到新業務組件，而後觸發工做流，查詢覈保的結果，結果會自動查詢保費的計算，再返回到前端。在印尼的國際化方面，低成本是必須的，另外須要作到業務的分離，這個就涉及到 Base 的開發模式，什麼叫 Base 開發模式？

當業務遍及多地區時，各個地區一定有本身特定的版本。可是隻要保證公共的基礎版本相同，就能夠在之後的工做中提升效率。例如 ：公司總部有一些基礎性的服務，可是印尼有本身的法規需求，若是後期香港也有這個需求，能夠在基礎版本達到某個級別審覈以後，把基礎版本打回到 Base 版本里，Base 版本再把它發佈到對應的不一樣地區的版本，就是說，在比較複雜的狀況下，它具備不一樣業務邏輯分離的層次，也具備代碼管理的層次，又有服務治理之間不一樣地區的管理層次。

建議

第一，增強可視化管理；

第二，引入服務網格，打包成一個全家桶，提供微服務體系內更豐富的功能，包括服務之間的網絡調用、限流、熔斷和監控。

第三，支持多語言，Dubbo 目前已經提供 PHP/Node.js/Python/Go 的客戶端，但願能夠支持更多的客戶端。

第四，不建議 Dubbo 支持分佈式事務管理。之前咱們剛開始使用Dubbo的時候，認爲有必要支持分佈式事務，因此在 Dubbo 基礎上改寫了代碼，使用過程很流暢，也可以保證咱們事物的一致性，並且跨平臺也能夠作到，可是當某個服務掛掉的時候，全部等待提交的事務會所有崩掉，會給數據庫形成致命的風險。

因此咱們更傾向的是讓 Dubbo 提供更多消息機制的支持，可以在作業務開發的同時對分佈式事務進行補償，以上就是咱們實踐中的一點思考和建議。

解疑時間

Q1：微服務組件替換單體的過程當中是一步步替代老系統，仍是直接總體替換？替換過程當中，須要用到多少人力、物力？
A1：首先將現有結構模塊化，模塊間相對獨立，最重要的數據結構要先分離業務邏輯，其次，再分庫或者設置權限，而後進行模塊化的一步步替換，在開發前須要計劃好整個替換過程。咱們第一個模塊啓動時，只有五我的，但要求每一個人技術要強、業務要精通，最重要的是獲得管理層的支持。

Q2：若是系統中沒有分佈式事務控制，數據不一致性如何發現？怎麼解決？
A2：基於Pinpoint的鏈式監控，運維人員能夠快速發現問題，繼而排除網絡問題以後進行人工干預，咱們在關鍵業務上使用MQ機制，可是其存在耗時、耗力、耗人的問題，不建議大規模使用分佈式事務控制。

Q3：公司內部數據量大的條件下，把舊系統遷移到新系統的過程當中如何去O？
能夠文回答下這個問題麼？
A3：首先在數據庫層面要保證Oracle數據庫到其餘數據庫的表結構及數據一致，能夠利用ETL等數據工具進行對比。其次，在應用層面能夠分兩步走，第一步自動化處理，經過自寫工具將應用的SQL在兩邊數據庫執行，發現錯誤的及時修正，當進行到第三輪的時候就差很少全部SQL均可以正常執行；第二步抽查關鍵算法或接口，批量數據兩邊數據庫執行對比結果。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。