如果讓我設計一套，TPS百萬級API閘道器！

作者：小傅哥
部落格：https://bugstack.cn

沉澱、分享、成長，讓自己和他人都能有所收穫！?

是滴，小傅哥又要準備搞事情了！這次準備下手API閘道器專案，因為這是所有網際網路大廠都有的一個核心服務，承接著來自使用者的滴滴叫車、美團外賣、京東購物、微信支付，更是大促期間千萬級訪問量的核心繫統。

? 那麼它是一個什麼樣的專案呢？為什麼會有它的存在？它是怎麼設計實現的呢？都用到了哪些技術棧呢？

一、前言：閘道器是啥東西

在計算機網路中，閘道器（Gateway）是轉發其他伺服器通訊資料的伺服器，接收從客戶端傳送來的請求時，它就像自己擁有資源的源伺服器一樣對請求進行處理。

而API閘道器也是隨著對傳統龐大的單體應用（All in one）拆分為眾多的微服務（Microservice）以後，所引入的統一通訊管理系統。用於執行在外部http請求與內部rpc服務之間的一個流量入口，實現對外部請求的協議轉換、引數校驗、鑑權、切量、熔斷、限流、監控、風控等各類共性的通用服務。

二、大廠：為啥都做閘道器

各大廠做閘道器，其實做的就是一套統一方案。將分散式微服務下的RPC到HTTP通訊的同類共性的需求，凝練成通用的元件服務，減少在業務需求場景開發下，非業務需求的同類技術訴求的開發成本。

那麼以往沒有閘道器的時候怎麼做，基本的做法就是再 RPC 服務之上再開發一個對應的 WEB 服務，這些 WEB 服務可以是 Spring MVC 工程，在 Spring MVC 工程中呼叫 RPC 服務，最終提供 HTTP 介面給到 H5、Web、小程式、APP 等應用中進行使用。如圖 1-1 所示

傳統開發 WEB 服務的幾個問題：

• 問題1：每一個 WEB 應用，都需要與之匹配申請一套工程、域名、機器等資源，一直到部署，研發效率降低，維護成本增加。
• 問題2：每一個 WEB 應用，都會有所涉及共性需求，限流、熔斷、降級、切量等訴求，維護程式碼成本增加。
• 問題3：每一個 WEB 應用，在整個使用生命週期內，都會涉及到文件的維護、工程的除錯、聯調的訴求，類似刀耕火種一樣的開發勢必降低研發效率。

所以：綜上在微服務下的傳統開發所遇到的這些問題，讓各個大廠都有了自己自研閘道器的訴求，包括；阿里、騰訊、百度、美團、京東、網易、亞馬遜等，都有自己成熟的 API 閘道器解決方案。畢竟這可以降低溝通成本、提升研發效率、提升資源利用率。

三、閘道器：系統架構設計

如果希望實現一個能支撐百億級吞吐量的閘道器，那麼它就應該是按照分散式架構思維做去中心化設計，支援橫向擴充套件。讓每一臺閘道器服務都成為一個算力，把不同的微服務RPC介面，按照權重策略計算動態分配到各個算力組中，做到分散式運算的能力。

此外從設計實現上，要把閘道器的通訊模組、管理服務、SDK、註冊中心、運營平臺等依次分開單獨開發實現，這樣才能進行獨立的組合包裝使用。

這就像為什麼 ORM 框架在開發的時候不是與 Spring 強繫結在一起，而是開發一個獨立的元件，當需要有 Spring 融合使用的時候，再單獨開發一個 Mybatis-Spring 來整合服務。

所以在這裡設計閘道器的時候也是同樣的思路，就像官網的通訊不應該一開始就把 Netty 相關的服務全部繫結到 Spring 容器，這樣即增加了維護成本，也降低了系統的擴充套件性。

諸如此類的軟體架構設計，都會在這套閘道器微服務架構中體現，整體架構如圖 1-2 所示

整個API閘道器設計核心內容分為這麼五塊；

• 第一塊：是關於通訊的協議處理，也是閘道器最本質的處理內容。這裡需要藉助 NIO 框架 Netty 處理 HTTP 請求，並進行協議轉換泛化呼叫到 RPC 服務返回資料資訊。
• 第二塊：是關於註冊中心，這裡需要把閘道器通訊系統當做一個算力，每部署一個閘道器服務，都需要向註冊中心註冊一個算力。而註冊中心還需要接收 RPC 介面的註冊，這部分可以是基於 SDK 自動掃描註冊也可以是人工介入管理。當 RPC 註冊完成後，會被註冊中心經過AHP權重計算分配到一組閘道器算力上進行使用。
• 第三塊：是關於路由服務，每一個註冊上來的Netty通訊服務，都會與他對應提供的分組閘道器相關聯，例如：wg/(a/b/c)/user/... a/b/c 需要匹配到 Nginx 路由配置上，以確保不同的介面呼叫請求到對應的 Netty 服務上。PS：如果對應錯誤或者為啟動，可能會發生類似B站事故。
• 第四塊：責任鏈下外掛模組的呼叫，鑑權、授信、熔斷、降級、限流、切量等，這些服務雖然不算是閘道器的定義下的內容，但作為共性通用的服務，它們通常也是被放到閘道器層統一設計實現和使用的。
• 第五塊：管理後臺，作為一個閘道器專案少不了一個與之對應的管理後臺，使用者介面的註冊維護、mock測試、日誌查詢、流量整形、閘道器管理等服務。

綜上系統微服務模組結構如下：

四、演示：閘道器執行效果

趁著週末假期小傅哥已經做了一部分的功能實現，就像小傅哥以前[《手寫Spring》]()、[《手寫Mybatis》]()一樣，此專案也是漸進式的逐步完成各個模組功能的開發。並參照優秀原始碼級的專案架構設計，運用抽象和分治的設計技巧，解決功能間的耦合呼叫和服務設計。同時也結合設計原則和相應場景下的設計模式，開發出高質量易於迭代和維護的程式碼。部分程式碼實現和執行如圖 1-3 所示

• 左側是API閘道器核心通訊模組，右側是RPC(Dubbo)服務。透過對網頁端發起的 http 請求，經過API閘道器的協議轉換和對RPC的泛化呼叫包裝結果資料並返回到頁面，就是中間這張圖的執行效果了。
• 左側工程的實現，以漸進式分拆模組逐步完成，例如： core-01(Netty通訊)、core-02(泛化呼叫)、core-03(執行器)等，讓每一個對API閘道器感興趣的讀者都能從中學習到；架構的分層、功能的設計、程式碼的實現。

五、邀請：我們們一起開發

?以上關API閘道器的專案，也是小傅哥準備帶著讀者一起利用週末和假期學習實踐的內容。現在上車你將會透過小傅哥的影片+文件+程式碼，三方面來與你一起學習，幫助你提升技術實力，為你的職業生涯續期，也為你可以走的更遠，可以多賺些錢。

• [x] 第1章：HTTP請求會話協議處理
• [ ] 第2章：代理RPC泛化呼叫
• [ ] 第3章：XML配置檔案解析
• [ ] 第4章：方法執行器封裝
• [ ] 梳理中 ... 每週更新

• Github：https://github.com/fuzhengwei/api-gateway
• Gitcode：https://gitcode.net/fuzhengwei/api-gateway