Dubbo在互金行業的應用

摘要： 融之家技術團隊從2015年截止到目前累計經歷了4次演進（單體應用、多實例部署、半微服務、微服務），讓平台能更懂用戶，更理解用戶的需求，把合適的人匹配到合適的產品。

前言

本文章是根據潘志偉老師在上海Dubbo沙龍的演講稿進行整理，意在為大家展示最真實、最一手的沙龍技術乾貨。

1、作者介紹

潘志偉(微信號panzw008)，現任上海融之家首席架構師，十餘年互聯網架構經驗 ，精通Microservice Architecture ，Hadoop擁有億級用戶平台架構經驗 萬級並發的API網關經驗。

2、上海融之家

上海融之家金融信息服務有限公司作為消費金融領域領先的信息技術服務提供商，打造了國內第一款互聯網貸款搜索平台，在短短2年內，用戶數從0發展到3000W+，累計撮合借款金額近150億。

面對如此快速的發展，原有的技術架構很難支撐越來越複雜的業務場景，在系統可用性以及穩定性方面以及快速迭代方面，都給融之家技術團隊帶來了很大的壓力。因此，如何針對當前需求，選擇合適的技術架構，保證架構平滑演進。融之家技術團隊從2015年截止到目前累計經歷了4次演進（單體應用、多實例部署、半微服務、微服務），讓平台能更懂用戶，更理解用戶的需求，把合適的人匹配到合適的產品。

一、單體應用

創業初期，融之家初始創業團隊在進行架構選型時，主要圍繞以下2點進行考慮：

1、研發資源有限，研發人力有限、技術水平有限，需要選擇一個易維護、簡單、方便部署的技術架構；

基於以上2點的考慮，創業期平台架構和部署方式非常簡單，採用最通用的Spring MVC+mybatis+MySQL架構，使用一台ECS和一台RDS部署線上環境。

這種基礎架構為業務快速上線奠定了堅實的基礎，App上線後的效果遠超我們當初的預期，業務進入快速增長期，但簡單平台架構是也帶來了很多問題。

二、多實例部署

由於業務高速增長，迭代需求非常頻發，但是人力資源有限，根本不可能停下來重新梳理架構，但是又必須解決目前平台架構發版後暫停服務等問題，我們選擇了在維護現有系統的基礎上增加多實例部署的方式來解決業務問題。

引入Nginx做反向代理，用戶Session信息寫入Redis，通過Redis實現多實例之間的session共享。多實例部署方式幫助我們暫時解決了問題，這種架構方式也持續了很長時間。在這段時間內我們的技術主要是做功能的迭代，更新頻率非常高。值得慶幸的是付出後有很大的回報，用戶量增加非常快，交易量也有很大的提升。但隨之而來的新問題又出現了，由於業務之間的共享都是依賴DB,導致平台裡面存在大量重複的代碼，代碼之間耦合非常嚴重，線上的Bug頻發、測試回歸量巨大，每次迭代上線都沒有辦法完成回歸。

三、「半」微服務

針對線上的頻發的故障以及越來越複雜的業務需求，技術團隊開始考慮重構系統，考慮引入微服務，微服務的降低系統複雜度、可獨立部署、容錯，可擴展的優點深深吸引了我們。希望通過服務的方式來隔離不同的業務，業務之間的依賴通過介面方式執行。在微服務框架的選型中，我們比對了Dubbo和Spring Cloud，經過技術內部多次討論最後選型Dubbo 2.5.3版本。經過重構後的業務系統如下：

四、微服務

服務化後解決了代碼耦合問題，也提升了線上產品穩定性。但是每個人編寫的代碼風格不一致，SQL水平不一致，有些人甚至在服務層做了多表聯合查詢，這給後續的分庫分表埋下了隱患。為了統一代碼風格，加速系統的重構，技術團隊結合業務現在以及同行的經驗，開發了一套微服務代碼工具。

同時，重新梳理了微服務組件名稱以及調用的流程。介面聚合層統一命名為back層，並處理協議轉化（http->Dubbo），原子服務層統一命名為basic層，每個原子服務單獨連接一台資料庫。

對於每個業務進行重新梳理以及服務邊界劃分，引入HBase、Hive、ES、HDFS等存儲模引擎做數據存儲，重構後的業務結構圖更清晰。

五、經驗分享

1、預發布環境和生產環境兼容

目前業界比較通用的開發流程為開發環境、測試環境、預發布環境、生產環境。開發環境由開發人員維護，測試環境則有測試人員維護、預發布和生產環境則有運維人員維護。但是如果預發布環境和生產環境完全一致則浪費太多機器，但是預發布環境又是缺一不可的。因此引入group分組的概念，把需要驗證的basic服務和預發布的back層所引入的服務配置在同一個組，則有效的解決了預發布和生產環境一致的問題。

2、服務許可權控制

平台規模越來越大，參與開發的人員也越來越多，此刻許可權問題尤其重要。對於用戶層面的許可權控制在back層面已經完成，但是對於內部核心服務之間的RPC調用也需要許可權控制的需求。但是目前Dubbo對於許可權這款的控制相對比較弱，通過了解業務方的需求後，基於Filter機制實現了一套RPC調用的許可權認證。

支持如下授權：

3、線程隔離

為了做到千人千面的推薦場景，在我們的App「借錢」列表中會調用後台幾十個服務，而且會根據用戶的行為實時調整排序邏輯。我們對於聚合後的響應時間也有明確約定要求<=1秒。為滿足業務方 需求，重新梳理了業務調用邏輯以及依賴關係，改掉了之前串列調用方式，把能並行調用的服務的全部並行調用。設置ExecutorService來並行化調用，通過future來獲取結果，同時設置了future.get 的超時時間。

然後由於依賴的後台服務過多，有些服務響應不及時，在高並發的場景下業務聚合層（back）的tomcat線程池爆滿，拖垮整個服務，引起平台雪崩。技術團隊引入Hystrix利用線程池隔離的方式來規避因某個服務響應慢而拖垮整個平台。為了降低現在代碼改動量，基於hystrix做了自定義annotation，只要使用自定義的註解並設置響應的參數即可完成線程池的隔離。

4、熔斷機制

我們希望能在配置中心手動觸發熔斷以及達到熔斷觸發值後能立即熔斷且主動報警，如果直接使用hystrix提供的@HystrixCommand註解不能實現手動觸發機制。對於熔斷的一些指標如錯誤率、時間窗口、主動告警等做了個性化設置。基於上述的需求通過註解方式實現了@JdqHystrixCommand註解。只需要在需要熔斷的方式上增加一句註解即可。

5、Mock平台

在開發、測試過程中經常出現這樣的場景，前後端介面協議已經定義，但是後端依賴的很多服務，其中部分服務還沒有提供，為了不影響開發進度，需要mock一些數據。測試人員需要模擬一次支付成功、註冊失敗、5秒延時返回結果，服務異常等等場景。需要能方便模擬，而且不需要研發人員修改任何代碼。基於Dubbo的Filter機制實現了一套Mock平台，JDQMockFilter會在Consumer端以及Provider端執行。JDQMockFilter拿到請求後會先調用Mock平台查詢是否有Mock服務。

6、監控

服務拆分後出現大量的服務組件，必須要時刻了微服務運行狀態， Dubbo自帶的簡易監控中心不能滿足我們監控需求。所以基於Dubbo的MonitorService自研了一套監控平台，實時收集微服務運行期間所產生的成功率、失敗率、平均耗時、最大耗時、並發量、數據傳輸排行等。對於服務的下線，耗時過長都會觸發報警。

7、服務框架預覽

經過4次的架構演變，平台的穩定性、吞吐量、並發量都有非常大的提升，整個RPC框架也重新定義了，增加了許可權平台，mock平台，監控平台。

六、總結

微服務架構可以更好的進行業務解耦，具備更好的擴展性以及獨立性，可以提高研發團隊間的並行化研發速度，提升效率、提高模塊復用性，具備高可用、高並發特性。但微服務架構對服務治理的能力要求比較高，維護成本也會比單體應用高。Dubbo 出生於阿里系，是阿里巴巴服務化治理的核心框架，並被廣泛應用於中國各互聯網公司；只需要通過 Spring 配置的方式即可完成服務化，對於應用無入侵。我們藉助Dubbo完成了微服務重構，目前用戶數以及介面調用量都在不斷提升。

原文鏈接