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，將無法完成。要麼只能砍需求，要麼需要消耗更多業務研發的資源來配合我們做大量升級驗證工作。遺留系統也能通過裝配這樣一套軟件，就能夠具備完整的分佈式架構能力，且性能損失只有一點點，同時還獲得了分佈式架構的快速演進能力，因此這絕對是一個值得投資的技術方向。
SOFAMesh架構圖
這個是 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大促中起到了什麼作用呢？我們先回顧下過去做過的一些事情。
螞蟻在上雲後整個系統具備了彈性伸縮能力，於是每次在搞大促活動，無論雙11、雙12還是新春紅包，我們都將對應業務鏈路的系統，動態彈到雲上，用完了再縮回來。這個動作說起來簡單，其實非常複雜，而且操作的變更非常大，但是由於幾個活動間隔時間足夠長，所以我們可以比較坦然的做這個事情，而且還是會額外消耗資源。
今年提了新要求，雙11零點要搞天貓大促，第二天早上7點螞蟻森林又要支持偷能量搞活動，考慮到雙十一後還有兩三個小時處理收尾流量和降級的調度任務，留給系統做調度的時間也就短短的4、5個小時，怎麼樣在這麼短的時間內將一個業務鏈路上的系統全部熄火，再把另外一條拉起來預熱到最佳狀態，而且不允許額外增加資源，這個挑戰非常大。
我們通過類似超賣的方式把兩條鏈路的應用部署在同一組 POD 裏，一組處於運行態，一組處於保活態，當需要切換時，我們將運行態的資源收縮，流量比例調低，變爲保活態，把另一組應用做反向操作變成運行態。
整個過程我們做了非常精細化的流量調撥、轉發、保活。保活非常重要，因爲應用在這麼短時間熱起來，需要有一定的保活流量來維繫應用的基本狀態，包括DB連接、通信連接、緩存等等。Service Mesh 在切換過程中將一部分流量轉發到別的機器，一部分放進來用於維繫應用的「熱狀態」。
聽到這裏大家可能會問，這樣的場景是不是隻有像螞蟻金服或者是阿里巴巴大的一些公司纔會有的？這個功能對於我來說有什麼用？對於大部分的企業的意義是什麼呢？這些流量調撥能力只是 Service Mesh 在大促應用場景當中一個小小的嘗試。Mesh 架構除了解決基礎設施下沉的一些問題之外，我認爲最大的價值在於服務化流量的精細化管控，這也是精細化運維的趨勢。
以上圖爲例，這裏介紹了精細化流量管控的三個方面，包括多版本發佈、壓測引流、服務分組。
很多朋友聽過灰度發佈，新上一個服務，線上灰度驗證一下，控制一定的流量比例給新服務，如果 OK 再全量放開，這件事情聽上去也不難，例如這個服務就是外部流量入口的話，很容易控制入口流量的比例，因爲流量上游就是外部客戶請求，一定是有接入層可以控制的，但當是一個上游有好幾十個，甚至好幾個百各應用來調用就不那麼好控制了。
如果我們想同時驗證一組新服務可能更難，如何能保證這個灰度流量只在這組新服務之間流轉而不逃逸出去？如果沒有統一的流量調撥能力就沒有辦法控制這麼細，那隻能用大招，就是用額外的資源，單獨開闢一個環境，或者是單獨開闢一個機房，專門作爲灰度環境，流量在這個環境內閉環，這個方案可行，也是我們目前在用的方案之一，但是成本很高。如果全部裝上這套系統，就可以在線劃分出來任意的邏輯單元，做流量灰度，做多版本驗證發佈。
同樣的邏輯也適用於細粒度的容災切換、引流壓測、服務分組等，未來可以基於這種全局的流量管控能力做很多創新，來做穩定性和高可用的事情，也能幫助業務做靈活的業務相關的流量調撥。
Service Mesh 帶來的全局流量管控能力就好比手機導航。比如要從國貿去北京南站，系統會給你一個推薦路線。當大家都用同類軟件的時候，整個系統就能根據整個交通通行狀況給不同的人不同的推薦路線，以便最大程度的提升整體交通的吞吐量，在全局形成最優方案。這就是導航系統通過手機這個 sidecar 來進行全局車流量調撥和優化的場景，這也是 Service Mesh 可以給我們系統帶來的價值。在這個方向上，我們內部已經有很多新的探索在做，我相信未來會有更多的創新玩法出來。
螞蟻金服 Service Mesh 正式對外開放
以上提到的技術會我們會在 SOFAStack 的微服務平臺上逐步開放，大家可能也都遇到了異構系統無法統一治理、分佈式改造成本比較高、技術棧綁定等問題，也在希望能有一種方式簡單直接的幫助整個系統改造爲一套分佈式系統，並且能適配兼容各種框架。我們今天開放的 SOFAMesh 可以以無侵入的方式幫助應用進行分佈式改造，支持多種協議，兼容異構系統，不但可以跑在雲原生，還可以跑在虛機上。且經過了大規模金融級的線上驗證。
這個圖是大概的架構，不展開講，核心意思是說這樣一套體系可以兼容螞蟻金服的 SOFA 系統，也可以兼容社區的 Dubbo 應用、SpringCloud 應用，整個可以跑在雲原生架構上，也可以跑在虛擬機架構上，背後是有經過我們多年考驗的服務註冊中心作爲支撐。
現在我們只邁出一小步，在未來還會繼續做更多探索。除了服務化，我們正在把全機房流量都統一管理起來，無論是從網絡接入層進來的南北向流量，還是一個機房內部的東西向，或者是機房之間的東西向流量，全部納入到一套體系上來管理。同時，在對外的產品上，爲了幫助更多的客戶適配已有的體系，我們也在做針對不同的註冊中心適配工作，以便能夠納入到同一個控制面統一管理，這個是未來演進的方向。
這些技術本身有很多核心的代碼也是開源的，對內在跟阿里集團在共建，對外也在努力向 upstream 做貢獻，跟谷歌這樣的公司合作。我們希望能夠得到大家更多的關注並參與貢獻，也希望大家能積極參與到雲原生架構在金融場景的落地探索中來。