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

牟定ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

---

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

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

什么是Service mesh？

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

Service mesh也有其獨特之處：它能夠適應(yīng)分布式微服務(wù)環(huán)境的獨特性質(zhì)。在搭建在微服務(wù)中的大規(guī)模應(yīng)用程序中，有許多既定的服務(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)中的與你交互的應(yīng)用程序的底層基礎(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負(fù)載均衡

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

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

Service mesh vs Kubernetes

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

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

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ù)的應(yīng)用程序即可完成請求。而service mesh調(diào)解微服務(wù)應(yīng)用程序內(nèi)部的請求，各種組件完全了解其環(huán)境。

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

Service mesh 架構(gòu)

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

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

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

• 與應(yīng)用程序容器一起運行的sidecar容器

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

Sidecar

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

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

本質(zhì)上，你所留下的是一個聚焦于業(yè)務(wù)邏輯的微服務(wù)。這個微服務(wù)不需要知道如何在其運行的環(huán)境中與所有其他服務(wù)進(jìn)行通信。它只需要知道如何與sidecar進(jìn)行通信即可，剩下的將由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)進(jìn)入了Linkerd項目并構(gòu)成了Linkerd 2.0的基礎(chǔ)。

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

• Istio：由Lyft、IBM與google聯(lián)合開發(fā)，Istio可以在不修改微服務(wù)源代碼的情況下，輕松為其加上如負(fù)載均衡、身份驗證等功能，它可以通過控制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適合你？如果要進(jìn)行一個全面的比較的話，超出了本文所涉及的范圍。但上述的所有產(chǎn)品都已經(jīng)在大型且嚴(yán)苛的環(huán)境中得到驗證。目前，Linkerd和Istio包含最豐富的功能集，但一切都還在迅速發(fā)展中，現(xiàn)在下定論還為時過早。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

名稱欄目：全方位詳解ServiceMesh（服務(wù)網(wǎng)格）-創(chuàng)新互聯(lián)
分享路徑：http://www.sd-ha.com/article10/dojhdo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、微信小程序、品牌網(wǎng)站建設(shè)、網(wǎng)站制作、定制網(wǎng)站、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)