10Wqps 超高并發 API網關 架構演進之路

說在前面

在（30+）讀者社群中，經常遇到一個 API網關 架構方面的問題：

(1) 老師，最近公司我們在規劃業務出口網關(目的，整合規範外部調用，如短信平台 mqtt 等) 我在做整理技術方案，但是沒有什麼思路。老師，這方面有沒有什麼參考資料呀

(2) 高并發業務出口網關，如何做系統架構？

(3 ）等等等等......

剛剛，在社群（30+）中，有小夥伴又問了這個問題。

其實，作為技術中台的架構師， 網關是Java架構的重點， 是以，一直想帶大家從 架構到實操， 完成一個 10Wqps 超高并發 網關實操指導。

而且指導履歷的過程中，也指導過小夥伴寫過 10Wqps 超高并發 網關履歷，裡邊涉及到大量的設計模式， 小夥伴的履歷，裡邊立馬金光閃閃。

後面有機會，帶大家做一下這個高品質的實操，并且指導大家寫入履歷。

我手上的資料涉密，不能公開。

現在，先結合網際網路的公開資料，梳理了 業務架構、技術選型、架構演進等三個方案，為小夥伴們提供一些重要的API網關的參考資料。

注：本文以 PDF 持續更新，最新Java 架構筆記、面試題 的PDF檔案，請背景私信【筆記】即可擷取！

API 網關的業務架構

從應用程式架構的變遷過程可以發現，随着業務多變性、靈活性的不斷提高，應用程式需要以更加靈活的組合來應對。

同時為了應對業務的細分以及高并發的挑戰，微服務的架構被廣泛使用，由于微服務架構中應用會被拆分成多個服務。

為了友善用戶端對這些服務的調用于是引入了 API 的概念。今天我們就來看看API 網關的原理以及它是如何應用的。

網關一詞最早出現在網絡裝置，比如兩個互相獨立的區域網路之間通過路由器進行通信， 中間的路由被稱之為網關。

落實在開發層面來說，就是用戶端與微服務系統之間存在的網關。從業務層面來說，當用戶端完成某個業務的時候，需要同時調用多個微服務。

如圖 1 所示，當用戶端發起下單請求需要調用：商品查詢、庫存扣減以及訂單更新等服務。

圖1 ：API 網關加入前後對比

如果這些服務需要用戶端分别調用才能完成，會增加請求的複雜度，同時也會帶來網絡調用性能的損耗。是以，針對微服務的應用場景就推出了 API 網關的調用。

在用戶端與微服務之間加入下單 API 網關，用戶端直接給這個 API 網關下達指令，由于後者完成對其他三個微服務的調用并且傳回結果給用戶端。

從系統層面來說，任何一個應用系統如果需要被其他系統調用，就需要暴露 API，這些 API 代表着的功能點。

正如上面下單的例子中提到的，如果一個下單的功能點需要調用多個服務的時候，在這個下單的 API 網關中就需要聚合多個服務的調用。

這個聚合的方式有點像設計模式中的門面模式（Facade），它為外部的調用提供了一個統一的通路入口。

不僅如此，如圖 2 所示，API 網關還可以協助兩個系統的通信，在系統之間加上一個中介者協助 API 的調用。

圖 2：對接兩個系統的 API 網關

從用戶端類型層面來說，為了屏蔽不同用戶端調用差異也可以加入 API 網關。

如圖 3 所示，在實際開發過程中 API 網關還可以根據不同的用戶端類型（iOS、Android、PC、小程式），提供不同的 API 網關與之對應。

圖 3：對接用戶端和服務端的 API 網關

由于 API 網關所處的位置是用戶端與微服務交界的地方，是以從功能上它還包括：路由，負載均衡，限流，緩存，日志，釋出等等。

這裡的參考資料：

400頁PDF電子書 《SpringCloud Alibaba 技術》

500頁 PDF電子書 《Java高并發核心程式設計》

pdf領取方式，請背景私信【筆記】即可擷取！

API 網關選型

來看下 API 網關如何設計、五種 API 網關的技術選型對比。

這裡的參考資料：

400頁PDF電子書 《SpringCloud Alibaba 技術》

500頁 PDF電子書 《Java高并發核心程式設計 》

pdf領取方式，請背景私信【筆記】即可擷取！

幾種常見網關的對比

先來個幾款 API 網關的對比，讓大家有個整體的印象。

設計網關，需要考慮哪些？

如果讓你設計一個 API 網關，你會考慮哪些方面？

路由轉發

請求先到達 API 網關，然後經過斷言，比對到路由後，由路由将請求轉發給真正的業務服務。

注冊發現

各個服務執行個體需要将自己的服務名、IP 位址和 port 注冊到注冊中心，然後注冊中心會存放一份系統資料庫，Gateway 可以從注冊中心擷取到系統資料庫，然後轉發請求時隻需要轉發到對應的服務名即可。

負載均衡

一個服務可以由多個服務執行個體組成服務叢集，而 Gateway 配置的通常是一個服務名，如 passjava-member 服務，是以需要具備負載均衡功能，将請求分發到不同的服務執行個體上。

彈力設計

網關還可以把彈力設計中的那些異步、重試、幂等、流控、熔斷、監視等都可以實作進去。這樣，同樣可以像 Service Mesh 那樣，讓應用服務隻關心自己的業務邏輯（或是說資料面上的事）而不是控制邏輯（控制面）。

安全方面

SSL 加密及證書管理、Session 驗證、授權、資料校驗，以及對請求源進行惡意攻擊的防範。錯誤處理越靠前的位置就是越好，是以，網關可以做到一個全站的接入元件來對後端的服務進行保護。當然，網關還可以做更多更有趣的事情，比如：灰階釋出、API聚合、API編排。

灰階釋出

網關完全可以做到對相同服務不同版本的執行個體進行導流，還可以收集相關的資料。這樣對于軟體品質的提升，甚至産品試錯都有非常積極的意義。

API 聚合

使用網關可以将多個單獨請求聚合成一個請求。在微服務體系的架構中，因為服務變小了，是以一個明顯的問題是，用戶端可能需要多次請求才能得到所有的資料。這樣一來，用戶端與後端之間的頻繁通信會對應用程式的性能和規模産生非常不利的影響。于是，我們可以讓網關來幫用戶端請求多個後端的服務（有些場景下完全可以并發請求），然後把後端服務的響應結果拼裝起來，回傳給用戶端（當然，這個過程也可以做成異步的，但這需要用戶端的配合）。

API 編排

同樣在微服務的架構下，要走完一個完整的業務流程，我們需要調用一系列 API，就像一種工作流一樣，這個事完全可以通過網頁來編排這個業務流程。我們可能通過一個 DSL 來定義和編排不同的 API，也可以通過像 AWS Lambda 服務那樣的方式來串聯不同的 API。

網關設計重點

網關設計重點主要是三個, 高性能、高可用、高擴充:

高性能

在技術設計上，網關不應該也不能成為性能的瓶頸。對于高性能，最好使用高性能的程式設計語言來實作，如 C、C++、Go 和 Java。網關對後端的請求，以及對前端的請求的服務一定要使用異步非阻塞的 I/O 來確定後端延遲不會導緻應用程式中出現性能問題。C 和 C++ 可以參看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的異步 IO 模型，Java 下如 Netty、Spring Reactor 的 NIO 架構。

高可用

因為所有的流量或調用經過網關，是以網關必須成為一個高可用的技術元件，它的穩定直接關系到了所有服務的穩定。網關如果沒有設計，就會成變一個單點故障。是以，一個好的網關至少要做到以下幾點。

• 叢集化。網關要成為一個叢集，其最好可以自己組成一個叢集，并可以自己同步叢集資料，而不需要依賴于一個第三方系統來同步資料。
• 服務化。網關還需要做到在不間斷的情況下修改配置，一種是像 Nginx reload 配置那樣，可以做到不停服務，另一種是最好做到服務化。也就是說，得要有自己的 Admin API 來在運作時修改自己的配置。
• 持續化。比如重新開機，就是像 Nginx 那樣優雅地重新開機。有一個主管請求分發的主程序。當我們需要重新開機時，新的請求被配置設定到新的程序中，而老的程序處理完正在處理的請求後就退出。

高可用性涵蓋了内部和外部的各種不确定因素，這裡講一下網關系統在高可用性方面做的努力。

高擴充

因為網關需要承接所有的業務流量和請求，是以一定會有或多或少的業務邏輯。而我們都知道，業務邏輯是多變和不确定的。比如，需要在網關上加入一些和業務相關的東西。是以，一個好的 Gateway 還需要是可以擴充的，并能進行二次開發的。當然，像 Nginx 那樣通過 Module 進行二次開發的固然可以。

另外，在運維方面，網關應該有以下幾個設計原則。

• 業務松耦合，協定緊耦合。在業務設計上，網關不應與後面的服務之間形成服務耦合，也不應該有業務邏輯。網關應該是在網絡應用層上的元件，不應該處理通訊協定體，隻應該解析和處理通訊協定頭。另外，除了服務發現外，網關不應該有第三方服務的依賴。
• 應用監視，提供分析資料。網關上需要考慮應用性能的監控，除了有相應後端服務的高可用的統計之外，還需要使用 Tracing ID 實施分布式鍊路跟蹤，并統計好一定時間内每個 API 的吞吐量、響應時間和傳回碼，以便啟動彈力設計中的相應政策。
• 用彈力設計保護後端服務。網關上一定要實作熔斷、限流、重試和逾時等彈力設計。如果一個或多個服務調用花費的時間過長，那麼可接受逾時并傳回一部分資料，或是傳回一個網關裡的緩存的上一次成功請求的資料。你可以考慮一下這樣的設計。
• DevOps。因為網關這個元件太關鍵了，是以需要 DevOps 這樣的東西，将其發生故障的機率降到最低。這個軟體需要經過精良的測試，包括功能和性能的測試，還有浸泡測試。還需要有一系列自動化運維的管控工具。

網關設計注意事項

1. 不要在網關中的代碼裡内置聚合後端服務的功能，而應考慮将聚合服務放在網關核心代碼之外。可以使用 Plugin 的方式，也可以放在網關後面形成一個 Serverless 服務。
2. 網關應該靠近後端服務，并和後端服務使用同一個内網，這樣可以保證網關和後端服務調用的低延遲，并可以減少很多網絡上的問題。這裡多說一句，網關處理的靜态内容應該靠近使用者（應該放到 CDN 上），而網關和此時的動态服務應該靠近後端服務。
3. 網關也需要做容量擴充，是以需要成為一個叢集來分擔前端帶來的流量。這一點，要麼通過 DNS 輪詢的方式實作，要麼通過 CDN 來做流量排程，或者通過更為底層的性能更高的負載均衡裝置。
4. 對于服務發現，可以做一個時間不長的緩存，這樣不需要每次請求都去查一下相關的服務所在的地方。當然，如果你的系統不複雜，可以考慮把服務發現的功能直接內建進網關中。
5. 為網關考慮 bulkhead 設計方式。用不同的網關服務不同的後端服務，或是用不同的網關服務前端不同的客戶。

另外，因為網關是為使用者請求和後端服務的橋接裝置，是以需要考慮一些安全方面的事宜。具體如下：

1. 加密資料。可以把 SSL 相關的證書放到網關上，由網關做統一的 SSL 傳輸管理。
2. 校驗使用者的請求。一些基本的使用者驗證可以放在網關上來做，比如使用者是否已登入，使用者請求中的 token 是否合法等。但是，我們需要權衡一下，網關是否需要校驗使用者的輸入。因為這樣一來，網關就需要從隻關心協定頭，到需要關心協定體。而協定體中的東西一方面不像協定頭是标準的，另一方面解析協定體還要耗費大量的運作時間，進而降低網關的性能。對此，我想說的是，看具體需求，一方面如果協定體是标準的，那麼可以幹；另一方面，對于解析協定所帶來的性能問題，需要做相應的隔離。
3. 檢測異常通路。網關需要檢測一些異常通路，比如，在一段比較短的時間内請求次數超過一定數值；還比如，同一用戶端的 4xx 請求出錯率太高……對于這樣的一些請求通路，網關一方面要把這樣的請求屏蔽掉，另一方面需要發出警告，有可能會是一些比較重大的安全問題，如被黑客攻擊。

網關應用

流量網關

流量網關,顧名思義就是控制流量進入叢集的網關,有很多工作需要在這一步做,對于一個服務叢集,勢必有很多非法的請求或者無效的請求,這時候要将請求拒之門外,降低叢集的流量壓力。

定義全局性的、跟具體的後端業務應用和服務完全無關的政策網關就是上圖所示的架構模型——流量網關。流量網關通常隻專注于全局的Api管理政策，比如全局流量監控、日志記錄、全局限流、黑白名單控制、接入請求到業務系統的負載均衡等，有點類似防火牆。Kong 就是典型的流量網關。

下面是kong的架構圖,來自官網:

這裡需要補充一點的是，業務網關一般部署在流量網關之後、業務系統之前，比流量網關更靠近業務系統。通常API網指的是業務網關。 有時候我們也會模糊流量網關和業務網關，讓一個網關承擔所有的工作,是以這兩者之間并沒有嚴格的界線。

業務網關

當一個單體應用被拆分成許許多多的微服務應用後，也帶來了一些問題。一些與業務非強相關的功能，比如權限控制、日志輸出、資料加密、熔斷限流等，每個微服務應用都需要，是以存在着大量重複的代碼實作。而且由于系統的疊代、人員的更替，各個微服務中這些功能的實作細節出現了較大的差異，導緻維護成本變高。另一方面，原先單體應用下非常容易做的接口管理，在服務拆分後沒有了一個集中管理的地方，無法統計已存在哪些接口、接口定義是什麼、運作狀态如何。

網關就是為了解決上述問題。作為微服務體系中的核心基礎設施，一般需要具備接口管理、協定适配、熔斷限流、安全防護等功能，各種開源的網關産品（比如 zuul）都提供了優秀高可擴充性的架構、可以很友善的實作我們需要的一些功能、比如鑒權、日志監控、熔斷限流等。

與流量網關相對應的就是業務網關,業務網關更靠近我們的業務,也就是與伺服器應用層打交道,那麼有很多應用層需要考慮的事情就可以依托業務網關,例如線上程模型、協定适配、熔斷限流，服務編排等。下面看看業務網關體系結構:

從這個圖中可以看出業務網關主要職責以及所做的事情, 目前業務網關比較成熟的 API 網關架構産品有三個 分别是:Zuul1、Zuul2 和 SpringCloud Gateway, 後面再進行對比。

網關與伺服器叢集

回到我們伺服器上,下面圖介紹了網關(Gateway)作用,可知 Gateway 方式下的架構，可以細到為每一個服務的執行個體配置一個自己的 Gateway，也可以粗到為一組服務配置一個，甚至可以粗到為整個架構配置一個接入的 Gateway。于是，整個系統架構的複雜度就會變得簡單可控起來。

這張圖展示了一個多層 Gateway 架構，其中有一個總的 Gateway 接入所有的流量(流量網關)，并分發給不同的子系統，還有第二級 Gateway 用于做各個子系統的接入 Gateway(業務網關)。可以看到，網關所管理的服務粒度可粗可細。通過網關，我們可以把分布式架構組織成一個星型架構，由網絡對服務的請求進行路由和分發。下面來聊聊好的網關應該具備哪些功能,也就是網關設計模式。

常見網關對比

既然對比,就先宏觀上對各種網關有一個了解,後面再挑一些常用的或者說應用廣泛的詳細了解。

目前常見的開源網關大緻上按照語言分類有如下幾類：

• Nginx+lua：OpenResty、Kong、Orange、Abtesting gateway 等
• Java：Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等
• Go：Janus、fagongzi、Grpc-gateway
• Dotnet：Ocelot
• NodeJS：Express Gateway、Micro Gateway

按照使用數量、成熟度等來劃分，主流的有 4 個：

• OpenResty
• Kong
• Zuul/Zuul2
• Spring Cloud Gateway

OpenResty

OpenResty是一個流量網關,根據前面對流量網關的介紹就可以知道流量網關的指責。

OpenResty基于 Nginx 與 Lua 的高性能 Web 平台，其内部內建了大量精良的 Lua 庫、第三方子產品以及大多數的依賴項。用于友善地搭建能夠處理超高并發、擴充性極高的動态 Web 應用、Web 服務和動态網關。

通過揉和衆多設計良好的 Nginx 子產品，OpenResty 有效地把 Nginx 伺服器轉變為一個強大的 Web 應用伺服器，基于它開發人員可以使用 Lua 程式設計語言對 Nginx 核心以及現有的各種 Nginx C 子產品進行腳本程式設計，建構出可以處理一萬以上并發請求的極端高性能的 Web 應用

OpenResty 最早是順應 OpenAPI 的潮流做的，是以 Open 取自“開放”之意，而Resty便是 REST 風格的意思。雖然後來也可以基于 ngx_openresty 實作任何形式的 web service 或者傳統的 web 應用。

也就是說 Nginx 不再是一個簡單的靜态網頁伺服器，也不再是一個簡單的反向代理了。第二代的 openresty 緻力于通過一系列 nginx 子產品，把nginx擴充為全功能的 web 應用伺服器。

ngx_openresty 是使用者驅動的項目，後來也有不少國内使用者的參與，從 openresty.org 的點選量分布上看，國内和國外的點選量基本持平。

ngx_openresty 目前有兩大應用目标：

1. 通用目的的 web 應用伺服器。在這個目标下，現有的 web 應用技術都可以算是和 OpenResty 或多或少有些類似，比如 Nodejs, PHP 等等。ngx_openresty 的性能（包括記憶體使用和 CPU 效率）算是最大的賣點之一。
2. Nginx 的腳本擴充程式設計，用于建構靈活的 Web 應用網關和 Web 應用防火牆。有些類似的是 NetScaler。其優勢在于 Lua 程式設計帶來的巨大靈活性。

Kong

相關連接配接：官網、Github

Kong基于OpenResty開發，也是流量層網關, 是一個雲原生、快速、可擴充、分布式的Api 網關。繼承了OpenResty的高性能、易擴充性等特點。Kong通過簡單的增加機器節點，可以很容易的水準擴充。同時功能插件化，可通過插件來擴充其能力。而且在任何基礎架構上都可以運作。具有以下特性：

• 提供了多樣化的認證層來保護Api。
• 可對出入流量進行管制。
• 提供了可視化的流量檢查、監視分析Api。
• 能夠及時的轉換請求和相應。
• 提供log解決方案
• 可通過api調用Serverless 函數。

Kong解決了什麼問題

當我們決定對應用進行微服務改造時，應用用戶端如何與微服務互動的問題也随之而來，畢竟服務數量的增加會直接導緻部署授權、負載均衡、通信管理、分析和改變的難度增加。

面對以上問題，API GATEWAY是一個不錯的解決方案，其所提供的通路限制、安全、流量控制、分析監控、日志、請求轉發、合成和協定轉換功能，可以解放開發者去把精力集中在具體邏輯的代碼，而不是把時間花費在考慮如何解決應用和其他微服務連結的問題上。

圖檔來自Kong官網:

可以看到Kong解決的問題。專注于全局的Api管理政策，全局流量監控、日志記錄、全局限流、黑白名單控制、接入請求到業務系統的負載均衡等。

Kong的優點以及性能

在衆多 API GATEWAY 架構中，Mashape 開源的高性能高可用API網關和API服務管理層——KONG（基于 NGINX+Lua）特點尤為突出，它可以通過插件擴充已有功能，這些插件（使用 lua 編寫）在API請求響應循環的生命周期中被執行。于此同時，KONG本身提供包括 HTTP 基本認證、密鑰認證、CORS、TCP、UDP、檔案日志、API請求限流、請求轉發及 NGINX 監控等基本功能。目前，Kong 在 Mashape 管理了超過 15,000 個 API，為 200,000 開發者提供了每月數十億的請求支援。

Kong架構

Kong提供一些列的服務,這就不得不談談内部的架構:

首先最底層是基于Nginx, Nginx是高性能的基礎層, 一個良好的負載均衡、反向代理器,然後在此基礎上增加Lua腳本庫,形成了OpenResty,攔截請求, 響應生命周期,可以通過Lua編寫腳本,是以插件比較豐富。

關于Kong的一些插件庫以及如何配置,可以參考簡書：開源API網關系統（Kong教程）入門到精通

Zuul1.0

Zuul是所有從裝置和web站點到Netflix流媒體應用程式後端請求的前門。作為一個邊緣服務應用程式，Zuul被建構來支援動态路由、監視、彈性和安全性。它還可以根據需要将請求路由到多個Amazon自動伸縮組。

Zuul使用了一系列不同類型的過濾器，使我們能夠快速靈活地将功能應用到服務中。

過濾器

過濾器是Zuul的核心功能。它們負責應用程式的業務邏輯，可以執行各種任務。

• Type ： 通常定義過濾器應用在哪個階段
• Async ： 定義過濾器是同步還是異步
• Execution Order ： 執行順序
• Criteria ： 過濾器執行的條件
• Action ： 如果條件滿足，過濾器執行的動作

Zuul提供了一個動态讀取、編譯和運作這些過濾器的架構。過濾器之間不直接通信，而是通過每個請求特有的RequestContext共享狀态。

下面是Zuul的一些過濾器:

Incoming

Incoming過濾器在請求被代理到Origin之前執行。這通常是執行大部分業務邏輯的地方。例如:認證、動态路由、速率限制、DDoS保護、名額。

Endpoint

Endpoint過濾器負責基于incoming過濾器的執行來處理請求。Zuul有一個内置的過濾器（ProxyEndpoint），用于将請求代理到後端伺服器，是以這些過濾器的典型用途是用于靜态端點。例如:健康檢查響應，靜态錯誤響應，404響應。

Outgoing

Outgoing過濾器在從後端接收到響應以後執行處理操作。通常情況下，它們更多地用于形成響應和添加名額，而不是用于任何繁重的工作。例如:存儲統計資訊、添加/剝離标準标題、向實時流發送事件、gziping響應。

過濾器類型

下面是與一個請求典型的生命周期對應的标準的過濾器類型：

• PRE ： 路由到Origin之前執行
• ROUTING ： 路由到Origin期間執行
• POST ： 請求被路由到Origin之後執行
• ERROR ： 發生錯誤的時候執行

這些過濾器幫助我們執行以下功能：

• 身份驗證和安全性 ： 識别每個資源的身份驗證需求，并拒絕不滿足它們的請求
• 監控 ： 在邊緣跟蹤有意義的資料和統計資料，以便給我們一個準确的生産視圖
• 動态路由 ： 動态路由請求到不同的後端叢集
• 壓力測試 ： 逐漸增加叢集的流量，以評估性能
• 限流 ： 為每種請求類型配置設定容量，并丢棄超過限制的請求
• 靜态響應處理 ： 直接在邊緣建構一些響應，而不是将它們轉發到内部叢集

Zuul 1.0 請求生命周期

Netflix宣布了通用API網關Zuul的架構轉型。Zuul原本采用同步阻塞架構，轉型後叫作Zuul2，采用異步非阻塞架構。Zuul2和Zuul1在架構方面的主要差別在于，Zuul2運作在異步非阻塞的架構上，比如Netty。Zuul1依賴多線程來支援吞吐量的增長，而Zuul 2使用的Netty架構依賴事件循環和回調函數。

原理詳見這篇： 500頁 PDF電子書 《Java高并發核心程式設計》

Zuul2.0

Zuul 2.0 架構圖

上圖是Zuul2的架構，和Zuul1沒有本質差別，兩點變化：

1. 前端用Netty Server代替Servlet，目的是支援前端異步。後端用Netty Client代替Http Client，目的是支援後端異步。
2. 過濾器換了一下名字，用Inbound Filters代替Pre-routing Filters，用Endpoint Filter代替Routing Filter，用Outbound Filters代替Post-routing Filters。

Inbound Filters ： 路由到 Origin 之前執行，可以用于身份驗證、路由和裝飾請求

Endpoint Filters ： 可用于傳回靜态響應，否則内置的ProxyEndpoint過濾器将請求路由到Origin

Outbound Filters ： 從Origin那裡擷取響應後執行，可以用于度量、裝飾使用者的響應或添加自定義header

有兩種類型的過濾器：sync 和 async。因為Zuul是運作在一個事件循環之上的，是以從來不要在過濾中阻塞。如果你非要阻塞，可以在一個異步過濾器中這樣做，并且在一個單獨的線程池上運作，否則可以使用同步過濾器。

上文提到過Zuul2開始采用了異步模型

優勢是異步非阻塞模式啟動的線程很少，基本上一個CPU core上隻需啟一個事件環處理線程，它使用的線程資源就很少，上下文切換(Context Switch)開銷也少。非阻塞模式可以接受的連接配接數大大增加，可以簡單了解為請求來了隻需要進隊列，這個隊列的容量可以設得很大，隻要不逾時，隊列中的請求都會被依次處理。

不足,異步模式讓程式設計模型變得複雜。一方面Zuul2本身的代碼要比Zuul1複雜很多，Zuul1的代碼比較容易看懂，Zuul2的代碼看起來就比較費勁。另一方面異步模型沒有一個明确清晰的請求->處理->響應執行流程(call flow)，它的流程是通過事件觸發的，請求處理的流程随時可能被切換斷開，内部實作要通過一些關聯id機制才能把整個執行流再串聯起來，這就給開發調試運維引入了很多複雜性，比如你在IDE裡頭調試異步請求流就非常困難。另外ThreadLocal機制在這種異步模式下就不能簡單工作，因為隻有一個事件環線程，不是每個請求一個線程，也就沒有線程局部的概念，是以對于CAT這種依賴于ThreadLocal才能工作的監控工具，調用鍊埋點就不好搞(實際可以工作但需要進行特殊處理)。

總體上，異步非阻塞模式比較适用于IO密集型(IO bound)場景，這種場景下系統大部分時間在處理IO，CPU計算比較輕，少量事件環線程就能處理。

Zuul 與 Zuul 2 性能對比

圖檔來源：Zuul's Journey to Non-Blocking

Netflix給出了一個比較模糊的資料，大緻Zuul2的性能比Zuul1好20%左右，這裡的性能主要指每節點每秒處理的請求數。為什麼說模糊呢？因為這個資料受實際測試環境，流量場景模式等衆多因素影響，你很難複現這個測試資料。即便這個20%的性能提升是确實的，其實這個性能提升也并不大，和異步引入的複雜性相比，這20%的提升是否值得是個問題。Netflix本身在其博文22和ppt11中也是有點含糊其詞，甚至自身都有一些疑問的。

Spring Cloud Gateway

這裡的基礎資料： 400頁PDF電子書 《SpringCloud Alibaba 筆記》

SpringCloud Gateway 是 Spring Cloud 的一個全新項目，該項目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術開發的網關，它旨在為微服務架構提供一種簡單有效的統一的 API 路由管理方式。

SpringCloud Gateway 作為 Spring Cloud 生态系統中的網關，目标是替代 Zuul，在Spring Cloud 2.0以上版本中，沒有對新版本的Zuul 2.0以上最新高性能版本進行內建，仍然還是使用的Zuul 2.0之前的非Reactor模式的老版本。而為了提升網關的性能，SpringCloud Gateway是基于WebFlux架構實作的，而WebFlux架構底層則使用了高性能的Reactor模式通信架構Netty。

Spring Cloud Gateway 的目标，不僅提供統一的路由方式，并且基于 Filter 鍊的方式提供了網關基本的功能，例如：安全，監控/名額，和限流。

Spring Cloud Gateway 底層使用了高性能的通信架構Netty。

SpringCloud Gateway 特征

SpringCloud官方，對SpringCloud Gateway 特征介紹如下：

（1）基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0

（2）內建 Hystrix 斷路器

（3）內建 Spring Cloud DiscoveryClient

（4）Predicates 和 Filters 作用于特定路由，易于編寫的 Predicates 和 Filters

（5）具備一些網關的進階功能：動态路由、限流、路徑重寫

從以上的特征來說，和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的差別，還是在底層的通信架構上。

簡單說明一下上文中的三個術語：

Filter（過濾器）

和Zuul的過濾器在概念上類似，可以使用它攔截和修改請求，并且對上遊的響應，進行二次處理。過濾器為org.springframework.cloud.gateway.filter.GatewayFilter類的執行個體。

Route（路由）

網關配置的基本組成子產品，和Zuul的路由配置子產品類似。一個Route子產品由一個 ID，一個目标 URI，一組斷言和一組過濾器定義。如果斷言為真，則路由比對，目标URI會被通路。

Predicate（斷言）：

這是一個 Java 8 的 Predicate，可以使用它來比對來自 HTTP 請求的任何内容，例如 headers 或參數。斷言的輸入類型是一個 ServerWebExchange。

網關對比總結

這裡的基礎資料： 400頁PDF電子書 《SpringCloud Alibaba 筆記》

基于Spring Cloud Gateway 實作業務網關

API 網關的定義中我們提到了為什麼要使用 API 網關，是為了解決用戶端對多個微服務進行通路的問題。

由于服務的切分導緻一個操作需要同時調用多個服務，是以為這些服務的聚合提供一個統一的門面，這個門面就是 API 網關。

針對于 API 網關有很多的實作方式，例如：Zuul，Kong 等等。這裡我們以 Spring Cloud Gateway 為例展開給大家介紹其具體實作。

一般來說，API 網關對内将微服務進行集合，對外暴露的統一 URL 或者接口資訊供用戶端調用。

那麼用戶端是如何與微服務進行連接配接，并且進行溝通的，需要引入下面幾個重要概念 。

圖 4：路由、斷言和過濾器

如圖 4 所示，Spring Cloud Gateway 由三部分組成：

①路由（Route）：任何一個來自于用戶端的請求都會經過路由，然後到對應的微服務中。

每個路由會有一個唯一的 ID 和對應的目的 URL。同時包含若幹個斷言（Predicate）和過濾器（Filter）。

②斷言（Predicate）：當用戶端通過 Http Request 請求進入 Spring Cloud Gateway 的時候，斷言會根據配置的路由規則，對 Http Request 請求進行斷言比對。

說白了就是進行一次或者多次 if 判斷，如果比對成功則進行下一步處理，否則斷言失敗直接傳回錯誤資訊。

③過濾器( Filter)：簡單來說就是對流經的請求進行過濾，或者說對其進行擷取以及修改的操作。注意過濾器的功能是雙向的，也就是對請求和響應都會進行修改處理 。

一般來說 Spring Cloud Gateway 中的過濾器有兩種類型：

• Gateway Filter
• Global Filter

Gateway Filter 用在單個路由和分組路由上。Global Filter 可以作用于所有路由，是一個全局的 Filter。

Spring Cloud Gateway 工作原理

500頁 PDF電子書 《Java高并發核心程式設計 》，

說完了 Spring Cloud Gateway 定義和要素，再來看看其工作原理。總的來說是對用戶端請求的處理過程。

圖 5：Spring Cloud Gateway 處理請求流程圖

如圖 5 所示，當用戶端向 Spring Cloud Gateway 發起請求，該請求會被 HttpWebHandlerAdapter 擷取，并且對請求進行提取，進而組裝成網關上下文。

将組成的上下文資訊傳遞到 DispatcherHandler 元件。DispatcherHandler 作為請求分發處理器，主要負責将請求分發到對應的處理器進行處理。

這裡請求的處理器包括 RoutePredicate HandlerMapping (路由斷言處理映射器) 。

路由斷言處理映射器用于路由的查找，以及找到 路由後傳回對應的 FilteringWebHandler。

其負責組裝 Filter 連結清單并執行過濾處理，之後再将請求轉交給應用服務，應用服務處理完後，最後傳回 Response 給用戶端 。

其中 FilteringWebHandler 處理請求的時候會交給 Filter 進行過濾的處理。

這裡需要注意的是由于 Filter 是雙向的是以，當用戶端請求服務的時候，會通過 Pre Filter 中的 Filter 處理請求。

當服務處理完請求以後傳回用戶端的時候，會通過 Post Filter 再進行一次處理。

2Wqps Spring Cloud Gateway 網關實踐

上面介紹了 Spring Cloud Gateway 的定義和實作原理，下面根據幾個常用的場景介紹一下 Spring Cloud Gateway 如何實作網關功能的。

我們會根據基本路由、權重路由、限流、動态路由幾個方面給大家展開介紹。

基本路由

基本路由，主要功能就是在用戶端請求的時候，根據定義好的路徑指向到對應的 URI。這個過程中需要用到 Predicates（斷言）中的 Path 路由斷言處理器。

基本路由 可以通過配置檔案實作， 具體請參見 尼恩 400頁 pdf 《SpringCloud Alibaba 聖經》

這裡不做贅述

權重路由

這個使用場景相對于上面的簡單路由要多一些。

由于每個微服務釋出新版本的時候，通常會保持老版本與新版版同時存在。

然後通過網關将流量逐漸從老版本的服務切換到新版本的服務。

這個逐漸切換的過程就是常說的灰階釋出。

此時，API 網關就起到了流量分發的作用，通常來說最開始的老版本會承載多一些的流量，例如 90% 的請求會被路由到老版本的服務上，隻有 10% 的請求會路由到新服務上去。

進而觀察新服務的穩定性，或者得到使用者的回報。當新服務穩定以後，再将剩下的流量一起導入過去。

圖 6：灰階釋出，路由到新/老服務

在兩個配置中對應的 URI 分别是新老兩個服務的通路位址，通過http://localhost:8888/v1和http://localhost:8888/v2來差別。

在 Predicates（斷言）中定義了的 Path 是想通的都是“/gatewaytest”，也就是說對于用戶端來說通路的路徑都是一樣的，從路徑上客戶不會感覺他們通路的是新服務或者是老服務。

主要參數是在 Weight，針對老/新服務分别配置的是 90 和 10。

也就是有 90% 的流量會請求老服務，有 10% 的流量會請求新服務。

簡單點說，如果有 100 次請求，其中 90 次會請求 v1（老服務），另外的 10 次會請求 v2（新服務）。

限流

當服務在短時間内迎來高并發，并發量超過服務承受的範圍就需要使用限流。例如：秒殺、搶購、下單服務。

通過請求限速或者對一個時間視窗内的請求進行限速來保護服務。當達到限制速率則可以拒絕請求，傳回錯誤代碼，或者定向到友好頁面。

一般的中間件都會有單機限流架構，支援兩種限流模式：

• 控制速率
• 控制并發

這裡通過 Guava 中的 Bucket4j 來實作限流操作。

由于需要對于使用者請求進行監控，是以通過實作 GatewayFilter 的方式自定義 Filter，然後再通過 Gateway API Application 應用這個自定義的 Filter。

可以基于令牌桶限流，是以需要設定桶的容量（capacity），每次填充的令牌數量（refillTokens）以及填充令牌的間隔時間（refillDuration）。

那麼當使用者通路 rateLimit 路徑的時候就會根據客制化的 Filter 進行限流。

這裡的限流隻是給大家提供一種思路，通過實作 GatewayFilter，重寫其中的 Filter 方法，加入對流量的控制代碼，然後在 Spring Cloud Gateway 中進行應用就可以了。

有關令牌桶、漏桶限流的具體知識，請參見

500頁 PDF電子書 《Java高并發核心程式設計》

動态路由

由于 Spring Cloud Gateway 本身也是一個服務，一旦啟動以後路由配置就無法修改了。

無論是上面提到的編碼注入的方式還是配置的方式，如果需要修改都需要重新啟動服務。

如果回到 Spring Cloud Gateway 最初的定義，我們會發現每個使用者的請求都是通過 Route 通路對應的微服務，在 Route 中包括 Predicates 和 Filters 的定義。

隻要實作 Route 以及其包含的 Predicates 和 Filters 的定義，然後再提供一個 API 接口去更新這個定義就可以動态地修改路由資訊了。

按照這個思路需要做以下幾步來實作：

①定義 Route、Predicates 和 Filters

其中 Predicates 和 Filters 包含在 Route 中。實際上就是 Route 實體的定義，針對 Route 進行路由規則的配置。

②實作路由規則的操作，包括添加，更新，删除

有了路由的定義（Route，Predicates，Filters），然後再編寫針對路由定義的操作。

例如：添加路由，删除路由，更新路由之類的。編寫 RouteServiceImpl 實作 ApplicationEventPublisherAware。

主要需要 override 其中的 setApplicationEventPublisher 方法，這裡會傳入 ApplicationEventPublisher 對象，通過這個對象釋出路由定義的事件包括：add，update，delete。

③對外部提供 API 接口能夠讓使用者或者程式動态修改路由規則

從代碼上來說就是一個 Controller。這個 Controller 中隻需要調用 routeServiceImpl 就行了，主要也是用到客制化路由實作類中的 add，update，delete 方法。

說白了就是對其進行了一次包裝，讓外部系統可以調用，并且修改路由的配置。

④啟動程式進行路由的添加和更新操作

假設更新 API 網關配置的服務在 8888 端口上。

于是通過 http://localhost:8888/actuator/gateway/routes 通路目前的路由資訊，由于現在沒有配置路由這個資訊是空。

那麼通過 http://localhost:8888/route/add 方式添加一條路由規則。可以設定 Route，當 Predicates 為 baidu 的時候，将請求引導到 www.baidu.com 的網站進行響應。

此時再通過通路 http://localhost:8888/baidu 的路徑通路的時候，就會被路由到 www.baidu.com 的網站。

此時如果需要修改路由配置，可以通過通路 http://localhost:8888/route/update 的 API 接口，通過 Post 方式傳入 Json 結構

在更新完成以後，再通路 http://localhost:8888/CTO 的時候就會把引導到目标的網站了。

這裡的參考資料：

400頁PDF電子書 《SpringCloud Alibaba 筆記》

500頁 PDF電子書 《Java高并發核心程式設計 》

pdf領取方式，請背景私信【筆記】即可擷取！

10W qps 天翼網關系統 架構演進曆程

1、前言

天翼賬号是中國電信打造的網際網路賬号體系産品，利用中國電信管道優勢為企業提供使用者身份認證能力。 其中網關系統是天翼賬号對外能力開放體系的重要組成：業務側它以集中入口、集中計費、集中鑒權管控為目标，技術側它支援隔離性、可配置、易開發、動态路由、可降級、高并發等場景。

自 2017 年天翼賬号網關系統上線以來，曆經數次網際網路的營銷大促活動，特别是 2021 年的春節紅包活動和剛過去雙 11 活動，天翼賬号網關系統在 10 萬級 QPS 和 10 億級日請求量的情況下，各項名額依然保持平穩，順利保障合作方活動的開展。在天翼賬号産品能力不斷提升的背後，是天翼賬号網關系統架構技術疊代發展的過程。

2、天翼賬号網關演進

2.1 重點演進曆程介紹

2017 年~ 2021 年天翼賬号網關系統經曆數次重要更疊更新，每次更新都給産品帶來新的發展機會，系統總體演進過程如下：

2.2 天翼賬号網關系統 1.0

2017 年初，天翼賬号技術團隊基于開源微服務網關 Zuul 元件開展了網關系統 1.0 的建設。

Zuul 是 Spring Cloud 工具包 Netflix 分組的開源微服務網關，它和 Eureka、ribbon、hystrix 等元件配合使用，本質是通過一系列的核心 filter，來實作請求過程的認證安全、動态路由、資料轉化、熔斷保護等功能。

其系統核心運作流程如下：

2018 年中，随着天翼賬号推出免密認證系列産品的快速發展，網關系統 1.0 的缺點日益凸顯主要表現在兩個方面：

1. 性能瓶頸: 微服務網關 Zuul 元件基于 Servlet 架構建構，采用的是阻塞和多線程方式實作，高并發下内部延遲嚴重，會造成連接配接增多和線程增加等情況，導緻阻塞發生，在實際業務應用中單機性能在 1000 QPS 左右。
2. 靈活度有限：為了實作路由和 Filter 動态配置，研發人員需要花費時間去整合開源适配 Zuul 元件控制系統。

為應對業務高峰，技術側常采用橫向擴充執行個體的政策來實作對高并發的支援，該政策給系統穩定性帶來一定的風險，同時部署大量的網關伺服器也提高産品的營運維護成本，是以網關系統架構更新迫在眉睫。

2.3 天翼賬号網關系統 2.0

2.3.1 技術選型

網際網路企業常見的方案有基于 Openresty 的 Kong、Orange，基于 Go 的 Tyk 和基于 Java 的 Zuul：

apiaxle、api-umbrella： 考慮到學習成本和項目後期發展的相容性，其語言和架構不在團隊優先考慮範圍

Zuul：目前正在應用中，Zuul 處理請求的方式是針對每個請求都啟用一個線程來處理。通常情況下，為了提高性能，所有請求被放到處理隊列中，等待空閑線程來處理。當存在大量請求逾時後會造成 Zuul 線程阻塞，目前隻能通過橫向擴充 Zuul 執行個體實作對高并發的支援。而 Zuul2.0 将 HTTP 請求的處理方式從同步變成了異步，以此提升處理性能。但團隊内部對繼續采用 Zuul 比較慎重，原因主要有以下兩點：

1. 版本穩定性需要斟酌 ，Zuul 的開源社群比較活躍，一直在更新狀态
2. 應用企業較少，除了 Netflix，目前 Zuul 在企業中的應用還比較少，性能和穩定性方面還有待觀察

Nginx： 高性能的 HTTP 和反向代理 Web 伺服器，應用場景涉及負載均衡、反向代理、代理緩存、限流等場景。但 Nginx 作為 Web 容器應用場景較少。Nginx 性能優越，而 Nginx 開發主要是以 C/C++ 子產品的形式進行，整體學習和開發成本偏高。Nginx 團隊開發了 NginxScript，可以在 Nginx 中使用 JavaScript 進行動态配置變量和動态腳本執行。

目前行業應用非常成熟的擴充是由章亦春将 Lua 和 Nginx 黏合的 ngx_Lua 子產品，将 Nginx 核心、LuaJIT、ngx_Lua 子產品、多功能 Lua 庫和常用的第三方 Nginx 子產品整合成為 OpenResty。開發人員安裝 OpenResty，使用 Lua 編寫腳本，部署到 Nginx Web 容器中運作，能輕松地開發出高性能的 Web 服務。OpenResty 具有高性能，易擴充的特點，成為了團隊首選。同時也面臨兩個選項：

1. 基于 OpenResty 自建，例如：一個類似于某東 JEN 的系統
2. 對開源架構二次開發，例如：Kong、Orange

根據調研結果，團隊衡量學習成本和開發周期等因素，最終決定采用對 Kong 架構二次開發的方案。以下是調研後的一些對比總結，僅供參考，如有疏漏，請不吝指出。

2.3.2 架構更新

天翼賬号技術團隊制定了網關系統 2.0 演進方案，部署架構如圖：

• 自研插件

除了 Kong 網關自帶的原生元件外，2.0 網關系統還相繼研發出：加密鑒權、日志處理、參數轉換、接口協定、消息隊列、服務穩定、鍊路追蹤及其它等 8 大類共計約 30 多個元件。

豐富的自研元件，保障了系統架構平穩的更新和業務的靈活性：

1. 支援産品 Appkey 認證，SSL/TLS 加密，支援針對 IP 或應用的黑、白名單
2. 符合自身業務的協定插件，包括了常見的加密、簽名算法和國密 sm2，sm3，sm4 等金融級别的算法
3. 監控和統計方面增加了基于 Redis、Kafka 的異步日志彙聚、統計方式，并支援 Zipkin、Prometheus 的追蹤、監控
4. 增加多種按業務精細化分類的限流熔斷政策，進一步完善服務保障體系

2.3.3 效果

網關 2.0 通過對 Kong 元件自研插件的開發和改造，實作了符合産品特性、業務場景的相關功能，也抽象了網關的通用功能。相較于 1.0 版本，具備以下優點：

1. 支援插件化，友善自定義業務開發
2. 支援橫向擴充，高性能、高并發、多級緩存
3. 高可用、高穩定性，具備隔離、限流、逾時與重試、復原機制
4. 插件熱啟用，即插即拔、動态靈活、無需重新開機，能快速适用業務變化

為了驗證新架構的性能，團隊對網關系統 2.0 進行了壓測：

• 結果 1：17:26 在目前測試環境下 QPS 在 1.2W 左右
• 結果 2：18:06 取消 Prometheus、流量控制、日志、權限校驗等插件，QPS 達到 1.3W+

壓測結果表明，天翼賬号網關系統 2.0 已經達到單機萬級 QPS，自研插件運作效率較高，對于網關性能的影響較小。

天翼賬号網關系統 2.0 初期是基于 Kong-v0.14.0 版本開發，運作至 2019 年 5 月時，Kong 已經更新到 v1.1.X 版本，有很多重要的功能和核心代碼更新，而且為了便于跟 Kubernetes 內建，團隊決定将版本升至 v1.1.X。

通過同步遷移、并行運作的方式天翼賬号網關系統 2.1 于 2019 年 9 月完成 Kong-v1.3 版本的更新。

期間天翼賬号網關系統仍平穩地完成了 2018 年阿裡雙 11 活動、2019 年春節活動等大型高并發場景的支撐工作。

2020 年 3 月，網關 2.1 及底層微服務完成了鏡像化改造，即可通過 Kubernetes 自動編排容器的方式部署，在動态擴容等方面有較大的提升。

2.4 天翼賬号網關系統 3.0

随着免密認證逐漸成為網際網路應用作為首選登入方式，網際網路頭部企業要求認證産品 SLA 相關技術名額對齊其内部名額，為了支撐産品精細化營運和進一步的發展，保障産品 SLA 合同及性能名額，技術團隊制定了網關系統 3.0 演進方案。

3.0 網關部署架構圖如下：

2.4.1 DP(Data Plane) 更新

2.4.1.1 Kong 元件更新

團隊摸餘（魚）工程師對開源項目 Kong 的版本釋出一直保持着較高的關注度，總結兩年來 Kong 主要版本更新新特性：

考慮到 Kong 2.5.0 版本為剛剛釋出的版本，采用的企業使用者不多，且開源社群對之前釋出的 V2.4.0 版有較好的評價，是以團隊評審後決定更新到 V2.4.0。

Kong 2.4.0 采用 OpenResty1.19.3.1，基于 Nginx 1.19.3，官方文檔測試單 Worker 可達 269,423 QPS。以 2.0 版本同樣環境壓測，天翼賬号網關系統 3.0（Kong 2.4) QPS 可達到 2W+，對比天翼賬号網關 2.X（Kong 1.3) QPS 1W+，性能預估可提升 80% 以上。

Kong 2.4.0 元件采用控制面 / 資料面（CP/DP） 混合部署新模式，具備以下優勢：

• 功能解耦

混合部署模式，CP 負責将配置資料推動到 DP 節點，DP 節點負責流量資料處理。

• 運作穩定

當 CP 不可用時，DP 可按照本地存儲的配置進行流量業務處理，待 CP 恢複，DP 會自動連接配接更新配置。

• 支援多語言插件

在原有 Lua 插件的基礎上，支援使用 JavaScript 、TypeScript、GO 編寫插件，後端 GO 語言團隊可進行相關擴充。

• 支援 UDP 代理

Routes、Services、Load Balancing、日志插件支援 UDP 代理，滿足業務發展需要。

2.4.1.2 精确網關分組

頂層采用分域名業務隔離，同時根據業務特性、保障級别、通路并發量等特點，

對網關叢集進行分組，完成子業務關聯性解耦，在應對大流量沖擊時降低對業務的影響，同時友善運維側精準擴容。

2.4.1.3 混合雲

建立阿裡雲節點，作為天翼賬号産品雙活系統的補充節點，在高并發時可由 DNS 排程實作自動切換，確定提供無間斷的服務。

2.4.2 CP(Control Plane) 更新

2.4.2.1 優化調用鍊路

增加 Consul 作為服務發現、配置管理中心服務，替換原有 Nginx 層路由功能。

對 Kong 元件提供 DNS 路由及發現服務，通過 Check 方式檢查微服務是否可用。

2.4.2.2 新增插件

• DP 緩存控制插件

Kong 2.4 采用 DP 和 CP 混合部署模式，DP 平面的節點無管理端口，原 Kong 1.3 通過 admin API 管理緩存的模式無法适用現有場景，是以研發了 c-cache-manage 插件，添加後，可通過資料層面 URL 請求對 DP 緩存進行管理。

• 流量複制插件

為了測試網關 3.0 的适用性，團隊自研流量複制插件，複制現網流量對網關 3.0 進行測試，整個測試過程不影響現網環境。

插件運作流程如下：

Konga 配置界面參考：

• Prometheus 插件改造

為了更好的展示 DP 和 CP 層面的資料，對自帶 Prometheus 插件進行改造，增加 DP、CP 角色次元，區分并收集資料平面相關監控名額。

2.4.2.3 完善預警監控

在系統原有的監控的基礎上，增加業務處理監控，通過業務處理監控，可将異常被動通知，轉為主動發現。業務出現異常，可第一時間協助客戶處理，提升系統的效能。

2.4.3 效果

演進完成後天翼賬号網關系統 3.0 具備以下優勢：

1. 高并發，可支撐十萬級 QPS
2. 高可用 ，保障系統 SLA 達到 99.96%
3. 靈活性伸縮性、 DNS 排程自動切換，可通過阿裡雲 ACK 迅速擴容
4. 豐富開發和應用場景，支援多語言插件（Go、Javascript、Lua), 支援 UDP 代理

天翼賬号網關系統 3.0 的部署，有效地保障了系統服務 SLA 等各項名額的達成。在今年雙 11 期間十萬級并發高峰時，系統 TP99 保持在 20MS 以内，總體表現非常穩定。

3、後序

天翼賬号網關經過多次演進，已日趨完善，總結其優勢如下：

1. 系統性能大幅度提升，天翼賬号網關系統 3.0 相較 1.0 性能提升 20 倍以上
2. 統一網關流量入口，超過 90% 以上流量由天翼賬号網關系統管控
3. 系統可用性得到加強，建立了基于 DNS 排程自動切換的三節點、混合雲穩定架構
4. 标準化可複用的插件，如頻控限流、降級熔斷、流量複制、API 協定等标準化插件
5. 豐富的多語言插件能力，Lua、Go、Javascript 的插件，可滿足不同技術團隊的需求

天翼賬号網關系統在中國電信統一賬号能力開放平台中處于舉足輕重的地位，它的疊代更新，為平台十萬級高并發提供了堅實的保障，也為系統維護減少了難度、提升了便捷性，順利支撐業務達成億級收入規模。

天翼賬号技術團隊在 follow 業界主流網關技術的同時，也注重強化網關插件的标準化、服務化建設，希望通過網關能力反哺其它産品賦能大網。

随着中國電信服務化、容器化、全面上雲的戰略推進，天翼賬号網關的系統架構也将随之變化，從全傳統環境到部分雲化再到全量上雲，不斷的向更貼近業務，更适用技術發展的形态演進。

本文的版本計劃和基礎學習資料：

作為技術中台的架構師， 網關是Java架構的重點， 是以，後面會大家從 架構到實操， 完成一個 10Wqps 超高并發 網關實操指導。

而且我指導履歷的過程中，也指導過小夥伴寫過 10Wqps 超高并發 網關履歷，裡邊涉及到大量的設計模式， 小夥伴的履歷，裡邊立馬金光閃閃。後面有機會，帶大家做一下這個高品質的實操，并且指導大家寫入履歷。

是以，這個材料後面也會進行持續疊代，大家可以找我來擷取最新版本和技術交流。

400頁PDF電子書 《SpringCloud Alibaba 筆記》

500頁 PDF電子書 《Java高并發核心程式設計 》

pdf領取方式，請背景私信【筆記】即可擷取！