一。從網絡的可靠性說起
機器之間可以通過物理連接（例如電纜、電話線、無線電波、衛星或紅外光束等等）傳遞信號，進行信息交換：
然而，數據在傳輸中可能會出現一些異常狀況，例如：
-
數據丟失：數據包可能會到達一個緩衝區已經被塞滿的路由器，接著被丟掉
-
順序出錯：一組數據包可能會途徑閒忙程度不同的多個路由器，出現不同程度的延遲，最後到達順序會與發出時的順序不一致
所以至少要有丟包重發、順序重組等控制機制，早期這部分工作由網絡服務/應用來完成（與業務邏輯並存於應用層）：
後來，這部分工作下沉到了網絡棧（操作系統的網絡層），由 TCP/IP 等標準網絡協議來保證數據傳輸的可靠性（下圖中的大粗線）：
二。微服務架構下的可靠性挑戰
網絡協議提供的可靠性保障對於小型的多機互聯場景而言足夠了，但在大規模的分佈式場景（如 微服務架構）中，需要引入更多的機制來保障整體的可靠性，例如：
-
Service Discovery 機制：通過服務註冊查詢機制，讓一個微服務能夠找到另一個，從而允許動態伸縮、以及故障轉移
-
熔斷機制（Circuit Breaker pattern）：提供斷路保護（就像電表跳閘），防止某個服務不可用引發級聯故障，比如操作不成功導致瘋狂重試，請求堆積，甚至耗盡相關資源，系統中不相關的部分也因此出現故障
同樣，這部分工作早期也是由微服務來完成的（與業務邏輯並存於微服務中）：
緊接著出現了 Finagle、Proxygen 等開源類庫，由專門的類庫來完成這些工作，而不必在每個服務中重複相同的控制邏輯：
然而，隨著系統中服務數量的增多，這種方式也暴露出了一些問題：
-
膠水部分的資源投入：需要投入資源將第三方庫與系統其餘部分連接起來
-
類庫限制了微服務的技術選型：這些類庫通常是特定於平台的，僅支持特定運行時或編程語言，會給微服務的技術選擇造成限制。畢竟，微服務的一大特點就是 允許使用不同的編程語言來編寫不同服務）
-
類庫的維護成本：類庫本身也需要持續維護升級，每次更新都需要重新部署所有服務，即便服務沒有任何改動
這樣看來，類庫似乎不是個理想的解決方案
三。將微服務控制下沉到網絡棧？
既然在應用層解決不太合適，那麼能否如法炮製，下沉到網絡棧呢？
與通用的基礎通信機制不同，這些應用服務相關的控制機制很難交由下層網絡棧來實現，照搬下沉行不通
Sidecar
不能在（服務）裡面，也不能在下面，所以最後放到了旁邊：
即，通過代理來實現這些網絡控制，所有出入流量都經過代理，稱之為 Sidecar：
Sidecar 作為輔助進程，隨應用程序運行在一旁，並為其提供額外的功能
問題似乎已經通過網絡代理完美解決了，業界也出現了一些開源方案：
然而，這些方案都建立在特定的基礎組件之上，例如 Nerve 和 Synapse 基於 Zookeeper，Prana 基於 Eureka，而無法適應不同的基礎組件
那麼，有沒有足夠靈活，基礎組件無關的解決方案呢？
有。叫 Service Mesh
四。從 Sidecar 到 Service Mesh
如果給每個服務配套一個代理 Sidecar，服務間僅通過代理互相通信，最終得到了類似這樣的部署模型：
即，代理之間相互連接形成了一個網狀網格，稱之為 Service Mesh（服務網格）：
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It's responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application.
一個專門處理服務間通信的基礎設施層，保障複雜服務拓撲中通信的可靠性
具體的，Service Mesh 能夠提供 Service Discovery、負載均衡、加密、觀察/跟踪、身份驗證和授權，以及熔斷機制等支持：
The mesh provides critical capabilities including service discovery, load balancing, encryption, observability, traceability, authentication and authorization, and support for the circuit breaker pattern.
從 Sidecar 到 Service Mesh，關鍵在於以更高的視角看待這一個個代理，發現它們形成的網絡所具有的價值：
五。Service Mesh + 部署平台
緊接著，Service Mesh 很自然地與（掌控著 Service 的）部署平台擦出了火花（如 Istio + Kubernetes），進而衍生出了控制層（Control Plane），讓這層基礎設施變得配置化：
並最終形成了控制層 + 數據層的上下結構：
其中，管理實例間網絡流量的部分稱為數據層（Data Plane），數據層的行為由控制層（Control Plane）生成的配置項來控制，而控制層一般會提供 API、CLI 以及 GUI 等多種方式管理應用
即：
暫無評論，快來發表你的看法吧