微服務--網關

網關

• 一、為什麼使用網關？
  • 1） 用戶端的需求量與每個微服務暴露的細粒度API數量的不比對。 （比如，移動用戶端一個頁面，需要請求上百個微服務，沒有效率）
  • 2）用戶端請求微服務的協定可能并不是web友好型。（每個服務的協定可能不一樣，應用應該在防火前外采用類似http協定）
    • 一個服務可能是用Thrift的RPC協定，而另一個服務可能是用AMQP消息協定。它們都不是浏覽或防火牆友好的，并且最好是内部使用。應用應該在防火牆外采用類似HTTP或者WEBSocket協定。
  • 3）很難重構;
    • 随着時間的推移，我們可能需要改變系統微服務目前的切分方案。例如，我們可能需要将兩個服務合并或者将一個服務拆分為多個。但是，如果用戶端直接與微服務互動，那麼這種重構就很難實施。
• 二、定義：
  •  一個伺服器，或者說是進入系統的唯一節點；
  • 封裝内部系統的架構，提供api給各個用戶端（facade模式（外觀模式）很像。 外觀模式是在擴充卡模式下把多個方法整合到一個對外的方法中。）；
  • 負責請求轉發、合成和協定轉換。  （比如： 可以在web協定與内部使用的非Web友好型協定間進行轉換，如HTTP協定、WebSocket協定。）；
  • 定制化的api （用戶端請求的資料需要多個服務時，它隻提供一個服務點就可以，不用用戶端請求多個服務）。
• 三、網關的用途：
  • 負責負載均衡、緩存、通路控制、請求分片和管理、靜态響應處理、授權、監控等任務；
• 四、優缺點
  • 優點：
    • 封裝應用内部結構；用戶端直接跟gatway互動更簡單點。API Gateway提供給每一個用戶端一個特定API，這樣減少了用戶端與伺服器端的通信次數，也簡化了用戶端代碼。
  • 缺點：
    • 是一個高可用的元件，必須要開發、部署和管理；可能成為開發的瓶頸，開發者必須更新API Gateway來提供新服務提供點來支援新暴露的微服務。更新API Gateway時必須越輕量級越好。
    • 否則，開發者将因為更新Gateway而排隊列。但是，除了這些缺點，對于大部分的應用，采用API Gateway的方式都是有效的。
• 五、實作
  • 設計要求：
    • 性能和可擴充性：
      • 隻有少數公司需要每天處理大規模(上億)的請求；對于大部分應用，網關的性能和可擴充性是非常重要的。支援同步、非阻塞I/O的網關。
      • 例子： jvm中，采用基于NIO技術的Netty; Nginx Plus提供一個成熟的、可擴充的、高性能web伺服器和反向代理，它們均容易部署、配置和二次開發。
    • 采用反應性程式設計模型:  
      • 因為有一些請求，需要調用多個後端服務并合并結果處理，如果發送給後端服務的請求是互相獨立的，可以并發的處理這些請求；如果這些請求之間是有依賴的，必須向請求A，才能請求B。
      • 比如java8 的 completableFuture，支援 多任務并發執行、支援任務完成的先後順序，原生的api，傳回每個任務的異常, api豐富。
      • 如果利用傳統的同步回調方法實作Api的合并會很麻煩，代碼複雜且難以維護。比較好的解決方法就是： 反應性程式設計模型，比如java8的completableFuture 和 js 的Promise 。
    • 服務調用：
      • 一個基于微服務的應用是一個分布式系統，并且必須采用線程間通信的機制。兩種線程間通信的方法： 1、采用異步機制，基于消息代理的方法；如JMS、AMQP；2、采用同步機制，如Thrift、Http。
      • 系統會同時采用同步和異步兩種機制。
      • 網關将需要支援多種通信機制。
    • 服務發現：
      • 網關需要知道每一個微服務的IP和端口，在傳統應用中，采用寫死；在雲基礎的微服務應用中，采用服務發現機制。
      • 兩種方式： 服務端發現與用戶端發現（網關需要查詢服務注冊處,也就是微服務執行個體位址的資料庫)。
    • 處理部分失敗：
      • 在分布式系統中當一個服務調用另一個服務逾時或者不可用的情況，就會發生部分失敗。
      • 網關不應該被阻斷并處于無限期等待下遊服務的狀态，如何處理這種失敗依賴于特定的場景和具體服務。比如：
        • 産品詳情頁中，推薦子產品無響應，其他資訊比如圖檔、價格等應該傳回給使用者，推薦部分可以傳回空、也可以固定傳回幾個；如果是産品資訊服務無響應，網關應該給用戶端傳回一個錯誤。
        • 當緩存有效時，網關應該能傳回緩存。比如，産品的價格變化并不頻繁，網關在價格服務不可用時應傳回緩存中的數值。這個緩存可以有網關本身實作，也可以借助redis 等這類外部緩存實作，通過
        • 傳回緩存資料或者預設資料，網關確定系統錯誤不影響使用者體驗。
      • Netflix Hysrix 對于實作遠端服務調用代碼來說是一個非常好用的庫。Hystrix記錄那些超過預設定的極限值的調用。它實作了circuit break模式，使得可以将用戶端從無響應服務的無盡等待中停止。
      • 如果一個服務的錯誤率超過預設值，Hystrix将中斷服務，并且在一段時間内所有請求立刻失效。Hystrix可以為請求失敗定義一個fallback操作，例如讀取緩存或者傳回預設值。
      • 如果你在用JVM，就應該考慮使用Hystrix。如果你采用的非JVM環境，那麼應該考慮采用類似功能的庫。
  • 六、總結
    • 對于大多數微服務基礎的應用，實作一個API Gateway都是有意義的，它就像是進入系統的一個服務提供點。API Gateway負責請求轉發、請求合成和協定轉換。
    • 它提供給應用用戶端一個自定義的API。API Gateway可以通過傳回緩存或者預設值的方式來掩蓋後端服務的錯誤。
  • 原文連結： https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
  • 參考連結： http://dockone.io/article/482 http://dockone.io/article/482
  • 雖然使用SpringCloud 已經很長時間，但是細細讀下來這篇文章，收益匪淺。簡單的翻譯和整理了一下，如有錯誤，還望指正。