螞蟻金服烈元：螞蟻網絡代理演進之路

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.三、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/...，因爲是跨團隊的項目，出於折中以及落地成本的考量，咱們選擇使用 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；
• 物理通訊基礎設施的升級勢必帶來應用網絡層的變革。

推薦閱讀

阿里巴巴王發康：阿里七層流量入口負載均衡算法演變之路

Apache APISIX 微服務網關極致性能架構解析