Service Mesh——下一代微服務架構
定義
根據Linkerd CEO William Morgan定義，Service Mesh是用於處理服務間通訊的基礎設施層，用於在雲原生應用複雜的服務拓撲中實現可靠的請求傳遞。在實踐中，Service Mesh通常是一組與應用一起部署，但對應用透明的輕量級網路代理。
架構難題
我司採用的微服務架構基於Thrift通訊，為了提供一個全域性通用的通訊協議，把這些與協議、路由等相關的操作封裝在內部基礎庫上，像Netflix、Twitter等SOA/微服務的早期採用者，他們通過建立內部庫的方式處理這些問題，然後提供給所有服務使用一樣。
這種方法的問題在於，把庫擴充套件到成百上千個微服務中難度極高，而且這些庫相對來說是比較”脆弱“的，每次需要升級基礎內部庫，對眾多微服務來說，雖然有容器支撐，也是一種小災難~~
而Service Mesh提供了一種解決困境的思路和統一方案。
Service Mesh與傳統基礎設施層不同之處在於，它形成了一個分散式的互連代理網路，以sidecar形式部署在服務兩側，服務對於代理無感知，且服務間所有通訊都由代理進行路由。
全域性視角
仔細觀察上面幾張圖，應該很清晰的闡述瞭解決問題的觀點。
Service Mesh由data plane構成，其中所有服務通過sidecar代理進行服務通訊。（所有代理相互連線形成一個Mesh，Service Mesh由此得名）網格同時包含一個control plane——可以將所有獨立的sidecar代理連線到一個分散式網路中，並設定網格還包括一個控制平面——它將所有獨立的sidecar代理連線到一個分散式網路中，並設定由data plane指定的策略。
Control plane定義服務發現、路由、流量控制等策略。這些策略可以是全域性的，也可以是限定的。Data plane負責在通訊時應用和執行這些策略。
微軟陣營的Service Fabric
完美解決服務發現、負載均衡、路由、流量控制、通訊可靠性、彈性、安全、監控/日誌等問題。
目前已經開源。
github： Service Fabric
google 的ISTIO
兩者對比
