2019 年 10 月 27 日，又拍雲聯合 Apache APISIX 社區舉辦 API 網關與高性能服務最佳實踐丨Open Talk 杭州站活動，螞蟻金服技術專家烈元做了題為《螞蟻金服網絡代理演進之路》的分享。本次活動，邀請了來自阿里巴巴、螞蟻金服、Apache APISIX、PolarisTech、又拍雲等企業的技術專家，分享網關和高性能服務的實戰經驗。
烈元，螞蟻金服技術專家，螞蟻金服開源項目 SOFAMosn 的核心成員，Tengine 專家。
以下是分享全文：
從網絡硬件設備到自研平台，從傳統服務治理到 Service Mesh，本次分享將會介紹螞蟻金服網絡代理在接入層以及 Service Mesh 化道路上是如何一步步支撐起秒級百萬支付，千萬春晚咻一咻的。
什么是網絡代理
宏觀上，網絡代理主要由南北流量和東西流量兩塊構成。南北流量就是統一結構層，是從外部 Internet 等到數據中心內部的流量走向，東西流量指數據中心內部的 VM 之間的流量，比如微服務就是東西流量。
當我們追蹤南北向的網絡流，請求通常會經過四層負載均衡，七層負載均衡等，這通常被稱為網絡接入層代理。當數據中心內部主動訪問公網時，流量通常也會經過 NAT 網關等做網絡地址的轉換，這也被稱為網絡代理。而在數據中心內部，網絡代理的存在感似乎不是那么強，隨着 SOA 的發展，我們形成了各種成熟的服務通信框架，例如螞蟻金服的 SOFARPC，阿里集團的 HSF，Google 的 gRPC 等，網絡代理功能被集成進了各種通信框架中，似乎已經 Proxyless 化了，但是隨着微服務以及 Service Mesh 的架構提出，東西向的網絡代理以獨立的姿態又出現了。
-
傳統的四層負載均衡的代表產品是 IPVS，百度、阿里等公司早年均對 IPVS 做了非常深度的定制功能，支撐了早期業務的飛速發展。
-
七層網絡代理各個大廠均有產品代表，Google 的 GFE、百度的 BFE、騰訊的 TGW，阿里經濟體內部也因為場景等原因有眾多，例如手淘的 Aserver，集團 Web 統一接入 Tengine，當然還有螞蟻金服的 Spanner。
-
隨着 Service Mesh 概念的提出和技術的逐漸成熟，Mesh 中 Sidecar 角色的網絡代理也像雨后春筍一樣多了起來，包括螞蟻金服的 SOFAMosn，Istio 社區方案的 Envoy 以及 Rust 編寫的 Linkerd，當然 Service Mesh 場景的網絡代理和網絡接入層的代理我認為沒有本質的差別，隨着雲原生的深入化，大家終將會形成合力並保持一致的形態。
我接下來會從這三個方面分別講述螞蟻金服網絡代理近十年來的演進過程。
螞蟻金服網絡代理的十年
早在 2016 年，流量對於網絡的挑戰就已經很大了，比如“咻一咻”業務，1 分鍾內產生 210 億次調用量，這個是真正從外部導入內部的流量，現在的數據就更大了。這種大流量、大業務場景對於系統是很大的挑戰。
螞蟻金服內部始終圍繞“穩定性高可用、容量、高效接入訪問加速、靈活彈性、安全合規防攻擊”這五方面來做整體設計，不斷升級核心能力，架構以及運維能力，底層基礎網絡物理帶寬從 1G 到 10G、25G、100G；阿里骨干廣域網絡走出杭州擴展到全國、全球規模，不斷地通過前瞻技術架構研發，技術自主能力的提升和轉變，助力業務發展。
接入層網絡代理的十年變遷，從 2010 年到 2019 年，主要經歷了三個時代，四個階段的發展。
前世
2010 年前螞蟻金服網絡代理是商業設備的時代，包括 F5 的 Bigip 作為四層接入，負責硬件的負載均衡，當然后面慢慢被 LVS 所替代；Netscaler 作為 SSO 的網絡卸載等。
自主研發
到了 2011 年，因為無法滿足各種業務邏輯，我們走上了自研的道路，設計了硬件、軟件的一體化方案。
自研四層網絡代理
2011 年后螞蟻金服進入四層網絡代理自研階段，主要是基於內核的 NetFilter，比如 LVS 做自研擴展。2014 年，我們全面使用 DPDK 技術進行了重構，極大的加大了網絡吞吐量。而從 2018 年至今，內核有了更多的網絡技術，比如 EBPF、可編程交換芯片等。
螞蟻七層網絡代理：Spanner
Spanner 是螞蟻金服的七層網絡代理 ，其意為扳手，主要是為螞蟻金服 SSL 卸載和網絡接入提供了白盒化解決方案，承載了螞蟻金服所有的業務流量，包括支付寶 App、Web、商戶等的終端訪問。
上圖是 2010 年至今的七層接入的演進過程，每個階段有不同的特性，Spanner 是基於 Nginx fork 的，和 Tengine 有很多的融合，因此會有很多 Tengine 的特性。
上圖是螞蟻七層網絡代理接入架構圖，用戶通過螞蟻金服的網絡入口進來，通過多協議接入，到 LVS 和 Spanner，Spanner 作為統一七層網關把請求分發給后面的應用。在 Spanner 上有很多業務邏輯、協議支持，比如 TLS 1.3、QUIC、HTTP 以及螞蟻自研的協議等。螞蟻的所有業務，包括支付寶錢包、其他頁面都是通過這個入口進來，Spanner 目前支持了億級用戶的同時在線、千萬級別的 QPS、百萬用戶的推送。
金融級三地五中心架構的流量調度
2013 年螞蟻金服上架了自己的邏輯數據中心架構 LDC，同時隨着演進支持了目前的螞蟻金服金融級的三地五中心容災架構：
Spanner 在其中承擔了很重要的流量調度作用。起初流量低的時候，一個機房、一個 LDC 就可以把所有的流量都接入。隨着用戶的增長，出現了同城雙活 LDC，同城多活 LDC，直到現在的彈性伸縮混部 LDC，快上快下，能夠很快的擴容機房出來，這種彈性構架對於 Spanner 流量調度有很高的要求。
為了滿足金融級三地五中心架構的流量調度的要求，針對不同的業務場景，Spanner 要提供不同的功能。舉個簡單的例子，比如第一次請求進來，Spanner 會隨機分流到一個 zone，zone 會把用戶分到所屬單元內，比如用戶屬於杭州單元，即杭州機房，當這個用戶下次再訪問時，就會直接定位到這個杭州機房。這個功能有點類似於Tengine 的 Session sticky，不過那是相對於單機的維度，而 Spanner 的調度是作用於機房維度的。
目前 Spanner 能夠支撐並不限於以下的場景：
-
機房內 zone 隨機路由
-
Cookie zone 轉發
-
藍綠發布
-
容災
-
彈性調度
-
壓測流量調度
-
灰度流量調度
SSL/TLS 實踐
螞蟻金服作為全集團最早實踐 https 全站的 BU，一直圍繞着安全，合規，性能的主題進行全站加密體系的建設。
軟硬件一體解決方案
2013 年螞蟻就引入了 Cavium Nitrox 和 Intel QAT 兩種卡，2014 年我們已經在全站實現了 HTTP 化和各種硬件加速。
硬件加速的主要改造點是支持異步，因為原生的 QAT 使用是同步的，比如 Nginx 把握手加密的請求提交給 QAT 卡之，需要做同步等待，在這個時段內你在 Nginx 就不能處理其他東西。而異步則不同，當 Nginx 把握手加密的請求提交給 QAT 卡后，可以直接去處理其他業務邏輯，等到 QAT 卡把這個握手相關信息做完並回調，再繼續處理。在 Spanner 里做 Nginx 的 SSL 握手異步化改造，改造了 Openssl 同 Cavium 的 SSL 加速卡進行適配，整套方案在當時的機型上較 CPU 提升了基於 RSA2048 算法的 SSL 握手 3 倍的性能。
協議實現的改造-MTLS
在協議層上，我們自研了 MTLS 協議。在 2015 年，TLS 1.3 還只是一個草稿，並沒有真正 Realese ，因此我們基於 TLS 1.3 草案，在 TLS 1.2 上以擴展形式實現了：
我們提前享受了 TLS 1.3 帶來了紅利同時在此基礎上做了更多優化，沉淀了螞蟻金服的輕量級 mTLS 加密庫。
安全合規能力持續升級
螞蟻金服是一家金融公司，這就要求我們必須支持國密算法的，我們內部比如網商銀行已經落地了國密算法的支持。由於國密算法的標准是基於 TLS 1.1 做的，在 TLS 1.3 下存在較大的性能問題，作為亞洲唯一有 OpenSSL Committer 的團隊，我們一直在跟國家做 TLS 1.3 支持國密算法的推進工作，相信不久將來就可以看到支持 TLS1.3 的國密。
AntTLS 庫是螞蟻內部基於 OpenSSL 自研的庫，加入了諸如多硬件卡的可信機制的支持 feature，對於包括國密在內的匯編優化也進行了大量的優化。除此之外，因為國密的硬件必須使用加密機，我們的硬件加速卡也通過了這些合規驗證。
移動無線戰役
伴隨着 ALL IN 無線的集團戰略的推進、支付寶 App 使用的人數增長和場景復雜化，我們同支付寶網絡團隊於 2015 年合作進行了名為“一網打盡”的移動技術整治專項，在介紹具體的技術改造前，我們先來看看移動互聯網場景的問題：
-
端到端的無線網絡復雜性；
-
運營商網絡黑盒；
-
無線終端的長時在線性；
具體到支付寶 App，線上支付、線下支付、大促、境外游支付等為常見的場景，而操作響應慢、無響應、支付緩慢、push 消息不及時等都是令人頭痛的移動體驗，所以我們圍繞快速穩定和高效進行一場移動無線戰役，這里將着重分析在 Spanner 上進行的技術改造。
當時我們最大的兩個業務是咻一咻和集五福。
以咻一咻為例，這個對於網絡的要求非常高，當時有上億的用戶等待上圖的界面，同時還有上億的用戶在不停點擊，還要有實時的顯示數。當時這幾塊對我們后台產生了億級別的 QPS，可以說實實在在的點擊全部是由七層網絡代理接入的，這對系統的穩定性是一個巨大的考量。
在無線移動網絡里，我們進行了很多優化，通過最優調度、網絡探測、動態超時等讓我們在網絡通暢時效果更好。同時也做了在錯誤情況下的重試，比如網絡不好的情況下做了很多短連補償，即在長連接請求不成功時發短連接來做補償，還有柔韌建連、自動重試，這讓我們在弱網環境下也能更好的完成任務。
萬物互聯雲原生
自 2018 年起，我們更多的在擴張協議接入，比如最近比較火的 MQTT，以及相當於新一代 HTTP/3 的 QUIC。
在構架升級上，我們在海外新建了很多就近接入節點，這樣讓你在海外可以通過加速節點更快地訪問到支付寶錢包。
還有對雲原生生態的融合，比如類似 UDPA 的基本的數據面平台，以及接入層容器化、混部。
QUIC 方案介紹
因為 QUIC 只有一個協議的實現，真正怎么落地和運用實際都是沒有的，我們引入 QUIC LB 解決 QUIC 連接遷移難題。舉個例子，從 4G 切換到了 WIFI 的這個轉換過程保持數據的連軸狀態，由 App 發起 QUIC 請求，最先的入口請求實際是 LVS+Aliguard，這是一個安全組件相當於流量防護，用於防 DDoS 攻擊。經過這個安全組件的清洗后，會把流量往后傳給 QUIC LB，這個作用是做一個打點保證同一個用戶的多次請求能夠訪問到后端的同一台機器上。
也就是說 QUIC 本身是無狀態的，但是在用戶第一次請求的時候，會埋上點，然后再往后端傳。在這之后才會把請求轉給真正的 Server。這個我們是由 Nginx Stream 模塊來實現的。
針對 QUIC 我們有過多的優化，如上圖，有一些針對這三大塊的專利產出對 QUIC 進行優化。
QUIC 我們主要應用於海外鏈路，比如在國外進行回源就是通過這個鏈路來進行的。因為在這種弱網場景下 QUIC 的的效果更好。
性能優化
2013 年，螞蟻的運營模式是多域名多 VIP，這就導致一個 Nginx 要開幾千個監聽端口，從而產生了一個很大的性能問題。比如關閉 AcceptMutex 肯定會產生驚群，這對 CPU SYS 的消耗很大；而如果把 Accept Mutex 打開，又會遇到性能瓶頸，因為每次在拿到鎖后，所有的監聽套接字都會加到 epoll 里，而且監聽套接字有幾千個，這個對性能損耗是很大的。
現在已經有了很多技術來解決這個問題，比如 Reuseport，最初支持 Reuseport 的是 Tengine，但是 Tengine 最先支持的版本在 Reload 時，連接會 reset，直到最后官方的版本才解決了 reset 問題。還有 EPOLLEXCLUSIVE 的一個參數，這個是在內核階段解決驚群問題的，但它對內核的要求非常高。
而在 2013 年時，我們的解決方法如上圖，嵌套 epoll listen fd。我們把所有的監聽套接字的 fd 加到 epoll 里，epoll 本身有一個 fd，我們再把這個 fd 加到 Nginx 的主 fd 里面。如此可以達到每次拿鎖之后，只需添加一個 fd，只要這個 fd 可讀，就證明里面肯定有事件。通過這個方式，我們大量減少了對於高並發下的系統負載。這在當時給我們提供了一種嵌套 epoll fd 的思路，在這種場景下，並非一定要去使用 Nginx 的那個 epoll，還可以自己在加 epoll 來存放某一類型的事件，這里是放監聽的事件。
Mesh 架構下的網絡代理
服務發現與路由
如開始提到，從宏觀上說網絡代理主要由南北流量和東西流量兩塊構成，而東西流量的服務發現與注冊和微服務相關，前面介紹的都是入口流量七層代理，后面介紹的會更接近於東西流量。
如上圖，東西流量最開始的構架是 F5，一個應用訪問另外一個應用通過內部 VIP 進行調度，這個是最老的模式，很難管理；之后發展為 Proxy 代理模式，也是做七層，一個 Nginx 做代理到后面的 App；最右邊模式是現在業內比較流行的，很多企業內部都用的這種發布注冊的模式，即一個應用注冊服務，然后來調對應的服務方，目前螞蟻金服內部也是這種模式，不過我們也在做一些技術改革。
Service Mesh
首先簡單介紹 Service Mesh 的概念。以螞蟻金服為例，螞蟻的應用都是 Java 類型的，因此有一個做發布注冊功能的 .jar，這個 .jar 包含了所有的發布、注冊、流量均衡以及限流這些跟業務無關的邏輯。這就是 ServiceMesh 的意思，從數據層面來講，就是拆出和業務無關的邏輯作為一個單獨進程來運行。在拆出了所有的發布、注冊、與應用邏輯無關的內容后，真正的 Java 里面就只有業務邏輯和一個簡單的協議發送，這二者是同級部署的，相當於 Java 直接發送給 Proxy 一個代理，然后通過 Proxy 來做這種交付或發布注冊。這個就是我們內部現在正在做的演變，也是業內比較火的一個微服務。
螞蟻金服內部進行 Service Mesh 主要是因為：
-
擁抱微服務，雲原生
-
異構語言體系融合
-
統一服務治理
-
運維體系有利支撐
-
全局流量管理，打通南北，東西
-
金融級網絡安全
現在大家一般的應用在外部才有加減密碼，金融級的網絡安全的意思是我們的東西流量即內部流量也是需要加密，如果沒有這個 sidecar 和架構，很難做到這種加密。因為不能讓每個 Java 里面的 .jar 去支持正數加載做加解密，並且也很難做很多優化。
為金融業務而生的 SOFAMesh
上圖是 SOFAMesh 的構架，每個 Pod 下面有應用和 SOFAMosn，SOFAMosn 是前面提到的獨立出來的 Sidecar，是一個數據平面。應用跟TLS、國密、服務鑒權之間的交流是通過 SOFAMosn 來交互的。還有流量鏡像層，這個跟安全更加相關，我們內部使用的會做審計工作，在這一層可以做很多的業務邏輯，最上層則是控制面。
以 SOFAMosn 支持 API 網關來舉例，中心化網關是很早以前的一個架構，是集群式網關。集群式網關在螞蟻內部會有一個關鍵的性能瓶頸，因為雙十一大促時，下面有成千上萬的業務接入，你根本不知道它們的水位是多少，很難平復水位。
因此就衍生出了去中心化網關的架構，把 API 網關的邏輯下沉到應用上，以 .jar 的形式接入進去，這樣窩點實際水位就和應用同等了，不需要有一個集中式單點的業務。但這也造成了升級非常困難的問題，因為線上幾百個應用，需要推動幾百個應用的業務方做架構的升級，有時升級需要 3 個月甚至半年。這個架構還有一個問題是異構系統沒有辦法完全支持。
所以我們在落地 Mesh 化網關方案，它會獨立於應用進程，部署在同級的兩個進程，這樣業務可以隨時改動，整個業務邏輯的改動對用戶是透明的。這個方案也可以解決之前所說的流量難以評估、性能瓶頸等問題，因為它和應用是同級部署的，直接做水平擴容就可以，不管什么情況下的壓測都能很好的評估出來。Mosn 里面也嵌入了 Lua 腳本模式來做動態配置，這個近期會開源。
螞蟻金服於 2017 年開始探索 Service Mesh，2018 年開始自研 SOFAMesh，2019 年上半年開始落地支撐了 618 業務，目前覆蓋交易核心鏈路 100+ 應用，10w+ 容器，並且通過一些業務流程的下沉，RT 降低了 7%。上圖展示了一些 SOFAMesh 的優勢。
雲原生安全網絡代理 SOFAMosn
SOFAMosn 的地址是：https://github.com/sofastack/sofa-mosn，由於是跨團隊的項目，出於折中以及落地成本的考量，我們選擇使用 Golang 。對於 Golang 的性能，我們前期也做了充分的調研和測試，在 Service Mesh 場景下單 Sidecar 的性能從來都不是需要最高優先級考慮的問題，往往對性能 RT 有極致要求的業務目前看來並不適合 Mesh 架構。
SOFAMosn 能力與模塊划分
上圖是 SOFAMosn 模塊與能力划分圖，我們在設計當中借鑒了很多 Nginx 和 Envoy 的設計理念與設計模型，它可以基於 Stream、Net 等進行能力擴展。
SOFAMosn 協程模型
Golang 體系下，我們使用輕量級的協程進行基礎架構，一條 TCP 連接對應一個 Read 協程，執行收包、協議解析，一個請求對應一個 Worker 協程，執行業務處理、Proxy 和 Write 邏輯。
SOFAMosn 能力擴展
協議擴展
通過使用同一的編解碼引擎以及編/解碼器核心接口，提供協議的 plugin 機制，目前已經支持：
-
SOFARPC
-
HTTP1.x,/HTTP2.0
-
Dubbo
NetworkFilter 擴展
通過提供 Network Filter 注冊機制以及統一的 Packet Read/Write Filter 接口，實現了 NetworkFilter 擴展機制，當前支持：
-
TCP proxy
-
Fault Injection
StreamFilter 擴展
通過提供 Stream Filter 注冊機制以及統一的 Stream Send/Receive Filter 接口，實現了 StreamFilter 擴展機制，包括支持：
-
流量鏡像
-
RBAC 鑒權
上圖是一個簡單用於說明這個擴展的心跳例子。
基於 xDS 的動態配置
上圖是我們支持的 xDS 全動態配置，最大特點是只要調用一個接口就可以增加cluster。大家使用 Nginx 最大的一個問題可能就是 cluster 的更新。在 xDS 模式下是全動態更新，比如監聽套接字、cluster、路由這些更新全部都是動態化的，是一個能夠滿足社區的標准方案。
Mesh 場景下網絡代理的挑戰
在 Service Mesh 場景下的網絡代理，和接入層還是有很多的不同的。對於接入層，可能就是一個集中式單獨產品，我們一個團隊可以管控。但是在 Service Mesh 場景下就需要更高考量，比如 SOFAMosn 要部署到線上數十萬多萬個容器，且實際每個容器的使用者都是不同的用戶。因此它對於平滑升級，可回滾的兼容是很有需求的，並且我們也需要對一些通用的框架進行針對性地擴展。
大家一般寫軟件，平時測壓性能挺好，但是一放到線上大規模環境，就崩掉了。這個就是兼容性問題，不同的應用，部分 Mesh 化；同一個應用，部分 Mesh 化。然后還有 TLS 加密鏈路，對哪些鏈路進行加密的問題，這些都是實際存在的問題。
平滑升級
如何把 Sidecar 注入到用戶的 App 中，業界目前使用的是透明代理的方式，現在用的最多的透明代理是 Iptable。Iptable 是直接把端口重定向，但是我們發現了一些性能上的大問題，所以我們還是選擇通過 Local 的方式進行，也就是 App 會改它的訪問端口，全部訪問 Local，訪問 Sidecar，當然這個方向我們明年會進行很大的改動。
10w+實例
大規模場景下，不光是數據面還有控制面都是一個巨大的挑戰。比如我們一個單例可能有上萬的路由節點，一個節點上可能有二十萬個后端機器列表，並且路由規則都有幾千條。這樣就導致在整個匹配過程中，實際性能造成了很大的影響，我們為此做了大量的優化。
動態服務發現
當你一直在做高頻的發布注冊時，對軟件的穩定性有着很大的考驗。比如一秒鍾可能會推幾十兆的機器列表數據，我們的機器列表頁很多，這樣就導致在這幾千上萬的機器列表推動下來，要進行 PB 反序列化以及做后手注入。
運維挑戰
SOFAMosn 發布業務無感知，平滑升級。
由於 Sidecar 作為基礎設施的特殊性，我們需要達到基礎設施升級的業務無感知的目的，傳統的網絡代理例如 Nginx 通過關閉老進程的 Listen 端口來做到新進程接管新連接和請求的目的，這種方案對於 HTTP 等短連接 Ping-Pong 協議是非常有效的，但是無法很好支持長連接的雙向流式協議。所以我們在 SOFAMosn 上實現了連接遷移能力，達到網絡代理升級過程中的連接平滑遷移，保證服務的持續性。通過 sendmsg 以及 TCP_REPAIR 都可以做到套接字的遷移，其實在此種場景中套接字的遷移能很好實現，整個連接的 session 恢復會是比較麻煩的過程。
資源問題
當網絡代理 SOFAMosn 作為 Sidecar 部署時，我們面臨了新的挑戰，不再像 Spanner 一樣獨占物理機，或者以獨立應用的容器化方式只用關心自己的能力以及資源消耗，我們必須精細化 CPU、內存等資源，才能達到與應用最優的協同合作方式。
性能問題
性能問題更多是 Golang 相關：
-
GOMAXPROCS ：Cpu 消耗與 RT 的 tradeoff
-
優化 GC 策略升級 1.12 版本，MADV_FREE，MADV_DONTNEED 帶來的影響
-
Chan 的吞吐極限，減少主業務數據的傳遞
-
CGO 對於 TLS 簽名計算有 83% 的性能衰退，AES 對稱加密
-
Unix Domain socket 較 TCP socket 提升 8% 性能
-
使用 tmpfs 或者 mmap MAP_LOCKED 優化 IO 負載較高對共享內存刷 page cache 的影響
Unix Domain socket 較 TCP socket 提升 8% 性能，因為它少走了很多 TCP 協議上的東西，所以我們計划讓同機交付走 Unix Domain socket。
TLS性能
Golang 的 TLS 是自己實現的，沒有使用 OpenSSL。針對這塊我們做了測試，如上圖，藍色是基於 Nginx，可以看到 Golang 自身做了很多匯編優化，所以性能並沒有相差很多。我們計划對 runtime 做匯編的優化，比如國密，以后的效果肯定是會越來越好。
HTTP 性能
HTTP 數據目前我們不是很滿意，后續會進行持續優化。我們內部目前做的最多的還是 RPC 協議，HTTP 協議會放到明年的 roadmap 里面，明年會重點支持 HTTP 系。
總結
關於未來：
-
雲原生，多雲混合雲時代，南北，東西流量的邊界逐漸模糊；
-
應用網絡代理層部分能力固化，下沉至系統網絡棧或者智能硬件設備；
-
Sidecar -> Proxyless -> Networkless；
-
物理通信基礎設施的升級勢必帶來應用網絡層的變革。