因公眾號更改推送規則，請點“在看”并加“星標”第一時間獲取精彩技術分享

點擊關注#互聯網架構師公眾號，領取架構師全套資料 都在這里

0、2T架構師學習資料干貨分

上一篇：分布式系統設計模式，你用過哪些？

大家好，我是互聯網架構師！

網關是每個大公司系統都具備的一個重要的模塊，今天這篇是關于網關架構演進的，相信能給大家帶來很多啟發。

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 的缺點日益凸顯主要表現在兩個方面：

性能瓶頸:?微服務網關 Zuul 組件基于 Servlet 框架構建，采用的是阻塞和多線程方式實現，高并發下內部延遲嚴重，會造成連接增多和線程增加等情況，導致阻塞發生，在實際業務應用中單機性能在 1000 QPS 左右。

靈活度有限：為了實現路由和 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 比較慎重，原因主要有以下兩點：

版本穩定性需要斟酌 ，Zuul 的開源社區比較活躍，一直在更新狀態

應用企業較少，除了 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 具有高性能，易擴展的特點，成為了團隊首選。同時也面臨兩個選項：

基于 OpenResty 自建，例如：一個類似于某東 JEN 的系統

對開源框架二次開發，例如：Kong、Orange

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

2.3.2 架構升級

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

• 自研插件

除了 Kong 網關自帶的原生組件外，2.0 網關系統還相繼研發出：加密鑒權、日志處理、參數轉換、接口協議、消息隊列、服務穩定、鏈路追蹤及其它等 8 大類共計約 30 多個組件。豐富的自研組件，保障了系統架構平穩的升級和業務的靈活性：

支持產品 Appkey 認證，SSL/TLS 加密，支持針對 IP 或應用的黑、白名單

符合自身業務的協議插件，包括了常見的加密、簽名算法和國密 sm2，sm3，sm4 等金融級別的算法

監控和統計方面增加了基于 Redis、Kafka 的異步日志匯聚、統計方式，并支持 Zipkin、Prometheus 的追蹤、監控

增加多種按業務精細化分類的限流熔斷策略，進一步完善服務保障體系

改造上游

利用 Go 語言的高并發特性，對上游并發量大的微服務進行重構。

2.3.3 效果

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

支持插件化，方便自定義業務開發

支持橫向擴展，高性能、高并發、多級緩存

高可用、高穩定性，具備隔離、限流、超時與重試、回滾機制

插件熱啟用，即插即拔、動態靈活、無需重啟，能快速適用業務變化

為了驗證新架構的性能，團隊對網關系統 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 具備以下優勢：

高并發，可支撐十萬級 QPS

高可用 ，保障系統 SLA 達到 99.96%

靈活性伸縮性、 DNS 調度自動切換，可通過阿里云 ACK 迅速擴容

豐富開發和應用場景，支持多語言插件（Go、Javascript、Lua), 支持 UDP 代理

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

3、后序

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

系統性能大幅度提升，天翼賬號網關系統 3.0 相較 1.0 性能提升 20 倍以上

統一網關流量入口，超過 90% 以上流量由天翼賬號網關系統管控

系統可用性得到加強，建立了基于 DNS 調度自動切換的三節點、混合云穩定架構

標準化可復用的插件，如頻控限流、降級熔斷、流量復制、API 協議等標準化插件

豐富的多語言插件能力，Lua、Go、Javascript 的插件，可滿足不同技術團隊的需求

天翼賬號網關系統在中國電信統一賬號能力開放平臺中處于舉足輕重的地位，它的迭代升級，為平臺十萬級高并發提供了堅實的保障，也為系統維護減少了難度、提升了便捷性，順利支撐業務達成億級收入規模。天翼賬號技術團隊在 follow 業界主流網關技術的同時，也注重強化網關插件的標準化、服務化建設，希望通過網關能力反哺其它產品賦能大網。隨著中國電信服務化、容器化、全面上云的戰略推進，天翼賬號網關的系統架構也將隨之變化，從全傳統環境到部分云化再到全量上云，不斷的向更貼近業務，更適用技術發展的形態演進。

? 來源：

? xie.infoq.cn/article/c6703d216c43c2b522b9b4ffa

相關閱讀：

1、Alibaba開源內網高并發編程手冊.pdf

2、2T架構師學習資料干貨分享

3、10000+TB 資源，阿里云盤，牛逼！！

4、基本涵蓋了Spring所有核心知識點總結

? · END ·

最后，關注公眾號互聯網架構師，在后臺回復：2T，可以獲取我整理的 Java 系列面試題和答案，非常齊全。

如果這篇文章對您有所幫助，或者有所啟發的話，幫忙掃描下發二維碼關注一下，您的支持是我堅持寫作最大的動力。

求一鍵三連：點贊、轉發、在看。

總結

以上是生活随笔為你收集整理的网关 架构演进及实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。