微服務架構設計 - Service Mesh 服務網格
簡介
了解過 Microservice 與 Kubernetes 的朋友們應該知道它們在軟體開發中扮演者什麼角色，在容器與佈署技術的興起，Kubernetes 持為佈署與管理多容器微服務的利器，但即便 Kubernetes 提供 Microservices 這麼多的幫助，在一些網路流量管理與觀測性上仍然有些可以加強的地方
這種情況 Service Mesh 可以補足這方面的需求，Service Mesh 類似 Kubernetes 的 Add-ons
，安裝到 Kubernetes 後就可以去增強 Cluster 的流量管理能力、觀測性以及安全性
Service Mesh 特性
- App 之間的通訊 Middleware
- 輕量的網路代理
- 解耦 App 的 Retries/Time out/Track/Monitor/Service Discovery
可以把他當作 App(微服務) 之間的代理人，負責每個 App(微服務) 之間的服務呼叫與容錯相關機制
也是因為 Kubernetes, Service Mesh 之類的通用工具出現，在早期軟體開發生態的 Spring Cloud, Netflix Eureka 等之類的工具都把任務交給 Service Mesh 了。
Service Mesh 原理
如上圖 Istio 的 Service Mesh 工作原理圖
Service Mesh 會在每個 Pod 新增一個 Sidecar 代理
這個 Sidecar 對 App(微服務) 來說是透明了，所有 App(微服務)之間的流量都會通過他，也就是說對應 App 的流量控制都可以利用這個 Sidecar 來實現。
Service Mesh 工作流程
- Control Plane 將所有 Service Mesh 推送到所有 Node 的 Sidecar Agent 中
- Sidecar Agent 將服務請求的路由到目的服務，根據參數判斷是什麼環境(Production/Test/Staging)，是公有/私有雲，這些路由資訊可以動態配置也可以全域配置也是單獨配置。
- 當 Sidecar 確認目的位址後，將流量轉發到目的服務，到達 Kubernetes Service 後續交由 Service 轉發給 Pod
- Sidecar 根據觀測到最近請求的 latency 選擇出全部目的 Instance 回應最快的 Instance
- Sidecar 傳送請求並且記錄回應類型與 latency
- 如果 Instance 掛了或出現異常，Sidecar 會在其他 Instance Retry
- 如果 Instance 一直返回錯，Sidecar 就會將該 Instance 從 Load Balance Pool 移除掉，之後再週期性的重試
- 如果請求的截止時間過了，Sidecar 自動判定為失敗
- Sidecar 以 Metric 與分散式追蹤捕抓更方面的數據，這些資訊會集中送到 Metric 系統
總結
根據上述工作原理，我們大概可以了解到 Service Mesh 在 Kubernetes 中起了什麼作用，特別是在請求的容錯機制上以及在網路路徑上的選擇，為我們的服務韌性與觀測性進行升級。
參考資料
- [Day02]在討論Istio之前,我們先來說說什麼是Service Mesh
- Day03 - 強化 Kubernetes 的秘方，服務網格(Service Mesh)介紹
- aws - 什麼是服務網格？
- 服务网格（Service Mesh ）
