摘要： 融之家技術團隊從2015年截止到目前累計經歷了4次演進（單體應用、多實例部署、半微服務、微服務），讓平臺能更懂用戶，更理解用戶的需求，把合適的人匹配到合適的產品。
前言
本文章是根據潘志偉老師在上海Dubbo沙龍的演講稿進行整理，意在為大家展示最真實、最一手的沙龍技術干貨。
1、作者介紹
潘志偉(微信號panzw008)，現任上海融之家首席架構師，十余年互聯網架構經驗 ，精通Microservice Architecture ，Hadoop擁有億級用戶平臺架構經驗 萬級并發的API網關經驗。
2、上海融之家
上海融之家金融信息服務有限公司作為消費金融領域領先的信息技術服務提供商，打造了國內第一款互聯網貸款搜索平臺，在短短2年內，用戶數從0發展到3000W+，累計撮合借款金額近150億。

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

一、單體應用
創業初期，融之家初始創業團隊在進行架構選型時，主要圍繞以下2點進行考慮：
1、研發資源有限，研發人力有限、技術水平有限，需要選擇一個易維護、簡單、方便部署的技術架構；
2、產品需要快速研發上線，并能夠滿足快速迭代要求；
基于以上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調用的權限認證。

支持如下授權：
? 按Application授權
? 根據IP地址授權
? 基于時間范圍授權
? 基于方法名授權
? 非授權業務方試圖調用服務則會觸發告警
3、線程隔離
為了做到千人千面的推薦場景，在我們的App“借錢”列表中會調用后臺幾十個服務，而且會根據用戶的行為實時調整排序邏輯。我們對于聚合后的響應時間也有明確約定要求<=1秒。為滿足業務方 需求，重新梳理了業務調用邏輯以及依賴關系，改掉了之前串行調用方式，把能并行調用的服務的全部并行調用。設置ExecutorService來并行化調用，通過future來獲取結果，同時設置了future.get 的超時時間。

然后由于依賴的后臺服務過多，有些服務響應不及時，在高并發的場景下業務聚合層（back）的tomcat線程池爆滿，拖垮整個服務，引起平臺雪崩。技術團隊引入Hystrix利用線程池隔離的方式來規避因某個服務響應慢而拖垮整個平臺。為了降低現在代碼改動量，基于hystrix做了自定義annotation，只要使用自定義的注解并設置響應的參數即可完成線程池的隔離。
4、熔斷機制
我們希望能在配置中心手動觸發熔斷以及達到熔斷觸發值后能立即熔斷且主動報警，如果直接使用hystrix提供的@HystrixCommand注解不能實現手動觸發機制。對于熔斷的一些指標如錯誤率、時間窗口、主動告警等做了個性化設置?；谏鲜龅男枨笸ㄟ^注解方式實現了@JdqHystrixCommand注解。只需要在需要熔斷的方式上增加一句注解即可。

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

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

7、服務框架預覽
經過4次的架構演變，平臺的穩定性、吞吐量、并發量都有非常大的提升，整個RPC框架也重新定義了，增加了權限平臺，mock平臺，監控平臺。

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

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。