這篇文章主要為大家展示了“kubernetes中什么是Service Mesh”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“kubernetes中什么是Service Mesh”這篇文章吧。

創(chuàng)新新互聯(lián)，憑借10余年的成都網站建設、做網站經驗，本著真心·誠心服務的企業(yè)理念服務于成都中小企業(yè)設計網站有上千案例。做網站建設，選創(chuàng)新互聯(lián)。

一：什么是Service Mesh

1.可以將Service Mesh比作是程序或者微服務間的TCP/IP，負責服務之間的網絡調用，限流，熔斷和監(jiān)控。對于編寫應用程序來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協(xié)議的 RESTful 應用），同樣使用 Service Mesh 也就無須關系服務之間的那些原來是通過應用程序或者其他框架實現(xiàn)的事情，比如 Spring Cloud、OSS，現(xiàn)在只要交給 Service Mesh 就可以了。

2.Service Mesh有如下幾個特點：
a. 應用程序間通信的中間層
b.輕量級的網絡代理
c.應用程序無感知
d.解耦應用程序的重試，超時，監(jiān)控，追蹤和服務發(fā)現(xiàn)

3.Service Mesh的架構

Service mesh 作為 sidecar 運行，對應用程序來說是透明，所有應用程序間的流量都會通過它，所以對應用程序流量的控制都可以在 serivce mesh 中實現(xiàn)。

二：為何使用Service Mesh

1.Service mesh 并沒有給我們帶來新功能，它是用于解決其他工具已經解決過的問題，只不過這次是在 Cloud Native 的 kubernetes 環(huán)境下的實現(xiàn)。

2.在傳統(tǒng)的 MVC 三層 Web 應用程序架構下，服務之間的通訊并不復雜，在應用程序內部自己管理即可，但是在現(xiàn)今的復雜的大型網站情況下，單體應用被分解為眾多的微服務，服務之間的依賴和通訊十分復雜。

3.在 Cloud Native 架構下，容器的使用給予了異構應用程序的更多可行性，kubernetes 增強的應用的橫向擴容能力，用戶可以快速的編排出復雜環(huán)境、復雜依賴關系的應用程序，同時開發(fā)者又無須過分關心應用程序的監(jiān)控、擴展性、服務發(fā)現(xiàn)和分布式追蹤這些繁瑣的事情而專注于程序開發(fā)，賦予開發(fā)者更多的創(chuàng)造性。

三：Service Mesh如何工作

 Linkerd 為例講解 service mesh 如何工作：

1.Linkerd 將服務請求路由到目的地址，根據(jù)其中的參數(shù)判斷是到生產環(huán)境還是測試環(huán)境，是路由到本地環(huán)境還是公有云環(huán)境？所有的這些路由信息可以動態(tài)配置，可以是全局配置也可以為某些服務單獨配置。

2.當 Linkerd 確認了目的地址后，將流量發(fā)送到相應服務發(fā)現(xiàn)端點(在 kubernetes 中是 service)，然后 service 會將服務轉發(fā)給后端的實例(Pod)。

3.Linkerd 根據(jù)它觀測到最近請求的延遲時間，選擇出所有應用程序的實例中響應最快的實例。

4.Linkerd 將請求發(fā)送給該實例，同時記錄響應類型和延遲數(shù)據(jù)。

5.如果該實例掛了、不響應了或者進程不工作了，Linkerd 將把請求發(fā)送到其他實例上重試。

6.如果該實例持續(xù)返回 error，Linkerd 會將該實例從負載均衡池中移除，稍后再周期性得重試。

7.如果請求的截止時間已過，Linkerd 主動失敗該請求，而不是再次嘗試添加負載。

8.Linkerd 以 metric 和分布式追蹤的形式捕獲上述行為的各個方面，這些追蹤信息將發(fā)送到集中 metric 系統(tǒng)。

四：Istio 與 Linkerd

當前的Service Mesh實現(xiàn)主要有兩大陣營，Linkerd和Istio。

下圖是Istio和Linkerd架構的不同，Istio是使用Sidecar模式，將Envoy植入到Pod中，而Linkerd則是在每臺node上都以DaemonSet的方式運行。

以上是“kubernetes中什么是Service Mesh”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道！