Apache SkyWalking 在 Service Mesh 中的可觀察性應用 | 線上直播回顧

時間 2020-07-12

標籤 apache skywalking service mesh 觀察應用線上直播回顧欄目 Apache 简体版

原文原文鏈接

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 下載地址。

前言nginx

本次演講爲你們分享的是 Apache SkyWalking 對 Service Mesh 可觀測性方面的應用實踐，共分爲三個部分：

第一部分是 Apache SkyWalking 的相關背景；
第二部分是 Service Mesh 場景下 SkyWalking 所面臨的挑戰；
最後是針對 Service Mesh 場景方案的演化；

SkyWalking 的歷史沿革及其特色git

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 面對的挑戰github

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

回顧視頻以及 PPT 下載地址