螞蟻金服在過去十五年重塑支付改變生活，為全球超過十二億人提供服務，這些背後離不開技術的支撐。在 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 左右，正在往進入1秒內最佳化。但是Java應用就很痛苦，普通 Java 應用的啟動時間大約在 30s 到 1min之內。雖然Serverless很美好，但是Java應用卻因為啟動速度問題，很難用到這個架構紅利。我們採用了 JVM 的 SVM 技術將應用進行靜態編譯，實現了一個正常啟動時間在60秒鐘左右的應用最佳化到 4 秒左右，當然這個是在犧牲掉反射等一些動態性換回來的，同時為了能夠儘量不讓應用改，還改了很多中介軟體的SDK ，以減少這方面適配對應用帶來的影響。當這個黑科技能完美支援1秒以內，整個Java技術生態就可以平滑的遷移過來，應用場景會更加的擴大。但這個需要挺長一個週期，而且也需要社群更多人參與進來，一起做開源類庫的反動態性的改造。所以，我們利用我們應用容器的類隔離性來支援多個模組或者同一個模組的不同版本在一個 Java 執行時裡跑，互不干擾，並且可以模擬 Serverless 下的快速冷啟動和快速擴縮容。

我們將這種具備隔離能力，支援模組快速裝載和解除安裝的 Java 執行時稱之為 SOFA Serverless Container，將最小的執行時模組稱之為 SOFA Function，這些小的程式碼片段透過一套 Serverless API 進行程式設計。在過渡階段，我們將 SOFA Serverless Container 部署成一個叢集，並在此之上混合排程多個 SOFA Function，此時 SOFA Serverless Container 和 SOFA Function 是 N:1。到後期，如果黑科技能解決 Java 應用的啟動速度問題，而這些SOFA Function 就可以平滑的過渡到 Pod 部署模式，此時一個 SOFA Function 只會跑在一個 SOFA Serverless Container。

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

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

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