可觀察性是一把覆蓋多個移動部件的寬傘。服務網格覆蓋了很多領域，無需我們編寫一行代碼。
服務網格和可觀察性是微服務社區中的熱門話題。在本趨勢報告中，我們將詳細探討服務網格以及良好的可觀察性堆棧如何幫助我們克服使用微服務時面臨的一些最緊迫的挑戰。
常見的微服務挑戰
采用微服務很難。調試并確保它們繼續運行更加困難。微服務以第 2 天操作的形式引入了大量開銷。讓我們深入探討使使用微服務變得困難的幾個方面。
在分布式系統中調試錯誤是一場噩夢
微服務的分布式特性使得調試錯誤變得困難。在單體應用中，只需查看日志和堆棧跟蹤就足以確定錯誤的根本原因。當涉及到微服務時，事情就不是那么簡單了。在出現錯誤的情況下，挖掘微服務的日志可能無法直接指出確切的問題。相反，它可以簡單地提及從依賴微服務收到的請求和/或響應中存在的錯誤。
換句話說，我們必須跟蹤整個網絡跟蹤以確定哪個微服務是問題的根本原因。這是一個非常耗時的過程。
識別系統中的瓶頸并不容易
在單體應用中，識別性能瓶頸就像分析我們的應用程序一樣容易。分析通常足以確定代碼庫中哪些方法最耗時。這有助于您將優化工作集中在一小段代碼上。不幸的是，找出導致整個系統變慢的微服務是一項挑戰。
單獨測試時，每個微服務似乎都表現出色。但在現實世界的場景中，每項服務的負載可能會有很大差異。可能存在一些其他微服務所依賴的核心微服務。在孤立的測試環境中復制此類場景非常困難。
維護微服務依賴樹很困難
微服務的全部意義在于我們可以發布新軟件的敏捷性。話雖如此，重要的是要注意發布微服務時可能會產生多種下游影響。某些經常破壞功能的事件是：
- 在上游依賴之前釋放依賴的微服務
- 刪除遺留系統仍然依賴的已棄用 API
- 發布破壞 API 兼容性的微服務
當微服務之間沒有明確的依賴樹時，這些事件變得難以避免。依賴樹可以更輕松地通知適當的團隊并更好地計劃發布。
可觀察性：微服務問題的解決方案
我上面提到的所有問題都可以通過可觀察性來解決。根據 Jay Livens 的說法，可觀察性是一種根據系統生成的指標和日志捕獲系統當前狀態的做法。它是一個系統，可以幫助我們監控應用程序的健康狀況，生成故障警報，并在問題發生時捕獲足夠的信息來調試問題。
圖 1：具有開源示例的可觀察性堆棧組件
任何可觀察性堆棧都將具有以下組件：
- 指標/日志的來源——我們用來生成數據的代理或庫
- Metric/log shipper——將數據傳輸到存儲引擎的代理；通常嵌入在度量源中
- 收集器/存儲- 負責存儲生成的數據的有狀態服務
- 儀表板——精美的圖表，使我們易于解釋和消化數據
- 警報管理器——負責觸發通知的服務
對我們來說幸運的是，有一些強大的開源工具可以幫助簡化設置可觀察性堆棧的過程。
介紹服務網格
可觀察性的一個主要方面是捕獲網絡遙測，擁有良好的網絡洞察力可以幫助我們解決我們最初談到的許多問題。通常，生成此遙測數據的任務由開發人員來實現。這是一個極其繁瑣且容易出錯的過程，并不會真正以遙測結束。開發人員還負責實施安全功能并使通信能夠抵御故障。
理想情況下，我們希望我們的開發人員編寫應用程序代碼，而不是別的。微服務網絡的復雜性需要下推到底層平臺。實現這種解耦的更好方法是使用服務網格，如Istio、Linkerd或Consul Connect。
服務網格是一種用于控制和監控微服務網絡和通信的架構模式。
讓我們以 Istio 為例來了解服務網格是如何工作的。
圖 2：典型的服務網格架構
來源：圖片改編自 Istio 文檔
服務網格有兩個主要組件：數據平面和控制平面。數據平面負責管理我們的微服務將產生的所有網絡流量。為了實現這一點，服務網格會在我們的每個微服務旁邊注入一個 sidecar 代理。這個 sidecar，通常是 Envoy，負責透明地攔截流過服務的所有流量。另一方面，控制平面僅負責配置代理。沒有應用程序流量到達控制平面。
如圖 2 所示，服務網格架構可幫助您抽象出我們之前談到的所有復雜性。最好的部分是我們可以開始使用服務網格，而無需編寫任何代碼。服務網格幫助我們管理基于微服務的架構的多個方面。一些顯著的優勢包括：
- 全面了解流量如何流動
- 控制網絡流量
- 保護微服務通信
在圖 3 中，應用 A 正在向應用 B 發出請求。由于位于每個應用旁邊的 Envoy 代理正在攔截請求，因此它們對流經這兩個微服務的流量具有完全的可見性。代理可以檢查此流量以收集信息，例如發出的請求數和每個請求的響應狀態代碼。
換句話說，服務網格可以幫助我們回答以下問題：
- 哪個服務正在與哪個對話？
- 每個微服務觀察到的請求吞吐量是多少？
- 每個 API 的錯誤率是多少？
圖 3：服務網格可以幫助收集指標
控制網絡
服務網格不僅僅是一個沉默的旁觀者。它可以積極參與塑造所有網絡流量。用作 sidecar 的 Envoy 代理是 HTTP 感知的，并且由于所有請求都流經這些代理，因此可以將它們配置為實現幾個有用的功能，例如：
- 自動退出——在遇到網絡錯誤時重放請求的能力
- 斷路——將已停止響應的上游微服務的不健康副本列入黑名單
- 請求重寫——在滿足某些條件時設置標頭或修改請求 URL 的能力
圖 4： 服務網格可以塑造網絡流量
它并沒有在這里結束。代理還可以根據一定的權重分割流量。例如，我們可以將代理配置為將 95% 的傳入流量發送到服務的穩定版本，而其余的可以重定向到金絲雀版本。這可以通過支持金絲雀部署等高級實踐來幫助我們簡化發布管理流程。
保護微服務通信
使用服務網格的另一個巨大優勢是安全性。我們的 sidecar 代理可以配置為使用雙向 TLS。這可確保所有網絡流量在傳輸過程中自動加密。管理和輪換 mTLS 所需證書的任務由服務網格控制平面完全自動化。
服務網格還可以通過選擇性地允許哪個服務與哪個服務進行通信來協助訪問控制。所有這些都可以幫助我們徹底消除諸如中間人攻擊等一整套安全漏洞。
圖 5：服務網格可以保護網絡流量
服務網格如何幫助提高可觀察性？
我們剛剛看到了服務網格如何捕獲遙測數據。讓我們更深入地了解這些數據可以支持什么樣的用例。
分布式跟蹤
我們已經討論了調試微服務有多么困難。解決這個可調試性問題的一種方法是通過分布式跟蹤——捕獲請求生命周期的過程。僅一張圖表就可以更容易找出問題的根本原因。
大多數服務網格會自動收集網絡跟蹤并將其發送到 Jaeger 等工具。您需要做的就是在應用程序代碼中轉發一些 HTTP 標頭。而已！
流量指標
服務網格可以幫助我們收集必須監控的四個黃金信號中的三個，以確定服務的健康狀況：
- 請求吞吐量——每個微服務正在服務的請求數
- 響應錯誤率——失敗請求的百分比
- 響應延遲——微服務響應所需的時間；這是一個直方圖，您可以從中提取n 個百分位數的延遲
服務網格收集的指標還有很多，但這些是迄今為止最重要的指標。這些指標可用于支持幾個有趣的用例。其中一些包括：
- 根據請求吞吐量等高級參數啟用擴展
- 啟用高級流量控制功能，例如速率限制和斷路
- 執行自動化 Canary 部署和 A/B 測試
服務網格可以幫助我們自動構建網絡拓撲，可以通過將跟蹤數據與流量指標相結合來構建。如果你問我，這是一個真正的救星。網絡拓撲可以幫助我們一目了然地可視化整個微服務依賴樹。此外，它還可以突出我們集群的網絡健康狀況。這對于識別我們的應用程序中的瓶頸非常有用。
結論
可觀察性是一把覆蓋多個移動部件的寬傘。對我們來說幸運的是，像服務網格這樣的工具覆蓋了很多領域，而不需要我們編寫一行代碼。簡而言之，服務網格通過以下方式幫助我們：
- 生成分布式跟蹤數據以簡化調試
- 充當關鍵指標的來源，例如微服務監控的黃金信號
- 生成網絡拓撲
