談?wù)勎⒎?wù)設(shè)計中的 API 網(wǎng)關(guān)模式

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

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

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

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

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

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

   
   
   
   
   
   

   
   

   API 網(wǎng)關(guān)

   
   

   
   

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

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

路由

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

  
  

  后端服務(wù)前端模式（BFF?Backend for Frontend）

  
  

  
  

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

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

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