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

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

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

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

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

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

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

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

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

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

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

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

曾經(jīng)有一段時(shí)間，人們期望構(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堆棧來推動(dòng)業(yè)務(wù)發(fā)展。

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

到如今，計(jì)算機(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)。

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

在90年代，Peter Deutsch和他在Sun Microsystems的同事們編輯了“分布式計(jì)算的8個(gè)謬誤”，其中列出了人們在使用分布式系統(tǒng)時(shí)傾向于做出的一些假設(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ù)洳粫?huì)改變（Topology 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. 快速提供計(jì)算資源（Rapid provisioning of compute resources）

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

3. 快速部署（Rapid deployment）

4. 容易提供存儲(chǔ)（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ì)算機(jī)相互通信的強(qiáng)大工具，但更復(fù)雜的體系結(jié)構(gòu)引入了另一層需求，而在這些架構(gòu)中工作的開發(fā)者必須再次滿足這些需求。

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

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

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

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

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

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

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

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

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

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

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

下一步

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

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

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

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

這種思想下的第一個(gè)有記錄的開發(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è)施。

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

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

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

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

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

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

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

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

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

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

到此，相信大家對“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://aaarwkj.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)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)