許文奇 螞蟻金服進階技術專家，SOFAStack 商業化産品技術 Leader，多年分布式架構及中間件研發經驗，負責過螞蟻金服分布式架構在多家金融機構的咨詢和落地
本文根據他在 2019 螞蟻金服 ATEC（Ant Technology Exploration Conference）科技大會上海站的分享整理。
本次分享主要會從單體架構和微服務架構的對比開始，後面重點談一下實施金融級分布式架構的常見三個問題。
常用架構：單體式架構
目前很多金融機構的架構是典型的單體式架構，一般由反向代理伺服器，資料庫和應用組成，所有業務子產品都打包在一個應用裡面運作，一般為了高可用考慮，應用至少會部署兩個節點。單體式架構在業務簡單的時候有很多它自身的優點：
- 開發，測試簡單
- 部署簡單
- 擴容簡單，隻要給應用加機器就行
但同樣，單體式架構也有很多缺點，尤其是業務規模變得複雜以後，缺點會非常突出：
- 編譯慢，啟動慢，代碼沖突等各種問題，嚴重影響開發效率
- 性能擴充有局限性，一定規模後，單純堆機器已經很難擴充性能了。
螞蟻金服的架構：分布式架構
微服務架構是目前大家最關注的一種分布式架構。微服務架構除了在性能可擴充性上對比單體式架構有巨大優勢，還有一個重要優勢展現在複雜業務下的生産效率優勢。
隻有在業務複雜度較低的時候，單體式架構的生産效率才能超過微服務架構，但随着業務複雜度上升，尤其過了臨界點，單體架構下的生産效率是非常恐怖的急速下墜，而微服務架構生産效率有所下降，但下降趨勢非常緩慢，且不會偏離原有生産效率太多，能很好的應對業務複雜性的增長。
是以實施微服務架構最重要的一個意義是在業務複雜度較高的情況下提升生産效率，更快速的進行業務創新。
實施金融級分布式架構最常見的三個挑戰
基于微服務架構的巨大優勢，很多金融機構、企業開始逐漸轉型微服務架構，轉型總是伴随着挑戰，這裡選了三個最常見的，最多使用者關心的問題，聊聊螞蟻金服的一些實踐心得：
- 如何進行微服務架構拆分及治理？
- 新的分布式架構如何相容老系統？
- 如何一步一步建構金融級容災架構？
1、微服務架構拆分及治理
微服務拆分模式可以從微服務架構的擴充立方開始講起，分為X軸，Y軸，Z軸三類拆分。
X軸代表橫向擴充模式。主要通過部署多份應用，負載均衡的方式來擴充性能，這個單體架構也可以做。當然，在微服務架構下，橫向擴充模式的實作方式有别于單體架構。
微服務架構做服務負載均衡不需要通過F5或者LVS叢集這樣的硬體裝置，隻需要通過注冊中心就可以實作，這樣帶來的好處是降低了成本，不需要購買大量的硬體裝置了；提高了性能，業務幹路上少了一個單點風險；降低了維護成本。
當然支援橫向擴充模式還需要應用是無狀态的，這個是微服務架構的基本要求，任何涉及狀态的資料都應該儲存在資料庫，緩存或者其他一些存儲媒體中。更高的要求的話，應用應該要滿足著名的12要素的要求。
Y軸代表功能分解模式。我們提倡業務系統在開發的時候就應該按照子產品化進行開發，滿足高内聚，低耦合的架構要求。為了更好支援子產品化開發，以SOFAStack中間件的SOFABoot架構為例，架構支援子產品隔離能力，不同的子產品使用不同的Spring上下文，這樣不同的子產品之間就不能直接引用了，如果需要調用别的子產品的接口，那麼需要走SOFABoot架構規定的特别聲明才可以辦到。這樣極大的規範了子產品化開發，使得這些系統将來在進行拆分的時候，成本非常的低。
關于功能分解，服務拆分，雖然沒有一個标準答案告訴我們就該怎麼做，但其實也有一些基本指導原則和實踐：
- 按照業務領域進行拆解，而不是組織。所有拆分必須按照業務領域模型進行合理劃分，因為實體組織不一定能和業務領域完全對應，且組織一般粒度較大，不能作為拆分細粒度微服務的參考。
- 從資料核心模型拆分開始先拆，而後再往上進行服務拆分。這個主要是進行拆分的一個重要次序問題。一般梳理資料核心模型比較容易，比如很容易梳理出哪些表，哪些資料屬于交易，哪些表，哪些資料屬于賬務，然後按照業務垂直進行拆分。有些業務歸屬不那麼明确的可以按照資料親和性進行拆分。然後資料核心模型拆分好以後，再往上按照功能子產品，所對應的場景，進行服務拆分。
- 單一職責。這個是微服務架構的一條金科玉律，要求微服務架構必須遵守。一個很主要的原因是為了避免微服務架構重新掉進單體架構的老問題裡面。原來單體架構最大的問題就是任何的改動，都要導緻整個應用重新的編譯打包部署，還包括全量回歸測試。試想一個微服務裡面有太多的功能、職責，如果任意一個業務子產品有需求，需要改動，必然導緻該微服務的應用重新編譯，打包部署和全量回歸測試，頻繁變動成本很高，研發效率也會降低。
- 注意拆分粒度，避免一開始拆得過細，循序漸進。關于拆分粒度，這個也是一個沒有标準答案的問題。總的一個原則就是适用最好。任何一家公司的業務都是獨一無二的，不存在一模一樣業務的兩家公司，是以别人的拆分，可以借鑒，但往往很難照抄。是以推薦拆分的時候，一開始不要拆得過細，按照業務發展的規律，循序漸進。舉個例子，比如說紅包業務，原來可能隻是營銷系統的一個子產品，但如果公司的業務在紅包這塊發展得足夠複雜，是可以考慮拆為單獨的微服務，這一切取決于業務發展。
- 注意服務分級和分層，避免循環依賴。這個要求服務拆分的時候，充分注意到哪些是核心服務，哪些是非核心服務，不能出現核心服務強依賴非核心服務的情況，更不能出現循環依賴的情況。
- 考慮團隊結構。最後微服務拆出來，肯定是要有對應團隊去維護的，是以整個拆分的粒度，拆分的邏輯也要考慮團隊結構的情況。
Z 軸代表資料分區模式。一般在資料庫遇到性能瓶頸的時候，需要進行資料拆分，一般分為垂直拆分和水準拆分。垂直拆分一般就是按照業務劃分來進行，比如以前賬務和交易放在一個資料庫，現在資料庫有瓶頸了，那麼就可以拆成賬務和交易兩個資料庫，緩解資料庫的性能瓶頸。當然，如果按照垂直拆分完畢以後，還是不能滿足性能要求，這個時候就需要進行水準拆分了。
關于水準拆分，也有一些重要的實踐原則。在做資料庫水準拆分的時候，最好一次性考慮未來十年，甚至二十年的業務的要求，要避免今天做了一個拆5張表的決定，過了兩年，發現不行，還要繼續拆成10張表，甚至20張表的情況。
重新分片是個非常複雜的工作，尤其是線上還不允許停機的情況。另外關于确定如何拆多少庫，多少表，也有一些實踐。一般拆的資料庫數量等于未來業務的峰值（TPS）除以單資料庫的容量（TPS）。這裡并不代表要一步到位，拆那麼多實際實體庫，一開始可借助SOFAStack分庫分表中間件虛拟成邏輯庫，隻需要少量實體庫，等到通路量上來後，再擴容實體庫。拆的表的數量等于單表時間業務量乘以存儲時長除以單标容量上限。記住表的數量一定要一步拆到位，避免過一兩年還要折騰。
做了資料拆分後，就會遇到分布式事務的問題，需要解決分布式事務的問題，這個也是金融行業區分與别的行業的最大不同。SOFAStack分布式事務中間件目前支援TCC和FMT兩種模式（這裡主要讨論實踐，對于TCC和FMT兩種模式的原理，這裡不再贅述，有興趣的可以參考之前的文章）。TCC模式雖然編碼複雜，業務有侵入，難度較高，但勝在性能好，是以像核心系統裡面的分布式事務都是用該方案。當然，因為複雜，是以實作中有些地方需要注意。
- 業務模型要分兩步設計。因為TCC是個二階段協定，一階段try的時候需要鎖定二階段送出的資源，是以業務模型要按照這樣的思路來進行設計，當然這裡還有一些技巧，需要保證鎖的粒度足夠小，否則性能就比傳統XA模式沒有太大優勢了。拿賬戶餘額舉例子，一般可以在資料庫表裡增加一個當機金額字段，需要轉錢走的時候，在try階段會增加當機金額，表示錢已經凍住，不能挪做别的用途，保證第二階段有足夠的資金進行轉賬。因為對賬戶餘額的鎖定是一個業務上的邏輯鎖，而且邏輯鎖粒度已經最小，隻需要鎖定需要轉賬的金額，全程幾乎無資料庫鎖，是以性能比較高。
- 業務資料并發控制。這個很好了解，對所有涉及金額的操作，肯定是要加鎖的，控制并發的，否則肯定會出錯的。
- 幂等控制。因為分布式環境下，非常容易出現多次調用的情況，為了保證業務不出錯，所有try，confirm，cancel方法都需要保證幂等。
- 允許空復原：這個其實出現機率不是特别高，但為了保證分布式事務的一緻性，必須要做這樣的控制。舉個例子來說明為什麼會出現這樣的情況。事務發起方調用參與者的try方法，因為網絡擁塞，try請求可能沒有到達參與者。然後try方法逾時，分布式事務架構判定一階段失敗，是以開始調用參與者的cancel方法。這個時候網絡好了，而且，cancel方法的調用先到參與者，這個時候，參與者會進行一次空復原（因為沒有執行過try方法，沒有鎖定任何資源），是以必須要保證這種情況下空復原沒有問題。
- 防懸挂控制：空復原之後，cancel方法執行成功，分布式事務架構判定這次分布式事務結束。這個時候如果之前被擁塞的try請求到達參與者，參與者執行了try方法，但這個時候分布式事務已經判定這次事務結束了，是以不會繼續推進二階段事務，這就出現二階段cancel比一階段Try先執行的情況，就造成了事務的懸挂，是以這裡要也需要業務代碼做個控制，防止事務的懸挂。
FMT模式的特點就是使用簡單，基本上像使用單機事務一樣，當然性能自然沒有TCC高，是以一般使用在外圍一點的系統，對性能要求不那麼高的系統上去保證分布式事務的一緻性。
最後關于服務治理，這塊有很多方法可以推薦，比如說API文檔化，API文檔可以借助開源的swagger來生成。還有對核心的服務一定要做限流保護，避免雪崩效應的發生。另外可以借助全鍊路壓測工具識别整個架構的性能短闆，做好相應的保護。
當然最重要的還是組織的問題，要保證微服務架構的有效運轉，一定要在組織層面有相應的保障。有些金融機構在落地微服務的時候，整個組織架構還是完全的老的一套組織架構體系，這個就有問題了。按照康威定律，組織溝通方式會通過系統設計表達出來，如果組織還是原來維護單體架構的一套組織體系，那麼必然在維護發展微服務架構的時候有很多的别扭和不适，久而久之可能整個微服務架構又會慢慢腐壞，退化掉。再比如很多企業提出要走中台戰略，如果都沒有一個實體的組織去負責這個中台，去背KPI去維護發展這個中台，把相應的通用能力沉澱到中台，那麼這個中台戰略其實是不能得到很好的貫徹及執行的，最終也達不到中台的效果。
組織的問題是實施微服務架構一個亟需解決的問題，很多企業可以考慮慢慢過渡，循序漸進的方式去調整組織架構，去适應未來的發展。
2、新的分布式架構相容老系統
金融行業其實整體的資訊化水準是領先其他行業的，這個也造成了分布式架構轉型中需要處理好大量老系統，很多老系統用的是C語言，COBOL語言開發，甚至也有一些Python等其他語言，如何保證新分布式架構對這塊的相容性，保證整體架構更新慢慢平滑過渡，這是一個經常遇到的問題。我們這邊主要推薦SOFAMesh/Gateway的方案去解決。SOFAMosn 就是一個Sidecar，它包括了中間件SDK的能力，包括服務注冊，熔斷限流，動态配置等。SOFAMosn 可以攔截應用的調用，并對相應的協定進行解析後進行代理轉發，這樣對于一些老系統，就可以使用Mesh的方案去通信，進而實作異構語言系統之間的互相調用。對于一些不友善部署Sidecar的老系統應用，還有Gateway的方案，SOFAGateway部署方案有點類似ESB，是個獨立的叢集，當然不會像ESB那樣有那麼複雜的路由能力。所有協定的相容，轉換都在Gateway完成，進而實作異構語言系統之間的通信，當然Gateway還可以附加一些額外的能力，比如對調用進行QPS控制，做一些安全校驗等。
3、建構金融級容災架構
我們知道，金融行業監管對系統的容災是有一定要求的，是以容災架構成了金融企業的标配。從架構的複雜性和解決的問題看，我們推薦按照同城雙活架構，兩地三中心架構，異地多活架構和三地五中心架構的次序來慢慢推進。
對于一般金融企業，做到同城雙活或兩地三中心一般足夠了，有條件的企業可以考慮異地多活方案。
在做同城雙活方案的時候，還是有個點需要特别注意，因為同城兩個機房一般有1~3ms的延時，而一個使用者請求一般會放大為十幾個甚至幾十個SQL的資料庫通路，那麼這些增加的延時有可能會造成一些性能問題甚至使用者根本無法使用。是以推薦在實施同城雙活架構的時候，一般最好能模拟這塊的延時，提早發現應用的一些問題，盡早優化，避免架構上線的時候才發現，造成一些線上問題。
要實作異地多活，一般就得考慮單元化架構了，因為異地之間200公裡的延時一般至少有7~10ms，上千公裡的話有30ms以上的延時，同城雙活的方案已經不能行得通了。單元化的思想主要是把業務劃分為一個個獨立的單元，讓業務調用盡量在單元裡面封閉，減少跨單元調用，這樣才能保證将一些單元部署在異地的時候不會影響線上正常運作。
當然單元化架構對業務有一定侵入，會增加開發運維的複雜性，有必要上異地多活的架構的企業可以考慮是否應用。
總結
目前， 越來越多的企業已經認識到分布式架構在實作業務靈活擴充以及靈活開發等方面的巨大價值，實施微服務架構的時候選擇完善、經過驗證的架構方案，中間件産品至關重要。
SOFAStack 金融級分布式架構是螞蟻金服分布式架構實踐的結晶，而且還在不斷革新中，持續助力金融機構、企業分布式架構轉型，可以在
https://tech.antfin.com/sofa，了解更多。