Service Mesh Virtual Meetup 是 ServiceMesher 社區和 CNCF 聯合主辦的線上系列直播。本期為 Service Mesh Virtual Meetup#1 ，邀請了四位來自不同公司的嘉賓，從不同角度展開了 Service Mesh 的應用實踐分享，分享涵蓋 Service Mesh 的可觀察性和生產實踐以及與傳統微服務中可觀察性的區別，還有如何使用 SkyWalking 來觀測 Service Mesh，來自陌陌和百度的 Service Mesh 生產實踐。
本文根據5月7日晚，美國 Service Mesh 服務商 Tetrate 創始工程師高洪濤的主題分享《Apache SkyWalking 在 Service Mesh 中的可觀察性應用》整理。文末包含本次分享的視頻回顧鏈接以及 PPT 下載地址。
前言
本次演講為大家分享的是 Apache SkyWalking 對 Service Mesh 可觀測性方面的應用實踐，共分為三個部分：
- 第一部分是 Apache SkyWalking 的相關背景；
- 第二部分是 Service Mesh 場景下 SkyWalking 所面臨的挑戰；
- 最後是針對 Service Mesh 場景方案的演化；
SkyWalking 的歷史沿革及其特點
SkyWalking 項目的建設目的是為了解決在微服務環境下，如何快速的定位系統穩定性問題。創始團隊於2016年啟動項目，經過一年的努力完善了最初的版本。2017年，團隊啟動將項目捐獻給 Apache 基金會的流程。在 Apache 基金會孵化器內，經過了多輪系統升級迭代，並獲得近乎翻倍的貢獻者和關注度，於2019年順利畢業。經過經年的升級與維護，SkyWalking 從最開始專注於分佈式追蹤系統的單一平臺，發展為包含多個門類並擁有豐富的功能的全領域 APM 系統。
SkyWalking 整體的系統架構包括有三個部分:
- 第一個是數據採集端，可以使用語言探針對系統的監控指標進行採集，同時也提供了一套完整的數據採集協議。第三方系統可以使用協議將相關的監控數據上報到分析平臺。
- 第二部是分析平臺，主要包括對監控指標數據的蒐集，流式化處理，最終將數據寫到存儲引擎之中。存儲引擎可使用Elasticsearch，MySQL數據庫等多種方案。
- 第三部分是 UI。UI 組件有豐富的數據展示功能，包含指標展板，調用拓撲圖，跟蹤數據查詢，指標比較和告警等功能。
在此基礎上，SkyWalking 本身組件具有豐富的定製功能，方便用戶去進行二次開發以支持自己特有的場景。
SkyWalking 定義了三個維度用來綁定相關的監控指標數據。
- 服務(Service)：表示對請求提供相同行為的一系列或一組工作負載。在使用打點代理或 SDK 的時候, 你可以定義服務的名字。如果不定義的話，SkyWalking 將會使用你在平臺上定義的名字, 如 Istio。
- 實例(Instance)：上述的一組工作負載中的每一個工作負載稱為一個實例。就像 Kubernetes 中的 Pod 一樣, 服務實例未必就是操作系統上的一個進程。但當你在使用打點代理的時候，一個服務實例實際就是操作系統上的一個真實進程。
- 端點(Endpoint)：對於特定服務所接收的請求路徑，如 HTTP 的 URL 路徑和 gRPC 服務的類名 + 方法簽名。
預定義的維度可以方便的進行數據預彙集操作，是 SkyWalking 分析引擎重要的組成部分。雖然其相對的會有使用不夠靈活的缺點，但在 APM 場景下，指標往往都是預先經過精心設計的，而性能才是關鍵因素。故 SkyWalking 採用這種預定義維度模式來進行數據彙集操作。
Service Mesh 場景下 SkyWalking 面對的挑戰
在描述 Service Mesh 的場景下所面臨的挑戰之前，需要去解釋可觀測性所包含的含義。可觀測性一般包含有三個部分:
- 第一點，日誌系統。由其可以構建出系統運行的實時狀態。故日誌成為非常方便的觀測手段。
- 第二點，分佈式追蹤。這部分數據在微服務場景下具有強大的生命力，可以提供給用戶分佈式系統觀測指標。
- 第三點，指標監控。相比於日誌和分佈式追蹤，其具有消耗小，處理簡便等特點，通常作為系統監測告警的重要數據來源。
如上所示是 Istio1.5 的架構圖。重點看一下他對可觀測性的支持。從圖上看，所有的監控指標都匯聚到中間的 Mixer 組件，然後由 Mixer 再發送給他左右的 Adapter，通過 Adapter 再將這些指標發送給外圍的監控平臺，如 SkyWalking 後端分析平臺。在監控數據流經 Mixer 的時候，Istio 的元數據會被附加到這些指標中。另一種新的基於 Telemetry V2 觀測體系是通過 Envoy 的 Proxy 直接將監控指標發送給分析平臺，這種模式目前還處於快速的演進和開發中，但是它代表著未來的一種趨勢。
從架構圖中我們可以看到，這裡面的第一個挑戰就是 Service Mesh 場景下，對於可觀測性的技術體系的支持是非常多變的。
Istio 本身就包括兩種不融合的體系，第一種是基於 Mixer 的場景，第二種是 Mixerless 場景。
Mixer 是基於訪問日誌進行指標生成的，也就是說服務與服務之間的訪問日誌經過 Mixer 增加相關的原數據後再發給外圍分析系統。其特點是這個模式非常的成熟、穩定，但是性能會非常的低。它的低效源於兩個方面，第一點是他的數據發送通道很長，中間節點過多。可以看到數據需要到從 Proxy 發送到 Mixer 節點，再發送給外圍的 Adapter 節點。另一個效能低下的原因主要是體現在它發送的是原始訪問日誌，其數據量是非常大的，會消耗過多的帶寬，這對整體的數據蒐集與分析提出了非常大的挑戰。
另一種模式是 Mixerless，它完全是基於 Metrics 指標的。通過可觀測性包含的技術及其特點分析可知，它是一種消耗比較小的技術，對帶寬以及分析後臺都是非常友好的。但是它同時也有自己的問題，第一個問題就是他需要的技術門檻是比較高的（使用 WASM 插件來實現），並且對於 Proxy 端的性能消耗也是比較大的。同時由於是新的技術，穩定性較差，相關接口與規範並不完整。
第二個挑戰就是無 Tracing 數據。SkyWalking 最早是為了收集處理跟蹤數據（Tracing）而設計的一套系統，但是我們可以從右邊的圖發現，對於 Service Mesh 上報的數據其實是基於調用的，也就是說它不存在一條完整的跟蹤鏈路。這樣就對後臺的分析模型有比較大的挑戰，如何才能同時支持好這兩種模式成為後端分析系統所要處理的棘手問題。
第三個挑戰就是維度匹配的問題。我們從前一章可以看到 SkyWalking 是包括三個維度的，其中對於實例和端點，在 Service Mesh 場景下都是有比較好的支持。這裡多說一句，不僅僅是對 Mesh 場景，對於大部分場景都可以很好的去匹配它們。但是對於服務的匹配是有相當大難度的，因為 SkyWalking 只有服務這一層的概念，而在 Istio 中有好幾個概念可以稱之為“服務”。如何才能進行相關的維度匹配，特別是對於服務級別的維度匹配，成為了 Service Mesh 是如何與 SkyWalking 結合的另一個關鍵點。
應用方案及其演化
與 Istio 的集成
我們從 Istio 的架構圖中可見，除了網絡流量控制服務以外，Istio 同時提供了對 Telemetry 數據集成的功能。Telemetry 組件主要通過 Mixer 進行集成，而這恰恰就是 SkyWalking 首先與 Istio 集成的點。早期 Istio 可以進行進程內的集成，即將集成代碼添加到其源碼進行變異，以達到最高性能。後來 Istio 為了降低系統的集成複雜性，將該功能演變為進程外的適配器。目前 SkyWalking 就是採用這種進程外適配器進行集成的。
安裝模式有兩種：
- 如果從 Helm Chart 安裝 SkyWalking，可以在 values.yml 文件中將如圖的參數設置為 true。而後 Helm 會自動安裝 SkyWalking 分析後臺，並將它以進程外適配器的模式集成到 Istio 中。
- 如果 SkyWalking 與 Istio 已經安裝，可以使用右圖中所示的 cr 文件來配置 Istio，使其將觀測數據發送到 SkyWalking 中；
安裝完畢後，使用 BookInfo 示例程序進行測試。可以看到維度匹配為：
- 服務 Service：< ReplicaSet >.< Namespace >；
- 實例 Instance: kubernetes://< Pod >；
- 端點 Endpoint：http url；
可以發現 Service 包含了 Namespace。故在不同 Namespace 下，一定是兩個不同的服務。
拓撲圖中除了示例中的服務和 Ingress 外，還包含有 istio-telemetry 組件。這反映了實際的數據流量，但有些用戶會覺得這稍顯冗餘，而後的方案大家會看到此處略有不同。
除了進行 Mixer 的集成以外，SkyWalking 同時可以與 Envoy 的 access log service 進行相關的系統集成，以達到 Mixer 類似的效果。與 Envoy 集成的優勢在於可以非常高效的將訪問日誌發送給 SkyWalking 的接收器，這樣延遲最小。但缺點是目前的 access log service 發送數據非常多，會潛在影響 SkyWalking 的處理性能和網絡帶寬。同時所有的分析模塊都依賴於較為底層的訪問日誌，一些 Istio 的相關特性不能被識別。比如這種模式下只能現實 Envoy 的元數據，Istio 的虛擬服務等概念無法有效的現實。
這種模式需要在安裝 SkyWalking 與 Istio 時進行配置。首先在 SkyWalking 的 Helm 裡將“envoy.als.enabled”設置為 true。而後安裝 Istio 時，需要設置"values.global.proxy.envoyAccessLogService"為如圖中的值。
從拓撲圖中看，與 Mixer 模式最明顯的區別為沒有 istio-telemetry 組件。這是由於該組件並沒有 Envoy Sidecar 來路由流量，故也不會產生訪問日誌。也就是，此種模式完全反應了實際的工作負載情況。
除了上述兩種模式，目前社區正在開發基於 Istio 最新的 TelemetryV2 協議的觀測模型。此種模式是基於 Metrics 監控而不是基於訪問日誌。這種模式將對外暴露兩種 Metrics：
- service level: 這種 Metrics 描述的是服務之間的關係指標，用來生成拓撲圖和服務級別的指標；
- proxy level: 這種 Metrics 描述的 Proxy 進程的相關指標，用來生成實例級別的指標；
此種模式為標椎的 Mixerless，其優點是對分析平臺友好，網絡帶寬消耗小。缺點為需要消耗 Envoy 的資源，特別是對內存消耗大。但是相信經過外來多輪優化，可以很好的解決這些問題。
但此種模式還有另外的缺點，即不能生成端點 Endpoint 的監控指標。如果用戶希望能包含此種指標，還需要使用基於 ALS 訪問日誌的模式。
Tracing 與 Metric 混合支持
在 SkyWalking8.0 之前，如果開啟 Service Mesh 模式，那麼傳統的 Tracing 模式是不能使用的。原因是他們共享了一個分析流水線。如果同時開啟會造成計算指標重複的問題。
在 SkyWalking8.0 中，引入的 MeterSystem 可以避免此種問題的產生。而且計劃將 Tracing 調整為可以配置是否生成監控指標，這樣最終將會達到的效果是：指標面板與拓撲圖的數據來源於 Envoy 的 Metrics，跟蹤數據來源於 Tracing 分析，從而達到支持 Istio 的 Telemetry 在控制面中的所有功能。
另外，Envoy 和 Istio 本身不支持 Skywalking 的遠程 Tracing 協議。目前社區已經嘗試進行 nginx 和 MOSN 等Mesh 環境中常用的 Proxy 的協議支持，後續也會嘗試將 Skywalking 協議添加到 Envoy 中（使用 WASM 插件）。
維度匹配
從安裝過程可以發現，服務 Service 在 Mixer 和 ALS 中的規則為 ReplicaSet+Namespace 的形式。其很難反映 Istio 實際的維度情況。後續在 TelemetryV2 中將會獲得真實的 Istio 服務間映射。同時也會嘗試增加如下的命名規則以區分跨Cluster的情況：“Version|App|Namespace|Cluster”。
總結
本次分享簡要的介紹了 Apache SkyWalking 在 Service Mesh 場景下的應用方案。主要是基於 Istio 做了詳細的介紹，通過三種主要的挑戰而引出的解決方案，將幫助大家更好的理解和使用 SkyWalking 的 Mesh 功能。希望大家有興趣去嘗試使用 SkyWalking 去觀測 Istio。
以上就是此次分享的全部內容，感謝大家的關注與支持！
嘉賓介紹
高洪濤，FoundingEngineer 美國 Service Mesh 服務商 Tetrate 創始工程師。原華為軟件開發雲技術專家，對雲原生產品有豐富的設計，研發與實施經驗。對分佈式數據庫、容器調度、微服務、Servic Mesh 等技術有深入的瞭解。目前為 Apache ShardingSphere 和 Apache SkyWalking 核心貢獻者，參與該開源項目在軟件開發雲的商業化進程。前噹噹網系統架構師，開源達人，曾參與 Elastic-Job 等知名開源項目。