余額寶-國民基金的大規(guī)模服務(wù)化的技術(shù)創(chuàng)新之道

1、 余額寶：國民基金的大規(guī)模服務(wù)化的技術(shù)創(chuàng)新之道 今年7月初我在ArchSummit大會上做了題為余額寶大規(guī)模服務(wù)化的技術(shù)創(chuàng)新的分享，反響還不錯(cuò)?，F(xiàn)將PPT和講稿整理出來，分享給大家。這次分享首先介紹的是余額寶的整體架構(gòu)變遷歷史；第二部分講一講我們是如何進(jìn)行基金實(shí)時(shí)銷售平臺及大數(shù)據(jù)平臺的服務(wù)化改造的；最后介紹“服務(wù)化”對我們運(yùn)維及研發(fā)模式的影響及我們的應(yīng)對策略。余額寶本質(zhì)上是一支貨幣基金，它的背后是天弘的增利寶基金。由于和支付寶的關(guān)系，它既是理財(cái)產(chǎn)品，又是支付產(chǎn)品，理財(cái)和支付的雙重屬性，再加上互聯(lián)網(wǎng)產(chǎn)品所特有的極簡的用戶體驗(yàn)，讓余額寶一經(jīng)推出，迅速成為了“爆款”，短短五年內(nèi)獲得了一個(gè)驚人的發(fā)展。

2、可以毫不夸張的說，余額寶的出現(xiàn)，開啟了中國的全民理財(cái)時(shí)代！為了適應(yīng)業(yè)務(wù)的爆炸式增長，5年來余額寶的技術(shù)架構(gòu)做了4次大的變更，每次技術(shù)變更的背后，都承載了天弘技術(shù)團(tuán)隊(duì)對系統(tǒng)規(guī)模、可擴(kuò)展性及升級成本的綜合考量和平衡之道。余額寶上線之初，解決的是“從無到有”的問題。當(dāng)時(shí)沒有其它類似的互聯(lián)網(wǎng)金融產(chǎn)品可以做參考，我們采用了傳統(tǒng)的典型企業(yè)級金融架構(gòu)。由于采用的是自建IDC機(jī)房的方式，我們用硬件負(fù)載均衡設(shè)備將交易請求接入進(jìn)來，前端是由兩臺weblogic構(gòu)成的小型的前置處理集群，請求被稍做處理之后，即被送到后端由金正的基金交易中間件構(gòu)建的集群做業(yè)務(wù)處理，其中 KCXP 和 KCBP 是金證公司的消息中間件和

3、業(yè)務(wù)中間件，業(yè)務(wù)數(shù)據(jù)存儲采用的是兩臺Oracle數(shù)據(jù)庫服務(wù)器構(gòu)建的一主一備的小集群，這個(gè)是線上庫，同時(shí)，還有一個(gè)同樣架構(gòu)的歷史庫服務(wù)。硬件方面采用的都是小型機(jī)設(shè)備，數(shù)據(jù)備份則采用EMC的產(chǎn)品。這是典型的IOE架構(gòu)，全套的商用軟硬件配置，成本很高。架構(gòu)體系雖然很多環(huán)節(jié)都采用了集群的方式，但更多的是使用主備模式，而不是負(fù)載均衡的分布式模式，因此系統(tǒng)的單點(diǎn)資源負(fù)載壓力較大，尤其是數(shù)據(jù)庫，基本上就是單庫模式（另一個(gè)庫是備庫），擴(kuò)展性較差。當(dāng)時(shí)的系統(tǒng)容量設(shè)計(jì)上限是能支持千萬級用戶，傳統(tǒng)基金銷售模式是走代銷機(jī)構(gòu)的方式，投資基金用戶也多以理財(cái)為目的。所以每天可能處理的帳戶開戶也就是幾萬到幾十萬的規(guī)模。由于余

4、額寶對接是支付寶，支付寶的用戶規(guī)模達(dá)到千萬級，這是設(shè)計(jì)產(chǎn)品時(shí)對需求的定位。按照預(yù)估，這個(gè)設(shè)計(jì)容量怎么都能扛個(gè)幾年。結(jié)果，我們低估了余額寶的熱度，上線短短10天左右，新開戶數(shù)已經(jīng)突破100W了，按這個(gè)速度，3個(gè)月左右數(shù)據(jù)庫容量上線就要被突破。事實(shí)也確實(shí)如此，我們的客戶量三個(gè)月就達(dá)到一千萬，余額寶一期系統(tǒng)的生命周期只有三個(gè)月！所以一期系統(tǒng)甫一上線，團(tuán)隊(duì)就不得不開始考慮擴(kuò)容，計(jì)劃將容量擴(kuò)充3050倍，計(jì)算規(guī)模也同步增加。如果還是采用一期系統(tǒng)的純商用軟硬件的模式進(jìn)行橫向擴(kuò)展的話，成本要達(dá)到12個(gè)億，這樣的成本對于當(dāng)時(shí)天弘這樣一家小型基金公司而言，是不可負(fù)擔(dān)之重！因此，在阿里的建議下，我們決定整體上云。

5、當(dāng)時(shí)做出這個(gè)決定的壓力還是非常大的，因?yàn)楫?dāng)時(shí)沒有任何一家金融公司和基金公司這么玩，我們成了第一個(gè)吃螃蟹的人。但在巨大的成本壓力之下，我們走出了這一步，這就是余額寶2.0！2.0的架構(gòu)中用阿里云上的軟負(fù)載均衡SLB替換了硬件負(fù)載均衡；用阿里云上的虛擬計(jì)算單元ECS替換小型機(jī)成為前置服務(wù)及中間件服務(wù)的服務(wù)器；用阿里云的web服務(wù)替換了前置服務(wù)器上的weblogic。最大的一個(gè)變化是數(shù)據(jù)庫層面，原來的Oracle單庫被替換成了阿里云上的一個(gè)50個(gè)節(jié)點(diǎn)的RDS集群，實(shí)際上就是進(jìn)行了分庫分表的拆分，經(jīng)過測算，需要使用50組業(yè)務(wù)節(jié)點(diǎn)，但在拆分時(shí)，考慮到擴(kuò)展性，并未簡單地拆分成50份，而是根據(jù)用戶帳號ID作

6、為分片主鍵將核心業(yè)務(wù)表拆分成1000份，然后每個(gè)節(jié)點(diǎn)處理20份數(shù)據(jù)（物理子表）。這樣做的好處是將來如果系統(tǒng)遇到瓶頸，需要擴(kuò)容時(shí)，不需要對拆分算法進(jìn)行修改，而且數(shù)據(jù)平均遷移時(shí)只需要以庫為級別進(jìn)行，從而避免了拆表。上云后，不僅數(shù)據(jù)庫總?cè)萘坑辛藥资兜奶嵘?，交易處理效率也從一期?20W筆/小時(shí)提升到了近2000W筆/小時(shí)；最大清算時(shí)間從之前的7個(gè)多小時(shí)降低到了不到2個(gè)小時(shí)；而總成本，才增加了不到1倍。所以，上云對我們系統(tǒng)整體效率的提升和成本的降低有非常明顯的作用。余額寶2.0的架構(gòu)穩(wěn)定運(yùn)行了近3年，中間經(jīng)歷了幾次小的升級優(yōu)化，有力支撐了這個(gè)過程中的各種業(yè)務(wù)創(chuàng)新，但也在支撐業(yè)務(wù)快速發(fā)展中埋下了一些“

7、坑”。2016年，我們決定對系統(tǒng)進(jìn)行一次大升級。這次升級的主要基調(diào)就是“業(yè)務(wù)邏輯重構(gòu)，優(yōu)化清算流程”，這就是余額寶3.0！這一階段的業(yè)務(wù)邏輯復(fù)雜度要遠(yuǎn)遠(yuǎn)高于3年前，因此3.0的架構(gòu)中，計(jì)算單元比2.0有了明顯的擴(kuò)充。由于數(shù)據(jù)庫前期預(yù)留的buffer比較大，并沒有成為本階段的瓶頸，依然維持了50個(gè)節(jié)點(diǎn)的規(guī)模。這次升級之后，總體計(jì)算能力有了較大幅度的提高。處理效率比起2.0的時(shí)候增長了2倍多，也支撐了2016年春節(jié)期間日交易4億多筆的峰值。但是，清算時(shí)間比2.0時(shí)期有較大增長，這成了系統(tǒng)的一個(gè)“隱患”。2017年，為了配合支付寶拓寬線下支付場景，并將業(yè)務(wù)推廣覆蓋到三、四線城市，同時(shí)，也要解決清算時(shí)

8、間過長的隱患，我們規(guī)劃了余額寶4.0的升級。這一階段的系統(tǒng)規(guī)模已經(jīng)很大了，如果還是按3.0的架構(gòu)進(jìn)行橫向擴(kuò)充的話，成本將呈線性增長。經(jīng)過綜合考量，決定在升級前，先優(yōu)化單節(jié)點(diǎn)的處理性能，提高效率及負(fù)載后再擴(kuò)容，以降低總體的升級成本。因此，這次升級首先將直銷和代銷業(yè)務(wù)合二為一，同一臺計(jì)算單元既處理直銷業(yè)務(wù)，也處理代銷業(yè)務(wù)，提高了單點(diǎn)的處理效率。在此基礎(chǔ)上，再進(jìn)行擴(kuò)容，將計(jì)算單元從340節(jié)點(diǎn)擴(kuò)充到480節(jié)點(diǎn)，數(shù)據(jù)庫擴(kuò)容4倍。通過這兩步優(yōu)化及擴(kuò)充動作，最終系統(tǒng)的容量及計(jì)算能力均有了48倍的提高，這套新的架構(gòu)支撐我們平穩(wěn)度過了2017年雙十一及春節(jié)的交易高峰?？吹竭@里，大家可能會有疑問：一般在系統(tǒng)服務(wù)化

9、改造中，服務(wù)是會被拆的越來越細(xì)，為什么我們反其道而行，反而對服務(wù)進(jìn)行了整合？這是因?yàn)?，余額寶發(fā)展到現(xiàn)在，業(yè)務(wù)模式已經(jīng)比較成熟，通過細(xì)粒度的服務(wù)模態(tài)來保證可擴(kuò)展性的需求已經(jīng)不是那么強(qiáng)烈；另一方面，系統(tǒng)規(guī)模龐大，擴(kuò)容的成本成為重點(diǎn)考慮因素；綜合這兩方面的考量，適當(dāng)增加單點(diǎn)的復(fù)雜度，可以降低整體成本。目前，針對余額寶這單只基金已經(jīng)建立起了一套完整的技術(shù)生態(tài)體系，它的核心是余額寶的產(chǎn)品、帳號、交易、清算等模塊，在結(jié)合實(shí)時(shí)調(diào)用和文件交互兩套接口的基礎(chǔ)上，構(gòu)建了電商大數(shù)據(jù)的分析體系及一系列輔助支撐系統(tǒng)。同時(shí)，余額寶系統(tǒng)和其它第三方系統(tǒng)也有大量的交互，包括支付寶、監(jiān)管、直代銷渠道等等。余額寶系統(tǒng)的建設(shè)直接鍛

10、煉了天弘的技術(shù)團(tuán)隊(duì)，讓我們明白了大型互聯(lián)網(wǎng)應(yīng)用是一個(gè)什么樣的玩法，這也直接推動了天弘自有的基金直銷平臺的服務(wù)化改造。接下來，我將從基金實(shí)時(shí)交易平臺及大數(shù)據(jù)平臺的服務(wù)化改造這兩方面來對此分別做詳細(xì)介紹。在開始這塊的內(nèi)容之前，先簡單的給大家介紹一下基金公司的業(yè)務(wù)?；鸸咀钪饕木褪恰百I賣”基金，我們從直銷和代銷渠道把交易請求“接”進(jìn)來，在我們的核心交易系統(tǒng)進(jìn)行申購、認(rèn)購、定投、贖回、轉(zhuǎn)換等等操作，這個(gè)過程里，會涉及與支付渠道、銀行等一系列的交付；同時(shí)，還有大量的清結(jié)算和TA清算，這個(gè)過程里，還要和銀證監(jiān)會、中登等一系列監(jiān)管機(jī)構(gòu)有數(shù)據(jù)上的交互。聚攏過來的巨量的資金會被統(tǒng)一管控、并投入到股市、債市、

11、貨幣市場等投資市場去賺錢收益。圍繞這個(gè)業(yè)務(wù)還有相應(yīng)的投研、基金產(chǎn)品管理、風(fēng)控、客服等中后臺的業(yè)務(wù)支持。以上，就是基金公司的日常業(yè)務(wù)模式。在天弘早期的基金銷售系統(tǒng)的建設(shè)中，其實(shí)沒有什么服務(wù)化的概念，當(dāng)時(shí)的模式是有什么類型的業(yè)務(wù)，就針對這種業(yè)務(wù)單獨(dú)開發(fā)一套獨(dú)立的銷售及清結(jié)算系統(tǒng)。由于業(yè)務(wù)量普遍不大，這些系統(tǒng)往往采用單體架構(gòu)模式，不考慮橫向擴(kuò)展性。經(jīng)過多年的發(fā)展和積累，內(nèi)部多套直銷及代銷交易系統(tǒng)并存，系統(tǒng)間帳號沒有打通，用戶的資產(chǎn)數(shù)據(jù)無法統(tǒng)一，用戶體驗(yàn)差；另一方面，各系統(tǒng)間功能重復(fù)的現(xiàn)象嚴(yán)重，不僅重復(fù)占用軟硬件資源，版本的控制也很麻煩。這種狀況甚至在我們整體遷移到云上之后還存在了很長的一段時(shí)間，所以

12、，所謂的“服務(wù)化”，并不是僅僅上云那么簡單，它更多的還是涉及到架構(gòu)思維的轉(zhuǎn)變。痛定思痛之后，我們決定將這些系統(tǒng)中通用的能力，包括用戶賬戶、交易、支付、資產(chǎn)、結(jié)算等抽取出來，以獨(dú)立服務(wù)的形式對外提供通用服務(wù)。這樣，原來的業(yè)務(wù)系統(tǒng)更多的充當(dāng)了一個(gè)交易大廳的角色，可以做的更輕，擴(kuò)展也就更容易了。用戶的交易請求通過安全網(wǎng)關(guān)層被統(tǒng)一接入進(jìn)來，我們目前使用了兩套網(wǎng)關(guān)，一套是SLB，另外一套是移動網(wǎng)關(guān)。整套平臺都是在阿里云及螞蟻金融云的I層及P層能力基礎(chǔ)之上構(gòu)建的，我們在它們的基礎(chǔ)之上還構(gòu)建了相應(yīng)的日志監(jiān)控、服務(wù)治理、APM、運(yùn)維管控等一系列能力。以上，就是我們目前實(shí)時(shí)交易平臺的整體服務(wù)化的架構(gòu)。數(shù)據(jù)分析也

13、是金融公司的一項(xiàng)重要工作，我們的大數(shù)據(jù)平臺會從實(shí)時(shí)線上業(yè)務(wù)系統(tǒng)、清結(jié)算系統(tǒng)、運(yùn)營活動、web及APP的用戶埋點(diǎn)中采集各個(gè)維度的數(shù)據(jù)，并以O(shè)DS（操作型數(shù)據(jù)）匯總到數(shù)據(jù)倉庫中，再根據(jù)預(yù)先定義的數(shù)據(jù)模型，抽取出相應(yīng)的主數(shù)據(jù)。在此基礎(chǔ)之上，基于用戶、運(yùn)營、資產(chǎn)、交易、風(fēng)控等主題來構(gòu)建多層次的數(shù)據(jù)集市。有了這個(gè)數(shù)據(jù)集市之后，我們就可以以服務(wù)的形式，在數(shù)據(jù)上做一層服務(wù)化的封裝，在其上進(jìn)行數(shù)據(jù)的應(yīng)用。一類應(yīng)用是數(shù)據(jù)的離線分析，包括留存分析、保有分析、營銷分析等等；另一類應(yīng)用是將這些重度匯總數(shù)據(jù)應(yīng)用在實(shí)時(shí)業(yè)務(wù)之中，尤其是營銷活動之中。我們在這些數(shù)據(jù)集市上，構(gòu)建了一些高級運(yùn)營活動，包括基于用戶綜合資產(chǎn)構(gòu)建的理

14、財(cái)競賽，如“弘運(yùn)榜”、“年度賬單”、“理財(cái)達(dá)人”等等；另外，我們還基于這些不同維度的數(shù)據(jù)，搞了一個(gè)衡量用戶綜合理財(cái)能力的指標(biāo)體系，即“財(cái)商指數(shù)”。我們這套能力是基于阿里云上的大數(shù)據(jù)加工及分析能力來構(gòu)建的，利用了阿里云的odps、DTS、QuickBI等一系列能力。在大數(shù)據(jù)平臺的能力構(gòu)建上，我們遵循如下模式：首先進(jìn)行數(shù)據(jù)模型的規(guī)劃；有了模型之后利用ETL進(jìn)行數(shù)據(jù)的抽取、轉(zhuǎn)換及清洗；接著再利用一系列的規(guī)則對數(shù)據(jù)質(zhì)量進(jìn)行監(jiān)控；將格的數(shù)據(jù)共享出去，供其他方應(yīng)用；另外，定期進(jìn)行數(shù)據(jù)資產(chǎn)評估，基于評估結(jié)果不斷的對模型進(jìn)行優(yōu)化調(diào)整。這樣，就形成了對數(shù)據(jù)的閉環(huán)操作。在這里，要重點(diǎn)強(qiáng)調(diào)的是數(shù)據(jù)質(zhì)量監(jiān)控。對于離線

15、分析，數(shù)據(jù)的精度及實(shí)時(shí)性普遍要求不高；但對于二次使用的匯總數(shù)據(jù)，則有很高的精度要求和實(shí)時(shí)性要求，比如用于用戶競賽排行并有獎勵(lì)的一些運(yùn)營活動，由于每筆交易記錄都與錢掛鉤，用戶對準(zhǔn)確性很敏感，稍有不慎就會引發(fā)大規(guī)模的客訴，因此我們在自構(gòu)建的規(guī)則引擎基礎(chǔ)上，利用數(shù)百條預(yù)先定義的規(guī)則，對數(shù)據(jù)進(jìn)行抽樣或者全量的檢測，一旦檢測到異常，則會自動觸發(fā)人工訂正或者自動化數(shù)據(jù)訂正的任務(wù)。我們目前使用的服務(wù)化的底層框架是螞蟻金融云提供的SOFA-RPC，這是一套脫胎于阿里HSF的P2P直連模式的分布式服務(wù)框架。SOFA-RPC提供了相對簡便的服務(wù)暴露及服務(wù)接入的方式。如上圖所示，它可以基于Spring的擴(kuò)展標(biāo)簽機(jī)制

16、，把一個(gè)Spring的bean實(shí)例以特定的協(xié)議暴露為遠(yuǎn)程服務(wù)，也可以以接口的形式把一個(gè)遠(yuǎn)程服務(wù)接入進(jìn)來，同時(shí)，它還提供了鏈?zhǔn)竭^濾器的機(jī)制，對所有的服務(wù)調(diào)用請求進(jìn)行一個(gè)串行式的處理，我們也可以通過它來實(shí)現(xiàn)一些自定義的服務(wù)管控策略，包括服務(wù)MOCK，線上數(shù)據(jù)采集等能力。單有分布式服務(wù)框架，還不足以保證服務(wù)化的平穩(wěn)落地。企業(yè)服務(wù)化之路要走的順暢，一定是要兩條腿走路的，一條腿是分布式服務(wù)框架，另一條腿是服務(wù)治理，只有兩條腿都健壯，路才能走的順暢。阿里云結(jié)合它線上的資源編排和資源調(diào)度能力，為SOFA-RPC提供了相對完善的服務(wù)生命周期管理的能力，能夠?qū)崿F(xiàn)諸如服務(wù)上線、下線，擴(kuò)容、縮容等操作。同時(shí)，螞蟻還

17、提供了一個(gè)叫Guardian的組件，通過它可以實(shí)現(xiàn)對線上服務(wù)的熔斷限流的自動保護(hù)機(jī)制，類似Netflix提供的Hystrix組件，大家有興趣可以去了解一下。我所在的移動開發(fā)部門，采用了螞蟻的移動開發(fā)平臺MPaaS框架，MpaaS是類似OSGi的一套模塊化的插件管理框架，APP應(yīng)用需要的各種基礎(chǔ)能力都可以以插件的形式集成進(jìn)來，它提供的服務(wù)遠(yuǎn)程調(diào)用能力就是基于SOFA-RPC。我們看一下上面的這個(gè)圖，MpaaS提供了統(tǒng)一的服務(wù)網(wǎng)關(guān)，可以實(shí)現(xiàn)對服務(wù)端的SOFA服務(wù)的遠(yuǎn)程調(diào)用能力；同時(shí)，它還提供了日志網(wǎng)關(guān)和消息網(wǎng)關(guān)，可以實(shí)現(xiàn)對APP上的埋點(diǎn)信息的采集服務(wù)及消息的推送服務(wù)。通過MPaaS這套框架，我們可

18、以相對方便的實(shí)現(xiàn)移動應(yīng)用的開發(fā)工作。以上就是目前我們基金實(shí)時(shí)銷售平臺的整體服務(wù)化的一個(gè)狀況，接下來，我們再介紹一下服務(wù)化對我們研發(fā)和運(yùn)維的影響。服務(wù)化的本質(zhì)就是一個(gè)“拆”字，原來的單體應(yīng)用被拆成了大大小小的應(yīng)用集群和服務(wù)集群，并被分散到網(wǎng)絡(luò)的各個(gè)節(jié)點(diǎn)，由不同的團(tuán)隊(duì)負(fù)責(zé)，每個(gè)團(tuán)隊(duì)各管一段。在這個(gè)背景下，運(yùn)維和研發(fā)都會遭遇一系列新的問題和挑戰(zhàn)，包括故障的定界定位、調(diào)用關(guān)系的梳理、集群環(huán)境下的調(diào)試及分布式環(huán)境下的事務(wù)一致性的保障等等。接下來就來看看，我們是如何破解這些困局的?！局挥懈咝У氖占€上服務(wù)的日志，才能更好的對服務(wù)進(jìn)行監(jiān)控和管控】傳統(tǒng)的日志收集一般采用諸如log4j這類的日志組件進(jìn)行日志的

19、落盤，再通過logstash或者flume這類的日志采集組件進(jìn)行落盤日志的增量收集，通過這種方式進(jìn)行日志采集存在大量的磁盤IO。對于線上服務(wù)器來說，最大的性能瓶頸就是磁盤IO，尤其是在高并發(fā)和高負(fù)載環(huán)境下，磁盤IO對系統(tǒng)性能的影響會被成倍放大。我們的測試顯示，在整個(gè)系統(tǒng)負(fù)載被打滿的前提下，日志采集所產(chǎn)生的整體性能消耗占了總資源的40%左右。為了降低系統(tǒng)資源占用，同時(shí)更高效的采集服務(wù)日志，我們開發(fā)了無磁盤IO的日志采集方式。具體流程是：采用類似Spring AOP的方式，對服務(wù)的請求進(jìn)行擋截，采集服務(wù)的調(diào)用延時(shí)、服務(wù)狀態(tài)等信息；同時(shí)，根據(jù)自定義的配置，抓取特定的入?yún)⒑统鰠?shù)據(jù)，所有這些信息都會被

20、封裝到一個(gè)消息對象之中，并扔到一個(gè)內(nèi)存消息隊(duì)列之中進(jìn)行緩存；與此同時(shí)，有獨(dú)立的線程對這些消息進(jìn)行預(yù)處理（如果需要的話），預(yù)處理結(jié)果也會被壓入內(nèi)存消息隊(duì)列中再次進(jìn)行緩存；最后，由獨(dú)立的發(fā)送線程將這些內(nèi)存消息隊(duì)列中的原始日志或者預(yù)處理數(shù)據(jù)發(fā)送到遠(yuǎn)程的日志手機(jī)端。在日志的收集端，接進(jìn)來的日志統(tǒng)一被扔到內(nèi)存消息隊(duì)列中緩存，再被分散到不同時(shí)間片段對應(yīng)的二級消息隊(duì)列中，由獨(dú)立的分析器實(shí)例集合進(jìn)行分析和落盤存儲，通過這種純內(nèi)存+全異步的處理方式，我們就可以最大限度的避免資源鎖的競爭，并榨取服務(wù)器的性能，從而實(shí)現(xiàn)對日志的高效的處理。通過這套體系，在不堵塞的情況下，任何一個(gè)服務(wù)節(jié)點(diǎn)的故障，在12秒之內(nèi)就能被我們

21、的分析器捕捉到。如果把分布式服務(wù)框架比作是“咖啡”的話，那應(yīng)用性能管理中的調(diào)用鏈監(jiān)控及分析就是“奶昔”了，咖啡和奶昔是什么，是絕配！調(diào)用鏈比常規(guī)的日志收集方式更關(guān)注日志之間的關(guān)系，它通過一個(gè)統(tǒng)一的traceId把不同服務(wù)節(jié)點(diǎn)上的日志聚合在一起，來完整描述一個(gè)請求的調(diào)用過程，通過這個(gè)調(diào)用鏈路，我們可以發(fā)現(xiàn)服務(wù)的性能瓶頸在哪里、埋點(diǎn)的缺失情況、網(wǎng)絡(luò)的質(zhì)量等等一系列信息，通過調(diào)用鏈的聚合，還可以獲取到服務(wù)集群的負(fù)載和健康度等更復(fù)雜的信息。調(diào)用鏈能夠有效解決分布式環(huán)境下的監(jiān)控需求，但在使用調(diào)用鏈的過程中，也要平衡全采集還是抽樣采集、自動插碼埋點(diǎn)還是手動埋點(diǎn)、實(shí)時(shí)統(tǒng)計(jì)還是預(yù)統(tǒng)計(jì)等等這些問題，如何權(quán)衡，需

22、要根據(jù)自身的特點(diǎn)及技術(shù)實(shí)力來做決策。今天由于時(shí)間關(guān)系，不在這里展開了，如果有感興趣的同學(xué)，可以關(guān)注我在大會后兩天的深度培訓(xùn)微服務(wù)治理的探索與實(shí)踐。我們前面說了，企業(yè)服務(wù)化落地要兩條“腿”走路，一條是服務(wù)框架，另外一條就是服務(wù)治理，服務(wù)化之路要走的順暢，一定是兩條腿都健壯。通過幾年的努力，我們已經(jīng)初步構(gòu)建了服務(wù)化的治理體系，能夠覆蓋到服務(wù)監(jiān)控和服務(wù)管控的大部分需求，其中管控的大部分能力是依托于螞蟻金融云的能力來構(gòu)建的，而監(jiān)控這部分能力則是在SOFA-RPC的基礎(chǔ)上，通過整合常規(guī)日志體系及APM監(jiān)控的能力來綜合獲取的。服務(wù)監(jiān)控這塊，我們從各個(gè)服務(wù)節(jié)點(diǎn)抽取服務(wù)調(diào)用延時(shí)、調(diào)用狀態(tài)、調(diào)用異常等信息，并匯

23、總到日志中心進(jìn)行綜合統(tǒng)計(jì)，得到各類的監(jiān)控報(bào)表和監(jiān)控大盤。通過錯(cuò)誤信息，我們可以進(jìn)行線上的故障定位定界；通過調(diào)用量的各級匯總，我們可以獲取線上實(shí)時(shí)“水位”，進(jìn)而進(jìn)行客觀的容量規(guī)劃；通過調(diào)用延時(shí)和錯(cuò)誤率，我們可以推斷線上服務(wù)的健康度；在這些數(shù)據(jù)的基礎(chǔ)上，基于時(shí)間維度，還可以獲取到服務(wù)隨時(shí)間的質(zhì)量演進(jìn)情況，這樣的話，我們對整個(gè)服務(wù)集群就能有一個(gè)全面而實(shí)時(shí)的了解，并在此基礎(chǔ)上，做出正確的管控決策。通過服務(wù)管控，可以將服務(wù)生命周期管理的調(diào)度指令下發(fā)到發(fā)布系統(tǒng)，進(jìn)行服務(wù)的上線、下線、擴(kuò)容、縮容等操作，另外限流、降級、調(diào)整負(fù)載的指令則會直接下發(fā)到各個(gè)服務(wù)節(jié)點(diǎn)中，由服務(wù)框架的SDK進(jìn)行相應(yīng)的調(diào)整動作。這樣，通

24、過服務(wù)的監(jiān)控（左邊）和服務(wù)的管控（右邊），就形成了針對服務(wù)治理的一個(gè)閉環(huán)的操作。在服務(wù)化的過程中，研發(fā)遇到的第一個(gè)困難，一定是調(diào)試。原來單體應(yīng)用中的服務(wù)被拆分到不同團(tuán)隊(duì)，并部署在不同的服務(wù)器上，而本地只有一個(gè)服務(wù)接口。這時(shí)候要做調(diào)試，要么做P2P直連，要么做MOCK。采用傳統(tǒng)的MOCk手段，要寫一堆的MOCK語句，比如用mockito，就要寫一堆的when.thenReturn.的語句，耦合度非常的高。我們是利用分布式服務(wù)框架提供的過濾器機(jī)制，開發(fā)了一個(gè)Mock過濾器，并通過Mock數(shù)據(jù)文件來詳細(xì)定義要被mock的服務(wù)的名稱、入?yún)⒓俺鰠ⅰ＿@樣，當(dāng)請求過來的時(shí)候，將服務(wù)名及入?yún)⒑蚼ock數(shù)據(jù)中的

25、定義進(jìn)行比對，結(jié)果吻合，則直接將mock數(shù)據(jù)文件中的出參反序列化后作為服務(wù)的調(diào)用結(jié)果直接返回，同時(shí)遠(yuǎn)程調(diào)用的所有后續(xù)操作被終止。這樣，就通過mock數(shù)據(jù)模擬了一個(gè)真實(shí)的遠(yuǎn)程服務(wù)。Mock過濾器的啟用可以通過配置文件來實(shí)現(xiàn)“開關(guān)控制”，可以只在開發(fā)和測試環(huán)境啟用，生產(chǎn)環(huán)境關(guān)閉。通過這種方式來構(gòu)建服務(wù)的mock能力，我們就不需要寫一堆的mock代碼了，而且整個(gè)過程對業(yè)務(wù)邏輯來說完全無感知，完全把mock能力下沉到底層的服務(wù)框架。通過這種方式構(gòu)建的分布式服務(wù)的mock能力，除了mock過濾器，最核心的就是Mock數(shù)據(jù)的構(gòu)建。mock數(shù)據(jù)的質(zhì)量直接決定了調(diào)測的質(zhì)量！說起mock數(shù)據(jù)，它所做的無非就是匹

26、配哪個(gè)服務(wù)、輸入的參數(shù)是什么，輸出的結(jié)果又是什么。但實(shí)際的情況往往更復(fù)雜，你不可能通過靜態(tài)數(shù)據(jù)去構(gòu)建一個(gè)所謂的“當(dāng)前時(shí)間”吧！因此，mock數(shù)據(jù)除了支持靜態(tài)輸入輸出數(shù)據(jù)的比對，還需要支持動態(tài)匹配模式，也就是支持腳本匹配，我們所構(gòu)建的服務(wù)mock框架，支持在mock數(shù)據(jù)中同時(shí)使用bsh和groovy這兩種腳本。另外，一個(gè)服務(wù)集群中，往往會存在同一服務(wù)的不同版本，因此要真實(shí)模擬現(xiàn)實(shí)情況的話，mock數(shù)據(jù)也必須有版本的概念。除了以上兩種匹配模式，我們針對實(shí)際情況，還開發(fā)了第三種mock模式，就是可以針對一個(gè)真實(shí)請求，部分修改它的回參來模擬出一個(gè)第三方的結(jié)果，這種方式在參數(shù)量非常多的情況下非常有用。所

27、以，要構(gòu)建好一個(gè)Mock數(shù)據(jù)是需要投入不少工作量的，那么誰來做這個(gè)事情呢？這實(shí)際上牽涉到管理規(guī)范了。我們的規(guī)定是，服務(wù)誰提供，就由誰來構(gòu)建這個(gè)mock數(shù)據(jù)，服務(wù)調(diào)用方可以在這個(gè)基礎(chǔ)上做修改或者替換。但這還不夠，由于服務(wù)會非常多，因此，對mock數(shù)據(jù)的管理一定要體系化和工程化。我的建議是，可以采用獨(dú)立的項(xiàng)目工程對mock數(shù)據(jù)進(jìn)行獨(dú)立的管理和發(fā)布。目前，我們針對前端和服務(wù)端都開發(fā)了完整的mock能力，可以讓開發(fā)人員在基本“無感”的狀態(tài)下進(jìn)行本地化的功能調(diào)測，同時(shí)提供一些自研的小工具來自動生成mock文件，以降低構(gòu)建mock的難度和人力投入。為了有效降低制作mock文件的成本，我們還基于服務(wù)框架的過

28、濾器機(jī)制開發(fā)了“在線數(shù)據(jù)抓取過濾器”，它可以將指定的服務(wù)請求的入?yún)⒑头祷亟Y(jié)果都抓取下來，并直接寫成mock數(shù)據(jù)文件。通過抓取方式獲得的mock數(shù)據(jù)文件，往往有更好的數(shù)據(jù)質(zhì)量，畢竟反映的是更加真實(shí)的業(yè)務(wù)場景。當(dāng)然了，這里還有一個(gè)合規(guī)性的問題，對線上數(shù)據(jù)的抓取是種敏感行為，大部分公司這么干都會很謹(jǐn)慎，一般都要做好數(shù)據(jù)脫敏的處理工作。對于我們，目前只在測試環(huán)境中進(jìn)行數(shù)據(jù)抓取操作。事務(wù)的一致性和可用性問題是分布式環(huán)境下“老生常談”的問題了，相信大家也或多或少遇到過這類問題。針對分布式事務(wù)，我們采取了3級應(yīng)對的策略。首先，在分庫分表操作中，我們會堅(jiān)持“實(shí)體組”優(yōu)先的策略，盡量按照統(tǒng)一的“片鍵”進(jìn)行分庫分

29、表操作，比如說，如果統(tǒng)一按“用戶賬戶ID”作為分庫分表鍵的話，那么用戶相關(guān)的交易、資產(chǎn)、支付等相關(guān)信息都會落到同一個(gè)物理庫實(shí)例之中，這樣的話，針對此用戶的相關(guān)操作，本地事務(wù)就可以生效，從而避免了分布式事務(wù)的使用。因?yàn)閷τ谌魏畏植际绞聞?wù)而言，不管做不做資源鎖定，為了有效保障事務(wù)狀態(tài)，都需要額外的資源處理消耗。另外，我們還提供了自研的支持多級事務(wù)的TCC服務(wù)，以應(yīng)對不可避免的分布式事務(wù)需求。采用TCC的原因最主要還是在于相對其它資源管理器而言，它相對簡單，我們不用關(guān)注資源層面，只需要關(guān)注服務(wù)接口即可。上面的第二張圖是TCC的典型架構(gòu)模式圖，相信只要研究過TCC的同學(xué)們一定看過這張圖，第三張則是我們

30、自研的TCC的一個(gè)更詳細(xì)的交互架構(gòu)圖，能體現(xiàn)更多技術(shù)細(xì)節(jié)，希望能對大家有所參考借鑒?？偟膩碚f，從我個(gè)人的理解而言，自己實(shí)現(xiàn)一個(gè)TCC框架（獨(dú)立服務(wù)）并不麻煩，最核心的是要解決兩大核心問題，一個(gè)是參與事務(wù)的業(yè)務(wù)數(shù)據(jù)的緩存和回放問題，我們在做TRY操作的時(shí)候，就需要將事務(wù)數(shù)據(jù)緩存起來，可以存到數(shù)據(jù)庫中，當(dāng)框架做Confirm和Cancel操作時(shí)，再用緩存的事務(wù)數(shù)據(jù)去運(yùn)行特定的服務(wù)邏輯，所以，這就要求在TRY、Confirm和Cancel的方法構(gòu)造上要有一定的約束，也就是相互之間要能夠識別哪些入?yún)⑹鞘聞?wù)數(shù)據(jù)；另一個(gè)是父子事務(wù)的事務(wù)ID的傳遞問題，我們通過分布式服務(wù)框架的“非業(yè)務(wù)傳參”來解決這個(gè)問題，

31、一旦某一個(gè)事務(wù)構(gòu)建了一個(gè)事務(wù)ID，這個(gè)事務(wù)ID就會被放置到環(huán)境上下文之中，并隨著RPC調(diào)用傳遞到遠(yuǎn)程服務(wù)，遠(yuǎn)程服務(wù)如果偵測到上下文中已經(jīng)存在事務(wù)ID了，則就不再構(gòu)建新的事務(wù)ID，這樣的話，父子事務(wù)之間就通過同一個(gè)事務(wù)ID關(guān)聯(lián)在一起。最后，最終一致性的保障一定是“對賬、對賬、對賬”，這是最傳統(tǒng)，也是最可靠的最后一道防線，這也是金融公司的基礎(chǔ)能力，這里我就不展開詳細(xì)說了。服務(wù)化之后，每個(gè)團(tuán)隊(duì)負(fù)責(zé)一部分的服務(wù)，經(jīng)常一個(gè)業(yè)務(wù)會涉及多個(gè)團(tuán)隊(duì)之間的協(xié)同配合，如何讓團(tuán)隊(duì)內(nèi)部、團(tuán)隊(duì)之間的協(xié)作更高效，天弘內(nèi)部也做了不同的嘗試，從綜合效果來說，敏捷模式會更適合一些。以我們移動平臺團(tuán)隊(duì)舉例，我們目前采用兩周一迭代、固定發(fā)版的模式，同時(shí)每個(gè)迭代之內(nèi)，采用“火車發(fā)布模式”，實(shí)行班車制，準(zhǔn)點(diǎn)發(fā)車，這樣的話，其它協(xié)作部門在很早之前就能大概知道我們的一個(gè)發(fā)布計(jì)劃，產(chǎn)品方面也大概知道要把需求放入哪個(gè)迭代之中。這樣，能夠有效減輕部門間的溝通成本。在每期工