技術文章 » API 閘道器的功能用途及實現方式

API 閘道器的功能用途及實現方式

2023-01-17 12:00:08

1. API 閘道器誕生背景

前言

API 經濟生態鏈已經在全球範圍覆蓋， 絕大多數企業都已經走在數位化轉型的道路上，API 成為企業連線業務的核心載體， 併產生巨大的盈利空間。快速增長的 API 規模以及呼叫量，使得企業 IT 在架構上、模式上面臨著更多的挑戰。

API 是什麼

API 閘道器是一個伺服器，是系統的唯一入口。從物件導向設計的角度看，它與外觀模式類似。API 閘道器封裝了系統內部架構，為每個使用者端提供一個客製化的 API。它可能還具有其它職責，如身份驗證、監控、負載均衡、快取、請求分片與管理、靜態響應處理。API 閘道器方式的核心要點是，所有的使用者端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能。通常，閘道器也是提供 REST/HTTP 的存取 API。伺服器端通過 API-GW 註冊和管理服務。

1. API 開放數量不斷增加

毋庸置疑，隨著企業的資料化進展，微服務改造，不同領域的 API 層出不窮，早在 2014 年 ProgrammableWeb 便預測 API 向量可達到 100,000 到 200,000，並會不斷增長。API 開發數量的增加給邊緣系統帶來機會，也隨即演變了 API 閘道器的出現。大規模的 API 管理系統成為核心的發展趨勢。

2. API 服務平臺多樣化

最初的 API 主要針對不同單體應用的網路單元之間資訊互動，現已演變到服務間快速通訊。隨著人工智慧 EI，IOT 的不斷演進，依賴 API 的平臺不斷更新，如 Web，Mobile，終端等，未來將會出現更多的服務體系。包括不限於：

  • 瀏覽器
  • IOS
  • Android
  • macOS
  • Windows
  • Linux
  • IOT
  • 其他行動端
  • 小程式
  • 終端裝置（如智慧零售、工業的終端等）
  • ......

3. 逐步替換原有企業的服務模式，API 即商品

賣計算，賣軟體，賣能力，最終的企業的銷售模式會逐步轉變，能力變現，釋放資料價值，依託不同的 API 管理平臺創造新的盈利。

API 閘道器誕生背景

隨著 API 的整體趨勢發展，每個時期都面臨著不同的挑戰，架構也隨之變化，具體如下圖：

  1. 1960-1980：阿帕網、ATTP、TCP
  2. 1980-1990：對等
  3. 1990-2000：訊息中介軟體、ESB（企業服務匯流排，Enterprise service bus），SOA（面向服務的架構）
  4. 2000 至今：Integration as a service，RESTful services，API 管理，雲上編排

從最原始的「傳輸協定通訊」 -> 「簡單的介面整合」 -> 「訊息中介軟體」 -> 「標準 REST」， 可以看到 API 的發展更趨向於簡潔， 整合，規範化， 這也促使更多的系統邊界元件不斷湧現，在承載了萬億級的 API 經濟的背景下， API 閘道器應運而生。

如果沒有合適的 API 管理工具， API 經濟不可能順利開展。 同時提出了對於 API 管理系統的生命週期定義： planning（規劃）, design（設計）， implementation（實施）， publication（釋出），operation（運維）, consumption（消費）, maintenance（維護） and retirement of APIs（下架）

如果沒有合適的 API 管理工具， API 經濟不可能順利開展。 同時提出了對於 API 管理系統的生命週期定義： planning（規劃）, design（設計）， implementation（實施）， publication（釋出），operation（運維）, consumption（消費）, maintenance（維護） and retirement of APIs（下架）

-- Magic Quadrant for Full Life Cycle API Management，Gartner, 2016-10-27

2. API 閘道器核心功能

  • API 生命週期管理
    • planning（規劃）
    • design（設計）
    • implementation（實施）
    • publication（釋出）
    • operation（運維）
    • consumption（消費）
    • maintenance（維護）
    • retirement（下架）
  • API 閘道器基礎功能
    • 認證
    • 鑑權
    • 服務發現和整合
    • 負載均衡
    • 紀錄檔
    • 鏈路追蹤
    • 監控
    • 重試
    • 限流
    • QoS
    • 熔斷器
    • 對映
    • 快取
    • Header、query 字串 等 跳脫
    • API 檔案
    • API 測試
    • SDK 生成
  • API 多版本、多環境管理
  • 外掛
  • API 集中式 metrics、logging、tracing 管理
  • 安全
    • HTTPS
    • IP 黑白名單
  • 高可用
    • 可熱重啟
  • 高效能
  • 可延伸性
    • 無狀態橫向擴充套件

3. API 閘道器的用途

OpenAPI

企業需要將自身資料、能力等作為開發平臺向外開放，通常會以 rest 的方式向外提供。最好的例子就是淘寶開放平臺、騰訊公司的 QQ 開發平臺、微信開放平臺。

Open API 開放平臺必然涉及到客戶應用的接入、API 許可權的管理、呼叫次數管理等，必然會有一個統一的入口進行管理，這正是 API 閘道器可以發揮作用的時候。

微服務閘道器

在微服務架構中，有一個元件可以說是必不可少的，那就是微服務閘道器，微服務閘道器處理了負載均衡，快取，路由，存取控制，服務代理，監控，紀錄檔等。

API 閘道器在微服務架構中正是以微服務閘道器的身份存在。

API 中臺

上述的微服務架構對企業來說有可能實施上是困難的，企業有很多遺留系統，要全部抽取為微服務改動太大，對企業來說成本太高。

但是由於不同系統間存在大量的 API 服務互相呼叫，因此需要對系統間服務呼叫進行管理，清晰地看到各系統呼叫關係，對系統間呼叫進行監控等。

API 閘道器可以解決這些問題，我們可以認為如果沒有大規模的實施微服務架構，那麼對企業來說微服務閘道器就是企業的 API 中臺。

4. API 閘道器的價值

通過 API 閘道器，可以封裝後端各種服務，以 API 的形式，提供給各方使用。API 閘道器產品的優勢總結如下：

  • API 全生命週期管理：協助開發者輕鬆完成 API 的建立、維護、釋出、監控等整個生命週期的管理。
  • 豐富的服務治理能力：支援 API 限流，引數校驗，後設資料維護，SDK 生成，批次操作等能力，協助開發者高效管理服務。
  • 可觀察性：通過 API 閘道器，支援對呼叫次數，前後端錯誤次數等豐富監控指標的可視和告警能力；通過全面的監控告警，保證使用者服務的可用性。
  • 可運營性：支援 企業 OpenAPI 定價，賬單等運營功能
  • 服務安全：通過接入多種認證方式，確保使用者 API 的存取安全性；通過嚴格的流量控制，避免使用者服務的過載。
  • 前後端業務解耦
  • 多型別後端打通

5. API 閘道器的實現方式

主流 API 閘道器

  • Istio（以及最新出的 Envoy Gateway)
  • Linkerd
  • NGINX 及其商業版
  • KONG
  • Traefik
  • APISIX
  • RedHat 3scale
  • Netflix Zuul
  • Spring Cloud Gateway
  • Amazon API Gateway
  • 阿里雲 API 閘道器（其最新開源的 Higress 是基於 Envoy Gateway 的）
  • 騰訊雲 API 閘道器
  • MuleSoft

OpenAPI

對於定位 OpenAPI 平臺的 API 閘道器，目前只能選擇專業的 API 閘道器作為解決方案。

微服務閘道器

對於定位為「微服務閘道器」的 API 閘道器，業務有多種實現方式：

Service Mesh

典型的如 Istio，架構如下：


通用反向代理

基於 NGINX 或 NGINX + LUA + OpenResty 的實現。典型如：

API 閘道器框架

公有云解決方案

其實公有云的解決方案也是基於以上方案的客製化化開發併產品化後釋出到公有云上，主流的也是基於：NGINX + LUA + OpenResty, 或者最新的可能是基於 Istio Gateway 的實現

其他方案

  • 基於 Netty、非阻塞 IO 模型。
  • 基於 Node.js 的方案。這種方案是應用了 Node.js 的非阻塞的特性。
  • 基於 Java，如 MuleSoft