金融混合云技術(shù)架構(gòu)

1、 金融混合云技術(shù)架構(gòu)互聯(lián)網(wǎng)技術(shù)發(fā)展日新月異，我們正在進(jìn)入云原生時(shí)代，這個(gè)過程中金融行業(yè)要如何擁抱云原生？在近兩年螞蟻金服將云原生在金融領(lǐng)域落地，沉淀下一些實(shí)踐經(jīng)驗(yàn)，接下來我想分享在螞蟻的演進(jìn)過程當(dāng)中，我們心中的云原生是什么樣的，在金融領(lǐng)域落地的時(shí)候遇到什么問題，以及我們是怎么解決的。經(jīng)過多年云計(jì)算的蓬勃發(fā)展，上云已經(jīng)不是太大問題，接下來的問題是怎么把云用好，用得更高效。RightScale 2019年最新數(shù)據(jù)顯示，現(xiàn)在公有云規(guī)模占22%，只使用私有云的客戶占3%，更多客戶通過混合的模式去使用云，通過混合云取得數(shù)據(jù)隱私、安全與效率、彈性的平衡。再看全球整個(gè)IT行業(yè)，公有云的比例只占整個(gè)基礎(chǔ)IT市

2、場的10%，市場空間仍然很大，IT市場中剩下很多都是傳統(tǒng)企業(yè)客戶。為什么傳統(tǒng)行業(yè)無法很好地利用公有云，一個(gè)重要的原因是因?yàn)樗麄兊?IT 系統(tǒng)經(jīng)過很長時(shí)間建設(shè)，很多都有自己的機(jī)房。另外有些則業(yè)務(wù)比較穩(wěn)定，對上公有云沒有很強(qiáng)的需求。它們通常會發(fā)展混合云策略，把一些核心業(yè)務(wù)留在私有云，而把一些邊緣業(yè)務(wù)或創(chuàng)新業(yè)務(wù)放在公有云上。這些特點(diǎn)在金融行業(yè)也非常明顯，除此之外金融行業(yè)還有兩個(gè)特征：業(yè)務(wù)形態(tài)走向開放和互聯(lián)網(wǎng)化：隨著互聯(lián)網(wǎng)和數(shù)字化經(jīng)濟(jì)的發(fā)展，金融機(jī)構(gòu)需要進(jìn)行數(shù)字化轉(zhuǎn)型，以及業(yè)務(wù)敏捷化、服務(wù)場景化，以應(yīng)對新的商業(yè)模式帶來的沖擊；監(jiān)管合規(guī)的訴求：金融行業(yè)的業(yè)務(wù)特點(diǎn)決定了必須是強(qiáng)隔離，強(qiáng)監(jiān)管的，所以公有云上

3、的資源共享模式在監(jiān)管方面會有比較大的挑戰(zhàn)。因此，混合云戰(zhàn)略對金融機(jī)構(gòu)更為適用。這一結(jié)論也得到研究支持，根據(jù)調(diào)研機(jī)構(gòu)Nutanix的報(bào)告，全球金融業(yè)在混合云應(yīng)用方面的發(fā)展速度超過其它行業(yè)，目前部署普及率達(dá)到21%，而全球平均水平為18.5%。那么，什么樣的混合云是適合金融機(jī)構(gòu)的呢？以螞蟻的演進(jìn)歷程為例。螞蟻在第四代架構(gòu)的時(shí)候演變成為云平臺架構(gòu)，而且為了應(yīng)對互聯(lián)網(wǎng)業(yè)務(wù)形態(tài)下突發(fā)性業(yè)務(wù)對資源的彈性需求，螞蟻也在同一階段將架構(gòu)直接進(jìn)化成彈性混合云架構(gòu)?，F(xiàn)在螞蟻已經(jīng)演進(jìn)到第五代云原生架構(gòu)。螞蟻又是如何在云原生的架構(gòu)下，把混合云變成金融級的混合云，我想會對各位有些啟發(fā)。在這個(gè)發(fā)展過程中，有一條主線，是不同

4、階段螞蟻對研發(fā)的標(biāo)準(zhǔn)和要求，包括：自主、成本、安全、穩(wěn)定、海量、敏捷，這也是在在線金融的時(shí)代，我們對云原生架構(gòu)的要求。從分布式到云原生 建立金融級交易支付系統(tǒng)建立金融級的在線交易系統(tǒng)，第一步是要實(shí)現(xiàn)金融級分布式的架構(gòu)，螞蟻在這方面的代表技術(shù)是SOFAStack和OceanBase，目前都已對外商業(yè)化，并有豐富的案例。SOFAStack代表的是，在整個(gè)應(yīng)用層或者無狀態(tài)服務(wù)這個(gè)層面上，如何去做可伸縮、可擴(kuò)展的一套架構(gòu)。OceanBase代表的是以數(shù)據(jù)庫為代表的存儲或者是有狀態(tài)服務(wù)層面，如何在架構(gòu)上面去進(jìn)行分布式。它們擁有四個(gè)特性：高可用，99.99%+的可用性保證，確保系統(tǒng)始終連續(xù)運(yùn)行不中斷；一致

5、性，在任何異常情況下數(shù)據(jù)最終一致，確保資金安全；可擴(kuò)展，支持應(yīng)用級、數(shù)據(jù)庫級、機(jī)房級、地域級的快速擴(kuò)展；高性能，存儲采用讀寫分離架構(gòu)，計(jì)算引擎全鏈路性能優(yōu)化，準(zhǔn)內(nèi)存數(shù)據(jù)庫性能。而這四個(gè)關(guān)鍵的特性都是金融業(yè)務(wù)最為看重的，而且需要在應(yīng)用和存儲上端到端實(shí)現(xiàn)。以一致性為例，在單個(gè)數(shù)據(jù)庫內(nèi)是可以確保數(shù)據(jù)一致性的，但在大規(guī)模應(yīng)用的情況下，單個(gè)數(shù)據(jù)庫總是會出現(xiàn)瓶頸，數(shù)據(jù)往往會像服務(wù)或者應(yīng)用一樣，按照類似交易、支付、賬目等粒度垂直拆開，當(dāng)這些數(shù)據(jù)分別存儲在不同的數(shù)據(jù)庫集群后，就需要在應(yīng)用層來解決一致性問題了，同時(shí)為了支持海量數(shù)據(jù)，數(shù)據(jù)庫集群內(nèi)部也會做分別和多副本，OceanBase 就是這樣一套分布式數(shù)據(jù)庫，

6、在其內(nèi)部也要實(shí)現(xiàn)分布式事務(wù)。只有這樣上下配合才能解掉所有分布式架構(gòu)下的一致性問題，缺一不可。再比如可擴(kuò)展性方面，有些系統(tǒng)號稱做了分布式架構(gòu)，實(shí)際可能只是用了微服務(wù)框架，做了應(yīng)用層的服務(wù)化改造，但數(shù)據(jù)庫層既沒有用水平擴(kuò)展的技術(shù)，也沒用分布式數(shù)據(jù)庫，整個(gè)系統(tǒng)的可擴(kuò)展性就卡在數(shù)據(jù)層的短板上。所以，真正的分布式系統(tǒng)，需要實(shí)現(xiàn)端到端的分布式，才能實(shí)現(xiàn)無限可擴(kuò)展和高性能，而真正的金融級分布式系統(tǒng)則要實(shí)現(xiàn)端到端的高可用和一致性。螞蟻金服三地五中心異地多活架構(gòu)我們認(rèn)為，高可用架構(gòu)最關(guān)鍵的目標(biāo)是數(shù)據(jù)不丟，業(yè)務(wù)不停。在這個(gè)目標(biāo)的基礎(chǔ)上，我們設(shè)計(jì)并實(shí)施了三地五中心的異地多活架構(gòu)。它的核心優(yōu)勢包括城市級容災(zāi)，低成本交

7、易，無限可擴(kuò)展，以及RPO=0，PTO30s. 大家知道我們在去年云棲大會上做了一次剪網(wǎng)線的demo，它演示了整個(gè)架構(gòu)層面上怎么樣做到跨城市多活和災(zāi)難情況下的恢復(fù)快速恢復(fù)能力。同時(shí)在高可用達(dá)標(biāo)的情況下，我們也做了很多風(fēng)險(xiǎn)相關(guān)的事情，總結(jié)起來就是在高可用的基礎(chǔ)上還要做到資金的安全、變更的免疫和故障的快速恢復(fù)。解決了高可用的問題，其實(shí)金融級最被高頻提到的話題就是安全，在云原生時(shí)代，我們要解決的是全鏈路、端到端的安全風(fēng)險(xiǎn)。具體分為三個(gè)層面：云原生網(wǎng)絡(luò)安全，包括策略化高效流量控制，全鏈路加密，流量劫持與分析；云原生基礎(chǔ)設(shè)施安全，包括安全容器，不共享內(nèi)核，以及安全沙箱；云原生業(yè)務(wù)安全，包括SOFAEnc

8、lave機(jī)密計(jì)算中間件，以及內(nèi)存安全的、多任務(wù)Enclave LibOS Occlum。這個(gè)部分我的同事在金融服務(wù)的云原生安全架構(gòu)演講中會詳細(xì)介紹（點(diǎn)此查看演講整理）。小結(jié)一下，所謂金融級的能力，最主要是要實(shí)現(xiàn)端到端的金融級的高可用，同時(shí)實(shí)現(xiàn)端到端的安全。接下來我想分享的是，在云原生這個(gè)階段往前走遇到了哪些問題。從單元化到彈性架構(gòu) 應(yīng)對互聯(lián)網(wǎng)爆炸式的流量脈沖從單元化到云原生下的彈性架構(gòu)首先解釋下什么是單元化，大家可能比較容易理解數(shù)據(jù)庫層的分庫分表或者說 Sharding，能夠通過分片的方式解決集中存儲計(jì)算性能問題，單元化的核心思想是把數(shù)據(jù)的分片提前到了入口請求的分片，在機(jī)房的網(wǎng)絡(luò)接入層將用戶請

9、求根據(jù)某個(gè)緯度（比如用戶ID）進(jìn)行 Sharding，這就好比把每個(gè)機(jī)房就當(dāng)做了一個(gè)巨大無比的有狀態(tài)的數(shù)據(jù)庫分片，當(dāng)你是一個(gè) ID 尾號為007或者008用戶的時(shí)候，當(dāng)請求通過手機(jī)端或者網(wǎng)頁域名發(fā)送到機(jī)房，接入層就已經(jīng)識別出應(yīng)該將你路由到華東地區(qū)還是在華南地區(qū)。當(dāng)你進(jìn)入到某個(gè)地區(qū)的機(jī)房時(shí)，大部分請求處理工作可以在機(jī)房內(nèi)部完成。偶爾會有一些業(yè)務(wù)可能會發(fā)生跨機(jī)房的服務(wù)調(diào)用，比如說數(shù)據(jù)在 A 機(jī)房的用戶給數(shù)據(jù)在 B 機(jī)房的用戶轉(zhuǎn)賬。這個(gè)時(shí)候就需要在這個(gè)機(jī)房上去做有狀態(tài)的設(shè)計(jì)。我們走向云原生時(shí)代的時(shí)候，在大的架構(gòu)上面用Kubernetes為基礎(chǔ)來設(shè)計(jì)，在單元化架構(gòu)下，我們選擇在每個(gè)單元里部署一個(gè)Kub

10、ernetes集群，將支持多 K8s 集群管理和管控指令下發(fā)的 Federated APIServer 做邏輯上的全局部署，其中管控元數(shù)據(jù)是存儲在一個(gè) ETCD 集群的，以保持全局?jǐn)?shù)據(jù)一致，但大家知道ETCD也只能解決同城雙機(jī)房的容災(zāi)，無法再應(yīng)對多城市多數(shù)據(jù)中心的一致性，因此我們正在把ETCD搬到我們的OB的 KV引擎上，這樣在引擎層還是保持 ETCD 的存儲格式和語義，存儲層就具備了三地五中心高可用能力。金融機(jī)構(gòu)異構(gòu)的基礎(chǔ)設(shè)施雖然這種架構(gòu)是適合螞蟻的技術(shù)架構(gòu)的，但在我們的技術(shù)開放給外部客戶時(shí)又會遇到很多新的問題，比方說在客戶的機(jī)房會有很多異構(gòu)的基礎(chǔ)設(shè)施，我們就需要以 Cloud Provid

11、er的標(biāo)準(zhǔn)來實(shí)現(xiàn)多云適配。而且包括我們在內(nèi)的很多金融機(jī)構(gòu)，因?yàn)楹芏嗬舷到y(tǒng)并沒有按照云原生的方式去設(shè)計(jì)，很多會對基礎(chǔ)設(shè)施有狀態(tài)依賴，比如依賴IP ，所以很難完全采用不可變基礎(chǔ)設(shè)施的模式來支撐。有些時(shí)候，由于對業(yè)務(wù)連續(xù)性的極高要求，也很難接受原生 K8s workload 的運(yùn)維模式，比如原生 deployment 做灰度或者金絲雀發(fā)布時(shí)，對應(yīng)用和流量的處理都是非常簡單粗暴的，這樣會導(dǎo)致運(yùn)維變更時(shí)的業(yè)務(wù)的異常和不連續(xù)。這些我們都通過擴(kuò)展原生的 Deployment 成更適合金融業(yè)務(wù)要求的 CAFEDeployment，使得大規(guī)模集群發(fā)布、灰度、回滾時(shí)更加優(yōu)雅，符合我們的技術(shù)風(fēng)險(xiǎn)三板斧原則。所以，金

12、融級的混合云首要解決的問題是彈性和異構(gòu)的問題，且要符合大規(guī)模金融級運(yùn)維的穩(wěn)定性。解決了這些問題，再往前去演進(jìn)新業(yè)務(wù)的時(shí)候，金融行業(yè)會非?？粗厝绾巫龇€(wěn)妥的創(chuàng)新，如何在開發(fā)和運(yùn)維保持傳統(tǒng)模式繼續(xù)支持業(yè)務(wù)的同時(shí)，引入新的運(yùn)維和開發(fā)模式，雙模齊頭并進(jìn)。從核心系統(tǒng)到創(chuàng)新業(yè)務(wù) 構(gòu)建可演進(jìn)的多?；A(chǔ)架構(gòu)雙模PaaS云原生其實(shí)源自于PaaS，所以在應(yīng)用云原生架構(gòu)的時(shí)候，也先在 PaaS 層遇到了平滑演講的問題。如何讓客戶既能保留以前的習(xí)慣，同時(shí)又可能會去嘗試新的交付模式？傳統(tǒng)的模式大家習(xí)慣于交付代碼包，習(xí)慣于基于虛擬機(jī)的運(yùn)維；而云原生時(shí)代以容器鏡像為交付載體，而運(yùn)行實(shí)例則是鏡像的實(shí)例化容器。我們采用容器來模擬

13、 VM 的運(yùn)行模式，通過擴(kuò)展 Deployment 來模擬 VM 的運(yùn)維模式，同時(shí)也支持容器的模式。再往上，無論是基于傳統(tǒng)架構(gòu)的PaaS，還是基于K8s的一套PaaS，實(shí)現(xiàn)的主要操作都是一樣的，都是建站、發(fā)布、重啟、擴(kuò)容/縮容、下線等等。實(shí)現(xiàn)兩套無疑非常浪費(fèi)資源，也增加了維護(hù)成本。對于用戶來說干的事情是一樣的，所以我們用 K8s 實(shí)現(xiàn)了所有的公共部分，統(tǒng)一元數(shù)據(jù)、統(tǒng)一運(yùn)維操作、統(tǒng)一資源抽象，在產(chǎn)品層和運(yùn)維方式上，提供兩種界面。同時(shí)在交付的方式上，也能支持傳統(tǒng)的應(yīng)用模式、技術(shù)棧模式，也可以基于鏡像，當(dāng)然在應(yīng)用之外我們還可以去支持函數(shù)。SOFA雙模微服務(wù)平臺再往上走就是雙模的微服務(wù)，同樣面臨老系統(tǒng)

14、和新系統(tǒng)的問題，我們以前分享過，是通過Mesh方式來統(tǒng)一解決的。云原生架構(gòu)下，Mesh 是 Pod 里的 Sidecar，但老系統(tǒng)往往沒有跑在 K8s 上，就自然不支持 Pod 和 Sidcar 的運(yùn)維模式，所以我們就得用 Agent 的模式來管理 Mesh 進(jìn)程，以支持 Mesh 能夠幫助老架構(gòu)下的應(yīng)用完成服務(wù)化改造，并支持新架構(gòu)和老架構(gòu)下服務(wù)的統(tǒng)一管理。數(shù)據(jù)面要雙模，控制面也支持雙模，傳統(tǒng)基于 SDK 的微服務(wù)會找老的服務(wù)注冊服務(wù)，但 Mesh 會基于控制面，我們會將控制面和老的服務(wù)注冊服務(wù)打通，并由后者來做真正的服務(wù)注冊發(fā)現(xiàn)服務(wù)，以實(shí)現(xiàn)全局服務(wù)的可見和路由，同時(shí)了解過螞蟻服務(wù)注冊體系的同

15、學(xué)知道，我們?nèi)绾卧诔笠?guī)模和多機(jī)房環(huán)境下實(shí)現(xiàn)高可用的設(shè)計(jì)，而這些能力很難短期在社區(qū)的控制面實(shí)現(xiàn)，我們正在逐步將這個(gè)能力沉淀到新架構(gòu)上，所以這種控制面的雙模也非常適合服務(wù)化架構(gòu)在這種混合模式下，平穩(wěn)過渡到云原生架構(gòu)。最后就是Serverless，最近Serverless非?；馃幔膱鼍半m然非常豐富，但是背后對性能有很高要求，每個(gè)應(yīng)用的啟動(dòng)速度需要非?？?，否則可能無法在生產(chǎn)環(huán)境使用。我們內(nèi)部的 Node 系統(tǒng)大量采用 Serverless 架構(gòu)，并對啟動(dòng)速度進(jìn)行了優(yōu)化，目前平均在4s 左右，正在往進(jìn)入1秒內(nèi)優(yōu)化。但是Java應(yīng)用就很痛苦，普通 Java 應(yīng)用的啟動(dòng)時(shí)間大約在 30s 到 1min

16、之內(nèi)。雖然Serverless很美好，但是Java應(yīng)用卻因?yàn)閱?dòng)速度問題，很難用到這個(gè)架構(gòu)紅利。我們采用了 JVM 的 SVM 技術(shù)將應(yīng)用進(jìn)行靜態(tài)編譯，實(shí)現(xiàn)了一個(gè)正常啟動(dòng)時(shí)間在60秒鐘左右的應(yīng)用優(yōu)化到 4 秒左右，當(dāng)然這個(gè)是在犧牲掉反射等一些動(dòng)態(tài)性換回來的，同時(shí)為了能夠盡量不讓應(yīng)用改，還改了很多中間件的SDK ，以減少這方面適配對應(yīng)用帶來的影響。當(dāng)這個(gè)黑科技能完美支持1秒以內(nèi)，整個(gè)Java技術(shù)生態(tài)就可以平滑的遷移過來，應(yīng)用場景會更加的擴(kuò)大。但這個(gè)需要挺長一個(gè)周期，而且也需要社區(qū)更多人參與進(jìn)來，一起做開源類庫的反動(dòng)態(tài)性的改造。所以，我們利用我們應(yīng)用容器的類隔離性來支持多個(gè)模塊或者同一個(gè)模塊的不同

17、版本在一個(gè) Java 運(yùn)行時(shí)里跑，互不干擾，并且可以模擬 Serverless 下的快速冷啟動(dòng)和快速擴(kuò)縮容。我們將這種具備隔離能力，支持模塊快速裝載和卸載的 Java 運(yùn)行時(shí)稱之為 SOFA Serverless Container，將最小的運(yùn)行時(shí)模塊稱之為 SOFA Function，這些小的代碼片段通過一套 Serverless API 進(jìn)行編程。在過渡階段，我們將 SOFA Serverless Container 部署成一個(gè)集群，并在此之上混合調(diào)度多個(gè) SOFA Function，此時(shí) SOFA Serverless Container 和 SOFA Function 是 N:1。到后期，如果黑科技能解決 Java 應(yīng)用的啟動(dòng)速度問題，而這些SOFA Function 就可以平滑的過渡到 Pod 部署模式，此時(shí)一個(gè) SOFA Function 只會跑在一個(gè) SOFA Se