微服務架構學習與思考(10):微服務閘道器和開源 API 閘道器01-以 Nginx 為基礎的 API 閘道器詳細介紹

2022-10-20 18:00:50

微服務架構學習與思考(10):微服務閘道器和開源 API 閘道器01-以 Nginx 為基礎的 API 閘道器詳細介紹

一、為什麼會有 API Gateway 閘道器

隨著微服務架構的流行,很多公司把原有的單體架構改造成了微服務架構。

第一步:拆分

微服務架構就是把一個大單體改造成一個一個小的應用。比如把一個電商網站,從單體改造成微服務架構,如下圖:

改造成微服務後,使用者通過 PC 和手機存取電商應用,都是呼叫後面的微服務 API,而且各自要呼叫多個後端 API 服務才能拿到需要的資料。業務量小的時候,這種存取方式沒有多大問題。使用者多了存取量大了呢?這種方式就不能持續。

第二步:API 功能逐漸增多

如果後面業務發展較快,使用者需要的功能越來越多,那麼相應的後端微服務的數量也會越來越多,用上面這種方式來存取,呼叫的微服務 API 數量越來越多,如果存取量大伺服器壓力就會加大,那能不能縮減下呼叫 API 的數量,減輕伺服器存取壓力?聚合服務,內部聚合一些 API 服務介面形成一個聚合服務,PC 或手機使用者端存取這個聚合服務,是不是就減少了存取次數?提高存取效能,提升使用者體驗。

為了提高 API 服務的可用性,還會給 API 加上限流控制,超時控制,熔斷降級,API 隔離等功能。

為了提高 API 服務存取安全性,還會給 API 加上存取控制,比如進行 JWT 驗證,黑白名單機制。如下圖:

第三步:API 閘道器

想一想,每一個 API 服務都需要這些功能,那能不能把這些功能集和在一起?後面就不需要給每個 API 新增同樣的功能。減少開發時間。

這些功能都可以整合到 API Gateway 閘道器中,如下圖:

還有,要上線服務或重構 API 服務時,這種使用者直接存取的方式,就會造成使用者存取出現錯誤,對使用者體驗是很大傷害。API 閘道器遮蔽使用者直接存取後端服務,它就可以平滑過渡這種釋出需求或重構 API 需求。

它還有負載均衡,後端服務可以進行相應擴充套件。

二、API 閘道器功能

通過上面介紹可以看到,API 閘道器可以統一後端的存取,也就是使用者存取後端服務必須通過 API 閘道器才能夠存取到。API 閘道器統一管理了後端的服務接入服務。

它就相當於一尊門神,守護著後端的所有服務。

API 閘道器的功能:

  • API 管理:API 上線、下線,API 路由轉發

  • 服務治理:限流控制,超時控制,熔斷降級

  • 安全策略:統一身份認證,黑白名單機制

  • 協定轉換:REST、gRPC、Dubbo 不同協定轉換

  • API 釋出策略:灰度釋出,流量染色

  • 負載均衡:服務擴充套件,服務伸縮

其他一些功能:監控報警、鏈路追蹤、紀錄檔收集審查等。

三、常見開源 API 閘道器介紹

在前面寫的關於微服務文章:微服務架構學習與思考(04):微服務技術體系 一文中又提到過一些開源閘道器軟體。這次再來詳細介紹下開源 API 閘道器軟體。

3.1 以 Nginx 為基礎的閘道器

Nginx 為基礎,在加上 Lua 語言來進行擴充套件程式設計的閘道器。

3.1.1 OpenResty

介紹:OpenResty® 是一個基於 Nginx 與 Lua 的高效能 Web 平臺,其內部整合了大量精良的 Lua 庫、第三方模組以及大多數的依賴項。用於方便地搭建能夠處理超高並行、擴充套件性極高的動態 Web 應用、Web 服務和動態閘道器。

OpenResty 官網:官網地址

github:OpenResty github

看這個介紹,OpenResty 的功能不止於閘道器功能,還有高效能動態 Web 應用和服務。

它內部整合了大量精良的 Lua 庫,庫地址

有很多 Nginx API for lua,你可以自己用 lua 來編寫相關功能。

當然,它還提供一個企業級(收費服務)產品,提供了很多關於 API 閘道器功能,Web 介面的操作。

沒有找到與開源產品功能對比,只有企業級產品功能介紹。

3.1.2 Kong

Kong 閘道器介紹

kong 是一個高效能高可用易擴充套件的 API 閘道器和 API 服務管理的軟體,它基於 OpenResty(Nginx+Lua)。

它可以在物理機上執行也可以在 kubernetes 上執行。

kong 官網:官網地址

github地址:kong github

kong 也提供了一張使用閘道器前後的對比圖,可以直觀看到使用 API 閘道器的變化,API 自身的功能明顯減少,都整合到 kong 裡面:

​ (來自:https://github.com/Kong/kong)

一些通用的功能都整合到 kong 裡,而後面 API/RPC 只需要編寫業務相關功能就可以了,簡化了 API 開發。

kong 架構

kong 架構圖:

  • Admin API:通過 admin api 來管理 kong 的功能
  • Plugins:外掛,預設外掛和使用者自定義外掛
  • Clustering & Database:儲存 kong 叢集節點資訊,API 資訊,外掛資訊等。目前提供了 PostgreSQL 和 Cassandra 2 種支援,如果需要高可用建議使用 Cassandra。
  • OpenResty:處理外掛、執行外掛程式
  • Nginx:處理底層操作

功能簡介

  • 開源產品和企業產品功能對比

kong 也提供了企業級產品,它還給出了 kong 開源產品和 kong 企業級產品功能對比圖,功能詳細對比在這裡 https://docs.konghq.com/gateway/latest/#features。

可以看到,企業級產品比開源產品提供了豐富得多的功能,這樣才能給企業提供價值。

對比來看,開源功能相對企業版較少(開源產品功能也挺多),但是開源產品功能已經足夠小公司用,還能自定義外掛功能。如果你有預算費用可以使用企業版,這樣更快還有官方諮詢服務。如果沒有預算,那開源也足夠用,也可自己開發外掛。

  • 開源產品功能

開源產品除了提供一些基礎功能:

包括 HTTP 基本認證、金鑰認證、CORS、監控、檔案紀錄檔、API 請求限流、請求轉發、快取、SSL設定等基本功能,這些功能都是通過外掛機制實現。

kong 3.0.x 檔案中,還看到了藍綠部署cluster等功能,更多功能可以看檔案。

還有一些其他重要功能特性:

  1. 叢集

kong 支援單節點叢集和多節點叢集。

單節點叢集:連線到資料庫(Cassandra 或 PostgreSQL)的單個 Kong 節點建立一個節點的 Kong 群集。通過此節點的 Admin API 應用的任何更改都將立即生效。

多節點叢集:多節點叢集它是通過定期後臺作業與其他節點進行資料同步。可以通過設定引數 db_update_frequency(預設 5 秒) 更改頻率,這個頻率更新有點慢。所以 kong 叢集資料一致性是最終一致性。

kong 也給使用者提供了自定義外掛的功能,如果你有需要,自己可以編寫外掛來擴充套件 kong 的功能。

  1. 擴充套件功能-編寫外掛

使用者可以編寫外掛來對 kong 功能進行擴充套件,kong 的外掛是在 API 請求響應迴圈的生命週期中被執行的。

kong 外掛檔案,預設用 lua 語言來編寫外掛,也可以用其它語言。

a. 編寫外掛可以使用的語言 lua,Go,python,js

kong 在 2.6.x 支援了其他語言編寫外掛,有 Go,python,js,檔案地址:https://docs.konghq.com/gateway/2.6.x/reference/external-plugins/。更老的版本應該也有支援的,得去看檔案。

它還有一個編寫外掛的模板

b. 外掛市場 plugin hub

kong 也有自己的一個外掛市場,也就是說你也可以給 kong 貢獻第三方外掛,是優質外掛可能會被收錄。

  1. 通過 admin-api 來管理 kong

詳細看檔案地址:https://docs.konghq.com/gateway/3.0.x/admin-api/

web UI 介面管理

kong 企業版提供了管理 UI,開源版本沒有管理 UI。但是程式設計師是多麼的勤奮也崇尚開源,所以就有很多開源貢獻的管理 UI,其中比較好用的,介紹 1 個, konga

konga 看 github 上的更新時間,也是 3 年前了,也算比較老的了。

3.1.3 APISIX 閘道器

APISIX 介紹

Apache APISIX 是 Apache 軟體基金會下的雲原生 API 閘道器,它兼具動態、實時、高效能等特點,提供了負載均衡、動態上游、灰度釋出(金絲雀釋出)、服務熔斷、身份認證、可觀測性等豐富的流量管理功能。我們可以使用 Apache APISIX 來處理傳統的南北向流量,也可以處理服務間的東西向流量。同時,它也支援作為 K8s Ingress Controller 來使用。

apisix 也是基於 nginx,openresty 的。

apisix 檔案:apisix doc

apisix github:apisix github

APISIX 架構

整體架構圖:

​ (from:https://apisix.apache.org/zh/docs/apisix/getting-started/)

從圖上可以看出,APISIX 底層基座也是基於 Nginx 和 OpenResty。執行在基座之上的是 APISIX 軟體。

  • 底層技術基座:Nginx 和 OpenResty

  • APISIX軟體:看上面架構圖,

    第一部分:APISIX Core,apisix 核心,包括 Lua 外掛、多語言外掛執行時(Plugin Runner)、Wasm 外掛執行時等

    第二部分:各種內建外掛,包括可觀測性、安全、流量控制等外掛。

APISIX 多語言外掛執行時提供多種開發語言的支援,比如 Golang、Java、Python、JS 等。

技術架構圖:

從另外一個角度來看看apisix架構,分為資料面和控制面:

​ (from:https://github.com/apache/apisix)

  • apisix 使用 etcd 作為設定中心來進行資料資訊儲存和同步設定。

特性功能

可以到 github 上看它的 Features,列舉了很多功能特性。

  • 擴充套件能力-外掛功能

a)apisix 內建了很多外掛,可以看檔案 Plugins

b)它也有一個外掛市場,plugin hub

c)當然你也可以自定義外掛。這些看起來與 kong 開源版本擁有擴充套件功能差不多。

  • 高可用叢集
  1. Apache APISIX 的資料平面是無狀態的,可以進行隨意的彈性伸縮,前面加一層負載均衡即可
  2. Apache APISIX 的控制平面是依賴於 etcd cluster 的高可用實現的,不需要任何關係型資料庫的依賴

與 kong 區別:

這第二點與 Kong 叢集有區別,Kong 叢集依賴的是 Postgre 和 Cassandra。

Web UI

通過RESTful API 來管理 apisix,通過 Admin API 來管理 apisix 節點。通過 Control API 控制單個 apisix 資料平面行為。

官方還提供了一個 Dashboard,通過 UI 管理 apisix。

與 kong 區別:

kong 開源版本沒有這個 Dashboard 功能,企業版本有。

3.1.4 Orange 閘道器

這個 orange 也是一 OpenResty 為基礎開發的閘道器,

orange 官網: orange 地址

github 地址:orange github

orange 的功能相對於前面的 kong 和 apisix,比較少。所以它的架構肯定比他們簡單,可以作為學習之用。

如果你不需要那麼多功能,可以試用下這款 API 閘道器。

四、API 閘道器缺點

  1. 讓系統複雜度變高

在整個系統架構中,多一個了 API 閘道器,就多了一份維護工作,多了一處發生「危險」的地方。

  1. API 閘道器可能成為效能瓶頸

因為所有的流量都要經過 API 閘道器,可以通過擴充套件叢集來解決。前面在加一組負載均衡裝置等方法。

五、參考