上篇文章《詩和遠方：螞蟻金服 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 鑑權；
基於 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，內存等資源，才能達到與應用最優的協同合作方式。
性能數據
上圖是一個簡單的同 Envoy 的性能測試，測試雙方使用默認配置沒有使用任何調優，僅供參考。
總結與思考
關於未來：
- 雲原生，多雲混合雲時代，南北，東西流量的邊界逐漸模糊；
- 應用網絡代理層部分能力固化，下沉至系統網絡棧或者智能硬件設備；
- Sidecar -> Proxyless -> Networkless；
- 物理通信基礎設施的升級勢必帶來應用網絡層的變革；
回望這十年，是商業的發展不斷推動着系統演進的十年，又是技術演進不斷成就着商業的奇蹟的十年，我們經過十年沉澱，建設了一套金融級的通信安全基礎設施，具備全局調度能力的應用層網絡 SDN 系統，新的基礎軟件，生態以及硬件在不斷迭代，提供越來越極致的架構改變和性能提升，技術的進步又會驅動業務不斷去拓展未曾接觸或曾經無法解決的問題領域，給我們帶來更大挑戰，所以我們將來更需要密切把握技術脈搏、兼具全局視野，以幫助我們做出關鍵判斷，未來已來，讓我們與時代同行，期待下一個十年。
作者介紹：
肖涵（涵暢），螞蟻金服高級技術專家。2011年加入螞蟻金服，一直從事四/七層網絡負載均衡，高性能代理服務器，網絡協議相關的研發工作，目前是螞蟻金服系統部應用網絡組負責人。
本文轉載自公衆號金融級分佈式架構（ID：Antfin_SOFA）。
原文鏈接：