服務網格Service Mesh、API閘道器和訊息佇列的對比 - Wolfram Hempel
讓我們跳過微服務的推銷 - 你已經知道它們是什麼以及為什麼它們有意義。事實上,近年來幾乎沒有什麼話題能夠獲得如此多的報導,因為將一件大東西分解成許多小東西可以讓它更容易處理。
麻煩的是:一旦我們打碎了我們的單體巨石,我們如何將它重新組合成一個仍然有意義的更大的系統?儘管Istio,Kong或Kafka的愛好者都會回答你,這個問題肯定不止有一個答案,不同的解決方案對應於不同的需求。
本文旨在闡明在微服務之間組織通訊的各種方法,以及Service Mesh,API Gateway或Message Queue可能是滿足您需求的最佳解決方案。
但在我們談論解決方案之前,讓我們談談這個問題:
有什麼問題?
為了正常執行,基於微服務的架構必須解決特定於其分散式特性的許多挑戰:
1.彈性
任何給定的微服務可能有幾十甚至幾百個例項 - 由於各種原因,每個例項都可能在任何時間點失敗。
2.負載平衡和自動擴充套件
由於可能有數百個端點能夠完成請求,因此路由和擴充套件都是重要的。實際上,大型架構最有效的節省成本措施之一是提高路由和擴充套件決策的精度。
3.服務發現
應用程式越複雜和分散式,找到現有端點並與它們建立通訊通道就越困難。
4.跟蹤和監控
微服務架構中的單個交易可能會透過多個服務進行傳輸,因此很難跟蹤其行程。
5.版本
隨著系統的成熟,更新可用端點和API變得至關重要,同時確保舊版本仍然可用。
解決方案
服務網格,API閘道器和訊息佇列都可以解決這些問題,當然,還有許多其他方法,從簡單的靜態負載平衡和固定IP到中央編排伺服器 - 但是這裡只看一下目前最流行和最複雜的選項。
API閘道器
API閘道器是類似HTTP反向代理的更大兄弟。它是一個可擴充套件的,通常面向Web的伺服器,可以接收來自公共網際網路和內部服務的請求,並將它們轉發到最適合的微服務例項。API閘道器通常具有許多有用的功能,包括負載平衡和執行狀況檢查,API版本控制和路由,請求身份驗證和授權,資料轉換,分析,日誌記錄,SSL終止等。流行的開源API閘道器的示例是Kong或Tyk。大多數雲提供商也提供自己的實施,例如AWS API Gateway,Azure Api Management或Google Cloud Endpoints。
優點
API閘道器功能強大,複雜程度相對較低,它們為公共網際網路提供了堅實的防禦層,並解除安裝了許多重複性任務,例如使用者身份驗證或資料驗證。
缺點
API閘道器相當集中。它們可以以水平可擴充套件的方式部署,但與服務網格不同,它們仍然需要單點來註冊新API或更改配置。從組織的角度來看,它們很可能由一個團隊維護
服務網格
Service Meshes是微服務例項之間的分散和自組織網路,用於處理負載平衡,端點發現,執行狀況檢查,監視和跟蹤。它們透過將一個小代理(稱為“邊車”)附加到每個調解流量並處理例項註冊,度量標準收集和維護的例項來工作。雖然在概念上是分散的,但大多數服務網格都帶有一個或多箇中心元素來收集資料或提供管理介面。流行的例子包括Istio,Linkerd或Hashicorp的Consul。
優點
服務網格更加動態,可以輕鬆改變形狀並適應新的功能和端點。它們的分散性使得在相當孤立的團隊中處理微服務變得更加容易。
缺點
服務網格可能非常複雜,需要大量移動部件。例如,充分利用Istio需要為每個節點部署單獨的流量管理器,遙測收集器,證書管理器和邊車流程。它們還是一個非常新的發展中技術,使用其構成你的架構的骨幹,可能讓你擔憂它的年輕。
訊息佇列
首先看一下,將服務網格與訊息佇列進行比較似乎比較蘋果和橙子:它們是完全不同的東西,但它們解決了同樣的問題,儘管方式截然不同。
訊息佇列允許您透過解耦傳送方和接收方在服務之間建立複雜的通訊模式,它們使用許多概念實現此目的,例如基於主題的路由或釋出 - 訂閱訊息傳遞,以及緩衝的任務佇列,使多個例項變得容易隨著時間的推移處理任務的不同方面。
訊息佇列已存在很長時間,因此有多種選擇可供選擇:流行的開源替代品包括Apache Kafka,AMQP Broker(如RabbitMQ或HornetQ)和雲提供商版本(如AWS SQS或Kinesis,Google PubSub或Azure Service Bus)。
優點
簡單地解耦傳送方和接收方是一個強有力的概念,它使許多其他概念,如健康檢查,路由,端點發現或負載平衡變得不必要。例項可以在緩衝佇列準備好的時候從緩衝佇列中選擇相關任務。當自動編排和擴充套件決策基於每個佇列中的訊息計數時,這變得尤其強大,從而導致高度資源有效的系統。
缺點
訊息佇列不擅長請求/響應通訊。有些人認為這可以在現有概念的基礎上進行,但實際上並非如此。由於它們的緩衝特性,它們還可以為系統增加顯著的延遲。它們也相當集中單點風險(雖然可以橫向擴充套件),並且在大規模執行時成本非常高。
選擇哪個?
API閘道器是公共面向API的前端;服務網格可處理服務間通訊(同步);使用訊息佇列進行非同步任務排程。
但是,如果我們將重點僅僅放在服務間通訊上,那麼可能的答案可能是:
- 如果您已經為面向公眾的API執行API閘道器,那麼您可能還要保持較低的複雜性並將其重用於服務間通訊
- 如果您在一個擁有孤立團隊和溝通不暢的大型組織內工作,服務網路可以為您提供最高程度的獨立性,從而可以輕鬆地隨著時間的推移新增新服務。
- 如果您正在設計一個系統,其中各個步驟隨著時間的推移而間隔開來,例如,像上傳,處理和釋出影片的服務這樣的youtube可能需要幾分鐘,請使用訊息或任務佇列。
(banq注:服務閘道器是屬於複雜的基礎設施,可實現服務之間直接同步呼叫,如同在一個機器內部呼叫一樣,雖然使用起來很方便,但是網路不是百分百可靠,雖然有複雜監控。請放棄RPC!分散式程式設計第一謊言:網路是可靠的 - David Boike)
相關文章
- 服務網格 Service Mesh
- 容器、服務網格和API閘道器:它始於邊緣API
- 服務網格service mesh 之 Linkerd
- 訊息佇列之JMS和AMQP對比佇列MQ
- 為什麼要使用服務網格Service Mesh?
- 螞蟻金服 Service Mesh 大規模落地系列 - 閘道器篇
- 訊息佇列的作用以及kafka和activemq的對比佇列KafkaMQ
- Service Mesh大咖訪談:使用服務網格的微服務通訊與治理微服務
- 閘道器服務:zuul與nginx的效能測試對比ZuulNginx
- 快速上手 Linkerd v2 Service Mesh(服務網格)
- 為什麼我們需要服務網格Service mesh?
- RabbitMQ,RocketMQ,Kafka 幾種訊息佇列的對比MQKafka佇列
- 深入Java微服務之閘道器係列2:常見Java閘道器實現方案對比Java微服務
- MQ 訊息佇列 比較MQ佇列
- Emoji.voto,Linkerd 服務網格(service mesh)的示例應用程式
- 服務網格入門從閘道器開始 - Christian Posta
- SpringCloud系列之API閘道器(Gateway)服務ZuulSpringGCCloudAPIGatewayZuul
- 訊息佇列之事務訊息,RocketMQ 和 Kafka 是如何做的?佇列MQKafka
- 最新出爐!開源 API 閘道器的效能對比:APISIX 3.0 和 Kong 3.0API
- 在企業組織中採用服務網格的挑戰:從API閘道器到微服務通訊逐步引入 – Christian PostaAPI微服務
- win10 訊息佇列服務怎麼開啟_win10怎麼新增訊息佇列Win10佇列
- 服務閘道器過濾器過濾器
- springcloud服務閘道器-gatewaySpringGCCloudGateway
- 高效能API閘道器(1)、微服務API閘道器架構設計API微服務架構
- hystrix對比服務網格istio的destinationrule
- Spring Cloud Zuul API服務閘道器之請求路由SpringCloudZuulAPI路由
- 訊息佇列系列一:訊息佇列應用佇列
- 訊息佇列MQ應用場景及主流框架對比佇列MQ框架
- .net core自定義高效能的Web API服務閘道器WebAPI
- 淺談服務閘道器和聯邦雲
- 訊息佇列佇列
- 微服務(七)Gateway服務閘道器微服務Gateway
- Ocelot整合Consul實現api閘道器與服務發現API
- Spring Cloud入門教程(五):API服務閘道器(Zuul) 上SpringCloudAPIZuul
- RestCloud API閘道器,輕量級ESB服務匯流排RESTCloudAPI
- 構建SpringCloud閘道器服務SpringGCCloud
- Service Mesh框架對比:Linkerd vs. Istio框架
- 訊息佇列 RocketMQ 5.0:從訊息服務到雲原生事件流平臺佇列MQ事件