緣由與名稱的由來 #
這個部分已經有大神說明得很好，不想再重複造輪子：
解決的痛點 #
這篇文章說明了「原始通信 → 微服務 → Service Mesh」發展的沿革，每次迭代都是為了解決先前的問題。
現在是分散式系統、微服務當道的時代，雖然已有大神將做分散式系統需要的通訊功能，如 Load Balance、Service Discovery、Circuit Break 等等，從程式碼中抽出，像 Spring Cloud 所做的事，但也產生以下的幾個問題：
語言有關 #
框架與應用程式一起打包，所以和應用程式開發使用的語言密切有關；有些語言沒有這類的框架支援
不透明性 #
框架對應用程式而言並不是透明的，應用程式必然知道它的存在；通常都和應用程式耦合，無可避免的侵入
難以管理 #
框架不是我們開發的，我們不太好管理它的錯誤或依賴複雜時的升級，有時根本連追蹤問題都做不到
就 Kubernetes 原生的通訊機制而言：
- Kube-proxy：實現了 Service 對多個 Pod 之間的流量負載平衡，但在 Pod 出問題時不會嘗試轉發給其他 Pod，而是會重啟不正常的 Pod；NodePort Service 無法直接使用 TLS，只能在 K8S Cluster 內 route 流量，也無法直接做精細流量管理
- Ingress：負責與外部通訊，必須與各種 Ingress Controller 對接，Ingress 只能用在 OSI L7 負載平衡（HTTP），無法直接 route L4 的 TCP/UDP 流量
Service Mesh 解決了這些問題，透過 sidecar 代理接管服務間的通訊、徹底與應用程式解耦，傳輸資訊的搜集也使服務的除錯更加容易，請求在不同服務間中穿梭更加可靠。
Service Mesh 究竟是啥 #
我知道前面文章一定有人沒看，就想知道它為啥會有這個名字？
先來直譯一下：
再來看看 Service Mesh 一詞的發明人，Buoyant 的 CEO William Morgan 是怎麼去形容它的：
Buoyant’s CEO William Morgan made the observation that the the interconnection between proxies form a mesh network. In early 2017, William wrote a definition for this platform, and called it a 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. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
（服務網格是一個基礎設施層，用於處理服務間通信。 雲原生應用有著複雜的服務拓撲，服務網格保證請求在這些拓撲中可靠地穿梭。 在實際應用當中，服務網格通常是由一系列輕量級的網路代理組成的，它們與應用程式部署在一起，但對應用程式透明。）
粗暴地說，Service Mesh 就是利用輕量級的網路代理形成的拓墣結構，攔截並代理處理通訊。
下圖中綠色代表應用程式的 container，藍色代表 proxy（圖片來自本篇文章最前面推薦的連結），看看這樣子是不是很符合它的名字「Service Mesh」呢？
Published