網絡傳輸可靠性

從計網的學習過程中我們可以知道數據在網絡傳輸中可能會出現一些異常狀況：

• 數據丟失：數據包可能會到達一個緩沖區已經被塞滿的路由器，接著被丟掉
• 順序出錯：一組數據包可能會途徑閑忙程度不同的多個路由器，出現不同程度的延遲，最后到達順序會與發出時的順序不一致

這些丟包重發、順序重組等控制機制已經由網絡協議棧幫我們實現好了，使開發人員更加關注業務層次：

在微服務架構中，則需要引入更多的機制來保障整體的可靠性：

• Service Discovery 機制：通過服務注冊查詢機制，讓一個微服務能夠找到另一個，從而允許動態伸縮、以及故障轉移
• 熔斷機制（Circuit Breaker pattern）：提供斷路保護（就像電表跳閘），防止某個服務不可用引發級聯故障，比如操作不成功導致瘋狂重試，請求堆積，甚至耗盡相關資源，系統中不相關的部分也因此出現故障

同樣，這部分工作早期也是由微服務來完成的（與業務邏輯并存于微服務中）：

緊接著出現了Finagle、Proxygen等開源類庫，由專門的類庫來完成這些工作，而不必在每個服務中重復相同的控制邏輯：

然而，隨著系統中服務數量的增多，這種方式也暴露出了一些問題：

• 膠水部分的資源投入：需要投入資源將第三方庫與系統其余部分連接起來
• 類庫限制了微服務的技術選型：這些類庫通常是特定于平臺的，僅支持特定運行時或編程語言，會給微服務的技術選擇造成限制。畢竟，微服務的一大特點就是允許使用不同的編程語言來編寫不同服務）
• 類庫的維護成本：類庫本身也需要持續維護升級，每次更新都需要重新部署所有服務，即便服務沒有任何改動

這樣看來，類庫似乎不是個理想的解決方案.
既然在應用層解決不太合適，那么能否如法炮制，下沉到網絡棧呢？

將微服務控制下沉到網絡棧？

與通用的基礎通信機制不同，這些應用服務相關的控制機制很難交由下層網絡棧來實現，照搬下沉行不通。

Sidecar

不能在（服務）里面，也不能在下面，所以最后放到了旁邊：

即，通過代理來實現這些網絡控制，所有出入流量都經過代理，稱之為 Sidecar。
Sidecar 作為輔助進程，隨應用程序運行在一旁，并為其提供額外的功能。
問題似乎已經通過網絡代理完美解決了，業界也出現了一些開源方案：Nerve 和 Synapse 基于Zookeeper，Prana 基于Eureka

從 Sidecar 到 Service Mesh

Sidecar 方案都建立在特定的基礎組件之上，而我們需要的是一種基礎組件無關的解決方案，這種模型叫做 Service Mesh
如果給每個服務配套一個代理 Sidecar，服務間僅通過代理互相通信，最終得到了類似這樣的部署模型：

即，代理之間相互連接形成了一個網狀網格，稱之為 Service Mesh（服務網格）：

服務網格是處理服務到服務通信的專用基礎結構層。
它負責通過復雜的服務拓撲結構可靠地傳遞請求，這些服務構成了一個現代的云本地應用程序。

具體的，Service Mesh 能夠提供Service Discovery、負載均衡、加密、觀察/跟蹤、身份驗證和授權，以及熔斷機制等支持。
從 Sidecar 到 Service Mesh，關鍵在于以更高的視角看待這一個個代理，發現它們形成的網絡所具有的價值：

Service Mesh + 部署平臺

Service Mesh 很自然地與（掌控著 Service 的）部署平臺擦出了火花（如Istio + Kubernetes），進而衍生出了控制層（Control Plane），讓這層基礎設施變得配置化：

并最終形成了控制層 + 數據層的上下結構：

其中，管理實例間網絡流量的部分稱為數據層（Data Plane），數據層的行為由控制層（Control Plane）生成的配置項來控制，而控制層一般會提供 API、CLI 以及 GUI 等多種方式管理應用

參考

http://www.ayqy.net/blog/service-mesh/