乾貨 | 餘額寶大規模服務化的技術創新

時間 2019-11-17

標籤乾貨餘額大規模服務技術創新简体版

原文原文鏈接

本文做者：李鑫，天弘基金移動平臺部任技術總監兼首架，主要負責天弘移動直銷平臺的總體技術架構和技術團隊管理。前端

在此以前，在華爲的中間件技術團隊，任六級技術專家，主導了多款華爲軟件的雲計算產品的規劃、設計、構建及落地工做，包括 APaaS、ASPaaS、服務治理平臺、分佈式服務調測框架等幾款產品；更早以前，在噹噹網的運做產品中心作技術負責人，主要負責電商中後臺的倉儲、物流、客服等系統的重構優化及技術管理工做。
git

我的從業十多年，作過不少技術方向，也是從項目版本研發慢慢到中間件研發，再到平臺研發，涉及的技術領域比較多。在並行計算、大規模分佈式服務及治理、中間件雲化及服務化（PaaS）、APM 監控、基礎開發平臺、數據集成等領域都有些技術積累，若是你們在這些領域有疑問或好的建議，歡迎加個人微信號共同探討。github

七月初，李鑫在 ArchSummit 深圳大會上作了題爲《餘額寶大規模服務化的技術創新》的分享，現場反響熱烈。現將 PPT 和講稿整理出來，分享給你們，但願能給你們一些啓發，也歡迎留言討論。web

分享分爲三部分：

餘額寶的總體架構變遷歷史；算法
講一講咱們是如何進行基金實時銷售平臺及大數據平臺的服務化改造的；數據庫
「服務化」對咱們運維及研發模式的影響及咱們的應對策略；後端

餘額寶的總體架構變遷歷史

餘額寶本質上是一支貨幣基金，它的背後是天弘的增利寶基金。因爲和支付寶的關係，它既是理財產品，又是支付產品，理財和支付的雙重屬性，再加上互聯網產品所特有的極簡的用戶體驗，讓餘額寶一經推出，迅速成爲了「爆款」，短短五年內得到了一個驚人的發展。能夠絕不誇張的說，餘額寶的出現，開啓了中國的全民理財時代！緩存

爲了適應業務的爆炸式增加，5年來餘額寶的技術架構作了4次大的變動，每次技術變動的背後，都承載了天弘技術團隊對系統規模、可擴展性及升級成本的綜合考量和平衡之道。安全

餘額寶上線之初，解決的是「從無到有」的問題。服務器

當時沒有其它相似的互聯網金融產品能夠作參考，咱們採用了傳統的典型企業級金融架構。因爲採用的是自建 IDC 機房的方式，咱們用硬件負載均衡設備將交易請求接入進來，前端是由兩臺 weblogic 構成的小型的前置處理集羣，請求被稍作處理以後，即被送到後端由金正的基金交易中間件構建的集羣作業務處理，其中 KCXP 和 KCBP 是金證公司的消息中間件和業務中間件，業務數據存儲採用的是兩臺Oracle數據庫服務器構建的一主一備的小集羣，這個是線上庫，同時，還有一個一樣架構的歷史庫服務。硬件方面採用的都是小型機設備，數據備份則採用EMC的產品。

這是典型的 IOE 架構，全套的商用軟硬件配置，成本很高。架構體系雖然不少環節都採用了集羣的方式，但更多的是使用主備模式，而不是負載均衡的分佈式模式，所以系統的單點資源負載壓力較大，尤爲是數據庫，基本上就是單庫模式（另外一個庫是備庫），擴展性較差。

當時的系統容量設計上限是能支持千萬級用戶，傳統基金銷售模式是走代銷機構的方式，投資基金用戶也多以理財爲目的。因此天天可能處理的賬戶開戶也就是幾萬到幾十萬的規模。因爲餘額寶對接是支付寶，支付寶的用戶規模達到千萬級，這是設計產品時對需求的定位。按照預估，這個設計容量怎麼都能扛個幾年。結果，咱們低估了餘額寶的熱度，上線短短10天左右，新開戶數已經突破100W了，按這個速度，3個月左右數據庫容量上線就要被突破。事實也確實如此，咱們的客戶量三個月就達到一千萬，餘額寶一期系統的生命週期只有三個月！

因此一期系統一上線，團隊就不得不開始考慮擴容，計劃將容量擴充30~50倍，計算規模也同步增長。若是仍是採用一期系統的純商用軟硬件的模式進行橫向擴展的話，成本要達到1~2個億，這樣的成本對於當時天弘這樣一家小型基金公司而言，是不可負擔之重！所以，在阿里的建議下，咱們決定總體上雲。

當時作出這個決定的壓力仍是很是大的，由於當時沒有任何一家金融公司和基金公司這麼玩，咱們成了第一個吃螃蟹的人。但在巨大的成本壓力之下，咱們走出了這一步，這就是餘額寶 2.0！

餘額寶 2.0 的架構中用阿里雲上的軟負載均衡 SLB 替換了硬件負載均衡；用阿里雲上的虛擬計算單元 ECS 替換小型機成爲前置服務及中間件服務的服務器；用阿里雲的 web 服務替換了前置服務器上的 weblogic。

最大的一個變化是數據庫層面，原來的 Oracle 單庫被替換成了阿里雲上的一個 50 個節點的 RDS 集羣，實際上就是進行了分庫分表的拆分，通過測算，須要使用 50 組業務節點，但在拆分時，考慮到擴展性，並未簡單地拆分紅 50 份，而是根據用戶賬號 ID 做爲分片主鍵將核心業務表拆分紅 1000 份，而後每一個節點處理 20 份數據（物理子表）。這樣作的好處是未來若是系統遇到瓶頸，須要擴容時，不須要對拆分算法進行修改，並且數據平均遷移時只須要以庫爲級別進行，從而避免了拆表。

上雲後，不只數據庫總容量有了幾十倍的提高，交易處理效率也從一期的 120W 筆/小時提高到了近 2000W 筆/小時；最大清算時間從以前的7個多小時下降到了不到 2 個小時；而總成本，才增長了不到 1 倍。因此，上雲對咱們系統總體效率的提高和成本的下降有很是明顯的做用。

餘額寶 2.0 的架構穩定運行了近 3 年，中間經歷了幾回小的升級優化，有力支撐了這個過程當中的各類業務創新，但也在支撐業務快速發展中埋下了一些「坑」。

2016 年，咱們決定對系統進行一次大升級。此次升級的主要基調就是「業務邏輯重構，優化清算流程」，這就是餘額寶 3.0！

這一階段的業務邏輯複雜度要遠遠高於 3 年前，所以 3.0 的架構中，計算單元比 2.0 有了明顯的擴充。因爲數據庫前期預留的 buffer 比較大，並無成爲本階段的瓶頸，依然維持了 50 個節點的規模。

此次升級以後，整體計算能力有了較大幅度的提升。處理效率比起 2.0 的時候增加了 2 倍多，也支撐了 2016 年春節期間日交易4億多筆的峯值。可是，清算時間比 2.0 時期有較大增加，這成了系統的一個「隱患」。

2017 年，爲了配合支付寶拓寬線下支付場景，並將業務推廣覆蓋到3、四線城市，同時，也要解決清算時間過長的隱患，咱們規劃了餘額寶 4.0 的升級。

這一階段的系統規模已經很大了，若是仍是按 3.0 的架構進行橫向擴充的話，成本將呈線性增加。通過綜合考量，決定在升級前，先優化單節點的處理性能，提升效率及負載後再擴容，以下降整體的升級成本。

所以，此次升級首先將直銷和代銷業務合二爲一，同一臺計算單元既處理直銷業務，也處理代銷業務，提升了單點的處理效率。在此基礎上，再進行擴容，將計算單元從 340 節點擴充到 480 節點，數據庫擴容4倍。經過這兩步優化及擴充動做，最終系統的容量及計算能力均有了 4~8 倍的提升，這套新的架構支撐咱們平穩度過了 2017 年雙十一及春節的交易高峯。

看到這裏，你們可能會有疑問：通常在系統服務化改造中，服務是會被拆的愈來愈細，爲何咱們反其道而行，反而對服務進行了整合？這是由於，餘額寶發展到如今，業務模式已經比較成熟，經過細粒度的服務模態來保證可擴展性的需求已經不是那麼強烈；另外一方面，系統規模龐大，擴容的成本成爲重點考慮因素；綜合這兩方面的考量，適當增長單點的複雜度，能夠下降總體成本。

目前，針對餘額寶這單隻基金已經創建起了一套完整的技術生態體系，它的核心是餘額寶的產品、賬號、交易、清算等模塊，在結合實時調用和文件交互兩套接口的基礎上，構建了電商大數據的分析體系及一系列輔助支撐系統。同時，餘額寶系統和其它第三方系統也有大量的交互，包括支付寶、監管、直代銷渠道等等。

咱們是如何進行基金實時銷售平臺及大數據平臺的服務化改造的

餘額寶系統的建設直接鍛鍊了天弘的技術團隊，讓咱們明白了大型互聯網應用是一個什麼樣的玩法，這也直接推進了天弘自有的基金直銷平臺的服務化改造。接下來，我將從基金實時交易平臺及大數據平臺的服務化改造這兩方面來對此分別作詳細介紹。

在開始這塊的內容以前，先簡單的給你們介紹一下基金公司的業務。

基金公司最主要的就是「買賣」基金，咱們從直銷和代銷渠道把交易請求「接」進來，在咱們的核心交易系統進行申購、認購、定投、贖回、轉換等等操做，這個過程裏，會涉及與支付渠道、銀行等一系列的交付；同時，還有大量的清結算和TA清算，這個過程裏，還要和銀證監會、中登等一系列監管機構有數據上的交互。聚攏過來的巨量的資金會被統一管控、並投入到股市、債市、貨幣市場等投資市場去賺錢收益。圍繞這個業務還有相應的投研、基金產品管理、風控、客服等中後臺的業務支持。

以上，就是基金公司的平常業務模式。

在天弘早期的基金銷售系統的建設中，其實沒有什麼服務化的概念，當時的模式是有什麼類型的業務，就針對這種業務單獨開發一套獨立的銷售及清結算系統。因爲業務量廣泛不大，這些系統每每採用單體架構模式，不考慮橫向擴展性。通過多年的發展和積累，內部多套直銷及代銷交易系統並存，系統間賬號沒有打通，用戶的資產數據沒法統一，用戶體驗差；另外一方面，各系統間功能重複的現象嚴重，不只重複佔用軟硬件資源，版本的控制也很麻煩。

這種情況甚至在咱們總體遷移到雲上以後還存在了很長的一段時間，因此，所謂的「服務化」，並非僅僅上雲那麼簡單，它更多的仍是涉及到架構思惟的轉變。

痛定思痛以後，咱們決定將這些系統中通用的能力，包括用戶帳戶、交易、支付、資產、結算等抽取出來，以獨立服務的形式對外提供通用服務。這樣，原來的業務系統更多的充當了一個交易大廳的角色，能夠作的更輕，擴展也就更容易了。用戶的交易請求經過安全網關層被統一接入進來，咱們目前使用了兩套網關，一套是 SLB，另一套是移動網關。整套平臺都是在阿里雲及螞蟻金融雲的I層及P層能力基礎之上構建的，咱們在它們的基礎之上還構建了相應的日誌監控、服務治理、APM、運維管控等一系列能力。

以上，就是咱們目前實時交易平臺的總體服務化的架構。

數據分析也是金融公司的一項重要工做，咱們的大數據平臺會從實時線上業務系統、清結算系統、運營活動、web 及 APP 的用戶埋點中採集各個維度的數據，並以 ODS（操做型數據）彙總到數據倉庫中，再根據預先定義的數據模型，抽取出相應的主數據。在此基礎之上，基於用戶、運營、資產、交易、風控等主題來構建多層次的數據集市。有了這個數據集市以後，咱們就能夠以服務的形式，在數據上作一層服務化的封裝，在其上進行數據的應用。一類應用是數據的離線分析，包括留存分析、保有分析、營銷分析等等；另外一類應用是將這些重度彙總數據應用在實時業務之中，尤爲是營銷活動之中。咱們在這些數據集市上，構建了一些高級運營活動，包括基於用戶綜合資產構建的理財競賽，如「弘運榜」、「年度帳單」、「理財達人」等等；另外，咱們還基於這些不一樣維度的數據，搞了一個衡量用戶綜合理財能力的指標體系，即「財商指數」。

咱們這套能力是基於阿里雲上的大數據加工及分析能力來構建的，利用了阿里雲的 MaxCompute、DTS、QuickBI 等一系列能力。在大數據平臺的能力構建上，咱們遵循以下模式：首先進行數據模型的規劃；有了模型以後利用 ETL 進行數據的抽取、轉換及清洗；接着再利用一系列的規則對數據質量進行監控；將格的數據共享出去，供其餘方應用；另外，按期進行數據資產評估，基於評估結果不斷的對模型進行優化調整。這樣，就造成了對數據的閉環操做。

在這裏，要重點強調的是數據質量監控。對於離線分析，數據的精度及實時性廣泛要求不高；但對於二次使用的彙總數據，則有很高的精度要求和實時性要求，好比用於用戶競賽排行並有獎勵的一些運營活動，因爲每筆交易記錄都與錢掛鉤，用戶對準確性很敏感，稍有不慎就會引起大規模的客訴，所以咱們在自構建的規則引擎基礎上，利用數百條預先定義的規則，對數據進行抽樣或者全量的檢測，一旦檢測到異常，則會自動觸發人工訂正或者自動化數據訂正的任務。

咱們目前使用的服務化的底層框架是螞蟻金融雲提供的 SOFARPC。SOFARPC 提供了相對簡便的服務暴露及服務接入的方式。如上圖所示，它能夠基於Spring的擴展標籤機制，把一個 Spring 的 bean 實例以特定的協議暴露爲遠程服務，也能夠以接口的形式把一個遠程服務接入進來，同時，它還提供了鏈式過濾器的機制，對全部的服務調用請求進行一個串行式的處理，咱們也能夠經過它來實現一些自定義的服務管控策略，包括服務 Mock，線上數據採集等能力。

單有分佈式服務框架，還不足以保證服務化的平穩落地。企業服務化之路要走的順暢，必定是要兩條腿走路的，一條腿是分佈式服務框架，另外一條腿是服務治理，只有兩條腿都健壯，路才能走的順暢。阿里雲結合它線上的資源編排和資源調度能力，爲 SOFARPC 提供了相對完善的服務生命週期管理的能力，可以實現諸如服務上線、下線，擴容、縮容等操做。同時，螞蟻還提供了一個叫 Guardian 的組件，經過它能夠實現對線上服務的熔斷限流的自動保護機制，相似 Netflix 提供的 Hystrix 組件，你們有興趣能夠去了解一下。

我所在的移動開發部門，採用了螞蟻的移動開發平臺 mPaaS 框架，mPaaS 是相似 OSGi的一套模塊化的插件管理框架，APP 應用須要的各類基礎能力均可以以插件的形式集成進來，它提供的服務遠程調用能力就是基於 SOFARPC。咱們看一下上面的這個圖，mpaaS提供了統一的服務網關，能夠實現對服務端的 SOFA 服務的遠程調用能力；同時，它還提供了日誌網關和消息網關，能夠實現對 APP 上的埋點信息的採集服務及消息的推送服務。經過 mPaaS 這套框架，咱們能夠相對方便的實現移動應用的開發工做。

以上就是目前咱們基金實時銷售平臺的總體服務化的一個情況，接下來，咱們再介紹一下服務化對咱們研發和運維的影響。

「服務化」對咱們運維及研發模式的影響及咱們的應對策略

服務化的本質就是一個「拆」字，原來的單體應用被拆成了大大小小的應用集羣和服務集羣，並被分散到網絡的各個節點，由不一樣的團隊負責，每一個團隊各管一段。在這個背景下，運維和研發都會遭遇一系列新的問題和挑戰，包括故障的定界定位、調用關係的梳理、集羣環境下的調試及分佈式環境下的事務一致性的保障等等。

接下來就來看看，咱們是如何破解這些困局的。

【只有更高效的收集線上服務的日誌，才能更好的對服務進行監控和管控】

傳統的日誌收集通常採用諸如 log4j 這類的日誌組件進行日誌的落盤，再經過 logstash 或者flume 這類的日誌採集組件進行落盤日誌的增量收集，經過這種方式進行日誌採集存在大量的磁盤 IO。對於線上服務器來講，最大的性能瓶頸就是磁盤 IO，尤爲是在高併發和高負載環境下，磁盤 IO 對系統性能的影響會被成倍放大。咱們的測試顯示，在整個系統負載被打滿的前提下，日誌採集所產生的總體性能消耗佔了總資源的 40% 左右。

爲了下降系統資源佔用，同時更高效的採集服務日誌，咱們開發了無磁盤IO的日誌採集方式。具體流程是：採用相似 Spring AOP 的方式，對服務的請求進行擋截，採集服務的調用延時、服務狀態等信息；同時，根據自定義的配置，抓取特定的入參和出參數據，全部這些信息都會被封裝到一個消息對象之中，並扔到一個內存消息隊列之中進行緩存；與此同時，有獨立的線程對這些消息進行預處理（若是須要的話），預處理結果也會被壓入內存消息隊列中再次進行緩存；最後，由獨立的發送線程將這些內存消息隊列中的原始日誌或者預處理數據發送到遠程的日誌手機端。

在日誌的收集端，接進來的日誌統一被扔到內存消息隊列中緩存，再被分散到不一樣時間片斷對應的二級消息隊列中，由獨立的分析器實例集合進行分析和落盤存儲，經過這種純內存+全異步的處理方式，咱們就能夠最大限度的避免資源鎖的競爭，並榨取服務器的性能，從而實現對日誌的高效的處理。

經過這套體系，在不堵塞的狀況下，任何一個服務節點的故障，在1~2秒以內就能被咱們的分析器捕捉到。

若是把分佈式服務框架比做是「咖啡」的話，那應用性能管理中的調用鏈監控及分析就是「奶昔」了，咖啡和奶昔是什麼，是絕配！

調用鏈比常規的日誌收集方式更關注日誌之間的關係，它經過一個統一的 traceId 把不一樣服務節點上的日誌聚合在一塊兒，來完整描述一個請求的調用過程，經過這個調用鏈路，咱們能夠發現服務的性能瓶頸在哪裏、埋點的缺失狀況、網絡的質量等等一系列信息，經過調用鏈的聚合，還能夠獲取到服務集羣的負載和健康度等更復雜的信息。

調用鏈可以有效解決分佈式環境下的監控需求，但在使用調用鏈的過程當中，也要平衡全採集仍是抽樣採集、自動插碼埋點仍是手動埋點、實時統計仍是預統計等等這些問題，如何權衡，須要根據自身的特色及技術實力來作決策。今天因爲時間關係，不在這裏展開了，若是有感興趣的同窗，能夠關注我在大會後兩天的深度培訓《微服務治理的探索與實踐》。

咱們前面說了，企業服務化落地要兩條「腿」走路，一條是服務框架，另一條就是服務治理，服務化之路要走的順暢，必定是兩條腿都健壯。

經過幾年的努力，咱們已經初步構建了服務化的治理體系，可以覆蓋到服務監控和服務管控的大部分需求，其中管控的大部分能力是依託於螞蟻金融雲的能力來構建的，而監控這部分能力則是在 SOFARPC 的基礎上，經過整合常規日誌體系及 APM 監控的能力來綜合獲取的。

服務監控這塊，咱們從各個服務節點抽取服務調用延時、調用狀態、調用異常等信息，並彙總到日誌中心進行綜合統計，獲得各種的監控報表和監控大盤。經過錯誤信息，咱們能夠進行線上的故障定位定界；經過調用量的各級彙總，咱們能夠獲取線上實時「水位」，進而進行客觀的容量規劃；經過調用延時和錯誤率，咱們能夠推斷線上服務的健康度；在這些數據的基礎上，基於時間維度，還能夠獲取到服務隨時間的質量演進狀況，這樣的話，咱們對整個服務集羣就能有一個全面而實時的瞭解，並在此基礎上，作出正確的管控決策。

經過服務管控，能夠將服務生命週期管理的調度指令下發到發佈系統，進行服務的上線、下線、擴容、縮容等操做，另外限流、降級、調整負載的指令則會直接下發到各個服務節點中，由服務框架的 SDK 進行相應的調整動做。

這樣，經過服務的監控（左邊）和服務的管控（右邊），就造成了針對服務治理的一個閉環的操做。

在服務化的過程當中，研發遇到的第一個困難，必定是調試。原來單體應用中的服務被拆分到不一樣團隊，並部署在不一樣的服務器上，而本地只有一個服務接口。這時候要作調試，要麼作 P2P 直連，要麼作 Mock 。採用傳統的 Mock 手段，要寫一堆的 Mock 語句，好比用 mockito，就要寫一堆的 when…..thenReturn….的語句，耦合度很是的高。

咱們是利用分佈式服務框架提供的過濾器機制，開發了一個Mock 過濾器，並經過 Mock 數據文件來詳細定義要被 Mock 的服務的名稱、入參及出參。這樣，當請求過來的時候，將服務名及入參和 Mock 數據中的定義進行比對，結果吻合，則直接將 Mock 數據文件中的出參反序列化後做爲服務的調用結果直接返回，同時遠程調用的全部後續操做被終止。這樣，就經過 Mock 數據模擬了一個真實的遠程服務。

Mock 過濾器的啓用能夠經過配置文件來實現「開關控制」，能夠只在開發和測試環境啓用，生產環境關閉。

經過這種方式來構建服務的 Mock 能力，咱們就不須要寫一堆的 Mock 代碼了，並且整個過程對業務邏輯來講徹底無感知，徹底把 Mock 能力下沉到底層的服務框架。

經過這種方式構建的分佈式服務的 Mock 能力，除了 Mock 過濾器，最核心的就是 Mock數據的構建。

Mock 數據的質量直接決定了調測的質量！

提及 Mock 數據，它所作的無非就是匹配哪一個服務、輸入的參數是什麼，輸出的結果又是什麼。但實際的狀況每每更復雜，你不可能經過靜態數據去構建一個所謂的「當前時間」吧！所以，Mock 數據除了支持靜態輸入輸出數據的比對，還須要支持動態匹配模式，也就是支持腳本匹配，咱們所構建的服務 Mock 框架，支持在 Mock 數據中同時使用 bsh 和 groovy這兩種腳本。另外，一個服務集羣中，每每會存在同一服務的不一樣版本，所以要真實模擬現實狀況的話，Mock 數據也必須有版本的概念。

除了以上兩種匹配模式，咱們針對實際狀況，還開發了第三種 Mock 模式，就是能夠針對一個真實請求，部分修改它的回參來模擬出一個第三方的結果，這種方式在參數量很是多的狀況下很是有用。

因此，要構建好一個 Mock 數據是須要投入很多工做量的，那麼誰來作這個事情呢？這實際上牽涉到管理規範了。咱們的規定是，服務誰提供，就由誰來構建這個mock數據，服務調用方能夠在這個基礎上作修改或者替換。但這還不夠，因爲服務會很是多，所以，對 Mock 數據的管理必定要體系化和工程化。個人建議是，能夠採用獨立的項目工程對 Mock 數據進行獨立的管理和發佈。

目前，咱們針對前端和服務端都開發了完整的 Mock 能力，可讓開發人員在基本「無感」的狀態下進行本地化的功能調測，同時提供一些自研的小工具來自動生成 Mock 文件，以下降構建 Mock 的難度和人力投入。

爲了有效下降製做 Mock 文件的成本，咱們還基於服務框架的過濾器機制開發了「在線數據抓取過濾器」，它能夠將指定的服務請求的入參和返回結果都抓取下來，並直接寫成 Mock數據文件。經過抓取方式得到的 Mock 數據文件，每每有更好的數據質量，畢竟反映的是更加真實的業務場景。固然了，這裏還有一個合規性的問題，對線上數據的抓取是種敏感行爲，大部分公司這麼幹都會很謹慎，通常都要作好數據脫敏的處理工做。對於咱們，目前只在測試環境中進行數據抓取操做。

事務的一致性和可用性問題是分佈式環境下「老生常談」的問題了，相信你們也或多或少遇到過這類問題。針對分佈式事務，咱們採起了 3 級應對的策略。

首先，在分庫分表操做中，咱們會堅持「實體組」優先的策略，儘可能按照統一的「片鍵」進行分庫分表操做，好比說，若是統一按「用戶帳戶ID」做爲分庫分表鍵的話，那麼用戶相關的交易、資產、支付等相關信息都會落到同一個物理庫實例之中，這樣的話，針對此用戶的相關操做，本地事務就能夠生效，從而避免了分佈式事務的使用。由於對於任何分佈式事務而言，無論作不作資源鎖定，爲了有效保障事務狀態，都須要額外的資源處理消耗。

另外，咱們還提供了自研的支持多級事務的 TCC 服務，以應對不可避免的分佈式事務需求。採用 TCC 的緣由最主要仍是在於相對其它資源管理器而言，它相對簡單，咱們不用關注資源層面，只須要關注服務接口便可。

上面的第二張圖是 TCC 的典型架構模式圖，相信只要研究過 TCC 的同窗們必定看過這張圖，第三張則是咱們自研的 TCC 的一個更詳細的交互架構圖，能體現更多技術細節，但願能對你們有所參考借鑑。

總的來講，從我我的的理解而言，本身實現一個 TCC 框架（獨立服務）並不麻煩，最核心的是要解決兩大核心問題，一個是參與事務的業務數據的緩存和回放問題，咱們在作 TRY 操做的時候，就須要將事務數據緩存起來，能夠存到數據庫中，當框架作 Confirm 和 Cancel 操做時，再用緩存的事務數據去運行特定的服務邏輯，因此，這就要求在 TRY、Confirm 和 Cancel 的方法構造上要有必定的約束，也就是相互之間要可以識別哪些入參是事務數據；另外一個是父子事務的事務 ID 的傳遞問題，咱們經過分佈式服務框架的「非業務傳參」來解決這個問題，一旦某一個事務構建了一個事務 ID，這個事務 ID 就會被放置到環境上下文之中，並隨着 RPC 調用傳遞到遠程服務，遠程服務若是偵測到上下文中已經存在事務 ID 了，則就再也不構建新的事務 ID，這樣的話，父子事務之間就經過同一個事務 ID 關聯在一塊兒。

最後，最終一致性的保障必定是「對帳、對帳、對帳」，這是最傳統，也是最可靠的最後一道防線，這也是金融公司的基礎能力，這裏我就不展開詳細說了。

服務化以後，每一個團隊負責一部分的服務，常常一個業務會涉及多個團隊之間的協同配合，如何讓團隊內部、團隊之間的協做更高效，天弘內部也作了不一樣的嘗試，從綜合效果來講，敏捷模式會更適合一些。

以咱們移動平臺團隊舉例，咱們目前採用兩週一迭代、固定發版的模式，同時每一個迭代以內，採用「火車發佈模式」，實行班車制，準點發車，這樣的話，其它協做部門在很早以前就能大概知道咱們的一個發佈計劃，產品方面也大概知道要把需求放入哪一個迭代之中。這樣，可以有效減輕部門間的溝通成本。在每期工做量評估的時候，咱們通常會預留一些工做量 buffer，以應對一些臨時性需求，這類需求不受版本約束，按需發佈。若是這個迭代週期內沒有這類緊急需求的話，咱們會從 backlog 中撈一些架構優化的需求來填補這些 buffer。

對每一個迭代而言，最不可控的就是 UI 的設計了，UI 的設計過程當中，感性化的因素會更多一些，可能會反覆修改屢次，不像程序代碼那麼明確。因此，咱們通常不將 UI 設計歸入迭代之中，而是將其做爲需求的一部分，在每一個迭代開始以前的工做量評估中，要求必須提供完整的UI物料，不然不予評估工做量，此需求也不會被歸入迭代之中。

要保證敏捷模式平穩推動，還須要一套與之匹配的 DevOps 研發工具體系去支撐它。這方面螞蟻金融雲有相對完善的研發管理工具體系，但咱們目前暫時沒有使用，畢竟團隊規模不同。咱們團隊目前規模還比較小，所以仍是採用業界最通用的一些開源的產品（包括Jekins、Jira、Wiki 等）來整合構建咱們本身的 DevOps 的工具鏈，但咱們會在咱們的研發Pipeline 中經過腳原本整合金融雲的一系列能力，包括包上傳、發佈能等一系列 IaaS 的能力。這樣，就將雲下的研發和雲上的發佈能力整合在了一塊兒。同時，咱們會收集 DevOps工具鏈中各個環節的數據，並經過自研的精益看板來進行各個維度的數據彙總統計和呈現，從而實現對研發的推動情況及質量的嚴格把控。