微服務--網關


網關
  • 一、爲什麼使用網關?
    • 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/


    • 參考鏈接:http://dockone.io/article/482


    • 雖然使用SpringCloud 已經很長時間,但是細細讀下來這篇文章,收益匪淺。簡單的翻譯和整理了一下,如有錯誤,還望指正。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章