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

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

服務(wù)器

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

每個(gè)微服務(wù)都將提供一個(gè)應(yīng)用程序編程接口(API)，作為其他服務(wù)與之通信的手段。這引發(fā)了服務(wù)網(wǎng)格與其他更傳統(tǒng)的API管理形式(如API網(wǎng)關(guān))之間的差異問(wèn)題。正如IBM公司解釋的那樣，API網(wǎng)關(guān)位于一組微服務(wù)和外部世界之間，根據(jù)需要路由服務(wù)請(qǐng)求，以便請(qǐng)求者不需要知道它正在處理基于微服務(wù)的應(yīng)用程序。另一方面，服務(wù)網(wǎng)格調(diào)解微服務(wù)應(yīng)用程序內(nèi)部的請(qǐng)求，并需要用戶(hù)完全了解其環(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)，并且有許多不同的方法來(lái)解決“服務(wù)網(wǎng)格”問(wèn)題，即管理微服務(wù)的通信。Aspen Mesh公司的Andrew Jenkins確定了三種可能的選擇，即服務(wù)網(wǎng)格創(chuàng)建的通信層可能存在的位置：

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

Sidecar是將應(yīng)用程序的組件部署到單獨(dú)的進(jìn)程或容器中,以提供隔離和封裝?；赟idecar的模式是最流行的服務(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公司對(duì)此給出一個(gè)很好的解釋。這種類(lèi)型的服務(wù)網(wǎng)格中的每個(gè)微服務(wù)容器都有另一個(gè)與之對(duì)應(yīng)的代理容器。服務(wù)到服務(wù)通信所需的所有邏輯都從微服務(wù)中抽象出來(lái)并放入Sidecars中。

這可能看起來(lái)很復(fù)雜，畢竟，企業(yè)的應(yīng)用程序中容器的數(shù)量實(shí)際上增加了一倍。但也在使用一種設(shè)計(jì)模式，這是簡(jiǎn)化分布式應(yīng)用程序的關(guān)鍵。通過(guò)將所有的網(wǎng)絡(luò)和通信代碼放在一個(gè)單獨(dú)的容器中，已經(jīng)將其作為基礎(chǔ)設(shè)施的一部分，并使開(kāi)發(fā)人員不再將其作為應(yīng)用程序的一部分來(lái)實(shí)現(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)格?沒(méi)有現(xiàn)成的商業(yè)產(chǎn)品。大多數(shù)服務(wù)網(wǎng)格都是開(kāi)放源碼項(xiàng)目，需要進(jìn)行一些最終的實(shí)現(xiàn)。一些比較知名的產(chǎn)品是：

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

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

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

標(biāo)題名稱(chēng)：服務(wù)網(wǎng)格如何幫助管理分布式微服務(wù)
當(dāng)前路徑：http://www.dlmjj.cn/article/cdsiccp.html