建站
咨詢
售后
建站咨詢
新聞中心
本篇內(nèi)容介紹了“Service Mesh是一種技術(shù)嗎”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
創(chuàng)新互聯(lián)專注于和平企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站設(shè)計,成都做商城網(wǎng)站。和平網(wǎng)站建設(shè)公司,為和平等地區(qū)提供建站服務(wù)。全流程按需定制網(wǎng)站，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)
Service Mesh從何而來？
在過去幾個月里，Service Mesh是行業(yè)內(nèi)毋庸置疑的焦點。關(guān)于Service Mesh、關(guān)于軟件架構(gòu)未來的文章觀點，圍繞著不同的技術(shù)供應(yīng)商而高度分化，不過有一點共通的事，對于如何在企業(yè)中使用API的快速轉(zhuǎn)換，以及這對于我們流量的拓?fù)湟馕吨裁础?/p>
服務(wù)API主要是作為將組織外部開發(fā)人員與內(nèi)部系統(tǒng)連接起來的邊緣接口，以及將這些內(nèi)部系統(tǒng)（微服務(wù)）綁定到功能整體的“粘合劑”存在的。因此，面向微服務(wù)體系結(jié)構(gòu)不可避免會出現(xiàn)數(shù)據(jù)中心內(nèi)部通信增加的情況。tongguo的不可避免的結(jié)果之一是數(shù)據(jù)中心內(nèi)的 內(nèi)部通信將增加。Service Mesh作為一種潛在的解決方案出現(xiàn)了，它通過提供一個不同的框架來部署現(xiàn)有技術(shù)，從而解決了東西部流量增加帶來的挑戰(zhàn)。
Service Mesh是一種模式，而非技術(shù)
正如微服務(wù)是一種模式而不是一種特定的技術(shù)一樣，Service Mesh也是一種模式。區(qū)分這兩者聽起來比實際要復(fù)雜得多。如果我們從面向?qū)ο缶幊?OOP)的角度來考慮這個問題，一個模式描述的是接口，而不是實現(xiàn)。
在微服務(wù)的背景下，Service Mesh部署模式能夠通過sidecar代理，更好地管理東西流量。當(dāng)我們拆分系統(tǒng)并使用微服務(wù)構(gòu)建新產(chǎn)品時，我們流量的拓?fù)浣Y(jié)構(gòu)也正在從外部為主轉(zhuǎn)向內(nèi)部流量的持續(xù)增長。數(shù)據(jù)中心里的東西通流量增長，緣于我們用網(wǎng)絡(luò)調(diào)用替換過去的函數(shù)調(diào)用，這意味著我們的微服務(wù)必須通過網(wǎng)絡(luò)來相互通信。但我們都知道，網(wǎng)絡(luò)有可能是不可靠的。
通過使用不同的部署模式，Service Mesh希望解決東西流量增加帶來的挑戰(zhàn)。雖然對于傳統(tǒng)的南北流量來說，100ms的中間件處理延遲雖然并不理想，但也不是不能接受，不過在東西流量的微服務(wù)架構(gòu)體系中，這樣的延遲就不能容忍了。原因是服務(wù)之間從東到西的流量增加會增加延遲，當(dāng)跨不同服務(wù)的API請求鏈被執(zhí)行和返回時，可能會導(dǎo)致700ms的延遲。
為了減少這種延遲，引入了與微服務(wù)進(jìn)程一起運(yùn)行的sidecar代理，以刪除網(wǎng)絡(luò)中的額外跳轉(zhuǎn)。Sidecar代理，對應(yīng)于我們請求執(zhí)行路徑上的數(shù)據(jù)平面，也提供了更好的彈性，因為我們不再有單點故障。值得注意的是，sidecar代理承擔(dān)了為我們的微服務(wù)的每個實例都有一個代理實例的成本，這需要一個很小的占用空間，以最小化資源損耗。
從功能的角度來看，API管理產(chǎn)品已經(jīng)提供了多年來所提供的Service Mesh。諸如可觀察性，網(wǎng)絡(luò)錯誤處理，健康檢查等功能是API管理的標(biāo)志。這些功能本身并不構(gòu)成任何新穎的功能，但作為一種模式，Service Mesh引入了在我們的體系結(jié)構(gòu)中部署這些功能的新方法。
傳統(tǒng)的API管理方案已經(jīng)跟不上了
為什么大多數(shù)傳統(tǒng)的API管理解決方案不允許這種新的部署選項？因為他們“出生在一個單一的世界”。
事實證明，Docker和Kubernetes出現(xiàn)之前構(gòu)建的API管理解決方案本身就是一個整體，并沒有被設(shè)計成在新興的容器生態(tài)系統(tǒng)中有效工作。傳統(tǒng)API管理解決方案所提供的重量級運(yùn)行時和較慢的性能在傳統(tǒng)的邊緣API用例中是可以接受的，但是在微服務(wù)體系結(jié)構(gòu)中，延遲會隨著時間的推移而通過增加?xùn)|西方向的流量活動而增加。從本質(zhì)上講，傳統(tǒng)的API管理解決方案最終都過于重量級、難以自動化，并且太慢，無法有效地協(xié)調(diào)與微服務(wù)固有的不斷增加的通信。
由于開發(fā)人員理解這一點，在容器出現(xiàn)之前誕生的遺留API管理解決方案引入了他們所謂的“微網(wǎng)關(guān)”來處理東西流量，避免重寫他們現(xiàn)有的、臃腫的、單一的網(wǎng)關(guān)解決方案。問題是，這些微網(wǎng)關(guān)雖然更輕量，但仍然需要遺留解決方案與它們一起運(yùn)行，以便執(zhí)行策略強(qiáng)制。這不僅意味著在堆棧中保持原來的重型依賴關(guān)系，還意味著每個請求之間的延遲增加。這就不難理解，為什么Service Mesh感覺上像是一個全新的類別，因為過去的API管理方案已經(jīng)無法支持需求了。
“Service Mesh是一種技術(shù)嗎”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！
網(wǎng)站標(biāo)題：ServiceMesh是一種技術(shù)嗎
文章源于：http://www.ef60e0e.cn/article/gjpcgd.html
