金融級雲原生如何助力雙十一？螞蟻金服的實踐經驗是這樣

2019年11月19日，螞蟻金服在北京舉辦「巔峯洞見·聚焦金融新技術」發佈會，介紹2019雙11支付寶背後的技術，並重磅發佈全新 OceanBase 2.2 版本和 SOFAStack 雙模微服務平臺。咱們將系列演講整理併發布在 「螞蟻金服科技」 公衆號上，歡迎關注。

螞蟻金服金融科技產品技術部總經理楊冰，在發佈會分享了螞蟻金服金融級雲原生在雙十一的大規模應用實踐，如下爲演講整理全文：

2018年雙11，螞蟻金服和網商銀行正式應用雲原生架構，2019年雙11，螞蟻金融級雲原生架構進一步深刻落地，Service Mesh 架構100%覆蓋螞蟻金服核心支付鏈路，是業界最大的 Service Mesh 集羣。本文將分享螞蟻金融級雲原生在2019年雙11中的大規模應用實踐。

歷年雙十一的交易峯值不斷增加，給整個技術帶來了巨大挑戰和牽引力。在這樣的驅動力下，技術架構又發生什麼樣的變革？螞蟻金服從第一代集中式架構，逐步走向分佈式架構，再到雲平臺，螞蟻的架構已經造成了比較體系化的金融級分佈式架構，可以很好的去支撐業務的發展。

金融級分佈式架構須要 Service Mesh

幾代架構演進中，雖然解決了不少業務痛點和問題，但也確實讓業務作了不少的升級、改造、上雲等事情。咱們開玩笑說雲包治百病，業務研發團隊就問，能不能讓咱們將來只關注業務開發自己，剩下的事情交給基礎設施？我相信這個問題也是咱們下一代架構往金融級雲原生架構演進過程當中須要去解決的一個問題，也是雲原生這個技術自己要解決的問題。總結來講：交易規模的演進確實須要架構升級，但架構升級不但願成爲業務的負擔。

如何解決這個問題呢？咱們先來回顧下架構演進的過程。

金融交易技術演進的第一階段是實現金融級分佈式架構，SOFAStack 和 OceanBase 是構成這個架構的基礎。須要強調的是，整個金融級能力，包括高可用、一致性、可擴展、高性能，都須要應用到數據存儲端到端總體能力。

好比分佈式事務，OceanBase 從數據庫層面提供了分佈式事務的支持，但當咱們把兩個極其重要的業務數據放到兩個 OceanBase 集羣的時候，就須要由應用層來解決跨數據庫的一致性問題，這個就是中間件須要提供的能力了。因此分佈式架構下必須具有的端到端的一致性，才能構成總體架構的一致性。高可用、可擴展、高性能也是同樣的道理，缺任何一個能力都不能算是真正的金融級分佈式架構。

這張架構圖的虛線如下表示的是目前螞蟻的金融級分佈式架構中的核心組件，這一層軟件經歷了十幾年的發展已經抽象的比較完備，並且很好的支撐了業務的發展。

但真正系統實現中，業務層跟下面幾個組件有着千絲萬縷的聯繫，這個關係可能存在於下層爲了減小上層的改動提供的兼容性SDK 裏，也許存在於上層遷就適配下層特殊用法裏，這樣的例子層出不窮，一直伴隨着整個架構演進的過程。

而在下層演進發展過程當中，這種耦合和千奇百怪的兼容適配問題就會造成巨大的阻力和風險。金融IT同行在作數字化轉型的時候也會遇到一樣的痛點，甚至於可能會比像螞蟻金服這樣的互聯網公司遇到的困難更多一些。相比於互聯網公司相對還比較統一的架構來講，不少企業的IT 系統中就像博物館，三代同堂，遺留系統一大堆，還有不少外採的系統。因此這個架構分層雖然清晰，但卻沒法獨立演進。

螞蟻一樣有這樣的問題，內部有上千個系統，幾十萬臺服務器，在業務迭代發展這麼快的狀況下，根本沒有太多精力來配合進行基礎設施的升級。而業務不動基礎設施就動不了，不少能力就沒法全局生效，這樣就發揮不了威力。

舉個最簡單的例子，全鏈路壓測很強大，但若是沒有自上而下的推進全業務線配合升級 SDK，使得總體通訊架構能支持全鏈路標識透傳和識別的能力，就沒法實現全鏈路壓測，也許到今天咱們還無法享受這個技術帶來的紅利。這樣的例子不少，不少的創新也是由於卡在「相互等待」的死鎖中，遲遲未能落地，甚至胎死腹中。

軟件世界裏面有一句經典的話：沒有什麼問題是不能經過一層抽象解決的，若是說有，那就再加一層。咱們但願可以有這一層將業務和基礎設施解耦，正好雲原生髮展過程當中出現了 Service Mesh，並且這一層軟件抽象從邏輯分層走向了物理分離，既起到了解耦的做用，又具有獨立演進的能力。

康威定律認爲，一個軟件系統的架構背後必定有對應的組織架構，以前的架構中，業務開發和基礎設施開發雖然在組織上已經基本分開，但軟件上卻沒有切開，Service Mesh 的出現正好解決了軟件架構和組織架構不匹配的問題。

把這層抽象剝離變成獨立的載體是一個趨勢，不只僅 Service 應該被 Mesh 化，更多的中間層能夠被 Mesh 化，螞蟻也是這麼實踐的。這也是業務應用在雲原生時代，如何把本身的一些訴求更好的交給雲，讓應用跟雲之間的交互變得更簡單的一個過程。

螞蟻金服自研的 SOFAMesh 在雙十一中大規模應用，100%覆蓋核心支付鏈路，容器規模幾十萬，千萬 QPS，性能消耗極低，而將迭代速度從1-2次每一年提高到10+次每個月。在 CPU、內存和相應時間等數據上來看，咱們經過極小資源的代價，換來了系統快速迭代的速度，在備戰雙十一的短短兩個月，Service Mesh 進行了幾十次迭代和發佈，快速響應了全新的大促需求，並完整屢次的全站升級和全鏈路的線上驗證。

這在之前幾乎是不可想象的，今年任務的複雜度和工做量，若是沒有 Service Mesh，將沒法完成。要麼只能砍需求，要麼須要消耗更多業務研發的資源來配合咱們作大量升級驗證工做。遺留系統也能經過裝配這樣一套軟件，就可以具有完整的分佈式架構能力，且性能損失只有一點點，同時還得到了分佈式架構的快速演進能力，所以這絕對是一個值得投資的技術方向。

<p style="text-align:center">SOFAMesh架構圖</p>

這個是 SOFAMesh 的架構圖，裏面是分紅控制面和數據面兩個部分，控制面是在產品層你們想要的一些能力，走向微服務架構要解決什麼樣的問題，但願在這個架構上有更多的運維能力、監控能力、流量調控能力、安全能力、擴展能力。

數據面 SOFAMosn 是獨立出來的進程，它能夠跟 APP 進行交互，和 APP 在一個 POD 裏。圖中除了 SOFAMosn 承載了 APP 之間的通訊任務以外，還將異步消息的通訊邏輯也沉澱進去了，成爲應用對外同步異步通訊的統一門面。同時咱們也把應用訪問數據庫的中間層路由邏輯和配置管理邏輯獨立成一個 sidecar，稱之爲 DBMesh，這個圖裏用 More Sidecar 來表示，意味着將來可能有更多的邏輯能夠下沉到 Mesh 層。

將來應用將使用很是輕薄的 SDK 或者簡單的 API 跟外界交互，而複雜的路由、治理、高可用等相關的邏輯就下沉到 Mesh 層了，此後全局架構改造就會變得很是的輕鬆，對業務沒有打擾。

接入 Service Mesh 的挑戰與解決之道

在應用 Service Mesh 的過程當中，螞蟻金服也遇到了很多困難和挑戰，不少的社區方案其實並不能很好的知足金融行業的需求，尤爲對高可用、穩定性的苛刻要求，螞蟻在接入過程當中也作了很多創新。

首先第一個問題是，Service Mesh 是如何接入到整個體系裏呢，它的資源消耗又怎樣呢？

要按雲原生社區的方式安裝一個 sidecar，就是擴容出來一批新的 POD，裏面已經爲APP 裝配好了 sidecar，而後把老的 POD 逐步下線銷燬。這就像要給一輛車裝個新功能，咱們須要搞一批有這個新功能的新車給到客戶，而後把老車召回，這個很是浪費資源。並且在給大規模集羣上 sidecar 時須要更多的資源 buffer 去作滾動升級，成本很高且效率很低，並且連應用和 POD 一併銷燬重建，這個變動的動靜太大，也的確有不小的風險。

咱們採用了注入升級的方式，這裏也對原生的 K8s 作了不少擴展的改動。

在資源消耗的優化方面，咱們也作了不少探索。理論上既然將這個進程獨立出來跑在容器裏，就應該分配獨立的 CPU 和內存資源，咱們開始也是這麼作的，但跑下來反而出現不少性能瓶頸。後來咱們發現，根本性問題在於雖然這個進程是獨立的，本質上它仍是一段從應用裏剝離出來的邏輯，不管它是幫助應用作服務通信，仍是訪問數據庫，都是在應用主鏈路上，若是爲這些邏輯設置了跟應用不同的 CPU 和內存限制，反而會使得應用在作主鏈路業務的時候，受到這個獨立進程的資源消耗瓶頸影響。最後咱們經過實踐，經過注入融合的方式，跟應用一塊兒去共享 CPU 和內存，不但能達到最好效果，也最大程度減小資源開銷。

這整個升級的過程，相似於咱們把一輛普通的車，注入一個模塊變成了一個可持續升級的特斯拉，隨時隨地作空中升級。並且這個模塊與應用共享電源和公共資源，達到最小的功耗。

既然空中升級的能力很好，怎麼樣能穩妥保證這個模塊自身的升級呢？

社區的方案是銷燬整個 POD，連同 APP 和 sidecar，再創造一個新的，裏面包含了原來的 APP 和新的 sidecar。這樣一來，雖然這個東西從應用層剝離出來，可是仍是跟應用放在一塊兒總體做爲一個軟件建立、銷燬、升級，未免顯得有些笨重。

其實大部分是要作這個進程的升級時，應用是沒有變化的。這種方案彷佛也違背了把它剝離出來進行獨立演進的初衷，這也是咱們探索過程當中發現社區的方式不太理想的地方，並且整個方案也沒有流量摘除、優雅上下線這種設計，整個方案比較簡陋粗暴。

咱們探索了獨立升級 sidecar 的模式，而且實現了較爲複雜的流量熱遷移。整個過程應用徹底無感知，就像是咱們給別人打電話，若是對方是個雙胞胎，當話筒被另外一個接過去時，咱們仍是面對的一樣的電話，一樣的通話通道，對方換了我的，咱們無感知。這樣整個升級過程很是的平滑，也對業務無打擾，流量也不會出現波動，符合金融級對穩定性的要求。

整個過程仍是用車打比方，以前看過一個勞斯萊斯的廣告，車子開過隔離帶的時候，裏面的乘客沒有任何感受，放在車上那杯水也沒有任何的震動，雖然沒坐過這麼好的車，不知道是否真的能作到像廣告裏的效果，但整個過程很震撼。我想平滑升級的效果就應該像這個過程同樣。

Service Mesh 在雙11大促中起到了什麼做用呢？咱們先回顧下過去作過的一些事情。

螞蟻在上雲後整個系統具有了彈性伸縮能力，因而每次在搞大促活動，不管雙十一、雙12仍是新春紅包，咱們都將對應業務鏈路的系統，動態彈到雲上，用完了再縮回來。這個動做提及來簡單，其實很是複雜，並且操做的變動很是大，可是因爲幾個活動間隔時間足夠長，因此咱們能夠比較坦然的作這個事情，並且仍是會額外消耗資源。

今年提了新要求，雙11零點要搞天貓大促，次日早上7點螞蟻森林又要支持偷能量搞活動，考慮到雙十一後還有兩三個小時處理收尾流量和降級的調度任務，留給系統作調度的時間也就短短的四、5個小時，怎麼樣在這麼短的時間內將一個業務鏈路上的系統所有熄火，再把另一條拉起來預熱到最佳狀態，並且不容許額外增長資源，這個挑戰很是大。

咱們經過相似超賣的方式把兩條鏈路的應用部署在同一組 POD 裏，一組處於運行態，一組處於保活態，當須要切換時，咱們將運行態的資源收縮，流量比例調低，變爲保活態，把另外一組應用作反向操做變成運行態。

整個過程咱們作了很是精細化的流量調撥、轉發、保活。保活很是重要，由於應用在這麼短期熱起來，須要有必定的保活流量來維繫應用的基本狀態，包括DB鏈接、通訊鏈接、緩存等等。Service Mesh 在切換過程當中將一部分流量轉發到別的機器，一部分放進來用於維繫應用的「熱狀態」。

聽到這裏你們可能會問，這樣的場景是否是隻有像螞蟻金服或者是阿里巴巴大的一些公司纔會有的？這個功能對於我來講有什麼用？對於大部分的企業的意義是什麼呢？這些流量調撥能力只是 Service Mesh 在大促應用場景當中一個小小的嘗試。Mesh 架構除了解決基礎設施下沉的一些問題以外，我認爲最大的價值在於服務化流量的精細化管控，這也是精細化運維的趨勢。

以上圖爲例，這裏介紹了精細化流量管控的三個方面，包括多版本發佈、壓測引流、服務分組。

不少朋友聽過灰度發佈，新上一個服務，線上灰度驗證一下，控制必定的流量比例給新服務，若是 OK 再全量放開，這件事情聽上去也不難，例如這個服務就是外部流量入口的話，很容易控制入口流量的比例，由於流量上游就是外部客戶請求，必定是有接入層能夠控制的，但當是一個上游有好幾十個，甚至好幾個百各應用來調用就不那麼好控制了。

若是咱們想同時驗證一組新服務可能更難，如何能保證這個灰度流量只在這組新服務之間流轉而不逃逸出去？若是沒有統一的流量調撥能力就沒有辦法控制這麼細，那隻能用大招，就是用額外的資源，單獨開闢一個環境，或者是單獨開闢一個機房，專門做爲灰度環境，流量在這個環境內閉環，這個方案可行，也是咱們目前在用的方案之一，可是成本很高。若是所有裝上這套系統，就能夠在線劃分出來任意的邏輯單元，作流量灰度，作多版本驗證發佈。

一樣的邏輯也適用於細粒度的容災切換、引流壓測、服務分組等，將來能夠基於這種全局的流量管控能力作不少創新，來作穩定性和高可用的事情，也能幫助業務作靈活的業務相關的流量調撥。

Service Mesh 帶來的全局流量管控能力就比如手機導航。好比要從國貿去北京南站，系統會給你一個推薦路線。當你們都用同類軟件的時候，整個系統就能根據整個交統統行情況給不一樣的人不一樣的推薦路線，以便最大程度的提高總體交通的吞吐量，在全局造成最優方案。這就是導航系統經過手機這個 sidecar 來進行全局車流量調撥和優化的場景，這也是 Service Mesh 能夠給咱們系統帶來的價值。在這個方向上，咱們內部已經有不少新的探索在作，我相信將來會有更多的創新玩法出來。

螞蟻金服 Service Mesh 正式對外開放

以上提到的技術會咱們會在 SOFAStack 的微服務平臺上逐步開放，你們可能也都遇到了異構系統沒法統一治理、分佈式改形成本比較高、技術棧綁定等問題，也在但願能有一種方式簡單直接的幫助整個系統改造爲一套分佈式系統，而且能適配兼容各類框架。咱們今天開放的 SOFAMesh 能夠以無侵入的方式幫助應用進行分佈式改造，支持多種協議，兼容異構系統，不但能夠跑在雲原生，還能夠跑在虛機上。且通過了大規模金融級的線上驗證。

這個圖是大概的架構，不展開講，核心意思是說這樣一套體系能夠兼容螞蟻金服的 SOFA 系統，也能夠兼容社區的 Dubbo 應用、SpringCloud 應用，整個能夠跑在雲原生架構上，也能夠跑在虛擬機架構上，背後是有通過咱們多年考驗的服務註冊中心做爲支撐。

如今咱們只邁出一小步，在將來還會繼續作更多探索。除了服務化，咱們正在把全機房流量都統一管理起來，不管是從網絡接入層進來的南北向流量，仍是一個機房內部的東西向，或者是機房之間的東西向流量，所有歸入到一套體系上來管理。同時，在對外的產品上，爲了幫助更多的客戶適配已有的體系，咱們也在作針對不一樣的註冊中心適配工做，以便可以歸入到同一個控制面統一管理，這個是將來演進的方向。

這些技術自己有不少核心的代碼也是開源的，對內在跟阿里集團在共建，對外也在努力向 upstream 作貢獻，跟谷歌這樣的公司合做。咱們但願可以獲得你們更多的關注並參與貢獻，也但願你們能積極參與到雲原生架構在金融場景的落地探索中來。