從網絡接入層到 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：github.com/sofastack/s…

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

公衆號：金融級分佈式架構（Antfin_SOFA）