服務(wù)網(wǎng)格如何幫助管理分布式微服務(wù)

作者：Josh Fruhlinger 2019-07-18 12:41:52

服務(wù)器

服務(wù)器產(chǎn)品

分布式 IT在數(shù)字化轉(zhuǎn)型趨勢下發(fā)生的變化之一是將大型單片應(yīng)用程序分解為微服務(wù)，這些小型的、離散的功能單元在容器中運(yùn)行，其軟件包包括服務(wù)所有代碼，并可以被隔離，輕松地從一個服務(wù)器移動到另一個服務(wù)器。

服務(wù)網(wǎng)格(Service Mesh)為服務(wù)通信帶來了安全性、彈性、可見性，因此使開發(fā)人員不必做這些。

IT在數(shù)字化轉(zhuǎn)型趨勢下發(fā)生的變化之一是將大型單片應(yīng)用程序分解為微服務(wù)，這些小型的、離散的功能單元在容器中運(yùn)行，其軟件包包括服務(wù)所有代碼，并可以被隔離，輕松地從一個服務(wù)器移動到另一個服務(wù)器。

像這樣的容器化架構(gòu)很容易在云中進(jìn)行擴(kuò)展和運(yùn)行，并且可以快速部署和迭代各個微服務(wù)。然而，隨著應(yīng)用程序的規(guī)模變得越來越大，同一服務(wù)的多個實例同時運(yùn)行，這些微服務(wù)之間的通信變得越來越復(fù)雜。服務(wù)網(wǎng)格是一種新興的架構(gòu)形式，旨在以減少管理和編程開銷的方式動態(tài)連接這些微服務(wù)。

什么是服務(wù)網(wǎng)格?

從廣泛的意義上講，“服務(wù)網(wǎng)格”正如Red Hat公司所描述的那樣，“服務(wù)網(wǎng)格是一種控制應(yīng)用程序的不同部分如何共享數(shù)據(jù)的方法?！?/p>

不過這個描述可能包含很多不同的東西。事實上，它聽起來很像大多數(shù)開發(fā)人員所熟悉的來自客戶端-服務(wù)器應(yīng)用程序的中間件。

服務(wù)網(wǎng)格的獨(dú)特之處在于，它是為適應(yīng)分布式微服務(wù)環(huán)境的獨(dú)特性質(zhì)而構(gòu)建的。在由微服務(wù)構(gòu)建的大型應(yīng)用程序中，可能存在給定服務(wù)的多個實例，它們運(yùn)行在不同的本地或云計算服務(wù)器上。顯然，所有這些移動部件都使得單個微服務(wù)很難找到他們需要與之通信的其他服務(wù)。服務(wù)網(wǎng)格會自動處理即時發(fā)現(xiàn)和連接服務(wù)，這樣開發(fā)人員和微服務(wù)都不必這樣做。

將服務(wù)網(wǎng)格視為開放式系統(tǒng)互聯(lián)(OSI)網(wǎng)絡(luò)模型的第7級軟件定義網(wǎng)絡(luò)(SDN)的等效物。正如軟件定義網(wǎng)絡(luò)(SDN)創(chuàng)建一個抽象層，因此網(wǎng)絡(luò)管理員不必處理物理網(wǎng)絡(luò)連接，服務(wù)網(wǎng)格將應(yīng)用程序的底層基礎(chǔ)結(jié)構(gòu)與企業(yè)交互的抽象體系結(jié)構(gòu)分離。

隨著開發(fā)人員開始努力解決真正龐大的分布式架構(gòu)的問題，服務(wù)網(wǎng)格的概念出現(xiàn)了。 Linkerd是該領(lǐng)域的第一個項目，誕生于Twitter內(nèi)部項目的分支。Istio是另一個受歡迎的服務(wù)網(wǎng)絡(luò)，擁有主要的企業(yè)支持，起源于Lyft。

服務(wù)網(wǎng)格負(fù)載平衡

服務(wù)網(wǎng)格提供的一個關(guān)鍵特性是負(fù)載平衡。人們通常將負(fù)載均衡視為網(wǎng)絡(luò)功能，企業(yè)希望防止任何一個服務(wù)器或網(wǎng)絡(luò)鏈路被流量淹沒，因此可以相應(yīng)地路由其數(shù)據(jù)包。正如Twain Taylor所描述的那樣，服務(wù)網(wǎng)格在應(yīng)用程序級別上做了類似的事情，理解這一點(diǎn)可以讓人們很好地理解服務(wù)網(wǎng)格就像是應(yīng)用程序?qū)拥能浖x的網(wǎng)絡(luò)。

本質(zhì)上，服務(wù)網(wǎng)格的一個工作是跟蹤分布在基礎(chǔ)設(shè)施上的各種微服務(wù)的哪些實例是“最健康的”。它可能會輪詢以查看它們是如何做的，或跟蹤哪些實例響應(yīng)緩慢服務(wù)請求，并將后續(xù)請求發(fā)送到其他實例。服務(wù)網(wǎng)格可以為網(wǎng)絡(luò)路由執(zhí)行類似的工作，注意到消息需要很長時間才能到達(dá)目的地，并采取其他路由進(jìn)行補(bǔ)償。這些速度慢的原因可能是底層硬件的問題，或者僅僅是服務(wù)被請求超載。重要的是，服務(wù)網(wǎng)格可以找到相同服務(wù)的另一個實例，并將其路由到該實例，從而最有效地利用整個應(yīng)用程序的容量。

服務(wù)網(wǎng)格與Kubernetes

如果人們對基于容器的架構(gòu)有些了解，那么可能想知道Kubernetes(流行的開源容器編排平臺)適合這種情況。畢竟，Kubernetes管理容器之間如何通信不是其全部要點(diǎn)嗎?正如Kublr公司在其企業(yè)博客上指出的那樣，可以將Kubernetes的服務(wù)資源視為一種非?；镜姆?wù)網(wǎng)絡(luò)，因為它提供服務(wù)發(fā)現(xiàn)和循環(huán)請求平衡。但是功能齊全的服務(wù)網(wǎng)格提供了更多功能，如管理安全策略和加密，“線路中斷”以暫停對慢響應(yīng)實例的請求。

人們需要了解的是，大多數(shù)服務(wù)網(wǎng)格確實需要像Kubernetes這樣的編排系統(tǒng)。服務(wù)網(wǎng)格提供擴(kuò)展功能，而不是替代功能。

服務(wù)網(wǎng)格與API網(wǎng)關(guān)

每個微服務(wù)都將提供一個應(yīng)用程序編程接口(API)，作為其他服務(wù)與之通信的手段。這引發(fā)了服務(wù)網(wǎng)格與其他更傳統(tǒng)的API管理形式(如API網(wǎng)關(guān))之間的差異問題。正如IBM公司解釋的那樣，API網(wǎng)關(guān)位于一組微服務(wù)和外部世界之間，根據(jù)需要路由服務(wù)請求，以便請求者不需要知道它正在處理基于微服務(wù)的應(yīng)用程序。另一方面，服務(wù)網(wǎng)格調(diào)解微服務(wù)應(yīng)用程序內(nèi)部的請求，并需要用戶完全了解其環(huán)境。

正如Justin Warren所指出的那樣，另一種思考方式是服務(wù)網(wǎng)格用于集群內(nèi)的東西向流量，而API網(wǎng)關(guān)用于進(jìn)出集群的南北流量。但服務(wù)網(wǎng)格的想法仍處于早期階段，并且不斷變化。許多服務(wù)網(wǎng)格(包括Linkerd和Istio)現(xiàn)在也提供南北向流量功能。

服務(wù)網(wǎng)格架構(gòu)

服務(wù)網(wǎng)格的概念最近幾年才出現(xiàn)，并且有許多不同的方法來解決“服務(wù)網(wǎng)格”問題，即管理微服務(wù)的通信。Aspen Mesh公司的Andrew Jenkins確定了三種可能的選擇，即服務(wù)網(wǎng)格創(chuàng)建的通信層可能存在的位置：

• 在每個微服務(wù)導(dǎo)入的庫中。
• 在為特定節(jié)點(diǎn)上的所有容器提供服務(wù)的節(jié)點(diǎn)代理程序中。
• 在與應(yīng)用程序容器一起運(yùn)行的Sidecar容器中。

Sidecar是將應(yīng)用程序的組件部署到單獨(dú)的進(jìn)程或容器中,以提供隔離和封裝。基于Sidecar的模式是最流行的服務(wù)網(wǎng)格模式之一，以至于它在某些方面通常成為服務(wù)網(wǎng)格的同義詞。雖然這并非嚴(yán)格，但是Sidecar容器方法已經(jīng)引起了很大的關(guān)注，這是人們需要仔細(xì)研究的架構(gòu)。

服務(wù)網(wǎng)格中的Sidecars

“Sidecars容器與其應(yīng)用容器一起運(yùn)行”是什么?Red Hat公司對此給出一個很好的解釋。這種類型的服務(wù)網(wǎng)格中的每個微服務(wù)容器都有另一個與之對應(yīng)的代理容器。服務(wù)到服務(wù)通信所需的所有邏輯都從微服務(wù)中抽象出來并放入Sidecars中。

這可能看起來很復(fù)雜，畢竟，企業(yè)的應(yīng)用程序中容器的數(shù)量實際上增加了一倍。但也在使用一種設(shè)計模式，這是簡化分布式應(yīng)用程序的關(guān)鍵。通過將所有的網(wǎng)絡(luò)和通信代碼放在一個單獨(dú)的容器中，已經(jīng)將其作為基礎(chǔ)設(shè)施的一部分，并使開發(fā)人員不再將其作為應(yīng)用程序的一部分來實現(xiàn)。

從本質(zhì)上講，剩下的是可以聚焦于其業(yè)務(wù)邏輯的微服務(wù)。微服務(wù)不需要知道如何在復(fù)雜的環(huán)境中與其他所有服務(wù)進(jìn)行通信。它只需要知道如何與Sidecars溝通，而Sidecars則負(fù)責(zé)處理其余的事情。

服務(wù)網(wǎng)格：Linkerd、Envio、Istio、Consul

那么有哪些可用的服務(wù)網(wǎng)格?沒有現(xiàn)成的商業(yè)產(chǎn)品。大多數(shù)服務(wù)網(wǎng)格都是開放源碼項目，需要進(jìn)行一些最終的實現(xiàn)。一些比較知名的產(chǎn)品是：

• Linkerd——于2016年發(fā)布，因此是最早的產(chǎn)品，Linkerd從Twitter開發(fā)的圖書館中分離出來。這個領(lǐng)域的另一位主要的產(chǎn)品，即Conduit，已經(jīng)進(jìn)入了Linkerd項目，并構(gòu)成了Linkerd 2.0的基礎(chǔ)。
• Envio——在Lyft創(chuàng)建，Envoy占據(jù)服務(wù)網(wǎng)格的“數(shù)據(jù)平臺”部分。要提供全服務(wù)網(wǎng)格，需要與“控制平臺” 配對。
• Istio——由Lyft、IBM、Google合作開發(fā)，Istio是一項服務(wù)代理的服務(wù)計劃，如Envoy。雖然Istio和Envoy是默認(rèn)的配對，但每個都可以與其他平臺配對。
• HashiCorp Consul——與Consul 1.2一起推出，這項名為Connect的功能為HashiCorp的分布式系統(tǒng)添加了服務(wù)加密和基于身份的授權(quán)，用于服務(wù)發(fā)現(xiàn)和配置，將其轉(zhuǎn)??變?yōu)橐粋€完整的服務(wù)網(wǎng)格。

那么更適合采用哪種服務(wù)網(wǎng)格?很難進(jìn)行比較，但這些產(chǎn)品都已在大型且苛刻的環(huán)境中得到驗證。Linkerd和Istio擁有廣泛的功能集，但都在迅速發(fā)展。

另外請記住，新的競爭對手可能隨時出現(xiàn)在市場中。例如，在2018年11月，亞馬遜公司開始提供AWS服務(wù)網(wǎng)格的公開預(yù)覽?？紤]到大量用戶采用亞馬遜的公共云，因此AWS App Mesh的推出應(yīng)該會產(chǎn)生重大影響。

文章名稱：服務(wù)網(wǎng)格如何幫助管理分布式微服務(wù)
文章轉(zhuǎn)載：http://www.5511xx.com/article/cdsiccp.html