架構模式: API網關

模式: API網關

上下文

讓咱們假設您正在構建一個使用Microservice體系結構模式的在線商店,而且您正在實現產品詳細信息頁面。您須要開發產品詳細信息用戶界面的多個版本:html

  • 用於桌面和移動瀏覽器的基於HTML5 / JavaScript的UI  -  HTML由服務器端Web應用程序生成
  • 原生Android和iPhone客戶端 - 這些客戶端經過REST API與服務器交互

此外,在線商店必須經過REST API公開產品詳細信息,以供第三方應用程序使用。
產品詳細信息UI能夠顯示有關產品的大量信息。例如,POJO in Action的Amazon.com詳細信息頁面顯示:前端

  • 有關該書的基本信息,如標題,做者,價格等。
  • 本店的購買歷史
  • 可用性
  • 購買選項此書常常購買的其餘商品
  • 購買此書的顧客
  • 購買的其餘商品
  • 顧客評論
  • 賣家排名
  • ...

因爲在線商店使用微服務架構模式,所以產品詳細信息數據分佈在多個服務上。例如,java

  • 產品信息服務 - 產品的基本信息,如標題,做者訂價服務
  • 產品價格訂購服務
  • 產品購買歷史庫存服務
  • 產品可用性評估服務
  • 客戶評論...

所以,顯示產品詳細信息的代碼須要從全部這些服務中獲取信息。git

問題

基於微服務的應用程序的客戶端如何訪問各個服務?github

關注點

  • 微服務提供的API的粒度一般與客戶端所需的不一樣。微服務一般提供細粒度的API,這意味着客戶端須要與多個服務進行交互。例如,如上所述,須要產品細節的客戶端須要從衆多服務中獲取數據。spring

  • 不一樣客戶須要不一樣的數據。例如,產品詳細信息頁面桌面的桌面瀏覽器版本一般比移動版本更精細。後端

  • 不一樣類型的客戶端的網絡性能不一樣。例如,移動網絡一般比非移動網絡慢得多且具備更高的延遲。固然,任何WAN都比LAN快得多。這意味着本機移動客戶端使用的網絡與服務器端Web應用程序使用的LAN具備很是不一樣的性能特徵。服務器端Web應用程序能夠對後端服務發出多個請求,而不會影響用戶體驗,由於移動客戶端只能作一些。api

  • 服務實例的數量及其位置(主機+端口)動態變化瀏覽器

  • 對服務的分區可能會隨着時間的推移而發生變化,應該從客戶端隱藏安全

  • 服務可能使用各類協議,其中一些協議可能不適合Web

解決方案

實現API網關,它是全部客戶端的單一入口點。API網關以兩種方式之一處理請求。有些請求只是代理/路由到適當的服務。它經過扇出多個服務來處理其餘請求。

 

API網關能夠爲每一個客戶端公開不一樣的API,而不是提供一個通用的樣式API。例如,Netflix API網關運行特定於客戶端的適配器代碼,該代碼爲每一個客戶端提供最適合其要求的API。

API網關也能夠實現安全性,例如驗證客戶端是否有權執行請求

變種

此模式的變體是前端模式的後端。它爲每種客戶端定義了一個單獨的API網關。

在此示例中,有三種客戶端:Web應用程序,移動應用程序和外部第三方應用程序。有三種不一樣的API網關。每一個都爲其客戶提供API。

例子

結果

使用API​​網關具備如下好處:

  • 將客戶端與應用程序分區爲微服務的方式隔離,使客戶端免於肯定服務實例位置的問題爲每一個客戶端提供最佳API減小請求/往返次數。例如,API網關使客戶端可以經過單次往返從多個服務中檢索數據。
  • 更少的請求也意味着更少的開銷並改善用戶體驗。
  • API網關對於移動應用程序相當重要。經過將用於調用多個服務的邏輯從客戶端移動到API網關來簡化客戶端從「標準」公共Web友好API協議轉換爲內部使用的任何協議 

API網關模式有一些缺點:

  • 複雜性增長 -  API網關是必須開發,部署和管理的另外一個移動部分因爲經過API網關額外的網絡跳躍而增長了響應時間 - 可是,對於大多數應用程序而言,額外往返的成本是微不足道的。

問題:

  • 如何實現API網關?事件驅動/被動方法最好是必須按比例擴展以處理高負載。在JVM上,基於NIO的庫(如Netty,Spring Reactor等)是有意義的。NodeJS是另外一種選擇。

相關的例子

  • 微服務架構模式產生了對這種模式的需求。
  • API網關必須使用客戶端發現模式或服務器端發現模式將請求路由到可用服務實例。
  • API網關能夠對用戶進行身份驗證,並將包含用戶信息的訪問令牌傳遞給服務
  • API網關將使用Circuit Breaker來調用服務
  • API網關一般實現API組合模式

已知的實現

相關文章
相關標籤/搜索