導讀：本文摘自于SkyWalking創(chuàng)始人吳晟撰寫的《Apache SkyWalking實戰(zhàn)》一書，介紹了SkyWalking對Service Mesh的監(jiān)控模型，并重點闡述了其與Istio的集成。通過本文，希望你對SkyWalking觀測Service Mesh場景有深入的了解，并從中窺探該方向未來的發(fā)展路徑。

Service Mesh的監(jiān)控往往被稱為可觀測性（Observability），其內(nèi)涵是要超越傳統(tǒng)的監(jiān)控體系的。它一般包括監(jiān)控、告警、可視化、分布式追蹤與日志分析?？梢娍捎^測性是監(jiān)控的一個超集。監(jiān)控認為目標系統(tǒng)是一個“黑盒”，通過觀察其關鍵指標來展現(xiàn)系統(tǒng)狀態(tài)，并報告異常情況。而可觀測性在此基礎上增加了“問題定位”的功能，通過可視化、分布式追蹤和日志分析功能來提供給用戶交互式定位問題的能力。

傳統(tǒng)應用的SRE只能夠通過監(jiān)控系統(tǒng)發(fā)現(xiàn)失敗的目標應用，而后由產(chǎn)品工程師來從代碼層面最終定位到具體問題。對于維護基于Service Mesh的微服務集群，SRE就需要可觀測性賦予的各種綜合能力來發(fā)現(xiàn)更加具體的問題，這種過程類似于在微服務集群中進行調(diào)試操作。

可觀測性是Service Mesh原生就需要解決的核心問題。由于Service Mesh被認為是新一代的基礎設施，在其上構(gòu)建可觀測組件將會比在應用中構(gòu)建更為便捷。同時，隨著基礎設施的落地與標準的逐步成型，可觀測組件將會進行穩(wěn)定的演進，而不會隨著應用技術棧的變遷而推倒重來?；谝陨显?#xff0c;作用于Service Mesh之上的可觀測性將會有更強的生命力與更大的商業(yè)潛力。

本章首先介紹SkyWalking的可觀測性模型，然后以Istio和Envoy為例來介紹SkyWalking對它們的觀測手段和未來技術的演進趨勢。

SkyWalking可觀測性模型

1、監(jiān)控指標

SkyWalking主要使用“黑盒”追蹤模型來生成Service Mesh的監(jiān)控指標。與經(jīng)典“黑盒”算法不同，SkyWalking并不會使用回歸模型生成單條Trace數(shù)據(jù)，而是直接使用分析引擎構(gòu)建監(jiān)控指標和拓撲圖。

如圖所示，SkyWalking從Service Mesh數(shù)據(jù)平面獲取到圖中被標記為奇數(shù)的請求數(shù)據(jù)（1，3，5，7，9，11）。傳統(tǒng)的“黑盒”算法會嘗試還原被標記為偶數(shù)的鏈路，從而形成完整的調(diào)用鏈。而SkyWalking會直接進行匯總統(tǒng)計，計算出兩節(jié)點之間的監(jiān)控指標，再使用這些成對的數(shù)據(jù)構(gòu)建出一段時間內(nèi)的拓撲圖。

Service Mesh 流量圖

故SkyWalking在Service Mesh模式下，Trace功能是缺失的，而其他功能是完好的。這是在效率和功能完整性之間的平衡。當然，如果希望使用Trace功能，可以通過另外一套SkyWalking集群實現(xiàn)。

通用Service Mesh的協(xié)議保存在https://github.com/apache/skywalking-data-collect-protocol/blob/v6.6.0/service-mesh-probe/service-mesh.proto。目前SkyWalking僅僅支持Istio，如果用戶希望支持其他的Service Mesh平臺，可以使用該協(xié)議向SkyWalking寫入監(jiān)控數(shù)據(jù)。

讓我們看一下協(xié)議的核心內(nèi)容：

message?ServiceMeshMetric?{int64?startTime?=?1;int64?endTime?=?2;string?sourceServiceName?=?3;int32?sourceServiceId?=?4;string?sourceServiceInstance?=?5;int32?sourceServiceInstanceId?=?6;string?destServiceName?=?7;int32?destServiceId?=?8;string?destServiceInstance?=?9;int32?destServiceInstanceId?=?10;string?endpoint?=?11;int32?latency?=?12;int32?responseCode?=?13;bool?status?=?14;Protocol?protocol?=?15;DetectPoint?detectPoint?=?16; }

如協(xié)議所示，主要內(nèi)容都是寫入一次調(diào)用的雙端信息。這里要注意，要想獲得正確的拓撲圖，服務的ID要保持一致。假如需要生成A→B→C的拓撲圖，則需要產(chǎn)生如下兩條數(shù)據(jù)：

sourceServiceId?=?A ... destServiceId?=?B sourceServiceId?=?B ... destServiceId?=?C

2、告警與可視化

Service Mesh的監(jiān)控指標與分布式追蹤的指標是使用統(tǒng)一的引擎聚合計算的，故其告警體系完全可以復用。這里唯一需要注意的是維度的映射。

以Kubernetes環(huán)境為例，其內(nèi)置資源非常豐富，到底用什么資源來映射到SkyWalking的Service呢？這里選擇范圍是很廣泛的，Deployment、Service、Statefulset看起來都可以，甚至一些Custom Resource也是可以的。這就需要使用者進行相關的設計，根據(jù)自己系統(tǒng)的狀況來將特定的目標進行映射。目前官方的做法是使用Statefulset來映射到Service，因為它可以指向多種二級資源，監(jiān)控性非常好。如果用戶有定制化需求，也可以自行添加。

可視化與告警類似，只要維度定義得當，監(jiān)控指標和拓撲圖就會依照維度進行完美展示。

3、分布式追蹤和日志

從理論上講，Service Mesh并不能給追蹤帶來任何變化。由于Service Mesh僅僅控制了流量的入口和出口，僅僅在proxy和sidecar上增加追蹤上下文的注入并不能將整個上下文在集群內(nèi)傳播，所以服務本身需要被注入追蹤上下文。

可能有讀者會認為，既然如此，那么就不要在Service Mesh組件內(nèi)增加傳播模塊了，還能減少額外的消耗而不影響追蹤鏈路。需要說明的是，追蹤標記點越多，其實越能更好地理解系統(tǒng)狀態(tài)，幫助定位問題。

這里舉一個例子來說明在Service Mesh組件上增加追蹤能力的作用。一個服務如果響應超時，傳統(tǒng)上我們是不能區(qū)分是網(wǎng)絡問題還是服務本身的問題的。但是有了Service Mesh的inbound agent，我們就可以從該agent有無數(shù)據(jù)來判斷是哪種問題：如果inbound有數(shù)據(jù)，說明是目標服務的問題；如果inbound沒有數(shù)據(jù)，則很可能是網(wǎng)絡問題。

對于日志，SkyWalking從系統(tǒng)設計上并不涵蓋日志的搜集和存儲，但是部分用戶在實踐中，會使用LocalSpan將業(yè)務日志寫入其中。同時由于7.0.0以后SkyWalking會引入業(yè)務擴展字段，可以預見未來將會有更多用戶將SkyWalking作為接收和分析日志的系統(tǒng)。日志、分布式追蹤與監(jiān)控指標的結(jié)合也是SkyWalking后端分析的發(fā)展目標。

觀測Istio的監(jiān)控指標

SkyWalking主要是接受Istio的監(jiān)控指標來進行聚合分析。由于Istio并不支持SkyWalking的追蹤上下文傳播的功能，故這部分不在討論范圍內(nèi)?，F(xiàn)在讓我們討論一下SkyWalking與Istio的兩種集成模式。

1、Mixer模式集成

除了網(wǎng)絡流量控制服務以外，Istio同時提供了對Telemetry數(shù)據(jù)集成的功能。Telemetry組件主要通過Mixer進行集成，如圖13-2所示，而這恰恰就是SkyWalking首先與Istio集成的點。早期Istio可以進行進程內(nèi)的集成，即將集成代碼添加到其源碼進行變異，以達到最高性能。后來Istio為了降低系統(tǒng)的集成復雜性，將該功能演變?yōu)檫M程外的適配器。目前SkyWalking就是采用這種進程外適配器進行集成的。

SkyWalking集成Mixer

未來Mixer 2.0版本將會采用Envoy的WASM系統(tǒng)模型進行構(gòu)建，Mixer插件將可以二進制形式被Envoy進行動態(tài)的變異加載。SkyWalking社區(qū)會跟進該模式，以實現(xiàn)新的適配器模型。

集成后，我們就可以看到如圖中所示的監(jiān)控指標頁面和服務拓撲圖了。

監(jiān)控指標Dashboard

使用Mixer生成的服務拓撲圖

2、ALS模式集成

除了進行Mixer的集成以外，SkyWalking同時可以與Envoy的ALS（Access Log Service）進行相關的系統(tǒng)集成（見圖13-5），以達到Mixer類似的效果。與Envoy集成的優(yōu)勢在于，可以非常高效地將訪問日志發(fā)送給SkyWalking的接收器，這樣延遲最小。但缺點是目前的ALS發(fā)送數(shù)據(jù)非常多，會潛在影響SkyWalking的處理性能和網(wǎng)絡帶寬；同時，所有的分析模塊都依賴于較為底層的訪問日志，一些Istio的相關特性不能被識別。比如這種模式下只能識別Envoy的元數(shù)據(jù)，Istio的虛擬服務等無法有效識別。對比圖13-6與圖13-4所示的拓撲圖，我們并沒有發(fā)現(xiàn)istio-policy組件，這是由于該組件與sidecar之間的通信是不通過Envoy轉(zhuǎn)發(fā)的，故從ALS中無法獲得此信息。

SkyWalking與ALS

<div?class="output_wrapper"?id="output_wrapper_id"?style="font-size:?16px;?color:?rgb(62,?62,?62);?line-height:?1.6;?word-spacing:?0px;?letter-spacing:?0px;?font-family:?'Helvetica?Neue',?Helvetica,?'Hiragino?Sans?GB',?'Microsoft?YaHei',?Arial,?sans-serif;"><pre?style="font-size:?inherit;?color:?inherit;?line-height:?inherit;?margin:?0px;?padding:?0px;"><code?class="hljs?makefile"?style="margin:?0px?2px;?line-height:?18px;?font-size:?14px;?font-weight:?normal;?word-spacing:?0px;?letter-spacing:?0px;?font-family:?Consolas,?Inconsolata,?Courier,?monospace;?border-radius:?0px;?color:?rgb(169,?183,?198);?background:?rgb(40,?43,?46);?overflow-x:?auto;?padding:?0.5em;?white-space:?pre?!important;?word-wrap:?normal?!important;?word-break:?normal?!important;?overflow:?auto?!important;?display:?-webkit-box?!important;">sourceServiceId&nbsp;=&nbsp;A<br>...<br>destServiceId&nbsp;=&nbsp;B<br>sourceServiceId&nbsp;=&nbsp;B<br>...<br>destServiceId&nbsp;=&nbsp;C<br></code></pre></div>

使用ALS生成的服務拓撲圖

觀測Istio的技術發(fā)展

目前Istio和SkyWalking都處于高速發(fā)展之中。Istio對于可觀測的演進主要有以下幾個方面。

Mixer被移除。Mixer由于其性能問題將被移除，上面介紹的第一種集成模式很快會成為歷史。

Envoy WASM將會替代Mixer成為可觀測的主力。未來，SkyWalking將會深度與Envoy WASM技術結(jié)合，它會帶來如下好處：

• 開發(fā)靈活。WASM技術類似Nginx的LuaJIT，依靠C++與Rust語言，可以獲得很好的靈活性。

• 性能優(yōu)良。由于WASM代碼會被編譯到Envoy內(nèi)部，其性能有很好的保證。

• 功能豐富。根據(jù)不能的場景，可以提供不同的插件組合，組合出更豐富的功能?；谝陨系奶攸c，SkyWalking對于Envoy和Istio可能有以下演進方向的影響。

• 使Envoy和Istio支持SkyWalking專用的追蹤傳播協(xié)議。

• 精細控制Envoy發(fā)送到OAP的數(shù)據(jù)粒度，目前ALS模式傳入的數(shù)據(jù)過于繁雜，且不能裁剪，使用WASM插件后希望可以進行更細的控制。

• 支持更多的控制平面。由于使用Envoy作為數(shù)據(jù)平面的Service Mesh系統(tǒng)已經(jīng)有一定規(guī)模，使用WASM模式可以避免與特定控制平面綁定，從而支持更多的系統(tǒng)。

關于SkyWalking的實戰(zhàn)內(nèi)容推薦閱讀《Apache SkyWalking實戰(zhàn)》一書，本文經(jīng)出版社授權(quán)發(fā)布。

作者簡介：吳晟，Apache基金會會員，Apache SkyWalking創(chuàng)始人、項目VP和PMC成員，Apache孵化器PMC成員，Apache ShardingSphere PMC成員，Apache APISIX (incubating) PPMC成員，Apache ECharts (incubating)和Apache DolphinScheduler (incubating)孵化器導師，Zipkin成員和貢獻者，CNCF OpenTracing核心維護者。

#歡迎來留言#

對此，你怎么看？

留言點贊數(shù)量最多的前三名

CSDN攜手【機械工業(yè)出版社】送出吳晟撰寫的

《Apache?SkyWalking實戰(zhàn)》一本

截至8月14日12:00點

更多推薦閱讀

• 中臺架構(gòu)詳解（上） | 大咖說中臺

• 游戲行業(yè)應該如何建設數(shù)據(jù)中臺？
  

• 30 年開源老兵，10 年躬耕 OpenStack，開源 1000 萬行核心代碼
  

• Python再奪冠，上古語言COBOL大流行，IEEE Spectrum 2020年度編程語言排行榜出爐！
  

• 美國禁止與字節(jié)跳動及微信交易，騰訊股價暴跌，字節(jié)跳動回應了

總結(jié)

以上是生活随笔為你收集整理的赠书 | SkyWalking 观测 Service Mesh 技术大公开的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。