Service Mesh是一種技術嗎

本篇內容介紹了“Service Mesh是一種技術嗎”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Service Mesh從何而來？

在過去幾個月里，Service Mesh是行業內毋庸置疑的焦點。關于Service Mesh、關于軟件架構未來的文章觀點，圍繞著不同的技術供應商而高度分化，不過有一點共通的事，對于如何在企業中使用API的快速轉換，以及這對于我們流量的拓撲意味著什么。

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

Service Mesh是一種模式，而非技術

正如微服務是一種模式而不是一種特定的技術一樣，Service Mesh也是一種模式。區分這兩者聽起來比實際要復雜得多。如果我們從面向對象編程(OOP)的角度來考慮這個問題，一個模式描述的是接口，而不是實現。

在微服務的背景下，Service Mesh部署模式能夠通過sidecar代理，更好地管理東西流量。當我們拆分系統并使用微服務構建新產品時，我們流量的拓撲結構也正在從外部為主轉向內部流量的持續增長。數據中心里的東西通流量增長，緣于我們用網絡調用替換過去的函數調用，這意味著我們的微服務必須通過網絡來相互通信。但我們都知道，網絡有可能是不可靠的。

通過使用不同的部署模式，Service Mesh希望解決東西流量增加帶來的挑戰。雖然對于傳統的南北流量來說，100ms的中間件處理延遲雖然并不理想，但也不是不能接受，不過在東西流量的微服務架構體系中，這樣的延遲就不能容忍了。原因是服務之間從東到西的流量增加會增加延遲，當跨不同服務的API請求鏈被執行和返回時，可能會導致700ms的延遲。

為了減少這種延遲，引入了與微服務進程一起運行的sidecar代理，以刪除網絡中的額外跳轉。Sidecar代理，對應于我們請求執行路徑上的數據平面，也提供了更好的彈性，因為我們不再有單點故障。值得注意的是，sidecar代理承擔了為我們的微服務的每個實例都有一個代理實例的成本，這需要一個很小的占用空間，以最小化資源損耗。

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

傳統的API管理方案已經跟不上了

為什么大多數傳統的API管理解決方案不允許這種新的部署選項？因為他們“出生在一個單一的世界”。

事實證明，Docker和Kubernetes出現之前構建的API管理解決方案本身就是一個整體，并沒有被設計成在新興的容器生態系統中有效工作。傳統API管理解決方案所提供的重量級運行時和較慢的性能在傳統的邊緣API用例中是可以接受的，但是在微服務體系結構中，延遲會隨著時間的推移而通過增加東西方向的流量活動而增加。從本質上講，傳統的API管理解決方案最終都過于重量級、難以自動化，并且太慢，無法有效地協調與微服務固有的不斷增加的通信。

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

“Service Mesh是一種技術嗎”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！