螞蟻金服在過去十五年重塑支付改變生活，為全球超過十二億人提供服務，這些背后離不開技術的支撐。在 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 等層面都提供了雙模的「混合」能力。

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

最后大家可以看到，無論是銀行或者整個金融領域的發展趨勢，和技術架構的演進趨勢其實是一一對應的，在不同的階段需要不同的能力。我相信很多銀行現在可能處于在做數字化轉型、移動化轉型的階段，但是隨著移動化轉型完成接入整個互聯網的渠道以后，其實支付寶前面碰到的很多問題相信很多的金融機構都會碰到，所以也希望今天的分享會對大家有些啟發。謝謝大家。

本文已標注來源和出處，版權歸原作者所有，如有侵權，請聯系我們。