談談微服務設計中的 API 網(wǎng)關模式

• 每個微服務都可以獨立于應用程序中的同級服務進行部署、升級、擴展、維護和重新啟動。
• 通過自治的跨職能團隊進行敏捷開發(fā)和敏捷部署。
• 運用技術時具備靈活性和可擴展性

在考慮客戶端與每個已部署的微服務 直接通信 的問題時，應考慮以下挑戰(zhàn)：

1. 如果微服務向客戶端公開了細粒度的 API，則客戶端應向每個微服務發(fā)出請求。在典型的單頁中，可能需要進行?多次服務器往返，才能滿足請求。對于較差的網(wǎng)絡條件下運行的設備（例如移動設備），這可能會更糟。

2. 微服務中存在的?多種通信協(xié)議（例如 gRpc、thrift、REST、AMQP 等）使客戶端很難輕松采用所有這些協(xié)議。

3. 必須在每個微服務中實現(xiàn)?通用網(wǎng)關功能（例如身份驗證、授權、日志記錄）。

4. 在不中斷客戶端連接的情況下，很難在微服務中進行更改。例如，在合并或劃分微服務時，可能需要重新編寫客戶端部分代碼。

   
   
   
   
   
   

   
   

   API 網(wǎng)關

   
   

   
   

為了解決上述挑戰(zhàn)，人們引入了一個附加層，該附加層位于客戶端和服務器之間，充當從客戶端到服務器的反向代理路由請求。與面向?qū)ο笤O計的模式相似，它為封裝底層系統(tǒng)架構的 API 提供了一個單一的入口，稱為 API 網(wǎng)關。

簡而言之，它的行為就像 API 管理員一樣，但重要的是不要將 API 管理與 API Gateway 混為一談。

路由

• 認證和授權
• 服務發(fā)現(xiàn)集成
• 緩存響應結果
• 重試策略、熔斷器、QoS
• 限速和節(jié)流
• 負載均衡
• log 日志、鏈路追蹤、關聯(lián)
• Header、query 字符串 以及 claims 轉義
• IP 白名單
• IAM
• 集中式日志管理（服務之間的 transaction ID、錯誤日志等）
• 身份的提供方，驗證與授權
  
  
  
  
  
  

  
  

  后端服務前端模式（BFF?Backend for Frontend）

  
  

  
  

• Apigee API Gateway
• MuleSoft
• Tyk.io
• Akana
• SwaggerHub
• Azure API Gateway
• Express API Gateway
• Karken D
  
  

• 負載均衡
• 服務發(fā)現(xiàn)
• 健康檢查
• 安全性

• 可能產(chǎn)生的單點故障或者瓶頸
  
  
• 由于通過 API 網(wǎng)關進行了額外的網(wǎng)絡跳轉以及復雜性風險，響應時間增長了。