從網路接入層到 Service Mesh，螞蟻金服網路代理的演進之路

本文作者：肖涵（涵暢）

上篇文章《 詩和遠方：螞蟻金服 Service Mesh 深度實踐 | QCon 實錄》中， 介紹了 Service Mesh 在螞蟻金服的落地情況和即將來臨的雙十一大考，幫助大家瞭解 Service Mesh 未來發展方向和前景。螞蟻金服持續在進行 Service Mesh 佈道和交流。本文內容整理自 10 月 26 日 Service Mesh Meetup#7 成都站主題演講，現場影片以及分享 PPT 獲取方式見文章底部。

從網路硬體裝置到自研平臺，從傳統服務治理到 Service Mesh，本文將介紹螞蟻金服網路代理在接入層以及 Service Mesh 化道路上是如何一步步支撐起秒級百萬支付，千萬春晚咻一咻的。

前言

在雲端計算和 SDN 下，我們經常聽到流量的東西南北向概念，簡單來說從外部 Internet 等到資料中心內部的流量走向被稱為南北流量，資料中心內部的 VM 之間的流量被稱為東西流量。

當我們追蹤南北向的網路流，請求通常會經過四層負載均衡，七層負載均衡等，這通常被我們稱為網路接入層代理。當資料中心內部主動訪問公網時候，流量通常也會經過 NAT 閘道器等做網路地址的轉換，這也被我們稱為網路代理。當我們把視角轉向資料中心內部，網路代理的存在感似乎不是那麼強，隨著 SOA 的發展我們形成了各種成熟的服務通訊框架，例如螞蟻金服的 SOFARPC，阿里集團的 HSF，Google 的 gRPC 等等，網路代理功能被整合進了各種通訊框架中，似乎已經 Proxyless 化了，但是隨著微服務以及 Service Mesh 的架構提出，東西向的網路代理以獨立的姿態又出現了。

本文將圍繞螞蟻金服近十年網路代理的變遷，揭示整個螞蟻金服接入層網路以及 Service Mesh 的演進過程，同時帶來我們的思考。

舊瓶新裝

我們先來看看業界情況，傳統四層負載均衡的代表產品當然是 IPVS，百度阿里等公司早年均對 IPVS 做了非常深度的定製功能，支撐了早期業務的飛速發展。接著也有 DPDK(阿里雲 SLB)，類 DPDK 技術的代表 Google 的 Maglev 以及 eBPF 技術的代表 Facebook 的 Katran 出現。

七層網路代理各個大廠均有產品代表，Google 的 GFE、百度 的 BFE、騰訊 的 TGW，阿里經濟體內部也因為場景等原因有眾多，例如手淘的 Aserver，集團 web 統一接入 Tengine，當然還有螞蟻金服的 Spanner（後面會詳細介紹）。同時隨著 Service Mesh 概念的提出和技術的逐漸成熟，Mesh 中 Sidecar 角色的網路代理也像雨後春筍一樣多了起來，包括螞蟻金服的 SOFAMosn，Istio 社群方案的 Envoy 以及 Rust 編寫的 Linkerd，當然 Service Mesh 場景的網路代理和網路接入層的代理我認為沒有本質的差別，隨著雲原生的深入化，大家終將會形成合力並保持一致的形態。

上圖是2019年 Gartner Networking 方向的曲線，可以看到在上升和爆發區有著非常多的網路代理的影子（Secure Access Service Edge，Service Mesh，Edge Networking，Firewall as a Service etc.），雖然網路代理是一項古老的技術以及產品形態，但是仍然隨著基礎設施以及業務的變化以新的能力和角色展現在世人眼前。

網路代理的十年

網路代理技術一直圍繞“高效接入，訪問加速，穩定高可用，安全合規”四個關鍵詞，不斷升級核心能力，架構以及運維能力，底層基礎網路物理頻寬從1G到10G、25G、100G；阿里骨幹廣域網路走出杭州擴充套件到全國、全球規模，不斷地透過前瞻技術架構研發，技術自主能力的提升和轉變，助力業務發展。

螞蟻金服應用網路架構概覽

產品理念

我們應該以什麼樣的業務設計來滿足上層業務以及市場的需要？產品理念決定了產品的走向，我們設定了網路產品的核心理念模型：

                                    網路產品設計理念

接入層代理十年變遷

接入層網路代理的十年變遷之路，我們可以總結為三個時代，四個階段：PC 時代，移動時代和萬物互聯雲原生時代，伴隨著這三個時代，我們經歷了四個關鍵路徑。

前世

2010年前螞蟻金服網路代理是商用裝置的時代，包括 F5 的 bigip，Netscaler 等產品，對於商業裝置白盒化，大家比較熟知的是去 IOE，其實網路裝置走在了更前面。使用商用裝置主要有幾個問題，廠商的 Lockin，成本以及靈活擴充套件等問題，所以從2010年螞蟻金服開始向自主研發演進。

自主研發

我們同時開啟了四七層網路接入的自研之路，四七層網路由於場景的不同，在整個演進路線上也有較大的差異。

四層負載均衡

四層網路由於不理解業務語義，主要進化路線是伴隨著系統技術，硬體技術的變化，圍繞提高吞吐，降低延遲的目標而演進。2014年全面使用 DPDK 進行技術重構，將傳統基於核心技術的 IPVS 新建，轉發指標分別從萬級，十萬級提高到百萬和千萬級的每秒包轉發。

同時隨著 Ebpf，Xdp 技術的出現，基於核心的高速轉發平面產品又橫空出世（包括 Facebook 開源的 Katran）打破了 DPDK 技術的壟斷，同時可程式設計交換晶片以及 P4 語言也加入了這一站場，這裡不具體討論每種技術的優劣。

Spanner

Spanner 是螞蟻金服的統一接入閘道器，其意為扳手，主要是為螞蟻金服 SSL 解除安裝和網路接入提供了白盒化解決方案，承載了螞蟻金服所有的業務流量，包括支付寶 App，Web，商戶等的終端訪問。

金融級三地五中心架構的流量排程

上圖展示了 Spanner 的編年史，在2013年螞蟻金服上架了自己的邏輯資料中心架構 LDC，同時隨著演進支援了目前的螞蟻金服金融級的三地五中心容災架構：

為了支援這套架構，螞蟻金服的所有基礎設施都進行了改造和技術升級，流量調撥能力作為最基礎的能力，是一個基本盤，Spanner 透過對請求頭的識別以及全站轉發規則對映來實現流量排程，支撐並不限於以下場景：

• 機房內隨機路由；
• 藍綠髮布；

• 容災：

• 邏輯機房內容災；

• 機房級別；

• 城市級別；

• 彈性排程；
• 壓測流量排程；

• 灰度流量排程；

SSL/TLS 實踐

螞蟻金服作為全集團最早實踐 https 全站的 BU，一直圍繞著安全，合規，效能的主題進行全站加密體系的建設。

成本之戰

前面提到2012年 Spanner 全面上線後，我們接入層具備了定製業務邏輯的能力，在2013年很好支撐了 LDC 的上線，同時我們在效能成本方面也有機會去進行持續的提升，同年我們引入 SSL 加速卡軟硬體一體解決方案，從現在來看該套方案已經非常成熟了，集團 Tengine，Openssl 都提供了非常方便的接入框架，但是當年這一塊還一直處於探索階段。我們在 Spanner 裡做了 Nginx 的 SSL 握手非同步化改造，改造了 Openssl 同 Cavium 的 SSL 加速卡進行適配，整套方案在當時的機型上較 CPU 提升了基於 RSA2048 演算法的 SSL 握手3倍的效能，同時也對後續各大廠商在這方面的實踐產生了指導性意義。

效能之戰

在解決了全站 SSL 帶來的成本提升問題後，協議效能以及使用者體驗問題擺在了我們面前，2018年8月，網際網路工程任務組（IETF）正式釋出 TLS1.3 協議的最終版本（RFC 8446）。該協議在安全性、效能和隱私方面有重大改進，大大提升 HTTPS 連線的速度效能。同年9月 Openssl 也宣佈釋出其最新版本 openssl1.1.1，支援 TLS1.3。但大家可以看到，無論是協議還是實現都在2018年才真正 Realese，但是在2014，2015年我們已經面臨了行動網路下的 SSL 帶來的問題，最終我們基於 TLS1.3 草案，在 TLS1.2 上以擴充套件形式實現了：

• 1RTT，0RTT 減少握手延遲；
• Cache Info 擴充套件快取證照等服務端資訊，避免再次握手時重複傳輸資料；
• ECDHE-keyshare 擴充套件；
• ECC-signature 擴充套件使用高效 ECDSA 簽名演算法的同時，相容廣泛使用的 RSA 證照；
• Small Ticket 自定義 Session Ticket 編碼格式，從160 byte -> 76 byte；

我們提前享受了 TLS1.3 帶來了紅利同時在此基礎上做了更多最佳化，沉澱了螞蟻金服的輕量級 mTLS 加密庫。

安全合規能力持續提升

央行、國家密碼管理局、支付清算協會等開啟了非銀行支付機構的國產密碼落地改造工作，螞蟻金服也全面開始擁抱監管，安全可控以及金融科技的能力建設。我們將此前在加密庫，Openssl 等方面的積累沉澱再啟程，打造了Babassl 庫（阿里經濟體共同打造）：

• Brisk and Better assurance SSL；
• 基於Openssl；
• 合併經濟體內部對 Openssl 的定製修改；
• 全面相容現有國家金鑰安全體系，並在此基礎上推出了效能更優的國密+tls1.3單證照標準；
• 支援 SGX 等可信機制；

• 輕量級，適配多終端；

  
  

同時我們有 Openssl 亞洲唯一 committer 楊洋加持。

移動無線戰役

伴隨著 ALL IN 無線的集團戰略的推進、支付寶 App 使用的人數增長和場景複雜化，我們同支付寶網路團隊於2015年合作進行了名為“一網打盡”的移動技術整治專項，在介紹具體的技術改造前，我們先來看看移動網際網路場景的問題：

• 端到端的無線網路複雜性；
• 運營商網路黑盒；
• 無線終端的長時線上性；

具體到支付寶 App，線上支付、線下支付、大促、境外遊支付等為常見的場景，而操作響應慢、無響應、支付緩慢、push 訊息不及時等都是令人頭痛的移動體驗，所以我們圍繞快速穩定和高效進行一場移動無線戰役，這裡將著重分析在 Spanner 上進行的技術改造。

咻一咻的併發挑戰

網路通道方面是一個持續建設過程。此前我們基於 TCP 通道以及 SPDY 私有幀打造了一套高效的端到端的網路鏈路，一網打盡網路專項主要對流量通道進行了持續升級和流量收編，將 RPC 鏈路，Push 鏈路統一。由於當時的背景，HTTP2 並沒有完備的實現，同時不支援雙向全雙工通訊，HTTP2 也並沒有對行動網路量身定做非常多的最佳化。基於此我們在統一通道上實現了新的協議 MMTP（螞蟻無線傳輸協議）以及 MTLS（SSL/TLS 實踐中提到），我們將Hpack 進行了動態化，同時進入基於 Zstd 的動態字典壓縮演算法，同時在實現上對包大小的追求到了極致，較之前的網路體驗提升非常明顯。在2015年的春晚紅包中，我們支撐了3億終端使用者同時線上，數千萬每秒的咻一咻點選。

經此一役，我們構建了統一接入雙工通道，實現了行動網路通訊的確定性，最終具備數億活躍裝置觸達、上億裝置同時線上、體驗可靠流暢的雲管端通道技術能力，在此之後沉澱為螞蟻金融科技移動產品 mPass 的網路接入元件。

萬物互聯雲原生

這一階段是我們再啟程的階段，透過前面個階段的錘鍊，我們的接入層已成體系，具備了持續整合，快速迭代的底座，為更好支援業務的不確定性提供了堅實的底盤。我們同螞蟻安全團隊、支付寶網路團隊共同持續進行安全合規加強，網路體驗提升的技術能力加強。

物聯裝置接入

基於 Spanner，我們實現了 MQTT 協議可以透過非常小的接入成本實現新的裝置和協議的接入。目前我們支援了 MQTT 協議的 IoT 裝置接入，包括支付寶收銀盒等產品形態。

安全防攻擊

在安全防攻擊方面螞蟻接入層一直在持續演進，透過和螞蟻安全團隊共建的 WAF，流量映象等，完備了接入層的安全合規體系。

通訊協議與架構升級

在高效接入方面螞蟻接入層一直在持續演進，透過引入 QUIC 協議，螞蟻全球加速節點來提升掃碼支付，商戶支付，境外遊，海外錢包等的使用者體驗。

QUIC較優實踐

• 引入 QUIC LB 解決 QUIC 連線遷移難題；
• 多程式輪轉 Listen 解決 Server 平滑升級；
• 服務不可用的網路 Reset；
• UDP 資料包高吞吐核心調優；
• 0RTT token 校驗，防重放攻擊；
• 客戶端 MTU 探測；

螞蟻全球網路加速

為了提升境外遊，螞蟻海外站點等的螞蟻金融使用者體驗，我們利用阿里集團全球的骨幹網路，基於螞蟻網路接入層技術建設了螞蟻全球網路加速節點。

雲原生生態融合

目前網際網路最流行的詞非“雲原生”莫屬，透過業務與基礎設施解耦帶來生產力解放的同時，傳統基礎設施的邊界越來越模糊，IaaS 與 PaaS 將在一定程度上融合。目前傳統的網路接入代理（包括 Spanner）仍然是以獨立於應用生命週期的方式，透過中間層（多為自身管控平面）與業務服務進行關聯，這樣導致維護成本頗高，在服務通訊 mesh 化後，接入層也可以透過下沉到中介軟體方式，從而達到基礎設施融合的目的。在網路代理資料平面方面 CNCF 正在籌建通用資料平面 API 工作組（Universal Data Plane API Working Group / UDPA-WG)，以制定資料平面的標準 API，為 L4/L7 資料平面配置提供事實上的標準。後續有望看到東西，南北流量代理均相容 UDPA，從而編織出一張全域性統一排程的雲原生網路。

Mesh 架構下的網路代理

服務發現與路由

東西流量的服務發現與路由，其實是一個去網路代理的過程，我們可以看到從初期的集中式代理演進到了服務配置中心的點對點通訊，但是在雲原生微服務的演進過程中，我們又對網路代理有了新的要求。這裡我不再著重描述 Service Mesh 是什麼，能解決什麼問題，只是稍作強調一下在 Service Mesh 場景下，網路代理又以新的方式回來了，他站在每一個服務的旁邊幫助服務打理與業務無關的各種網路以及服務治理問題（負載均衡，服務路由，鑑權等）。

為金融業務而生的 SOFAMesh

螞蟻金服於2017年開始探索 Service Mesh，2018年開始自研 Sidecar-SOFAMosn 以及控制平面（整體產品SOFAMesh），2019年上半年開始落地支撐了618部分業務，2019年下半年全面鋪開迎接雙十一大促，目前對外公佈資料是覆蓋交易核心鏈路100+應用，數十萬容器例項，目前正在靜待今年雙十一的驗證。

可以看到螞蟻金服 SOFAMesh 在架構演進上的決心非常大，目前已經到了中盤拿結果階段，為什麼螞蟻金服需要 Service Mesh：

• 擁抱微服務，雲原生；
• 異構語言體系融合；
• 統一服務治理；
• 運維體系有利支撐；
• 全域性流量管理，打通南北，東西；
• 金融級網路安全；

Service Mesh 架構帶來的紅利都是螞蟻金服所需要的，這裡不再多介紹，而對於金融級網路安全我可以多做一些描述。

我們透過 Mesh 化支援了服務的全鏈路加密以及服務鑑權，在金融場景同時支援國密演算法，擁抱監管合規。同時控制平面適配螞蟻金服 KMI 系統，能達到金融級的秘鑰管理能力，同時在 Mesh 代理 SOFAMosn 上實現了 Mirroring 流量功能，透過實時分析服務通訊流量構築強大的金融風控系統。至此從研發，測試，灰度，生產打造了全安全生命週期 Service Mesh 架構，支撐了螞蟻金服的各種業務。

雲原生安全網路代理 SOFAMosn

SOFAMosn：

Written in go

前面提到螞蟻金服自研了 Golang 版本的網路代理 SOFAMosn：

• 為什麼我們要自研？
• 為什麼我們不用 Spanner？
• 為什麼不使用社群方案 Envoy、Linkerd？

其實在研發初期，我們已經預料到作為下一代螞蟻金服的基礎架構，Mesh 化勢必帶來革命性的變革以及演進成本，我們有非常宏大的藍圖：準備將原有的網路和中介軟體方面的各種能力重新沉澱和打磨，打造成為未來新一代架構的底層平臺，承載各種服務通訊的職責。

這是一個需要多年時間打造，滿足未來五年乃至十年需求的長期規劃專案，合作共建團隊跨業務，SRE，中介軟體，基礎架構等。我們必須有一個具備靈活擴充套件，高效能，滿足長期演進的網路代理轉發平面。Spanner、Envoy 在研發效率、靈活擴充套件等方面均有不滿足的地方，同時在整個 Mesh 改造涉及到非常多的部門和研發人員，必須考慮到跨團隊合作的落地成本，所以我們基於 Golang 棧自研了雲原生場景下的新型網路代理 SOFAMosn。對於 Golang 的效能，我們前期也做了充分的調研和測試，在 Service Mesh 場景下單 Sidecar 的效能從來都不是需要最高優先順序考慮的問題，往往對效能 RT 有極致要求的業務目前看來並不適合 Mesh 架構。

SOFAMosn 能力與模組劃分

SOFAMosn 主要劃分為以上幾個模組，我們可以基於 Stream、Net 等進行能力擴充套件，下面會講到。

SOFAMosn 協程模型

Golang 體系下，我們使用輕量級的協程進行基礎架構，一條 TCP 連線對應一個 Read 協程，執行收包、協議解析，一個請求對應一個 Worker 協程，執行業務處理、Proxy 和 Write 邏輯。

SOFAMosn 能力擴充套件

協議擴充套件

透過使用同一的編解碼引擎以及編/解碼器核心介面，提供協議的 plugin 機制，目前已經支援：

• SOFARPC；
• HTTP1.x,/HTTP2.0；
• Dubbo；

NetworkFilter  擴充套件

透過提供 Network Filter 序號產生器制以及統一的 Packet Read/Write Filter 介面，實現了 Network Filter 擴充套件機制，當前支援：

• TCP proxy；
• Fault Injection；

StreamFilter  擴充套件

透過提供 Stream Filter 序號產生器制以及統一的 Stream Send/Receive Filter 介面，實現了 Stream Filter 擴充套件機制，包括支援：

• 流量映象；
• RBAC鑑權；

心跳檢查擴充套件 Demo

基於 xDS 的動態配置

Mesh 場景下網路代理的挑戰

從前面的介紹可以得知，網路接入層最大的挑戰就是應對海量洪峰流量時的高效性，而作為 Mesh 場景的大規模落地，除此之外還有更多需要考慮的問題：

• 不同的應用，部分 Mesh 化；相同的應用，部分 Mesh 化；TLS 鏈路的相容等。我們必須做到任何場景下 保證可正常處理請求，做到可灰度、可回滾的 相容，平滑遷移；
• 通用的框架能力（SOFAMosn/Envoy）無法直接滿足複雜的、定製的業務能力，需要進行針對性的 更加靈活 擴充套件 實現；
• 需要 融合 已有的應用服務體系，如註冊中心、配置中心等，做到行為的 一致性；
• 大規模場景下需要面對的 資源分配，自動化問題、效能問題，穩定性 問題；

下面我主要談談大規模下的問題，數十萬例項對控制平面效能，穩定性帶來巨大挑戰以及單例項數萬路由節點，數千路由規則，不僅佔用記憶體，對路由匹配效能也有較大影響。在服務發現方面，海量高頻的釋出訂閱動作對網路代理的穩定性和效能也帶來挑戰。微服務的治理和運維同樣一直都是一個難題，Mesh化後獨立出來的網路代理需要融入到雲原生業務體系裡統一對待，所以SOFAMosn的獨立平滑升級，良好的釋出策略等都是非常重要的。

平滑升級

由於 Sidecar 作為基礎設施的特殊性，我們需要達到基礎設施升級的業務無感知的目的，傳統的網路代理例如 Nginx 透過關閉老程式的 Listen 埠來做到新程式接管新連線和請求的目的，這種方案對於 HTTP 等短連線 Ping-Pong 協議是非常有效的，但是無法很好支援長連線的雙向流式協議。所以我們在 SOFAMosn 上實現了連線遷移能力，達到網路代理升級過程中的連線平滑遷移，保證服務的持續性。透過 sendmsg 以及 TCP_REPAIR 都可以做到套接字的遷移，其實在此種場景中套接字的遷移能很好實現，整個連線的 session 恢復會是比較麻煩的過程。

資源問題

當網路代理 SOFAMosn 作為 Sidecar 部署時，我們面臨了新的挑戰，不再像 Spanner 一樣獨佔物理機，或者以獨立應用的容器化方式只用關心自己的能力以及資源消耗，我們必須精細化 CPU、記憶體等資源，才能達到與應用最優的協同合作方式。

總結與思考

關於未來：

• 雲原生，多雲混合雲時代，南北，東西流量的邊界逐漸模糊；
• 應用網路代理層部分能力固化，下沉至系統網路棧或者智慧硬體裝置；
• Sidecar -> Proxyless -> Networkless；

• 物理通訊基礎設施的升級勢必帶來應用網路層的變革；

  
  

回望這十年，是商業的發展不斷推動著系統演進的十年，又是技術演進不斷成就著商業的奇蹟的十年，我們經過十年沉澱，建設了一套金融級的通訊安全基礎設施，具備全域性排程能力的應用層網路 SDN 系統，新的基礎軟體，生態以及硬體在不斷迭代，提供越來越極致的架構改變和效能提升，技術的進步又會驅動業務不斷去擴充未曾接觸或曾經無法解決的問題領域，給我們帶來更大挑戰，所以我們將來更需要密切把握技術脈搏、兼具全域性視野，以幫助我們做出關鍵判斷，未來已來，讓我們與時代同行，期待下一個十年。

這次螞蟻金服 Service Mesh 上雙十一，將是 Service Mesh 的歷史時刻：Service Mesh 首次超大規模部署， 歡迎對 Service Mesh 感興趣的同學持續關注本號，在雙十一之後將會分享一系列螞蟻金服 Mesh 化相關文章，與大家交流分享。

作者介紹

本文作者：肖涵（涵暢），螞蟻金服高階技術專家。2011年加入螞蟻金服，一直從事四/七層網路負載均衡，高效能代理伺服器，網路協議相關的研發工作，目前是螞蟻金服系統部應用網路組負責人。