在 2019 年 12 月 7 日 ArchSummit 全球架構師峰會（北京站）專題演講中，來自螞蟻金服 網商銀行的高級技術專家 王恆（花名子諒），分享了《新一代互聯網金融彈性架構實踐》話題。
王恆老師 2013 年加入阿里巴巴，先後在阿里巴巴數據庫事業部，參與了多年雙 11 大促以及阿里巴巴單元化異地多活等重大事件。後來加入阿里雲，負責阿里雲 IaaS 產品的硬件規劃、設計、研發、定製化等硬件服務工作，致力於做好雲計算基礎設施。2019 年加入螞蟻金服 網商銀行，從雲計算用戶角度，重新思考和設計應用系統，致力於推動金融行業的技術發展。
演講主要從四個方面進行，首先介紹網商銀行的價值觀和使命，然後根據金融行業的技術挑戰，引出今天的主題“彈性架構設計”，最後一起探討未來智能化架構想法。（以下是演講內容整理）
網商銀行簡介
網商銀行，是普惠金融的踐行者，這是 4 年前成立時就賦予的使命。希望通過互聯網技術、大數據和渠道創新，幫助小微企業和個人創業者解決容災難、融資貴，以及農村金融服務匱乏的問題。網商銀行基於雲計算基礎設施，大數據驅動的風控管控能力，打造輕資產、平臺化、交易型的金融平臺，同時聯合金融和非金融的生態合作伙伴，持續推進和踐行普惠金融。
網商銀行成立初期，馬老師曾把網商銀行服務小微企業比喻為打造一架直升飛機。如果傳統金融機構是飛機，那麼網商銀行作為一家銀行，要做的是“直升機”。直升機和飛機雖然都能飛，但卻有完全不同的飛行原理，直升機不比飛得高，比的卻是飛得低，可以完成超低空飛行。網商銀行要做的正是貼地服務，這樣才能有速度且有覆蓋面，更靈活地服務更多小微企業。
2019 年雙 11 期間，這架“直升機”採用 310 模式，即 3 分鐘申請、1 秒鐘放貸、0 人工干預，累計貸款 3000 億、戶均貸款頻次 7 次、15 萬小商家貸款筆數 100 次，切實解決中小微商家“小頻短急”的金融服務需求。
互聯網金融的挑戰
互聯網金融有別於傳統金融系統，但卻需要具備金融高可用、高標準、低風險的技術基礎，同時必須兼具互聯網規模化的服務能力，讓所有能夠使用互聯網的客戶都有機會使用普惠的金融服務，因此也需要具備高性能、彈性伸縮以及低成本特點。兩者結合在一起，形成了新一代互聯網金融的技術架構需求。
同時，金融行業一直以來面臨的容量擴縮容和城市級容災能力，一直是困擾金融服務高可用的一道難以跨越的鴻溝。容量彈性伸縮方面，經常遇到單臺服務器計算能力受限、IDC 資源受限（如電力、機架位等）等問題，導致金融系統常常無法快速應對業務的高峰請求。城市級的容災，同城冗餘備份或跨城遠程備份，都無法在機房或數據中心級別故障時，具備快速支撐金融服務的能力。
面對新一代互聯網金融的技術架構需求，以及金融行業容量和容災的技術挑戰，在 2019 年雙 11 之前，我們只能新增加 30% 的計算單元，卻要支撐住 3 萬筆 / 秒的能力。這樣的交易峰值，是 2018 年雙 11 的 3 倍還要多，這些巨大的挑戰，需要我們在已有的條件上進行突破，進行一系列的技術架構升級改造。
彈性架構設計實踐
首先，來看一下彈性架構的演進路徑，從集中式架構模式，到分佈式微服務的架構，應用經歷垂直、水平的拆分，實現分佈式架構，以及升級到單元化、多活、彈性的技術架構體系，最後到越來越多的智能化應用的發展路徑上。在金融行業落地過程中，這條道路異常艱辛，但卻是實踐的指導思想。
設計彈性架構的體系，需要先從宏觀上來看，系統上需要具備什麼能力，需要哪些功能組件，然後逐個模塊進行詳細處理。否則“頭痛醫頭腳痛醫腳”，無法做好技術架構的優化。
設計彈性架構到底需要哪些能力的建設（如上圖）：雲計算基礎設施作為技術底層服務，這已經成為必然；分佈式關係型數據庫，解決數據庫的高性能、高可用、彈性伸縮的能力；單元化分佈式中間件平臺，屏蔽分佈式架構、單元化架構帶來的複雜度；頂層的單元化流量調撥平臺，讓單元化的流量流到對應的單元，避免跨域調用；配備上研發協同平臺和運維管控平臺，保障研發效率和生產穩定性，構建起完整的金融架構體系。接下來將分別從這些方面來詳細介紹網商銀行的實踐過程，中間也會穿插一些“故事”，便於讀者更清晰的瞭解這條路。
如何做彈性，重點是數據拆分，這是讓應用具備細粒度彈性的必然之路。數據拆分包括垂直拆分和水平拆分兩方面：垂直拆分層面非常容易理解，就是將不同的應用系統從同一個數據源中拆分出來，一方面可以避免資源的互相爭搶，另一方面也讓應用系統具備獨立彈性的能力。同時，當年不靠譜的“前任”還挖了一些坑，在數據表設計層面，沒有遵循數據庫設計原則，應用系統運行起來越來越臃腫，這個時候就要根據數據的親和性進行垂直拆分，這是個大動作。具體的方法大多數需要配合應用側一起，進行數據拆分。
水平拆分一直是數據拆分的一個難題，也因此滋生了大量數據中間件服務和創業公司的出現，但這裡我們專注於一些指導策略的說明。拆庫的數量設計，按照未來業務峰值能力，跟單庫容量上限進行拆分。拆表的數量設計，按照業務量和存儲時長的乘積，以及單表容量上限來決定。原則只是指導方針，實際過程中該如何進行拆分呢？首先根據業務屬性進行分析，從業務系統入口來看，如何進行分類，如果是 toC 業務，那麼流量入口就是用戶 ID，那麼數據水平拆分就按照用戶 ID 進行拆分；如果是 toB 的業務，那麼流量入口就是商家 ID，那麼數據水平拆分就按照商家 ID 進行拆分。toB 和 toC 系統之間怎麼辦呢？那是數據交互的另外一層問題。
接下來從流量入口說起，首先對流量負載按權重進行調度調配，同時根據底層的壓力進行動態調整（如上圖）。在接入層將根據數據拆分的邏輯，或者單元化的邏輯，進行數據流量的轉發，使得應用處理落在服務註冊的單元內。之後的應用處理，所有的請求調用和處理都會在一個機房或一個單元內完成。在應用層，也會根據應用集群的設置進行路由和權重的刷新，確保集群流量的動態調配。中間件層同樣根據底層數據庫的壓力，進行動態的路由和權重刷新。存儲層為了解決請求的處理，以及存儲服務的可用性，提供高可用的容災能力。
在接入層將流量按照用戶維度進行調撥，將用戶的請求調撥到封閉的單元內完成，具備單元級別的服務自包含。這樣徹底解決用戶請求跨單元、跨機房的調用關係，使應用系統具備高度內聚、單元化、可擴展的能力，看起來似乎是最完美的狀態。也許有人會疑慮，實際生產上肯定做不到這樣乾淨的切分，一定也無法完全避免跨單元、跨機房的服務調用，所以認為這個方案實施起來是不現實的。而網商銀行實際落地的時候，也面臨了同樣的問題，一部分系統無法做到完全單元內封閉，還需要跨單元、跨機房調用。
為了解決這個問題，我們進行了一些規則的定義，按數據訪問的類型進行劃分，將應用系統分為 RZone、CZone、GZone。RZone 是核心業務系統，即按照流量接入維度進行拆分，承擔用戶請求和處理的核心業務單元，這些應用可以做到單元內的自包含。CZone 是共享業務單元，會被核心系統高頻調用的系統，無法按照統一的維度進行拆分的業務系統。GZone 是指全局訪問的業務系統，無法按照統一的維度進行訪問，同時業務系統也不會被頻繁調用，否則會成為業務的瓶頸。這樣系統分類後，可以讓每一個核心應用的單元內做到應用系統、中間件、數據等服務的自包含，同時每個數據中心至少包含一個 CZone 提供共享的服務調用，且包含零個或若干個 GZone 或 RZone。由於 RZone 調用 GZone 可能存在跨機房調用，延時會增大，因此會盡可能減少 GZone 的服務調用，而確保頻繁的服務調用在本機房內完成。
如果按照 IDC 的方式來建業務系統，會陷入一個盲區，就是不斷的向同一個 IDC 裡添加東西，會撐爆這個數據中心。經過系統的分類設計，形成了一個邏輯數據中心的概念（LDC），打破了 IDC 的容量限制，將核心業務單元進行細粒度部署，一方面實現異地多活，提供並行計算的能力，另一方面也將容災的風險粒度降低，避免 IDC 故障引起的大面積系統癱瘓。然而這樣設計之後，也遇到了巨大的挑戰：
- 一方面，業務系統開發的複雜度變高了，數據分片後，如何知道應用寫入那個數據庫，這是個非常複雜的問題；
- 第二方面，系統出現問題的時候，問題分析和排查非常複雜，很難立即識別並解決系統的問題；
- 第三方面，產生大量的分佈式事務，系統的複雜度更高，尤其是在金融領域；
- 第四方面，微服務的流控、熔斷、批處理、變更等，都成為非常複雜的一件事情，運維工程師非常痛苦。
為了解決這個問題，螞蟻金服開發了一套金融級分佈式中間件平臺 SOFA，是一套雲原生的技術棧體系，將基礎框架（對應開源的 Spring Boot）、微服務框架（對應開源的 Dubbo）、數據訪問代理（對應開源的各種 Proxy、數據傳輸平臺）、分佈式事務（對應開源的多種 TCC 框架）、消息隊列（對應開源的 RocketMQ、ZeroMQ 等）、分佈式鏈路跟蹤（對應開源的 OpenTrace）等服務開發框架打包，整體提升了技術棧的水位，用於解決因為數據拆分、單元化、分佈式帶來的一系列問題。當然還需要配套的研發交付平臺和運維監控平臺來配合，形成一個完整的技術棧體系。
在實際應用過程中，中間件可以說是業務系統的中樞神經。在接入層轉發後，根據微服務註冊平臺進行服務路由，微服務的流控、熔斷、批處理、變更等，都在微服務域產品中處理完成，針對服務網格（Service Mesh）在下面詳細說。應用間的異步調用，通過分佈式消息隊列進行交互。應用數據庫的訪問，通過數據訪問代理進行路由轉發，同時通過數據同步服務將生產系統的數據傳輸到大數據平臺進行處理。應用系統的日誌數據，進行實施的鏈路追蹤和業務系統健康狀況的實時監控。
Service Mesh 和 Severless 這兩年比較熱，大多數情況下技術人是看熱鬧的多，實際參與者少。在這件事情上，網商銀行 2019 年雙 11 就進行了服務網格的嘗試，並取得了不錯的效果。服務網格是讓應用和服務調用分離，讓應用更專注於應用邏輯的開發，讓服務網格專注於服務化。於是，將 RPC、緩存、消息等強相關的服務調用形成為統一的 MOSN SideCar，數據庫訪問形成 DBMesh SideCar，安全服務模塊形成 MIST SideCar，這樣就將應用邏輯跟服務調用剝離，讓應用開發專注於處理應用邏輯的設計和開發，服務層專注做好服務層高可用、流控、流量轉發等能力建設，而運維工程師也從“救火員”轉變為系統風險和架構師，專注於應用的系統風險控制，而云原生產品專注於滿足產品優化和功能完善。
服務網格的經驗告訴我們，釋放應用開發工程師對複雜基礎服務架構的學習成本和依賴，可以快速提高研發效能，同時也有利於服務的獨立升級和演進，而不涉及應用系統的改造。研發迭代效率的快速提升，也加速了業務的創新。
另一個要解決的難題就是金融數據庫，網商銀行採用了最近熱度高漲的 OceanBase 分佈式數據庫，選擇的初衷是經過了螞蟻金服近 10 年的金融場景打磨，並經受住了高性能、高可用、穩定性、擴展性等一系列考驗。當然，從我對數據庫領域的感受來看，數據庫是最熱門、最活躍、最多樣化的一個領域，而經過金融考驗的數據庫也有幾個，大家可以自己找對應的產品。這裡也給大家幾個提醒：
- 數據一致性，這是金融的底線，所以一定要經過大量的驗證，尤其是在容災切換的瞬間，是否能保障數據的一致性，才是最關鍵的因素；
- 彈性可擴展性，無論是 scaleout 還是 scaleup，只按業務需求進行彈性，解決業務峰值的壓力，都是一些必備的能力；
- 高可用，保證系統連續性和可用性的保障，說起來容易，做起來確實非常困難，這也是實踐的過程。
說到高可用，可以回想一下前面講到金融容災、容量的挑戰，如何做到同城、異地容災，是網商銀行一直以來探索的問題。在解決單機房故障時，需要快速進行跨機房的容災切換，尤其是當前的寫數據庫，需要在保障數據一致性的前提下，進行快速切換。而面對城市級故障時，同樣需要在保障數據一致性的前提下，快速切換到第二個城市。因此，我們形成了三地五中心的數據架構，藉助 OceanBase 的 Paxos 能力，解決了 IDC 和城市級的容災能力。
肯定有人會說，成本太高了，一份數據寫 5 個副本，這個成本有點高。的確，我們也遇到了這樣的挑戰。於是將城市三做了一下優化，為了保障 Paxos 協議的正常選主邏輯，因此將城市三節點只需要寫 redo log，而不需要完整的數據庫節點，這樣節省了數據的存儲空間成本。為了保障數據庫的持續服務，RPO=0 的技術目標，我們沒有繼續進行成本優化。此外，為了提高數據庫的計算能力，數據庫單元化使得內部服務正常調用均為單元內封閉，因此多單元可以提供並行計算的能力，真正實現了業務的異地多活能力。
經過上述一系列的單元化、分佈式改造，加上中間件服務、分佈式數據庫的支持能力，以及運維平臺和研發效率平臺的配合，實現了按照業務需求，以單元為粒度，進行動態的彈性。應對今年雙 11 大促 3 倍以上交易峰值的增加，我們動態彈性擴容到金融行業雲環境，雲計算為網商提供了彈性伸縮的能力，應對了應用的“脈衝”流量，讓網商銀行經受住了雙 11 的考驗。此外，今年的雲單元技術架構體系，還獲得了中國人民銀行科技司的“科技進步二等獎”。
未來智能化架構
對於未來的架構演進，網商銀行將不斷往智能化的架構體系演進。
首先從技術層面上，計算的動態彈性能力方面，需要逐步根據業務的流量預測、資源預測等維度，實現快速在金融行業雲上部署金融單元，既保障彈性能力，又要保障金融業務的穩定性和低成本，這在其他領域可能是一個常態，但在金融領域卻極其困難；同時網商銀行在 Service Mesh 和 Serverless 的計算形態落地和實踐，將進一步擴大到全域，增強計算的靈活性，應用的計算配置化目標。
在數據和算法層面，基於大量的系統運行時數據，繼續提高數據鏈路的故障診斷和自愈率，讓數據真的有價值，讓算法更加智能化，提高問題處理效率；此外網商銀行在風控、營銷、體驗、資產負債管理等各個方面都進行了智能化的實踐，尤其在智能風控方面，當前信貸不良率降低到 1.5% 以下，已經遠遠低於行業水平，但這遠遠不夠。我們正致力於研究和實踐多方安全計算，打破數據孤島，讓數據進行安全的計算，持續提高金融風控水位，例如聯邦學習、共享學習、多方安全計算等技術。
在金融業務方面，目前網商銀行啟動了“凡星計劃”，一個人可以走得很快，一群人會走得更遠，網商銀行這一架直升機肯定不夠，需要一個直升機機群才能覆蓋全球廣大的中小微企業。因此，開放金融基礎能力和金融風控能力，賦能行業合作伙伴，一起為中小微企業提供普惠的金融服務。
希望經過我們一起的努力，讓每一個平凡的小微個體擁有平等的金融服務機會，成為閃亮的明星。網商銀行，無微不至。
