從網絡接入層到 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：

https://github.com/sofastack/sofa-mosn

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年加入螞蟻金服，一直從事四/七層網絡負載均衡，高性能代理伺服器，網絡協定相關的研發工作，目前是螞蟻金服系統部應用網絡組負責人。