雲原生時代，什麼是螞蟻金服推薦的金融架構？

螞蟻金服在過去十五年重塑支付改變生活，爲全球超過十二億人提供服務，這些背後離不開技術的支撐。在 2019 杭州雲棲大會上，螞蟻金服將十五年來的技術沉澱，以及面向將來的金融技術創新和參會者分享。咱們將其中的優秀演講整理成文並將陸續發佈在「金融級分佈式架構」公衆號上，本文爲其中一篇。

本文做者：楊延昭（楊冰），螞蟻金服智能科技產品技術部總監

互聯網技術發展突飛猛進，咱們正在進入雲原生時代，這個過程當中金融行業要如何擁抱雲原生？在近兩年螞蟻金服將雲原生在金融領域落地，沉澱下一些實踐經驗，接下來我想分享在螞蟻的演進過程中，咱們心中的雲原生是什麼樣的，在金融領域落地的時候遇到什麼問題，以及咱們是怎麼解決的。

通過多年雲計算的蓬勃發展，上雲已經不是太大問題，接下來的問題是怎麼把雲用好，用得更高效。RightScale 2019年最新數據顯示，如今公有云規模佔22%，只使用私有云的客戶佔3%，更多客戶經過混合的模式去使用雲，經過混合雲取得數據隱私、安全與效率、彈性的平衡。

再看全球整個 IT 行業，公有云的比例只佔整個基礎 IT 市場的10%，市場空間仍然很大，IT 市場中剩下不少都是傳統企業客戶。爲何傳統行業沒法很好地利用公有云，一個重要的緣由是由於他們的 IT 系統通過很長時間建設，不少都有本身的機房。另外有些則業務比較穩定，對上公有云沒有很強的需求。它們一般會發展混合雲策略，把一些核心業務留在私有云，而把一些邊緣業務或創新業務放在公有云上。

這些特色在金融行業也很是明顯，除此以外金融行業還有兩個特徵：

• 業務形態走向開放和互聯網化：隨着互聯網和數字化經濟的發展，金融機構須要進行數字化轉型，以及業務敏捷化、服務場景化，以應對新的商業模式帶來的衝擊；
• 監管合規的訴求：金融行業的業務特色決定了必須是強隔離，強監管的，因此公有云上的資源共享模式在監管方面會有比較大的挑戰。

所以，混合雲戰略對金融機構更爲適用。這一結論也獲得研究支持，根據調研機構 Nutanix 的報告，全球金融業在混合雲應用方面的發展速度超過其它行業，目前部署普及率達到21%，而全球平均水平爲18.5%。

那麼，什麼樣的混合雲是適合金融機構的呢？以螞蟻的演進歷程爲例。

螞蟻在第四代架構的時候演變成爲雲平臺架構，並且爲了應對互聯網業務形態下突發性業務對資源的彈性需求，螞蟻也在同一階段將架構直接進化成彈性混合雲架構。如今螞蟻已經演進到第五代雲原生架構。螞蟻又是如何在雲原生的架構下，把混合雲變成金融級的混合雲，我想會對各位有些啓發。在這個發展過程當中，有一條主線，是不一樣階段螞蟻對研發的標準和要求，包括：自主、成本、安全、穩定、海量、敏捷，這也是在在線金融的時代，咱們對雲原生架構的要求。

從分佈式到雲原生 創建金融級交易支付系統 

創建金融級的在線交易系統，第一步是要實現金融級分佈式的架構，螞蟻在這方面的表明技術是 SOFAStack 和 OceanBase，目前都已對外商業化，並有豐富的案例。SOFAStack 表明的是，在整個應用層或者無狀態服務這個層面上，如何去作可伸縮、可擴展的一套架構。OceanBase 表明的是以數據庫爲表明的存儲或者是有狀態服務層面，如何在架構上面去進行分佈式。它們擁有四個特性：

• 高可用，99.99%+的可用性保證，確保系統始終連續運行不中斷；
• 一致性，在任何異常狀況下數據最終一致，確保資金安全；
• 可擴展，支持應用級、數據庫級、機房級、地域級的快速擴展；
• 高性能，存儲採用讀寫分離架構，計算引擎全鏈路性能優化，準內存數據庫性能。

而這四個關鍵的特性都是金融業務最爲看重的，並且須要在應用和存儲上端到端實現。 以一致性爲例，在單個數據庫內是能夠確保數據一致性的，但在大規模應用的狀況下，單個數據庫老是會出現瓶頸，數據每每會像服務或者應用同樣，按照相似交易、支付、帳目等粒度垂直拆開，當這些數據分別存儲在不一樣的數據庫集羣后，就須要在應用層來解決一致性問題了，同時爲了支持海量數據，數據庫集羣內部也會作分別和多副本，OceanBase 就是這樣一套分佈式數據庫，在其內部也要實現分佈式事務。只有這樣上下配合才能解掉全部分佈式架構下的一致性問題，缺一不可。

再好比可擴展性方面，有些系統號稱作了分佈式架構，實際可能只是用了微服務框架，作了應用層的服務化改造，但數據庫層既沒有用水平擴展的技術，也沒用分佈式數據庫，整個系統的可擴展性就卡在數據層的短板上。

因此，真正的分佈式系統，須要實現端到端的分佈式，才能實現無限可擴展和高性能，而真正的金融級分佈式系統則要實現端到端的高可用和一致性。

螞蟻金服三地五中心異地多活架構咱們認爲，高可用架構最關鍵的目標是數據不丟，業務不停。在這個目標的基礎上，咱們設計並實施了三地五中心的異地多活架構。它的核心優點包括城市級容災，低成本交易，無限可擴展，以及 RPO=0，PTO<30s. 你們知道咱們在去年雲棲大會上作了一次剪網線的demo，它演示了整個架構層面上怎麼樣作到跨城市多活和災難狀況下的恢復快速恢復能力。同時在高可用達標的狀況下，咱們也作了不少風險相關的事情，總結起來就是在高可用的基礎上還要作到資金的安全、變動的免疫和故障的快速恢復。

解決了高可用的問題，其實金融級最被高頻提到的話題就是安全，在雲原生時代，咱們要解決的是全鏈路、端到端的安全風險。具體分爲三個層面：

• 雲原生網絡安全，包括策略化高效流量控制，全鏈路加密，流量劫持與分析；
• 雲原生基礎設施安全，包括安全容器，不共享內核，以及安全沙箱；
• 雲原生業務安全，包括 SOFAEnclave 機密計算中間件，以及內存安全的、多任務 Enclave LibOS Occlum。

 這個部分個人同事在《金融服務的雲原生安全架構》演講中會詳細介紹。小結一下，所謂金融級的能力，最主要是要實現端到端的金融級的高可用，同時實現端到端的安全。接下來我想分享的是，在雲原生這個階段往前走遇到了哪些問題。

從單元化到彈性架構 應對互聯網爆炸式的流量脈衝 

從單元化到雲原生下的彈性架構

首先解釋下什麼是單元化，你們可能比較容易理解數據庫層的分庫分表或者說  Sharding，可以經過分片的方式解決集中存儲計算性能問題，單元化的核心思想是把數據的分片提早到了入口請求的分片，在機房的網絡接入層將用戶請求根據某個緯度（好比用戶 ID）進行 Sharding，這就比如把每一個機房就當作了一個巨大無比的有狀態的數據庫分片，當你是一個 ID 尾號爲007或者008用戶的時候，當請求經過手機端或者網頁域名發送到機房，接入層就已經識別出應該將你路由到華東地區仍是在華南地區。當你進入到某個地區的機房時，大部分請求處理工做能夠在機房內部完成。偶爾會有一些業務可能會發生跨機房的服務調用，好比說數據在 A 機房的用戶給數據在 B 機房的用戶轉帳。這個時候就須要在這個機房上去作有狀態的設計。

咱們走向雲原生時代的時候，在大的架構上面用 Kubernetes 爲基礎來設計，在單元化架構下，咱們選擇在每一個單元裏部署一個 Kubernetes 集羣，將支持多 K8s 集羣管理和管控指令下發的 Federated APIServer 作邏輯上的全局部署，其中管控元數據是存儲在一個 ETCD 集羣的，以保持全局數據一致，但你們知道 ETCD 也只能解決同城雙機房的容災，沒法再應對多城市多數據中心的一致性，所以咱們正在把 ETCD 搬到咱們的 OB 的 KV 引擎上，這樣在引擎層仍是保持 ETCD 的存儲格式和語義，存儲層就具有了三地五中心高可用能力。

金融機構異構的基礎設施

雖然這種架構是適合螞蟻的技術架構的，但在咱們的技術開放給外部客戶時又會遇到不少新的問題，比方說在客戶的機房會有不少異構的基礎設施，咱們就須要以  Cloud Provider 的標準來實現多雲適配。 

並且包括咱們在內的不少金融機構，由於不少老系統並無按照「雲原生」的方式去設計，不少會對基礎設施有狀態依賴，好比依賴 IP ，因此很難徹底採用不可變基礎設施的模式來支撐。有些時候，因爲對業務連續性的極高要求，也很難接受原生 K8s workload 的運維模式，好比原生 Deployment 作灰度或者金絲雀發佈時，對應用和流量的處理都是很是簡單粗暴的，這樣會致使運維變動時的業務的異常和不連續。這些咱們都經過擴展原生的 Deployment 成更適合金融業務要求的 CAFEDeployment，使得大規模集羣發佈、灰度、回滾時更加優雅，符合咱們的「技術風險三板斧原則」。

因此，金融級的「混合雲」首要解決的問題是彈性和異構的問題，且要符合大規模金融級運維的穩定性。解決了這些問題，再往前去演進新業務的時候，金融行業會很是看重如何作穩妥的創新，如何在開發和運維保持傳統模式繼續支持業務的同時，引入新的運維和開發模式，雙模齊頭並進。

從核心系統到創新業務 構建可演進的多模基礎架構 

雙模 PaaS

雲原生其實源自於 PaaS，因此在應用雲原生架構的時候，也先在 PaaS 層遇到了平滑演進的問題。如何讓客戶既能保留之前的習慣，同時又可能會去嘗試新的交付模式？傳統的模式你們習慣於交付代碼包，習慣於基於虛擬機的運維；而云原生時代以容器鏡像爲交付載體，而運行實例則是鏡像的實例化容器。咱們採用容器來模擬 VM 的運行模式，經過擴展 Deployment 來模擬 VM 的運維模式，同時也支持容器的模式。

再往上，不管是基於傳統架構的PaaS，仍是基於K8s的一套PaaS，實現的主要操做都是同樣的，都是建站、發佈、重啓、擴容/縮容、下線等等。實現兩套無疑很是浪費資源，也增長了維護成本。對於用戶來講乾的事情是同樣的，因此咱們用 K8s 實現了全部的公共部分，統一元數據、統一運維操做、統一資源抽象，在產品層和運維方式上，提供兩種界面。同時在交付的方式上，也能支持傳統的應用模式、技術棧模式，也能夠基於鏡像，固然在應用以外咱們還能夠去支持函數。

SOFA 雙模微服務平臺

再往上走就是雙模的微服務，一樣面臨老系統和新系統的問題，咱們之前分享過，是經過 Mesh 方式來統一解決的。雲原生架構下，Mesh 是 Pod 裏的 Sidecar，但老系統每每沒有跑在 K8s 上，就天然不支持 Pod 和 Sidcar 的運維模式，因此咱們就得用 Agent 的模式來管理 Mesh 進程，以支持 Mesh 可以幫助老架構下的應用完成服務化改造，並支持新架構和老架構下服務的統一管理。

數據面要雙模，控制面也支持雙模，傳統基於 SDK 的微服務會找老的服務註冊服務，但 Mesh 會基於控制面，咱們會將控制面和老的服務註冊服務打通，並由後者來作真正的服務註冊發現服務，以實現全局服務的可見和路由，同時瞭解過螞蟻服務註冊體系的同窗知道，咱們如何在超大規模和多機房環境下實現高可用的設計，而這些能力很難短時間在社區的控制面實現，咱們正在逐步將這個能力沉澱到新架構上，因此這種控制面的雙模也很是適合服務化架構在這種混合模式下，平穩過渡到雲原生架構。

最後就是 Serverless，最近 Serverless 很是火熱，它的場景雖然很是豐富，可是背後對性能有很高要求，每一個應用的啓動速度須要很是快，不然可能沒法在生產環境使用。

咱們內部的 Node 系統大量採用 Serverless 架構，並對啓動速度進行了優化，目前平均在4s左右，正在往進入1s內優化。可是Java應用就很痛苦，普通 Java 應用的啓動時間大約在30s到1min以內。雖然 Serverless 很美好，可是 Java 應用卻由於啓動速度問題，很難用到這個架構紅利。咱們採用了 JVM 的 SVM 技術將應用進行靜態編譯，實現了一個正常啓動時間在60s左右的應用優化到4s左右，固然這個是在犧牲掉反射等一些動態性換回來的，同時爲了可以儘可能不讓應用改，還改了不少中間件的 SDK ，以減小這方面適配對應用帶來的影響。當這個黑科技能完美支持1s之內，整個 Java 技術生態就能夠平滑的遷移過來，應用場景會更加的擴大。但這個須要挺長一個週期，並且也須要社區更多人蔘與進來，一塊兒作開源類庫的反動態性的改造。因此，咱們利用咱們應用容器的類隔離性來支持多個模塊或者同一個模塊的不一樣版本在一個 Java 運行時裏跑，互不干擾，而且能夠模擬 Serverless 下的快速冷啓動和快速擴縮容。

咱們將這種具有隔離能力，支持模塊快速裝載和卸載的 Java 運行時稱之爲 SOFA Serverless Container，將最小的運行時模塊稱之爲 SOFA Function，這些小的代碼片斷經過一套 Serverless API 進行編程。在過渡階段，咱們將 SOFA Serverless Container 部署成一個集羣，並在此之上混合調度多個 SOFA Function，此時 SOFA Serverless Container 和 SOFA Function 是 1:N。到後期，若是黑科技能解決 Java 應用的啓動速度問題，而這些 SOFA Function 就能夠平滑的過渡到 Pod 部署模式，此時一個 SOFA Function 只會跑在一個 SOFA Serverless Container。

再總結下，金融級的混合雲要解決技術平滑演進的話，仍是要具有可演進可迭代的能力，因此咱們在 PaaS、微服務、Serverless 等層面都提供了雙模的「混合」能力。

金融行業業務與技術發展趨勢

最後你們能夠看到，不管是銀行或者整個金融領域的發展趨勢，和技術架構的演進趨勢實際上是一一對應的，在不一樣的階段須要不一樣的能力。我相信不少銀行如今可能處於在作數字化轉型、移動化轉型的階段，可是隨着移動化轉型完成接入整個互聯網的渠道之後，其實支付寶前面碰到的不少問題相信不少的金融機構都會碰到，因此也但願今天的分享會對你們有些啓發。謝謝你們。

雲原生活動推薦：螞蟻金服聯合 CNCF Service Mesh Meetup 成都站

Service Mesh Meetup 是由螞蟻金服聯合 CNCF 官方共同出品，ServiceMesher 社區主辦，主題圍繞服務網格、Kubernetes 及雲原生，在全國各地循環舉辦的技術沙龍。

本期 Meetup 邀請社區大咖，從服務網格下微服務架構設計、在 5G 時代的應用、如何使用開源的 Traefik 構建雲原生邊緣路由及螞蟻金服的服務網格代理演進角度給你們帶來精彩分享。

時間：2019年10月26日（週六）13:00-17:00
地點：成都武侯區螞蟻C空間
報名方式：戳這裏，便可鎖定席位