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 等知名開源項目。