摘要：為了降低現(xiàn)在代碼改動量，基于做了自定義，只要使用自定義的注解并設(shè)置響應(yīng)的參數(shù)即可完成線程池的隔離。

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

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

1、作者介紹
潘志偉(微信號panzw008)，現(xiàn)任上海融之家首席架構(gòu)師，十余年互聯(lián)網(wǎng)架構(gòu)經(jīng)驗 ，精通Microservice Architecture ，Hadoop擁有億級用戶平臺架構(gòu)經(jīng)驗 萬級并發(fā)的API網(wǎng)關(guān)經(jīng)驗。

2、上海融之家
上海融之家金融信息服務(wù)有限公司作為消費金融領(lǐng)域領(lǐng)先的信息技術(shù)服務(wù)提供商，打造了國內(nèi)第一款互聯(lián)網(wǎng)貸款搜索平臺，在短短2年內(nèi)，用戶數(shù)從0發(fā)展到3000W+，累計撮合借款金額近150億。

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

一、單體應(yīng)用
創(chuàng)業(yè)初期，融之家初始創(chuàng)業(yè)團隊在進行架構(gòu)選型時，主要圍繞以下2點進行考慮：

1、研發(fā)資源有限，研發(fā)人力有限、技術(shù)水平有限，需要選擇一個易維護、簡單、方便部署的技術(shù)架構(gòu)；
2、產(chǎn)品需要快速研發(fā)上線，并能夠滿足快速迭代要求；

基于以上2點的考慮，創(chuàng)業(yè)期平臺架構(gòu)和部署方式非常簡單，采用最通用的Spring MVC+mybatis+MySQL架構(gòu)，使用一臺ECS和一臺RDS部署線上環(huán)境。

這種基礎(chǔ)架構(gòu)為業(yè)務(wù)快速上線奠定了堅實的基礎(chǔ)，App上線后的效果遠超我們當(dāng)初的預(yù)期，業(yè)務(wù)進入快速增長期，但簡單平臺架構(gòu)是也帶來了很多問題。

二、多實例部署
由于業(yè)務(wù)高速增長，迭代需求非常頻發(fā)，但是人力資源有限，根本不可能停下來重新梳理架構(gòu)，但是又必須解決目前平臺架構(gòu)發(fā)版后暫停服務(wù)等問題，我們選擇了在維護現(xiàn)有系統(tǒng)的基礎(chǔ)上增加多實例部署的方式來解決業(yè)務(wù)問題。

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

三、“半”微服務(wù)
針對線上的頻發(fā)的故障以及越來越復(fù)雜的業(yè)務(wù)需求，技術(shù)團隊開始考慮重構(gòu)系統(tǒng)，考慮引入微服務(wù)，微服務(wù)的降低系統(tǒng)復(fù)雜度、可獨立部署、容錯，可擴展的優(yōu)點深深吸引了我們。希望通過服務(wù)的方式來隔離不同的業(yè)務(wù)，業(yè)務(wù)之間的依賴通過接口方式執(zhí)行。在微服務(wù)框架的選型中，我們比對了Dubbo和Spring Cloud，經(jīng)過技術(shù)內(nèi)部多次討論最后選型Dubbo 2.5.3版本。經(jīng)過重構(gòu)后的業(yè)務(wù)系統(tǒng)如下：

四、微服務(wù)
服務(wù)化后解決了代碼耦合問題，也提升了線上產(chǎn)品穩(wěn)定性。但是每個人編寫的代碼風(fēng)格不一致，SQL水平不一致，有些人甚至在服務(wù)層做了多表聯(lián)合查詢，這給后續(xù)的分庫分表埋下了隱患。為了統(tǒng)一代碼風(fēng)格，加速系統(tǒng)的重構(gòu)，技術(shù)團隊結(jié)合業(yè)務(wù)現(xiàn)在以及同行的經(jīng)驗，開發(fā)了一套微服務(wù)代碼工具。

同時，重新梳理了微服務(wù)組件名稱以及調(diào)用的流程。接口聚合層統(tǒng)一命名為back層，并處理協(xié)議轉(zhuǎn)化（http->Dubbo），原子服務(wù)層統(tǒng)一命名為basic層，每個原子服務(wù)多帶帶連接一臺數(shù)據(jù)庫。

對于每個業(yè)務(wù)進行重新梳理以及服務(wù)邊界劃分，引入HBase、Hive、ES、HDFS等存儲模引擎做數(shù)據(jù)存儲，重構(gòu)后的業(yè)務(wù)結(jié)構(gòu)圖更清晰。

五、經(jīng)驗分享
1、預(yù)發(fā)布環(huán)境和生產(chǎn)環(huán)境兼容
目前業(yè)界比較通用的開發(fā)流程為開發(fā)環(huán)境、測試環(huán)境、預(yù)發(fā)布環(huán)境、生產(chǎn)環(huán)境。開發(fā)環(huán)境由開發(fā)人員維護，測試環(huán)境則有測試人員維護、預(yù)發(fā)布和生產(chǎn)環(huán)境則有運維人員維護。但是如果預(yù)發(fā)布環(huán)境和生產(chǎn)環(huán)境完全一致則浪費太多機器，但是預(yù)發(fā)布環(huán)境又是缺一不可的。因此引入group分組的概念，把需要驗證的basic服務(wù)和預(yù)發(fā)布的back層所引入的服務(wù)配置在同一個組，則有效的解決了預(yù)發(fā)布和生產(chǎn)環(huán)境一致的問題。

2、服務(wù)權(quán)限控制
平臺規(guī)模越來越大，參與開發(fā)的人員也越來越多，此刻權(quán)限問題尤其重要。對于用戶層面的權(quán)限控制在back層面已經(jīng)完成，但是對于內(nèi)部核心服務(wù)之間的RPC調(diào)用也需要權(quán)限控制的需求。但是目前Dubbo對于權(quán)限這款的控制相對比較弱，通過了解業(yè)務(wù)方的需求后，基于Filter機制實現(xiàn)了一套RPC調(diào)用的權(quán)限認(rèn)證。

支持如下授權(quán)：
? 按Application授權(quán)
? 根據(jù)IP地址授權(quán)
? 基于時間范圍授權(quán)
? 基于方法名授權(quán)
? 非授權(quán)業(yè)務(wù)方試圖調(diào)用服務(wù)則會觸發(fā)告警

3、線程隔離
為了做到千人千面的推薦場景，在我們的App“借錢”列表中會調(diào)用后臺幾十個服務(wù)，而且會根據(jù)用戶的行為實時調(diào)整排序邏輯。我們對于聚合后的響應(yīng)時間也有明確約定要求<=1秒。為滿足業(yè)務(wù)方 需求，重新梳理了業(yè)務(wù)調(diào)用邏輯以及依賴關(guān)系，改掉了之前串行調(diào)用方式，把能并行調(diào)用的服務(wù)的全部并行調(diào)用。設(shè)置ExecutorService來并行化調(diào)用，通過future來獲取結(jié)果，同時設(shè)置了future.get 的超時時間。

然后由于依賴的后臺服務(wù)過多，有些服務(wù)響應(yīng)不及時，在高并發(fā)的場景下業(yè)務(wù)聚合層（back）的tomcat線程池爆滿，拖垮整個服務(wù)，引起平臺雪崩。技術(shù)團隊引入Hystrix利用線程池隔離的方式來規(guī)避因某個服務(wù)響應(yīng)慢而拖垮整個平臺。為了降低現(xiàn)在代碼改動量，基于hystrix做了自定義annotation，只要使用自定義的注解并設(shè)置響應(yīng)的參數(shù)即可完成線程池的隔離。

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

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

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

7、服務(wù)框架預(yù)覽
經(jīng)過4次的架構(gòu)演變，平臺的穩(wěn)定性、吞吐量、并發(fā)量都有非常大的提升，整個RPC框架也重新定義了，增加了權(quán)限平臺，mock平臺，監(jiān)控平臺。

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

原文鏈接：http://click.aliyun.com/m/100...