溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
Service mesh是近幾年才出現的一個新興概念。它可以解決微服務之間通信愈發復雜的問題。那么什么是Service mesh？它有什么具體的功能？它的架構又是如何的呢？它與Kubernetes的關系是怎樣的？所有答案戳文了解！
在數字化轉型的旗幟下，IT界的一大變化是大型單體應用程序被分解為微服務架構，即小型、離散的功能單元，并且這些應用程序在容器中運行。包含所有服務代碼以及依賴項的軟件包被隔離起來，并且能輕松從一個服務器遷移到另一個。
像這樣的容器化架構很容易在云中擴展和運行，并且能夠快速迭代和推出每個微服務。然而，當應用程序越來越大并且在同一個服務上同時運行多個實例時，微服務之間通信將會變得愈發復雜。Service mesh的出現將解決這一問題，它是一個新興的架構形式，旨在以減少管理和編程開銷的形式來連接這些微服務。
關于Service mesh的定義，最為廣泛接受的觀點是：它是一種控制應用程序不同部分彼此共享數據的方式。這一描述包含了service mesh的方方面面。事實上，它聽起來更像是大多數開發人員從客戶端-服務器應用程序中熟悉的中間件。
Service mesh也有其獨特之處：它能夠適應分布式微服務環境的獨特性質。在搭建在微服務中的大規模應用程序中，有許多既定的服務實例，它們跨本地和云服務器運行。所有這些移動部件顯然使得各個微服務難以找到他們需要與之通信的其他服務。Service mesh可以在短時間內自動處理發現和連接服務，而無需開發人員以及各個微服務自行匹配。
我們可以將service mesh等同為軟件定義網絡（SDN）的OSI網絡模型第7層。正如SDN創建一個抽象層后網絡管理員不必處理物理網絡連接，service mesh將解耦在抽象架構中的與你交互的應用程序的底層基礎架構。
隨著開發人員開始努力解決真正龐大的分布式架構的問題，service mesh的概念適時地出現了。這一領域的第一個項目是Linkerd，它一開始是Twitter內部項目的一個分支。Istio是另一個十分流行的service mesh項目，它起源于Lyft，現在這一項目獲得了許多企業的支持。
Service mesh其中一個關鍵功能是負載均衡。我們常常將負載均衡視為網絡功能——你想要防止服務器或網絡鏈接被流量淹沒，因此相應地你會路由你的數據包，而Service mesh在應用程序層面也在執行類似的事情。
本質上，Service mesh的工作之一是跟蹤分布在基礎設施上的各種微服務的哪些實例是“最健康的”。它可能對他們進行調查來查看它們如何工作的或跟蹤哪些實例對服務請求響應緩慢并將后續請求發送到其他實例。此外，service mesh也會為網絡路由做類似的工作，如果發現當消息需要很長時間才能送達，那么service mesh將會采用其他路由進行補償。這些減速可能是由于底層硬件出現問題，或者僅僅是由于服務因請求過載或處理能力不足導致的。但沒有關系，service mesh會找到另一個相同服務的實例，然后將其路由以替代響應緩慢的實例，高效利用了整個應用程序的資源。
如果你稍微熟悉基于容器的架構，你可能會想Kubernetes這個流行的開源容器編排平臺能否適合這種情況。畢竟，Kubernetes不就是管理著你的容器之間如何互相通信的嗎？你可將Kubernetes“服務”資源視為非常基礎的service mesh，因為它提供服務發現和請求的輪詢調度均衡。但是完整的service mesh則提供更豐富的功能，如管理安全策略和加密、“斷路”以暫停對緩慢響應的實例的請求以及如上所述的負載均衡等。
請記住，大多數service mesh確實需要像Kubernetes這樣的編排系統。Service mesh只是提供擴展功能，而非替代編排平臺。
每個微服務都會提供一個API，它會作為其他服務與其通信的手段。這引發了service mesh與其他更傳統的API管理形式（如API網關）之間的差異問題。API網關位于一組微服務和“外部”世界之間，它根據需要路由服務請求，以便請求者不需要知道它正在處理基于微服務的應用程序即可完成請求。而service mesh調解微服務應用程序內部的請求，各種組件完全了解其環境。
另一方面，service mesh用于優化集群內東西流量（server-server流量），API網關用于進出集群的南北流量（server-client流量）。但service mesh目前依舊處于早期階段還在不斷發展變化中。許多service mesh（包括Linkerd和Istio）現在已經可以提供南北功能。
Service mesh這一概念其實出現的時間并不長，并且已經有相當數量的不同的方法來解決“service mesh”的問題，如管理微服務通信。目前，確定了三種service mesh創建的通信層可能存在的位置：
每個微服務導入的library
在特定節點提供服務給所有容器的節點agent
基于sidecar的模式目前是service mesh最受歡迎的模式之一，以至于它在某種程度上已經成為了service mesh的代名詞。盡管這種說法并不嚴謹，但是sidecar已經引起了很大的關注，我們將在下文更詳細地研究這一架構。
Sidecar容器與你的應用程序容器一起運行意味著什么呢？在這類service mesh中每個微服務容器都有另一個proxy容器與之相對應。所有的服務間通信的需求都會被抽象出微服務之外并且放入sidecar。
這似乎很復雜，畢竟你有效地將應用程序中的容器數量增加了1倍。但你使用的這一種設計模式對于簡化分布式應用程序至關重要。通過將所有的網絡和通信代碼放到單獨的容器中，將其作為基礎架構的一部分，并使開發人員無需將其作為應用程序的一部分實現。
本質上，你所留下的是一個聚焦于業務邏輯的微服務。這個微服務不需要知道如何在其運行的環境中與所有其他服務進行通信。它只需要知道如何與sidecar進行通信即可，剩下的將由sidecar完成。
那么說了這么多，什么是可用的service mesh呢？目前，這一領域還沒有出現完全現成的商業產品。大部分的service mesh只是開源項目，需要通過一定的操作步驟才能實現，現在比較知名的項目有：
Envoy：由Lyft創建，為了能夠提供完整的service mesh功能，Envoy占據“數據平面”的部分，與其進行匹配。
哪個service mesh適合你？如果要進行一個全面的比較的話，超出了本文所涉及的范圍。但上述的所有產品都已經在大型且嚴苛的環境中得到驗證。目前，Linkerd和Istio包含最豐富的功能集，但一切都還在迅速發展中，現在下定論還為時過早。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
