說在前面

在（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領取方式，請後台私信【筆記】即可獲取！