ServiceMesh 如何幫助 SRE

要監控服務，而不是服務器或者容器什麼的。

在之前的文章中，我們介紹了 SRE 應該圍繞 SLO 展開運維工作，我們也知道了監控是獲得 SLO 相關第一手數據的重要手段。SRE 所希望的監控，是直接從服務的關鍵路徑上獲取的狀態信息；從運行服務的服務器或者容器的獲得的狀態信息在，只能間接說明服務的狀態，這就是本文開頭那句話的含義。

服務網格

對於一個基於 HTTP 的業務來說，直接拿到每個請求的返回代碼，無疑是一個核心的監控措施。從架構上說，通過負載均衡器是可以非常客觀的獲得後端服務的這個監控指標的。

隨着業務的逐漸複雜，通過負載均衡器來訪問服務的不僅僅是最終客戶，也可能是另一個服務：

隨着流量的上升，我們希望負載均衡器也能一起水平擴展：

顯然，負載均衡器的數量沒有必要比服務 B 的數量還多，如果我們將負載均衡的功能直接集成到服務 B 中呢？

流量控制：對應負載均衡器的流量導向
服務發現：讓負載均衡器的後端更靈活，更易於管理
鏈路跟蹤：通過向流量中注入追蹤信標，可以更容易的流量的來龍去脈進行跟蹤並分析服務瓶頸
安全與權限控制：通過對流量進行加密和注入權限控制屬性，可以更方便地進行安全管理跟 Kubernetes 的 sidecar 技術結合，以上工作都可以在應用程序無感的前提下實現，這個就是著名的 Istio。

在 Stackdriver 中，可以直接查看服務的監控信息：

也可以查看服務組件之間的調用關係：

Stackdriver 的 SLO 監控面板可以直接提供與 SLO、錯誤預算相關的數據：

在服務網格 (或者更直接點，Istio) 的幫助下，SRE 工程師可以通過直接更新 VirtualService 實現流量切換的辦法完成升級。

因爲切換流量的執行速度非常快，整個升級過程將會很平順。

更進一步，我們可以使用流量分配功能，將部分流量引導到新版本：

由於只分配了部分流量到新版本，那麼即使新版本有瑕疵，也只會消耗一小部分錯誤預算。我們可以重複這個過程：

在這個過程中，我們可以一邊監控錯誤預算的消耗，一邊控制流量的轉移，並可以設定條件，如果錯誤預算的消耗超過某個閾值就回滾到初始狀態：

ASM 作爲谷歌雲託管的服務網格解決方案產品，在開源的 Istio 的基礎上，主要還提供了以下的能力：

控制平面託管

託管的指標收集器：ASM 可以觀察服務的運行狀況和性能。依賴於 Sidecar 代理，攔截到工作負載的所有入站和出站 HTTP 流量，並將數據報告給 ASM。從而，開發人員無需注入任何代碼即可收集遙測指標數據。

託管的 CA：ASM 提供 Google 全託管的 CA(Certificate authority) 服務，可以幫助你配置 Service Mesh 的 CA 服務。

Traffic Director：是一個用於服務網格的完全託管且生產可用的流量控制平面。使用 Traffic Director，您可以輕鬆地在多個區域中的羣集和 VM 實例之間部署 Global 負載平衡，減輕服務代理的運行狀況檢查的壓力，以及配置複雜的流量控制策略。

開箱即用的服務管理能力

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/H7DjDrks80NPg75X00Ow7w