RPC
服務網格（Service Mesh）是螞蟻集團下一代架構的核心，在螞蟻集團當前的體量下，將現有的 SOA 體系快速演進至 Service Mesh 架構，猶如給奔跑的火車換輪子。本文以 RPC 層面的設計和改造方案為中心，分享螞蟻集團在雙十一大促面臨大流量挑戰時，核心應用如何將現有的微服務體系平滑過渡到 Service Mesh 架構下，并降低大促成本。
Service Mesh 簡介
與社區 Service Mesh 相比，螞蟻 Service Mesh 的結構也分為下述兩個部分：
控制面：名為 SOFAMesh。未來會以更加開放的姿態參與到 Istio 中。
數據面：名為 MOSN，支持 HTTP、SOFARPC、Dubbo、WebService。下文主要講述的即數據面的落地。
社區 Service Mesh 架構和螞蟻集團 Service Mesh 架構對比圖
為什么要 Service Mesh？
Service Mesh 解決了在 SOA（Service-Oriented Architecture） 下面存在的亟待解決的如下問題：
基礎架構和業務研發耦合問題
業務透明的穩定性與高可用性等問題
使用 Service Mesh 前狀態
在沒有 Service Mesh 之前，整個 SOFAStack 技術演進的過程中，主要存在下述的問題：
框架和業務過于耦合。
一些 RPC 層面的需求，比如：流量調度、流量鏡像、灰度引流等，需要投入更多開發資源進行支持。
需要業務方來升級對應的中間件版本。
主要問題示例如下：
框架和業務耦合：升級成本高，很多需求由于在客戶端無法推動，需要在服務端提供相應的功能，方案不夠優雅。
機器資源逐年增加：如果不增加機器，很難應對雙十一的巨大流量。
流量調度訴求：流量調撥、灰度引流、藍綠發布、AB Test 等新的訴求不容易滿足。
框架升級訴求：在基礎框架準備完成后，對于新功能，如果用戶的 API 層不升級，無法確定是否能兼容舊版本。
版本不統一：線上客戶端框架版本不統一。
在 SOA 的架構下，負責業務的團隊和負責基礎設施的團隊，合作現狀如下：
業務團隊之間可以實現解耦：負責業務的團隊都可以獨立地去負責一個或者多個業務，這些業務的升級維護也不需要其他團隊的介入。SOA 做到的是團隊之間可以按照接口的契約來解耦。
基礎設施團隊和業務團隊耦合嚴重：長期以來，基礎設施團隊要推動很多業務時，都需要服務團隊進行緊密的配合，例如幫助升級 JAR 包等。這種耦合會帶來各種問題，例如線上客戶端版本的不一致、升級成本高等。
使用 Service Mesh 后狀態
Service Mesh 能夠將基礎設施下沉，讓基礎設施團隊和業務團隊解耦，從而允許各自更加快步地往前跑。
解耦前后對比圖
Service Mesh 解決方案
選型思考
問題：要實現 Service Mesh 的預期效果，首先要面臨技術選型。技術選型主要面臨下述幾個問題。
開源/自研：由于存在自有協議和歷史遺留問題，不適合全部遷移到 Envoy。
SDK/透明劫持：透明劫持的運維和可監控性不好、性能不高、風險不太可控。
最終選型方案：自研數據面 + 輕量 SDK，也就是 MOSN（Modular Open Smart Network-Proxy）。
總體目標架構
MOSN 目前支持下述組件：
Pilot
螞蟻的服務發現組件 SOFARegistry
螞蟻的消息組件 SOFAMQ
數據庫組件
MOSN 在產品層已向開發者提供下述能力：
運維
監控
安全
要實現上述狀態，我們要解決業務的三大訴求：
框架升級方案
容器替換方案
MOSN 升級方案
框架升級方案
升級前，線上現狀：
應用代碼和框架有一定程度的解耦。
用戶面向的是一個 API。
代碼需要打包后，在 SOFABoot 中運行。
升級方案：主要步驟示例如下。
評估后，在風險可控的情況下，直接升級底層的 SOFABoot。
讓 RPC 去檢測一些信息，來確定當前 Pod 是否需要開啟 MOSN 的能力。
通過檢測 PaaS 傳遞的容器標識，確定 MOSN 開啟狀態，將發布和訂閱傳給 MOSN，直接完成調用，不再尋址。
優缺點：
優點：通過批量的運維操作，直接修改了線上的 SOFABoot 版本，使得現有的應用具備了 MOSN 的能力。
缺點：
該升級方案運行時需要關閉流量等輔助操作。
不具備平滑升級的能力。
直接和業務代碼強相關，不適合長期操作。
不采用社區流量劫持方案的考慮：
iptables 在規則配置較多時，性能下滑嚴重。
它的管控性和可觀測性不好，出了問題比較難排查。
Service Mesh 從初期就把螞蟻集團線上系統全量切換 Mesh 作為目標，對性能和運維的要求非常高，不能接受業務有損或者資源消耗率大幅度上升。
容器替換方案
框架升級方案，只是解決了可以做，而并不能做得好，更沒有做得快，面對線上數十萬帶著流量的業務容器， 如何實現這些容器的快速穩定接入？在流量很大情況下，傳統的替換接入需消耗大量接入成本，于是，螞蟻團隊選擇了原地接入。
傳統接入和原地接入對比圖
傳統接入和原地接入對比：
傳統接入：
升級操作需要有一定的資源 Buffer，然后批量的進行操作，通過替換 Buffer 的不斷移動，來完成升級。
要求 PaaS 層有非常多的 Buffer，需要更多的錢來買資源。
CPU 利用率低。
原地接入：
通過 PaaS 層，Operator 操作直接在現有容器中注入，并原地重啟，在容器級別完成升級。升級完成后，該 Pod 就具備了 MOSN 的能力。
提高了 CPU 利用率。
是一個類似超賣的方案，看上去分配了 CPU 和內存，實際上，基本沒增加。
MOSN 升級方案
容器替換方案完成后，我們要面臨第三個問題：由于是大規模的容器，所以 MOSN 在開發過程中，勢必會存在一些問題，MOSN 出現問題，如何升級？線上幾十萬容器升級一個組件的難度是很大的，因此，在版本初期就需考慮到 MOSN 的升級方案。
簡版升級方案
方案思路：銷毀容器，用新容器重建，示例如下。
方案缺陷：
在容器數量很多時，運維成本不可承受。
銷毀容器后，如果重建速度不夠快，就可能會影響業務的容量，造成業務故障。
無損升級方案
為了解決簡版升級方案的不足，在 MOSN 層面，和 PaaS 一起，開發了無損流量升級方案，示例如下：
方案思路：
MOSN 會感知自己的狀態。
新的 MOSN 啟動時，會通過共享卷的 Domain Socket 來檢測同 Pod 是否已有老的 MOSN 在運行，如果有，則通知原有 MOSN 進行平滑升級操作，流程如下：
New MOSN 通知 Old MOSN，進入平滑升級流程。
Old MOSN 把服務的 Listen Fd 傳遞給 New MOSN，New MOSN 接收到 Fd 之后啟動， 此時 Old 和 New MOSN 都正常提供服務。
New MOSN 通知 Old MOSN 關閉 Listen Fd，然后開始遷移存量的長連接。
Old MOSN 遷移完成，銷毀容器；
方案示例如下：
方案優勢：線上做任意的 MOSN 版本升級，都不影響老業務。
MOSN 應用之分時調度
技術的變革通常并不是技術本身的訴求，而是業務的訴求，是場景的訴求。很少有人會為了升級而升級，為了革新而革新。通常，技術受業務驅動，也反過來驅動業務。
在阿里經濟體下，淘寶直播、實時紅包、螞蟻森林等各種活動的不斷擴張，給技術帶了復雜的場景考驗。
這種場景，對于業務來說就意味著代碼已經最優化而流量卻幾乎無法支撐，解決辦法就是擴容增加機器，而更多的機器意味著更多的成本付出。對于這樣的情況，Service Mesh 是一個很好的解決辦法。
通過和 JVM 及系統部的配合，利用進階的分時調度實現靈活的資源調度，可以實現更好的效果且不必加機器資源，說明如下：
資源需求：假設有如下兩個大的資源池的資源需求。
在 X 點的時候，資源域 A 需要更多的資源。
在 Y 點的時候，資源域 B 需要更多的資源。
資源總量不得增加。
借調方案：上述資源需求需要通過借調機器來完成，借調方案有下述 2 種。
常規方案：
先釋放資源，然后銷毀進程，接著重建資源，最后啟動資源域 B 的資源。
該過程對于大量的機器是重型操作，而且變更就是風險，關鍵時候做這種變更，很有可能帶來衍生影響。
分時調度方案：MOSN 的解決思路如下。
有一部分資源一直通過超賣運行著兩種應用。
X 時刻：資源域 A 處于運行態，資源域 B 處于保活態。資源域 A 通過 MOSN 將流量全部轉走，應用的 CPU 和內存就被限制到非常低的情況，大概保留 1% 的能力。這樣操作，機器依然可以預熱，進程也不停。
Y 時刻：資源域 B 處于運行態，資源域 A 處于保活態。在需要比較大的資源調度時，通過推送開關，可以打開資源限制，保活狀態取消等。資源域 B 瞬間可以滿血復活。而資源域 A 此時進入 X 時刻狀態，CPU 和內存被限制。
MOSN 以一個極低的資源占用完成流量保活的能力，使得資源的快速借調成為可能。
MOSN 分時調度細節圖
Service Mesh 未來之展望
Service Mesh 在螞蟻集團經過兩年的沉淀，最終經受住了雙十一的檢驗。在雙十一活動中，螞蟻集團覆蓋了數百個雙十一交易核心鏈路，MOSN 注入的容器數量達到了數十萬，雙十一當天處理的 QPS 達到了幾千萬，平均處理 RT < 0.2 ms，MOSN 本身在大促中間完成了數十次的在線升級，基本上達到了設計的預期效果，初步完成了基礎設施和業務第一步的分離，見證了 Mesh 化之后基礎設施的迭代速度。
不論何種架構，軟件工程沒有銀彈。架構設計與方案落地總是一種平衡與取舍，目前還有一些 Gap 需要繼續努力去攻克，但是，螞蟻人相信云原生是遠方和未來。
經過兩年的探索和實踐，螞蟻集團積累了豐富的經驗。Service Mesh 可能會是云原生下最接近 “銀彈” 的那一顆子彈，未來 Service Mesh 會成為云原生下微服務的標準解決方案，接下來螞蟻集團將和阿里集團一起深度參與到 Istio 社區中去，和社區一起把 Istio 打造成 Service Mesh 的事實標準。
期待的 Service Mesh 架構
