一：什麼是Service Mesh

1.可以將Service Mesh比作是程式或者微服務間的TCP/IP，負責服務之間的網路呼叫，限流，熔斷和監控。對於編寫應用程式來說一般無須關心 TCP/IP 這一層（比如透過 HTTP 協議的 RESTful 應用），同樣使用 Service Mesh 也就無須關係服務之間的那些原來是透過應用程式或者其他框架實現的事情，比如 Spring Cloud、OSS，現在只要交給 Service Mesh 就可以了。

2.Service Mesh有如下幾個特點：
a. 應用程式間通訊的中間層
b.輕量級的網路代理
c.應用程式無感知
d.解耦應用程式的重試，超時，監控，追蹤和服務發現

3.Service Mesh的架構

Service mesh 作為 sidecar 執行，對應用程式來說是透明，所有應用程式間的流量都會透過它，所以對應用程式流量的控制都可以在 serivce mesh 中實現。

二：為何使用Service Mesh

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

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

3.在 Cloud Native 架構下，容器的使用給予了異構應用程式的更多可行性，kubernetes 增強的應用的橫向擴容能力，使用者可以快速的編排出複雜環境、複雜依賴關係的應用程式，同時開發者又無須過分關心應用程式的監控、擴充套件性、服務發現和分散式追蹤這些繁瑣的事情而專注於程式開發，賦予開發者更多的創造性。

三：Service Mesh如何工作

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

1.Linkerd 將服務請求路由到目的地址，根據其中的引數判斷是到生產環境還是測試環境，是路由到本地環境還是公有云環境？所有的這些路由資訊可以動態配置，可以是全域性配置也可以為某些服務單獨配置。

2.當 Linkerd 確認了目的地址後，將流量傳送到相應服務發現端點(在 kubernetes 中是 service)，然後 service 會將服務轉發給後端的例項(Pod)。

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

4.Linkerd 將請求傳送給該例項，同時記錄響應型別和延遲資料。

5.如果該例項掛了、不響應了或者程式不工作了，Linkerd 將把請求傳送到其他例項上重試。

6.如果該例項持續返回 error，Linkerd 會將該例項從負載均衡池中移除，稍後再週期性得重試。

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

8.Linkerd 以 metric 和分散式追蹤的形式捕獲上述行為的各個方面，這些追蹤資訊將傳送到集中 metric 系統。

四：Istio 與 Linkerd

當前的Service Mesh實現主要有兩大陣營，Linkerd和Istio。

Feature	Istio	Linkerd
部署架構	Envoy/Sidecar	DaemonSets
易用性	複雜	簡單
支援平臺	kuberentes	kubernetes/mesos/Istio/local
當前版本	0.3.0	1.3.3
是否已有生產部署	否	是

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

kubernetes實踐之六十五：Service Mesh

相關文章