導語：過去幾年是雲原生理念高速普及的黃金時期。微服務、容器、無伺服器架構、服務網格等新技術的出現，在技術社區中激起了一浪又一浪的創新熱潮。然而由於金融行業對性能和安全的嚴苛要求，雲原生技術在企業實際場景中的實施落地，特別是在金融場景的實施落地，仍然面臨諸多挑戰。
本文整理自2020阿里雲線上峰會螞蟻集團資深技術專家尹博學的主題演講，為大家分享螞蟻關於金融級IT架構及分布式架構的思考和應用實踐。關注"螞蟻金服科技"公眾號，螞蟻SOFAStack白皮書即將發布，不要錯過哦~~
以下為演講整理全文：
大家好，我是螞蟻集團的尹博學，今天和大家分享一下螞蟻關於金融級IT架構及分布式架構的一些思考和應用案例，主要包含三個部分，分別是行業常見的分布式架構介紹、螞蟻單元化架構的介紹以及單元化架構的應用案例。
行業常見分布式架構
行業常見的分布式架構主要包含，單活架構、雙活架構和冷備架構。從容災能力角度來看，雙活架構和冷備架構均能做到應用級跨機房容災，但是資料庫因為使用了異步複製的技術，無法做到機房級RPU=0的容災。再看灰度發布的能力，冷備架構和雙活架構都只能做到機房級灰度發布，無法做到更細粒度的灰度發布。
螞蟻單元化架構介紹
在介紹完行業常見的分布式架構後，我們來看一下螞蟻的分布式架構發展歷程，和單元化架構的詳細介紹。
這是螞蟻分布式架構發展歷程。螞蟻也經歷了單活、同城雙活、兩地三中心，三個階段。其中兩地三中心是同城雙活加一個冷備。隨著螞蟻業務和業務量複雜度的越來越高，業務對於基礎架構的要求也越來越高，即擴展能力、容災能力、灰度能力要求越來越高。最終螞蟻發展到了單元化架構，將主要業務拆分單元即分片，裝入不同的邏輯單元內，每個分片的資料庫實現三地五中心部署即三地五中心的單元化架構。
首先我們來看一下螞蟻單元化架構的整體架構設計，整體架構包含RZone、GZone和CZone。其中GZone部署的是無法拆分的數據和業務，GZone的數據和業務被RZone依賴，GZone全局只部署一份，而RZone部署的是可拆分的業務和對應的數據。每個RZone內的數據分片如圖所示有五副本，實現三地五中心部署，每個分片內只有一個可寫入的主副本，其餘副本按照Paxos協議做數據強一致。每個RZone內實現業務單元封閉，獨立完成自己的所有業務。而CZone的出現是因為GZone全局只有一份，不同城市的RZone可能依賴GZone服務和數據的時候需要遠距離調用，延遲比較大，所以在每個城市部署一個CZone作為GZone的只讀副本，為本城市的RZone提供服務。
介紹完單元化架構的整體設計之後，我們從容災、灰度發布、彈性三個方面詳細看一下該架構的能力。
首先看容災能力，容災能力分為同城容災和異地容災，以圖中所示為例，RZone1出現故障先看同城容災能力，我們目標將RZone1切換至同城容災RZone2。先做資料庫分片切換，RZone1對應的分片為分片1，把分片1在RZone2的副本提升為主副本，資料庫副本提升完畢後將RZone1的流量切換至RZone2，實現同城容災RPO=0、RTO<1min。
再看異地容災，同樣以RZone1故障為例。目標切換至RZone3，先做資料庫切換，分片1在RZone3的副本切換成主副本，完成後將RZone1的流量切換至RZone3，實現異地容災，該過程RPO=0、RTO<1min。
接下來我們看彈性。彈性的背景是業務在大促、節假日等流量出現大幅上漲的過程，我們可以短期租借新的城市和新的IDC。如圖所示，我們租借城市X的IDCX作為RZoneX，將RZone5的部分流量彈出至RZoneX，對應流量的數據也彈出至RZoneX內。在節假日大促結束之後，將RZoneX內的流量和數據彈回至RZone5，然後回收RzoneX，這樣大幅節約了機房成本。
介紹完彈性之後，我們來看灰度能力。如圖所示，我們將四個RZone（RZone1、RZone2、RZone3、RZone4）的業務和應用分為A、B組，日常A組和B組各承擔50%的應用流量。在應用新版本發布時，我們將A組的流量全部切換至B組，此時在A組上部署新版本，部署完畢後將B組的流量按粒度切換至A組上，切換粒度等於數據分片的粒度。在切換的過程中可以做A組和B組的服務對比，如果發現A組的服務異常，可以快速將流量切換回B組。在A組服務一段時間後無異常發生，最終可以將B組的流量全部切換至A組，把B組的版本更新為新的版本，在整個切換的過程中實現了可灰度、可回滾、可監控。
我們再深入到架構內部，來闡釋一下架構內關鍵模塊是如何支撐該架構的。
首先我們看流量路由模塊。流量路由模塊的核心是將用戶的uid信息和對應的Zone信息植入到cookie中，供流量路由模塊做精準路由。我們以用戶uid=68、RZone=RZ03為例來看流量路由模塊是如何工作的，首次用戶接入時cookie內無zone信息，流量接入模塊會隨即將該請求發到一個RZone內，如發到RZone1內，RZone1通過zoneClinet會準確計算該請求應發至RZone3，即通過RouteClinet將該請求發送。發送過程中將計算出的uid信息和對應的zone信息植入cookie內轉發至RZone3，RZone3完成本次業務請求後將結果返回給用戶，其後用戶同意session內的其它請求，因為在cookie內已經有了準確的路由信息，會被流量路由模塊準確的發至RZone3完成業務請求。
接著我們再看一下服務路由，服務路由分為本機房服務路由和跨機房服務路由調用。先看本機房服務路由，服務調用端向本機房服務註冊中心訂閱服務，發現服務地址後做本機房服務路由調用。再看跨機房服務路由調用，服務調用端向其他IDC的註冊中心訂閱服務地址，發現服務地址後做跨機房服務調用。
最後我們看數據是如何實現高可靠的。螞蟻使用自研的分布式關係資料庫OceanBase，每個分片的資料庫做5副本部署，部署地域實現三地五中心部署，5副本中有3副本實現強一致，如圖所示可以實現同城、IDC容災和異地容災。
單元化架構實踐場景
介紹完螞蟻單元化架構的主要概念即關鍵模塊信息之後，我們看一下單元化架構在外部客戶實施的一些案例。
第一個案例是一家城商行，它的業務系統、IT系統歷史比較長，無法一步跨越到單元化架構，我們為其推薦了大GZone的模式，即把城商行的所有服務和數據不做拆分，直接裝入一個GZone內，在GZone的基礎上實現同城雙活即應用同城雙中心部署，資料庫同城三中心部署，從而實現同城容災能力，RPO=0、RTO<1min，但無法實現異地容災能力，其可灰度能力和彈性能力都無法做到更細力度。
再看第二個區域銀行的案例。我們為這家區域銀行實現了同城單元化，即將這家區域銀行的主要業務拆分成兩個邏輯業務單元兩個分片，將其裝入一個城市的兩個IDC內，在另外一個城市建設冷備，其資料庫每個分片實現5副本部署，其中4副本在主城市兩個中心內部署，1副本部署在了本機房內。該架構實現了同城容災能力，同時也實現了細粒度的灰度能力和彈性能力，但同樣無法實現異地容災能力。
最後我們看一下螞蟻網商銀行的案例。網商銀行實現了異地多活單元化完整的架構，網商銀行的主要業務拆分成了4個分片，裝入4個RZone內，這4個RZone分別部署在了兩個城市內，各承擔25%的流量，而資料庫實現5副本三個城市部署。其中提供服務的兩個地域兩個城市部署4副本，遠端部署1副本。該架構實現了同城容災、異地容災，同時也實現更細粒度的灰度能力和彈性伸縮能力。
介紹完這三個案例後，我們看到了單元化架構的一個靈活性，既可以大GZone部署，也可以同城單元化部署和異地多活單元化部署。今天我們介紹了螞蟻架構的發展歷程即單元化在一些關鍵外部客戶的應用案例。
我的介紹就到這裡，謝謝大家。
加入我們：
螞蟻集團-商業化產品專家
工作地點：杭州、上海
崗位職責：
1、對金融科技或雲計算相關領域熟悉，結合行業發展趨勢及業務戰略方向對平臺/行業產品的長期發展做出市場判斷和業務規劃，找到產品商業化的突破。
2、作為產品，協同銷售、產品、研發、運營團隊，推進重大產品項目的落地，拿到滿足業務訴求的產品產出，並且能夠以技術商業諮詢的角度協同業務團隊落地重要客戶項目。
3、確保螞蟻在金融科技領域中的產品行業競爭力和影響力，對螞蟻產品的競爭力負責。
4、在產品相關的技術領域，完成競爭對手的動態和優劣勢分析
5、產品生態合作夥伴的建設和運營，結合行業生態，快速形成市場規模形成面向行業的場景化解決方案。
任職資格：
1、5年以上企業級產品設計、規劃、和管理的工作經驗 ，在產品決策、執行和願景規劃上有全面把控能力, 有國際化視野優先；
2. 深入理解雲計算技術和雲原生技術（如：微服務、devops、k8s、serverless等），熟悉業界主流雲廠商 PaaS 平臺和產品，了解其特性和各自的優劣勢；
3、業務能力，對金融科技化有深刻的理解，熟悉領域內領先公司的業務及產品，對業務趨勢有自己的見解和分析；
4、產品能力，能綜合多業務的不同場景，形成產品設計和解決方案設計。
5、協同能力，具備良好的團隊溝通協同能力，能推動多業務、角色的大型項目順利推進，結果導向帶領團隊拿到結果；
6、技術能力，在深度學習、分布式架構、企業級應用平臺，資料庫、大數據等一個或者多個領域有深入研究和理解；
7、敬業精神及抗壓能力，有ownership，有很強的抗壓能力和心力，能在關鍵時刻找到突破點。
簡歷投遞郵箱：
zhenxiong.mzx@antgroup.com
免責聲明：市場有風險，選擇需謹慎！此文僅供參考，不作買賣依據。
責任編輯：kj005
文章投訴熱線:156 0057 2229 投訴郵箱:29132 36@qq.com