全方位詳解Service Mesh（服務(wù)網(wǎng)格）

Service mesh是近幾年才出現(xiàn)的一個新興概念。它可以解決微服務(wù)之間通信愈發(fā)復雜的問題。那么什么是Service mesh？它有什么具體的功能？它的架構(gòu)又是如何的呢？它與Kubernetes的關(guān)系是怎樣的？所有答案戳文了解！
 

 

 
在數(shù)字化轉(zhuǎn)型的旗幟下，IT界的一大變化是大型單體應用程序被分解為微服務(wù)架構(gòu)，即小型、離散的功能單元，并且這些應用程序在容器中運行。包含所有服務(wù)代碼以及依賴項的軟件包被隔離起來，并且能輕松從一個服務(wù)器遷移到另一個。
 

像這樣的容器化架構(gòu)很容易在云中擴展和運行，并且能夠快速迭代和推出每個微服務(wù)。然而，當應用程序越來越大并且在同一個服務(wù)上同時運行多個實例時，微服務(wù)之間通信將會變得愈發(fā)復雜。Service mesh的出現(xiàn)將解決這一問題，它是一個新興的架構(gòu)形式，旨在以減少管理和編程開銷的形式來連接這些微服務(wù)。

什么是Service mesh？

關(guān)于Service mesh的定義，最為廣泛接受的觀點是：它是一種控制應用程序不同部分彼此共享數(shù)據(jù)的方式。這一描述包含了service mesh的方方面面。事實上，它聽起來更像是大多數(shù)開發(fā)人員從客戶端-服務(wù)器應用程序中熟悉的中間件。

Service mesh也有其獨特之處：它能夠適應分布式微服務(wù)環(huán)境的獨特性質(zhì)。在搭建在微服務(wù)中的大規(guī)模應用程序中，有許多既定的服務(wù)實例，它們跨本地和云服務(wù)器運行。所有這些移動部件顯然使得各個微服務(wù)難以找到他們需要與之通信的其他服務(wù)。Service mesh可以在短時間內(nèi)自動處理發(fā)現(xiàn)和連接服務(wù)，而無需開發(fā)人員以及各個微服務(wù)自行匹配。

我們可以將service mesh等同為軟件定義網(wǎng)絡(luò)（SDN）的OSI網(wǎng)絡(luò)模型第7層。正如SDN創(chuàng)建一個抽象層后網(wǎng)絡(luò)管理員不必處理物理網(wǎng)絡(luò)連接，service mesh將解耦在抽象架構(gòu)中的與你交互的應用程序的底層基礎(chǔ)架構(gòu)。
 

隨著開發(fā)人員開始努力解決真正龐大的分布式架構(gòu)的問題，service mesh的概念適時地出現(xiàn)了。這一領(lǐng)域的第一個項目是Linkerd，它一開始是Twitter內(nèi)部項目的一個分支。Istio是另一個十分流行的service mesh項目，它起源于Lyft，現(xiàn)在這一項目獲得了許多企業(yè)的支持。

Service mesh負載均衡

Service mesh其中一個關(guān)鍵功能是負載均衡。我們常常將負載均衡視為網(wǎng)絡(luò)功能——你想要防止服務(wù)器或網(wǎng)絡(luò)鏈接被流量淹沒，因此相應地你會路由你的數(shù)據(jù)包，而Service mesh在應用程序?qū)用嬉苍趫?zhí)行類似的事情。
 

本質(zhì)上，Service mesh的工作之一是跟蹤分布在基礎(chǔ)設(shè)施上的各種微服務(wù)的哪些實例是“最健康的”。它可能對他們進行調(diào)查來查看它們?nèi)绾喂ぷ鞯幕蚋櫮男嵗龑Ψ?wù)請求響應緩慢并將后續(xù)請求發(fā)送到其他實例。此外，service mesh也會為網(wǎng)絡(luò)路由做類似的工作，如果發(fā)現(xiàn)當消息需要很長時間才能送達，那么service mesh將會采用其他路由進行補償。這些減速可能是由于底層硬件出現(xiàn)問題，或者僅僅是由于服務(wù)因請求過載或處理能力不足導致的。但沒有關(guān)系，service mesh會找到另一個相同服務(wù)的實例，然后將其路由以替代響應緩慢的實例，高效利用了整個應用程序的資源。

Service mesh vs Kubernetes

如果你稍微熟悉基于容器的架構(gòu)，你可能會想Kubernetes這個流行的開源容器編排平臺能否適合這種情況。畢竟，Kubernetes不就是管理著你的容器之間如何互相通信的嗎？你可將Kubernetes“服務(wù)”資源視為非?；A(chǔ)的service mesh，因為它提供服務(wù)發(fā)現(xiàn)和請求的輪詢調(diào)度均衡。但是完整的service mesh則提供更豐富的功能，如管理安全策略和加密、“斷路”以暫停對緩慢響應的實例的請求以及如上所述的負載均衡等。
 

請記住，大多數(shù)service mesh確實需要像Kubernetes這樣的編排系統(tǒng)。Service mesh只是提供擴展功能，而非替代編排平臺。

Service mesh vs API 網(wǎng)關(guān)

每個微服務(wù)都會提供一個API，它會作為其他服務(wù)與其通信的手段。這引發(fā)了service mesh與其他更傳統(tǒng)的API管理形式（如API網(wǎng)關(guān)）之間的差異問題。API網(wǎng)關(guān)位于一組微服務(wù)和“外部”世界之間，它根據(jù)需要路由服務(wù)請求，以便請求者不需要知道它正在處理基于微服務(wù)的應用程序即可完成請求。而service mesh調(diào)解微服務(wù)應用程序內(nèi)部的請求，各種組件完全了解其環(huán)境。

另一方面，service mesh用于優(yōu)化集群內(nèi)東西流量（server-server流量），API網(wǎng)關(guān)用于進出集群的南北流量（server-client流量）。但service mesh目前依舊處于早期階段還在不斷發(fā)展變化中。許多service mesh（包括Linkerd和Istio）現(xiàn)在已經(jīng)可以提供南北功能。

Service mesh 架構(gòu)

Service mesh這一概念其實出現(xiàn)的時間并不長，并且已經(jīng)有相當數(shù)量的不同的方法來解決“service mesh”的問題，如管理微服務(wù)通信。目前，確定了三種service mesh創(chuàng)建的通信層可能存在的位置：

• 每個微服務(wù)導入的library

• 在特定節(jié)點提供服務(wù)給所有容器的節(jié)點agent

• 與應用程序容器一起運行的sidecar容器

基于sidecar的模式目前是service mesh最受歡迎的模式之一，以至于它在某種程度上已經(jīng)成為了service mesh的代名詞。盡管這種說法并不嚴謹，但是sidecar已經(jīng)引起了很大的關(guān)注，我們將在下文更詳細地研究這一架構(gòu)。
 

 

Sidecar

 
Sidecar容器與你的應用程序容器一起運行意味著什么呢？在這類service mesh中每個微服務(wù)容器都有另一個proxy容器與之相對應。所有的服務(wù)間通信的需求都會被抽象出微服務(wù)之外并且放入sidecar。

 
這似乎很復雜，畢竟你有效地將應用程序中的容器數(shù)量增加了1倍。但你使用的這一種設(shè)計模式對于簡化分布式應用程序至關(guān)重要。通過將所有的網(wǎng)絡(luò)和通信代碼放到單獨的容器中，將其作為基礎(chǔ)架構(gòu)的一部分，并使開發(fā)人員無需將其作為應用程序的一部分實現(xiàn)。

本質(zhì)上，你所留下的是一個聚焦于業(yè)務(wù)邏輯的微服務(wù)。這個微服務(wù)不需要知道如何在其運行的環(huán)境中與所有其他服務(wù)進行通信。它只需要知道如何與sidecar進行通信即可，剩下的將由sidecar完成。

Service mesh明星項目：Linkerd、Envio、Istio、Consul

那么說了這么多，什么是可用的service mesh呢？目前，這一領(lǐng)域還沒有出現(xiàn)完全現(xiàn)成的商業(yè)產(chǎn)品。大部分的service mesh只是開源項目，需要通過一定的操作步驟才能實現(xiàn)，現(xiàn)在比較知名的項目有：
 

• Linkerd：2016年發(fā)布，是這些項目中最老的。Linkerd是從Twitter開發(fā)的library中分離出來的。在這一領(lǐng)域另一位重量型選手，Conduit，已經(jīng)進入了Linkerd項目并構(gòu)成了Linkerd 2.0的基礎(chǔ)。

• Envoy：由Lyft創(chuàng)建，為了能夠提供完整的service mesh功能，Envoy占據(jù)“數(shù)據(jù)平面”的部分，與其進行匹配。
   

• Istio：由Lyft、IBM與google聯(lián)合開發(fā)，Istio可以在不修改微服務(wù)源代碼的情況下，輕松為其加上如負載均衡、身份驗證等功能，它可以通過控制Envoy等代理服務(wù)來控制所有的流量。此外，Istio提供容錯、金絲雀部署、A/B測試、監(jiān)控等功能，并且支持自定義的組件和集成。
  Rancher 2.3 Preview2版本上開始支持Istio，用戶可以直接在UI界面中啟動Istio并且可以為每個命名空間注入自動sidecar。Rancher內(nèi)置了一個支持Kiali的儀表盤，簡化Istio的安裝和配置。這一切讓部署和管理Istio變得簡單而快速。

• HashiCorp Consul：與Consul 1.2一起推出了一項名為Connect的功能，為HashiCorp的分布式系統(tǒng)添加了服務(wù)加密和基于身份的授權(quán)，可用于服務(wù)發(fā)現(xiàn)和配置。

哪個service mesh適合你？如果要進行一個全面的比較的話，超出了本文所涉及的范圍。但上述的所有產(chǎn)品都已經(jīng)在大型且嚴苛的環(huán)境中得到驗證。目前，Linkerd和Istio包含最豐富的功能集，但一切都還在迅速發(fā)展中，現(xiàn)在下定論還為時過早。