簡介： 本文整理自中國人壽保險（海外）股份有限公司深圳中心技術總監家黃曉彬在 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 提供更多消息機制的支持，能夠在做業務開發的同時對分佈式事務進行補償，以上就是我們實踐中的一點思考和建議。
解疑時間：點擊這裏
原文出處：阿里雲大學開發者社區