螞蟻金服在過去十五年重塑支付改變生活，為全球超過十二億人提供服務，這些背後離不開技術的支撐。在 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 等層面都提供了雙模的「混合」能力。
金融行業業務與技術發展趨勢
最後大家可以看到，無論是銀行或者整個金融領域的發展趨勢，和技術架構的演進趨勢其實是一一對應的，在不同的階段需要不同的能力。我相信很多銀行現在可能處于在做數字化轉型、移動化轉型的階段，但是随着移動化轉型完成接入整個網際網路的管道以後，其實支付寶前面碰到的很多問題相信很多的金融機構都會碰到，是以也希望今天的分享會對大家有些啟發。謝謝大家。
OceanBase 登頂TPC-C測試榜，實作中國資料庫零的突破，想要了解背後的技術細節？歡迎下載下傳電子書《OceanBase TPC-C測試技術解析》，長按識别以下二維碼，關注“螞蟻金服科技”官方公衆号，并在對話框内回複“TPCC”，即可免費下載下傳。