探索 API 网关

  • 3 分鐘

您的解決方案可能包含數個前端和後端服務。 在此情節中，用戶端要如何知道要呼叫哪些端點？ 引進新的服務或重構現有服務時，會發生什麼事？ 服務如何處理 SSL 終止、驗證和其他考量？

API 管理閘道 (也稱為資料平面或執行階段) 是負責 Proxy API 要求、套用原則及收集遙測的服務元件。

API 閘道位於用戶端和服務之間。 它會作為反向 Proxy，將要求從用戶端路由傳送到服務。 它也會執行各種跨領域工作，例如驗證、SSL 終止和速率限制。 如果您未部署閘道，用戶端就必須將要求直接傳送給後端服務。 不過，直接向用戶端公開服務會有一些潛在問題：

  • 它會導致複雜的用戶端程式碼。 用戶端必須追蹤多個端點，並以彈性的方式處理失敗。
  • 它會讓用戶端與後端發生結合。 用戶端需要知道個別服務的分解方式。 這會讓您難以維護用戶端，也較不容易重構服務。
  • 單一作業可能需要呼叫多個服務。
  • 每個公眾對應的服務都必須處理各種考量，例如驗證、SSL 及用戶端速率限制。
  • 服務必須公開用戶端熟悉的通訊協定，例如 HTTP 或 WebSocket。 這會限制通訊協定的選擇。
  • 具有公用端點的服務是潛在的受攻擊面，因此必須予以強化。

閘道可透過讓用戶端與服務分離來協助解決這些問題。

受控和自我裝載

API 管理同時提供受控和自我裝載閘道：

  • 受控 - 受控閘道是針對 Azure 中，每個服務層級中的每個 API 管理執行個體部署的預設閘道元件。 使用受控閘道時，所有 API 流量都會流經 Azure，不論實作 API 的後端裝載位置為何。

  • 自我裝載 - 自我裝載閘道是預設受控閘道的選擇性容器化版本。 它對於需要在裝載 API 後端的相同環境中執行 Azure 閘道的混合式和多重雲端案例非常有用。 自我裝載閘道可讓使用混合式 IT 基礎結構的客戶，透過 Azure 中的單一 API 管理服務，管理裝載於內部部署與跨雲端裝載的 API。