微服務的架構--API 網關相關知識梳理

1. API網關解決的問題

在微服務的架構下，API 網關是一個常見的架構設計模式。以下是微服務中常見的問題，需要引入 API 網關來協助解決。

1. 微服務提供的 API 的粒度通常與用戶端所需的粒度不同。微服務通常提供細粒度的 API，這意味着用戶端需要與多個服務進行互動。例如産品詳細資訊頁面需要從多個服務中擷取資料。
2. 不同的用戶端需要不同的資料。例如産品詳細資訊頁面PC端版本通常比移動版本更為詳盡。
3. 對于不同類型的用戶端，網絡性能是不同的。例如移動網絡通常要慢得多并且具有更高的延遲。PC端 Web 應用程式可以向後端服務發出多個請求，而不會影響使用者體驗，而移動用戶端隻能提供幾個請求。
4. 微服務執行個體數量及其位置（主機+端口）動态變化
5. 服務劃分會随着時間的推移而變化，應該對用戶端隐藏
6. 服務可能會使用多種協定，其中一些協定可能對網絡不友好

2. API網關提供的主要功能

常見的 API 網關主要提供以下的功能：

1. 反向代理和路由 - 這是大多數項目采用網關最主要的原因。為所有用戶端提供單一入口，并隐藏内部服務部署的細節。
2. 負載均衡 - 網關可以将單個傳入的請求路由到多個後端目的地。
3. 身份驗證和授權 - 進行身份驗證并僅允許可信用戶端通路 API，并且還能夠使用類似 RBA C等方式來授權。
4. IP 清單白名單/黑名單 - 允許或阻止某些 IP 位址通過。
5. 性能分析 - 提供一種記錄與 API 調用相關的使用和其他有用度量的方法。
6. 限速和流控 - 控制 API 調用的能力。
7. 請求變形 - 在進一步轉發之前，能夠在轉發之前轉換請求和響應（包括 Header 和 Body）。
8. 版本控制 - 同時使用不同版本的 API 選項或可能以金絲雀釋出或藍/綠部署的形式提供慢速推出 API
9. 斷路器 - 微服務架構模式有用，以避免使用中斷
10. 多協定支援 WebSocket/GRPC
11. 緩存 - 減少網絡帶寬和往返時間消耗，如果可以緩存頻繁要求的資料，則可以提高性能和響應時間
12. API 文檔 - 如果計劃将 API 暴露給組織以外的開發人員，那麼必須考慮使用 API 文檔，例如 Swagger 或 OpenAPI。

3. 常用的API網關

3.1. Nginx

Nginx 是異步架構的網頁伺服器，也可以用作反向代理、負載平衡器和 HTTP 緩存。該軟體由伊戈爾·賽索耶夫建立并于 2004 年首次公開釋出。2011 年成立同名公司以提供支援。2019 年 3 月 11 日，Nginx 公司被 F5 Networks 以 6.7 億美元收購。

Nginx 有以下的特點：

1. 由 C 編寫，占用的資源和記憶體低，性能高。
2. 單程序多線程，當啟動 nginx 伺服器，會生成一個 master 程序，master 程序會 fork 出多個 worker 程序，由 worker 線程處理用戶端的請求。
3. 支援反向代理，支援 7 層負載均衡（拓展負載均衡的好處）。
4. 高并發，nginx 是異步非阻塞型處理請求，采用的 epoll 和 queue 模式
5. 處理靜态檔案速度快
6. 高度子產品化，配置簡單。社群活躍，各種高性能子產品出品迅速。

如上圖所示，Nginx 主要由 Master，Worker 和 Proxy Cache 三個部分組成。

• Master 主要：NGINX 遵循主從架構。它将根據客戶的要求為 Worker 配置設定工作。将工作配置設定給 Worker 後，Master 将尋找客戶的下一個請求，因為它不會等待 Worker 的響應。一旦響應來自 Worker，Master 就會将響應發送給用戶端
• Worker 工作單元：Worker 是 NGINX 架構中的 Slave。每個工作單元可以單線程方式一次處理 1000 個以上的請求。一旦處理完成，響應将被發送到主伺服器。單線程将通過在相同的記憶體空間而不是不同的記憶體空間上工作來節省 RAM 和 ROM 的大小。多線程将在不同的記憶體空間上工作。
• Cache 緩存：Nginx 緩存用于通過從緩存而不是從伺服器擷取來非常快速地呈現頁面。在第一個頁面請求時，頁面将被存儲在高速緩存中。

3.2. Kong

Kong 是基于 NGINX 和 OpenResty 的開源 API 網關。

Kong 的總體基礎結構由三個主要部分組成：NGINX 提供協定實作和工作程序管理，OpenResty 提供 Lua 內建并挂鈎到 NGINX 的請求處理階段，而 Kong 本身利用這些挂鈎來路由和轉換請求。資料庫支援 Cassandra 或 Postgres 存儲所有配置。

Kong 附帶各種插件，提供通路控制，安全性，緩存和文檔等功能。它還允許使用 Lua 語言編寫和使用自定義插件。Kong 也可以部署為 Kubernetes Ingress 并支援 GRPC 和 WebSockets 代理。

OpenResty 是一個軟體套件，捆綁了 NGINX，一組子產品，LuaJIT 和一組 Lua 庫。其中最主要的是 ngx_http_lua_module一個NGINX 子產品，該子產品嵌入 Lua 并為大多數 NGINX 請求階段提供 Lua 等效項。這有效地允許在 Lua 中開發 NGINX 子產品，同時保持高性能（LuaJIT 相當快），并且 Kong 用它來提供其核心配置管理和插件管理基礎結構。

3.3. APISIX

Apache APISIX 是一個動态、實時、高性能的 API 網關， 提供負載均衡、動态上遊、灰階釋出、服務熔斷、身份認證、可觀測性等豐富的流量管理功能。

APISIX 于 2019 年 4 月由中國的支流科技建立，于 6 月開源，并于同年 10 月進入Apache孵化器。支流科技對應的商業化産品的名字叫 API7 ：）。APISIX 旨在處理大量請求，并具有較低的二次開發門檻。

APISIX 的主要功能和特點有：

• 雲原生設計，輕巧且易于容器化
• 內建了統計和監視元件，例如 Prometheus，Apache Skywalking 和 Zipkin。
• 支援 gRPC，Dubbo，WebSocket，MQTT 等代理協定，以及從 HTTP 到 gRPC 的協定轉碼，以适應各種情況
• 擔當 OpenID 依賴方的角色，與 Auth0，Okta 和其他身份驗證提供程式的服務連接配接
• 通過在運作時動态執行使用者功能來支援無伺服器，進而使網關的邊緣節點更加靈活
• 支援插件熱加載
• 不鎖定使用者，支援混合雲部署架構
• 網關節點無狀态，可以靈活擴充

從這個角度來看，API 網關可以替代 Nginx 來處理南北流量，也可以扮演 Istio 控制平面和 Envoy 資料平面的角色來處理東西向流量。

APISIX 的架構如下圖所示：

3.4. Tyk

Tyk 是一款基于 Golang 和 Redis 建構的開源 API 網關。它于 2014 年建立，比 AWS 的 API 網關即服務功能早。Tyk 用 Golang 編寫，并使用 Golang 自己的 HTTP 伺服器。

Tyk 支援不同的運作方式：雲，混合（在自己的基礎架構中為 GW）和本地。

圖檔

Tyk 由 3 個元件組成：

• 網關：處理所有應用流量的代理。
• 儀表闆：可以從中管理 Tyk，顯示名額群組織 API 的界面。
• Pump：負責持久儲存名額資料，并将其導出到 MongoDB（内置），ElasticSearch 或 InfluxDB 等。

3.5. Zuul

Zuul 是 Netflix 開源的基于 Java 的 API 網關元件。

圖檔

Zuul 包含多個元件：

• zuul-core：該庫包含編譯和執行過濾器的核心功能。
• zuul-simple-webapp：該 Webapp 展示了一個簡單的示例，說明如何使用zuul-core建構應用程式。
• zuul-netflix：将其他 NetflixOSS 元件添加到 Zuul 的庫-例如，使用Ribbon路由請求。
• zuul-netflix-webapp：将 zuul-core 和 zuul-netflix 打包到一個易于使用的程式包中的 webapp。

Zuul 提供了靈活性和彈性，部分是通過利用其他 Netflix OSS 元件進行的：

• Hystrix 用于流控。包裝對始發地的呼叫，這使我們可以在發生問題時丢棄流量并确定流量的優先級。
• Ribbon 是來自 Zuul 的所有出站請求的客戶，它提供有關網絡性能和錯誤的詳細資訊，并處理軟體負載平衡以實作均勻的負載配置設定。
• Turbine 實時彙總細粒度的名額，以便我們可以快速觀察問題并做出反應。
• Archaius 處理配置并提供動态更改屬性的能力。

Zuul 的核心是一系列過濾器，它們能夠在路由 HTTP 請求和響應期間執行一系列操作。以下是 Zuul 過濾器的主要特征：

• 類型：通常定義路由流程中應用過濾器的階段（盡管它可以是任何自定義字元串）
• 執行順序：在類型中應用，定義跨多個過濾器的執行順序
• 準則：執行過濾器所需的條件
• 動作：如果符合條件，則要執行的動作

3.6. Gravitee

Gravitee 是 http://Gravitee.io 開源的，基于 Java 的，簡單易用，性能高，且具成本效益的開源 API 平台，可幫助組織保護，釋出和分析您的 API。

Gravity 提供網關，API 門戶和 API 管理，其中網關和管理 API 部分是開源的，門戶需要注冊許可證來使用。

4. 總結

• nginx

  Nginx 基于 C 開發的高性能 API 網關，擁有衆多的插件，如果你的 API 管理的需求比較簡單，接受手工配置路由，Nginx 是個不錯的選擇。

• Kong

  Kong 是基于 Nginx 的 API 網關，使用 OpenResty 和 Lua 擴充，背景使用 PostgreSQL，功能衆多，社群的熱度很高，但是性能上看比起 Nginx 有相當的損失。如果你對功能和擴充性有要求，可以考慮 Kong。

• APISIX

  APISIX 和 Kong 的架構類似，但是采用了雲原生的設計，使用 ETCD 作為背景，性能上比起 Kong 有相當的優勢，适合對性能要求高的雲原生部署的場景。特别提一下，APISIX 支援 MQTT 協定，對于建構 IOT 應用非常友好。

• Tyk

  Tyk 使用 Golang 開發，背景使用 Redis，性能不錯，如果你喜歡 Golang，可以考慮一下。要注意的是 Tyk 的開源協定是 MPL，是屬于修改代碼後不能閉源，對于商業化應用不是很友好。

• Zuul

  Zuul 是 Netflix 開源的基于 Java 的 API 網關元件，他并不是一款開箱即用的 API 網關，需要和你的 Java 應用一起建構，所有的功能都是通過內建其它元件的方式來使用，适合對于 Java 比較熟悉，用 Java 建構的應用的場景，缺點是性能其他的開源産品要差一些，同樣的性能條件下，對于資源的要求會更多。

• Gravitee

  Gravitee 是 http://Gravitee.io 開源的基于 Java 的 API 管理平台，它能對 API 的生命周期進行管理，即使是開源版本，也有很好的 UI 支援。但是因為采用了 Java 建構，性能同樣是短闆，适合對于 API 管理有強烈需求的場景。

參考

https://www.linkedin.com/in/taogang/