本篇內(nèi)容介紹了“Service Mesh是一種技術(shù)嗎”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)專注于和平企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站設(shè)計(jì),成都做商城網(wǎng)站。和平網(wǎng)站建設(shè)公司,為和平等地區(qū)提供建站服務(wù)。全流程按需定制網(wǎng)站，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

Service Mesh從何而來？

在過去幾個(gè)月里，Service Mesh是行業(yè)內(nèi)毋庸置疑的焦點(diǎn)。關(guān)于Service Mesh、關(guān)于軟件架構(gòu)未來的文章觀點(diǎn)，圍繞著不同的技術(shù)供應(yīng)商而高度分化，不過有一點(diǎn)共通的事，對(duì)于如何在企業(yè)中使用API的快速轉(zhuǎn)換，以及這對(duì)于我們流量的拓?fù)湟馕吨裁础?/p>

服務(wù)API主要是作為將組織外部開發(fā)人員與內(nèi)部系統(tǒng)連接起來的邊緣接口，以及將這些內(nèi)部系統(tǒng)（微服務(wù)）綁定到功能整體的“粘合劑”存在的。因此，面向微服務(wù)體系結(jié)構(gòu)不可避免會(huì)出現(xiàn)數(shù)據(jù)中心內(nèi)部通信增加的情況。tongguo的不可避免的結(jié)果之一是數(shù)據(jù)中心內(nèi)的 內(nèi)部通信將增加。Service Mesh作為一種潛在的解決方案出現(xiàn)了，它通過提供一個(gè)不同的框架來部署現(xiàn)有技術(shù)，從而解決了東西部流量增加帶來的挑戰(zhàn)。

Service Mesh是一種模式，而非技術(shù)

正如微服務(wù)是一種模式而不是一種特定的技術(shù)一樣，Service Mesh也是一種模式。區(qū)分這兩者聽起來比實(shí)際要復(fù)雜得多。如果我們從面向?qū)ο缶幊?OOP)的角度來考慮這個(gè)問題，一個(gè)模式描述的是接口，而不是實(shí)現(xiàn)。

在微服務(wù)的背景下，Service Mesh部署模式能夠通過sidecar代理，更好地管理東西流量。當(dāng)我們拆分系統(tǒng)并使用微服務(wù)構(gòu)建新產(chǎn)品時(shí)，我們流量的拓?fù)浣Y(jié)構(gòu)也正在從外部為主轉(zhuǎn)向內(nèi)部流量的持續(xù)增長(zhǎng)。數(shù)據(jù)中心里的東西通流量增長(zhǎng)，緣于我們用網(wǎng)絡(luò)調(diào)用替換過去的函數(shù)調(diào)用，這意味著我們的微服務(wù)必須通過網(wǎng)絡(luò)來相互通信。但我們都知道，網(wǎng)絡(luò)有可能是不可靠的。

通過使用不同的部署模式，Service Mesh希望解決東西流量增加帶來的挑戰(zhàn)。雖然對(duì)于傳統(tǒng)的南北流量來說，100ms的中間件處理延遲雖然并不理想，但也不是不能接受，不過在東西流量的微服務(wù)架構(gòu)體系中，這樣的延遲就不能容忍了。原因是服務(wù)之間從東到西的流量增加會(huì)增加延遲，當(dāng)跨不同服務(wù)的API請(qǐng)求鏈被執(zhí)行和返回時(shí)，可能會(huì)導(dǎo)致700ms的延遲。

為了減少這種延遲，引入了與微服務(wù)進(jìn)程一起運(yùn)行的sidecar代理，以刪除網(wǎng)絡(luò)中的額外跳轉(zhuǎn)。Sidecar代理，對(duì)應(yīng)于我們請(qǐng)求執(zhí)行路徑上的數(shù)據(jù)平面，也提供了更好的彈性，因?yàn)槲覀儾辉儆袉吸c(diǎn)故障。值得注意的是，sidecar代理承擔(dān)了為我們的微服務(wù)的每個(gè)實(shí)例都有一個(gè)代理實(shí)例的成本，這需要一個(gè)很小的占用空間，以最小化資源損耗。

從功能的角度來看，API管理產(chǎn)品已經(jīng)提供了多年來所提供的Service Mesh。諸如可觀察性，網(wǎng)絡(luò)錯(cuò)誤處理，健康檢查等功能是API管理的標(biāo)志。這些功能本身并不構(gòu)成任何新穎的功能，但作為一種模式，Service Mesh引入了在我們的體系結(jié)構(gòu)中部署這些功能的新方法。

傳統(tǒng)的API管理方案已經(jīng)跟不上了

為什么大多數(shù)傳統(tǒng)的API管理解決方案不允許這種新的部署選項(xiàng)？因?yàn)樗麄儭俺錾谝粋€(gè)單一的世界”。

事實(shí)證明，Docker和Kubernetes出現(xiàn)之前構(gòu)建的API管理解決方案本身就是一個(gè)整體，并沒有被設(shè)計(jì)成在新興的容器生態(tài)系統(tǒng)中有效工作。傳統(tǒng)API管理解決方案所提供的重量級(jí)運(yùn)行時(shí)和較慢的性能在傳統(tǒng)的邊緣API用例中是可以接受的，但是在微服務(wù)體系結(jié)構(gòu)中，延遲會(huì)隨著時(shí)間的推移而通過增加?xùn)|西方向的流量活動(dòng)而增加。從本質(zhì)上講，傳統(tǒng)的API管理解決方案最終都過于重量級(jí)、難以自動(dòng)化，并且太慢，無法有效地協(xié)調(diào)與微服務(wù)固有的不斷增加的通信。

由于開發(fā)人員理解這一點(diǎn)，在容器出現(xiàn)之前誕生的遺留API管理解決方案引入了他們所謂的“微網(wǎng)關(guān)”來處理東西流量，避免重寫他們現(xiàn)有的、臃腫的、單一的網(wǎng)關(guān)解決方案。問題是，這些微網(wǎng)關(guān)雖然更輕量，但仍然需要遺留解決方案與它們一起運(yùn)行，以便執(zhí)行策略強(qiáng)制。這不僅意味著在堆棧中保持原來的重型依賴關(guān)系，還意味著每個(gè)請(qǐng)求之間的延遲增加。這就不難理解，為什么Service Mesh感覺上像是一個(gè)全新的類別，因?yàn)檫^去的API管理方案已經(jīng)無法支持需求了。

“Service Mesh是一種技術(shù)嗎”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！