ServiceMesh模式是怎么來的

本篇內(nèi)容主要講解“Service Mesh模式是怎么來的”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Service Mesh模式是怎么來的”吧!

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比上蔡網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式上蔡網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋上蔡地區(qū)。費(fèi)用合理售后完善，十年實(shí)體公司更值得信賴。

分布式系統(tǒng)幫助我們解決了很多過去甚至無法思考的用例，但同時也帶來了諸多新的問題。

當(dāng)系統(tǒng)規(guī)模較小、架構(gòu)較簡單時，開發(fā)者通過減少遠(yuǎn)程交互數(shù)量來降低額外的復(fù)雜性。像處理分發(fā)的最安全方法是盡可能避免它，即使這意味著產(chǎn)生跨系統(tǒng)的重復(fù)邏輯和數(shù)據(jù)。

但現(xiàn)實(shí)情況是，從開始的幾臺大型中央計算機(jī)，到如今成百上千個小型服務(wù)，行業(yè)反戰(zhàn)的需求要求我們不得不作出突破。我們需要走出困境，解決不斷涌現(xiàn)的新挑戰(zhàn)和懸而未決的問題，先采取個案處理的臨時解決辦法，再用更復(fù)雜的辦法來應(yīng)對。但我們不斷的解決問題、設(shè)計出更好的解決方案，解決那些最常見需求的模式、庫和平臺隨之出現(xiàn)。

計算機(jī)的聯(lián)網(wǎng)

起初，人們想要實(shí)現(xiàn)兩臺或多臺電腦之間的交互：

為最終用戶完成某個目標(biāo)的服務(wù)對話。這顯然是一個過于簡化的視圖，因?yàn)樵诖a操作的字節(jié)和通過電線發(fā)送和接收的電信號之間轉(zhuǎn)換的許多層都丟失了。但是，抽象概念對于我們的討論是足夠的。讓我們通過將網(wǎng)絡(luò)堆棧顯示為一個不同的組件來添加更多的細(xì)節(jié):

通過一個服務(wù)與另一個服務(wù)對話以實(shí)現(xiàn)最終用戶的某個目標(biāo)，這里我們把網(wǎng)絡(luò)堆棧加入進(jìn)來：

上述模型從20世紀(jì)50年代以來一直被反復(fù)使用。一開始，計算機(jī)很少見而且價格昂貴，因此兩個節(jié)點(diǎn)之間的每條連接都會被精心設(shè)計和維護(hù)。然而隨著計算機(jī)越來越便宜、越來越流行，連接數(shù)量和數(shù)據(jù)量急劇增加，當(dāng)人們越來月以來網(wǎng)絡(luò)系統(tǒng)，開發(fā)就必須確保所構(gòu)建軟件符合用戶的服務(wù)質(zhì)量要求。

想要達(dá)到與其水平，就需要解決很多問題，例如讓機(jī)器找到彼此、在一條線上處理多個并發(fā)連接、允許機(jī)器在不直接連接的情況下相互通信、在網(wǎng)絡(luò)間路由包、加密通信等等。

以流控制（flow control）為例。流控制本身是一種機(jī)制，阻止一臺服務(wù)器發(fā)送比下游服務(wù)器處理上限更多數(shù)據(jù)包。在網(wǎng)絡(luò)系統(tǒng)中，我們至少有兩臺獨(dú)立的計算機(jī)，它們彼此不太“了解”，因此流控制是必要的。計算機(jī)A以給定速率向計算機(jī)B發(fā)送字節(jié)，不能保證B將以足夠快、一致的的速度處理收到的字節(jié)。例如，計算機(jī)B可能正忙于并行運(yùn)行其他任務(wù)，或者包可能會無序到達(dá)，而計算機(jī)B被阻塞等待應(yīng)該首先到達(dá)的數(shù)據(jù)包。換句話說，計算機(jī)A不僅不具備計算機(jī)B所期望的性能，而且很可能會讓事情變得更糟，可能會使計算機(jī)B過載，而計算機(jī)B不得不排隊(duì)等待所有進(jìn)入的數(shù)據(jù)包以進(jìn)行處理。

曾經(jīng)有一段時間，人們期望構(gòu)建網(wǎng)絡(luò)服務(wù)和應(yīng)用的人能夠處理他們編寫代碼中提出的上述挑戰(zhàn)。在我們的流控制示例中，意味著應(yīng)用本身必須包含所需邏輯，以確保我們沒有用數(shù)據(jù)包重載服務(wù)。這種大量使用網(wǎng)絡(luò)的邏輯與業(yè)務(wù)邏輯并行。抽象圖如下所示：

幸運(yùn)的是，隨著技術(shù)快速發(fā)展，出現(xiàn)了很多標(biāo)準(zhǔn)（如TCP/IP）可以將流控制或其他問題的解決方案集成到網(wǎng)絡(luò)堆棧中——代碼仍然存在，但已經(jīng)從應(yīng)用轉(zhuǎn)移到了操作系統(tǒng)提供的底層網(wǎng)絡(luò)層中。

但考慮到高性能和可靠性，很少有組織能說自己只使用商用操作系統(tǒng)附帶的TCP/IP堆棧來推動業(yè)務(wù)發(fā)展。

微服務(wù)架構(gòu)的出現(xiàn)

到如今，計算機(jī)已經(jīng)無處不在，上述網(wǎng)絡(luò)堆棧也已經(jīng)證明了自己是可靠連接系統(tǒng)的“事實(shí)上的”工具集。由于有了更多的節(jié)點(diǎn)和穩(wěn)定的連接，業(yè)界開始使用各種類型的網(wǎng)絡(luò)系統(tǒng)，從細(xì)粒度的分布式代理和對象，到由更大但仍然重度分布的組件組成的面向服務(wù)的架構(gòu)。

這種極端的分布帶來了許多有趣的高級用例和好處，但也帶來了一些挑戰(zhàn)。有些挑戰(zhàn)是全新的，而有些挑戰(zhàn)只是我們在討論原始網(wǎng)絡(luò)時討論過的高級版本。

在90年代，Peter Deutsch和他在Sun Microsystems的同事們編輯了“分布式計算的8個謬誤”，其中列出了人們在使用分布式系統(tǒng)時傾向于做出的一些假設(shè)。Peter的觀點(diǎn)是，這些在更原始的網(wǎng)絡(luò)架構(gòu)或理論模型中可能是正確的，但在現(xiàn)代世界中并不正確:

1. 網(wǎng)絡(luò)是可靠的（The Network is Reliable）

2. 延遲為零（Latency is Zero）

3. 帶寬是無限的（Bandwidth is Infinite）

4. 網(wǎng)絡(luò)是安全的（The Network is Secure）

5. 拓?fù)洳粫淖儯═opology does not Change）

6. 有一名管理員（There is one Administrator）

7. 傳輸成本為零（Transport Cost is Zero）

8. 網(wǎng)絡(luò)是同質(zhì)的（The Network is Homogenous）

將上述清單斥為“謬論”，意味著開發(fā)者不能忽視這些問題，必須明確地解決它們。

更復(fù)雜的是，轉(zhuǎn)向更加分布式的系統(tǒng)——我們通常稱之為微服務(wù)架構(gòu)——在可操作性方面引入了新的需求。以下是我們必須處理的一些問題:

1. 快速提供計算資源（Rapid provisioning of compute resources）

2. 基本的監(jiān)視（Basic monitoring）

3. 快速部署（Rapid deployment）

4. 容易提供存儲（Easy to provision storage）

5. 容易接近邊緣（Easy access to the edge）

6. 身份驗(yàn)證/授權(quán)（Authentication/Authorisation）

7. 標(biāo)準(zhǔn)化的RPC（Standardised RPC）

因此，盡管幾十年前開發(fā)的TCP/IP棧和通用網(wǎng)絡(luò)模型仍然是使計算機(jī)相互通信的強(qiáng)大工具，但更復(fù)雜的體系結(jié)構(gòu)引入了另一層需求，而在這些架構(gòu)中工作的開發(fā)者必須再次滿足這些需求。

例如，考慮服務(wù)發(fā)現(xiàn)和斷路器，這兩種技術(shù)用于解決上面列出的部分彈性和分布式挑戰(zhàn)。

歷史往往會重演，第一批基于微服務(wù)構(gòu)建系統(tǒng)的組織遵循的策略與前幾代網(wǎng)絡(luò)計算機(jī)的策略非常相似，這意味著處理上述要求的責(zé)任放在了編寫服務(wù)的開發(fā)者身上。

服務(wù)發(fā)現(xiàn)是自動查找哪些服務(wù)實(shí)例滿足給定查詢的過程，例如名為Teams的服務(wù)需要查找名為Players的服務(wù)實(shí)例，并將屬性環(huán)境設(shè)置為production。我們將調(diào)用一些服務(wù)發(fā)現(xiàn)過程，該過程將返回合適服務(wù)器的列表。對于大多數(shù)一體化架構(gòu)，這是一個簡單的任務(wù)，通常使用DNS、負(fù)載平衡器和一些端口號約定（例如所有服務(wù)將其HTTP服務(wù)器綁定到端口8080）。在分布式環(huán)境中，任務(wù)開始變得更加復(fù)雜，以前信任DNS查找依賴關(guān)系的服務(wù)現(xiàn)在必須處理諸如客戶端負(fù)載平衡、多個不同環(huán)境、地理位置分散的服務(wù)器等等問題。之前我們需要一行代碼解析主機(jī)名，而現(xiàn)在，我們的服務(wù)需要許多行樣板文件來處理更高版本引入的各種情況。

斷路器是邁克爾·尼加德提出的一種模式，Martin Fowler把該模式總結(jié)為：

斷路器背后的邏輯很簡單，在斷路器對象中包裝一個用于監(jiān)視故障的受保護(hù)的函數(shù)調(diào)用。一旦故障達(dá)到某個閾值，斷路器就會跳閘，并且所有對斷路器的進(jìn)一步調(diào)用都會返回錯誤，不會進(jìn)行任何保護(hù)調(diào)用。通常情況下，我們還會需要一些對斷路器的檢測警報。

這樣簡單的設(shè)備可以為服務(wù)之間的交互增加更多可靠性。然而同樣的，隨著分布水平提高，它們往往會變得非常復(fù)雜，系統(tǒng)出現(xiàn)問題的可能性也隨之水漲船高，即使是“斷路器跳閘就會發(fā)出某種監(jiān)控警報”這種小事也不簡單了。過去只需幾行代碼的東西現(xiàn)在需要大量的樣板來處理。

但坦白說，上面列出的這兩個例子很難正確地實(shí)現(xiàn)，這也是為什么像Twitter的Finagle和Facebook的Proxygen這樣復(fù)雜的大型庫會變得流行，用來避免在每個服務(wù)中重寫相同的邏輯。

上面所描述的模型被大多數(shù)開創(chuàng)性的微服務(wù)架構(gòu)企業(yè)所采納，如Netflix、Twitter和SoundCloud，而隨著系統(tǒng)中的服務(wù)數(shù)量的增加，他們還偶然發(fā)現(xiàn)了這種方法的各種缺陷。

即使使用Finagle這樣的庫，企業(yè)仍然需要從其工程團(tuán)隊(duì)中投入時間來構(gòu)建連接庫和其他生態(tài)系統(tǒng)的“粘合劑”。按照SoundCloud和DigitalOcean的經(jīng)驗(yàn)，在一個100-250人的工程師組織中，遵循以上策略，需要將1/10的員工用于構(gòu)建工具。當(dāng)開發(fā)者被分配給專門負(fù)責(zé)構(gòu)建工具的團(tuán)隊(duì)時，這種成本是很明顯的，但更常見的情況是，一些不可見的隱性成本和時間成本。

第二個問題是，上述方法限制了微服務(wù)可以使用的工具、運(yùn)行時和語言。微服務(wù)的庫通常是為特定平臺編寫的，無論是編程語言還是JVM之類的運(yùn)行時。如果一個企業(yè)使用的平臺不是庫支持的平臺，那么它通常需要將代碼移植到新的平臺本身。開發(fā)者必須再次構(gòu)建工具和基礎(chǔ)設(shè)施，而不是把精力放在核心業(yè)務(wù)和產(chǎn)品上。這就是為什么像SoundCloud和DigitalOcean這樣的中型組織決定只支持一個用于內(nèi)部服務(wù)的平臺——scala和Go。

最后一個值得討論的問題是治理。庫模型可以抽象實(shí)現(xiàn)處理微服務(wù)架構(gòu)需求所需的特性，但它本身仍然是一個需要維護(hù)的組件。確保數(shù)千個服務(wù)實(shí)例使用相同或至少兼容的庫版本并非易事，每一次更新都意味著集成、測試和重新部署所有服務(wù)——即使服務(wù)本身沒有任何變化。

下一步

與我們在網(wǎng)絡(luò)堆棧中看到的類似，將大規(guī)模分布式服務(wù)所需的特性提取到底層平臺是非?？扇〉?。

人們使用更高級別的協(xié)議(如HTTP)編寫非常復(fù)雜的應(yīng)用程序和服務(wù)，甚至不考慮TCP如何控制網(wǎng)絡(luò)上的數(shù)據(jù)包。這種情況正是微服務(wù)所需要的，在這種情況下，從事服務(wù)的開發(fā)者可以專注于他們的業(yè)務(wù)邏輯，避免在編寫自己的服務(wù)基礎(chǔ)架構(gòu)代碼或管理整個團(tuán)隊(duì)的庫和框架上浪費(fèi)時間。

把這個想法和我們的圖表結(jié)合起來，我們可以得出如下結(jié)論:

不幸的是，更改網(wǎng)絡(luò)堆棧以添加這個層并不是一項(xiàng)可行的任務(wù)。許多從業(yè)者發(fā)現(xiàn)的解決方案是將其作為一組代理實(shí)現(xiàn)。這里的想法是，服務(wù)不會直接連接到它的下游依賴項(xiàng)，而是所有的流量都將通過一個小軟件來透明地添加所需的特性。

這種思想下的第一個有記錄的開發(fā)利用了“sidecars”概念。sidecar是一種輔助進(jìn)程，在應(yīng)用旁執(zhí)行，并提供額外的特性。2013年，Airbnb寫了關(guān)于Synapse和Nerve的文章，一種sidecar的開源實(shí)現(xiàn)。一年后，Netflix引入了Prana，這是一種致力于允許非jvm應(yīng)用程序從他們的NetflixOSS生態(tài)系統(tǒng)中獲益的sidecar。SoundCloud也構(gòu)建了sidecars，讓Ruby legacy能夠使用為JVM微服務(wù)構(gòu)建的基礎(chǔ)設(shè)施。

雖然有幾個這樣的開源代理實(shí)現(xiàn)，但它們往往被設(shè)計成與特定的基礎(chǔ)設(shè)施組件一起工作。例如，當(dāng)談到服務(wù)發(fā)現(xiàn)Airbnb的神經(jīng)和突觸時，我們假設(shè)服務(wù)是在Zookeeper中注冊的，而對于Prana，我們應(yīng)該使用Netflix自己的Eureka服務(wù)注冊。

隨著微服務(wù)架構(gòu)的日益流行，出現(xiàn)了一種新的代理，它們足夠靈活，可以適應(yīng)不同的基礎(chǔ)設(shè)施組件和首選項(xiàng)。第一個廣為人知的系統(tǒng)是Linkerd，基于他們在Twitter微服務(wù)平臺上的工作而創(chuàng)建。很快，Lyft的工程團(tuán)隊(duì)也宣布了遵循類似原則的項(xiàng)目——Envoy。

Service Mesh - 服務(wù)網(wǎng)格

在這種模型中，我們的每個服務(wù)都將有一個附屬的代理sidecar?？紤]到服務(wù)之間僅通過sidecar代理進(jìn)行通信，我們最終的部署類似于下面的圖:

Buoyant首席執(zhí)行官威廉·摩根觀察到代理之間的互連形成了一個網(wǎng)狀網(wǎng)絡(luò)，于是在2017年初，為這個平臺寫了一個定義，并稱之為Service Mesh（服務(wù)網(wǎng)格）:

Service Mesh是處理服務(wù)間通信的基礎(chǔ)設(shè)施層，負(fù)責(zé)實(shí)現(xiàn)請求的可靠傳遞。在實(shí)踐中，Service Mesh通常實(shí)現(xiàn)為輕量級網(wǎng)絡(luò)代理，與應(yīng)用部署在一起，但是對應(yīng)用透明。

該定義最有意義的地方在于，它不再將代理視為獨(dú)立的組件，而是承認(rèn)它們形成的網(wǎng)絡(luò)本身是有價值的。

隨著企業(yè)將其微服務(wù)部署移動到更復(fù)雜的運(yùn)行時，如Kubernetes和Mesos，人們和企業(yè)已經(jīng)開始使用這些平臺提供的工具來正確地實(shí)現(xiàn)網(wǎng)格網(wǎng)絡(luò)的想法。它們正在從一組獨(dú)立的代理轉(zhuǎn)向一個適當(dāng)?shù)?、某種程度上集中的控制平面。

在鳥瞰圖，我們能看到實(shí)際的服務(wù)流量仍然從代理直接流向代理，但是控制平面知道每個代理實(shí)例。控制平面使代理能夠?qū)崿F(xiàn)訪問控制和度量收集等功能:

要完全理解大型系統(tǒng)中Service Mesh的影響還為時過早。這種方法的兩個好處在我看來已經(jīng)很明顯了。首先，不需要編寫定制軟件來處理微服務(wù)架構(gòu)最終代碼，這將允許許多較小的組織享受以前只有大型企業(yè)才能使用的功能，從而創(chuàng)建各種有趣的用例。第二，這種體系結(jié)構(gòu)可能讓我們最終實(shí)現(xiàn)使用最佳工具/語言完成工作的夢想，而不必?fù)?dān)心每個平臺的庫和模式的可用性。

到此，相信大家對“Service Mesh模式是怎么來的”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

網(wǎng)站題目：ServiceMesh模式是怎么來的
網(wǎng)頁路徑：http://bm7419.com/article46/igodeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航、用戶體驗(yàn)、虛擬主機(jī)、全網(wǎng)營銷推廣、域名注冊

廣告

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