赠书 | SkyWalking 观测 Service Mesh 技术大公开
導讀：本文摘自于SkyWalking創始人吳晟撰寫的《Apache SkyWalking實戰》一書，介紹了SkyWalking對Service Mesh的監控模型，并重點闡述了其與Istio的集成。通過本文，希望你對SkyWalking觀測Service Mesh場景有深入的了解，并從中窺探該方向未來的發展路徑。
Service Mesh的監控往往被稱為可觀測性（Observability），其內涵是要超越傳統的監控體系的。它一般包括監控、告警、可視化、分布式追蹤與日志分析。可見可觀測性是監控的一個超集。監控認為目標系統是一個“黑盒”，通過觀察其關鍵指標來展現系統狀態，并報告異常情況。而可觀測性在此基礎上增加了“問題定位”的功能，通過可視化、分布式追蹤和日志分析功能來提供給用戶交互式定位問題的能力。
傳統應用的SRE只能夠通過監控系統發現失敗的目標應用，而后由產品工程師來從代碼層面最終定位到具體問題。對于維護基于Service Mesh的微服務集群，SRE就需要可觀測性賦予的各種綜合能力來發現更加具體的問題，這種過程類似于在微服務集群中進行調試操作。
可觀測性是Service Mesh原生就需要解決的核心問題。由于Service Mesh被認為是新一代的基礎設施，在其上構建可觀測組件將會比在應用中構建更為便捷。同時，隨著基礎設施的落地與標準的逐步成型，可觀測組件將會進行穩定的演進，而不會隨著應用技術棧的變遷而推倒重來。基于以上原因，作用于Service Mesh之上的可觀測性將會有更強的生命力與更大的商業潛力。
本章首先介紹SkyWalking的可觀測性模型，然后以Istio和Envoy為例來介紹SkyWalking對它們的觀測手段和未來技術的演進趨勢。
SkyWalking可觀測性模型
1、監控指標
SkyWalking主要使用“黑盒”追蹤模型來生成Service Mesh的監控指標。與經典“黑盒”算法不同，SkyWalking并不會使用回歸模型生成單條Trace數據，而是直接使用分析引擎構建監控指標和拓撲圖。
如圖所示，SkyWalking從Service Mesh數據平面獲取到圖中被標記為奇數的請求數據（1，3，5，7，9，11）。傳統的“黑盒”算法會嘗試還原被標記為偶數的鏈路，從而形成完整的調用鏈。而SkyWalking會直接進行匯總統計，計算出兩節點之間的監控指標，再使用這些成對的數據構建出一段時間內的拓撲圖。
Service Mesh 流量圖
故SkyWalking在Service Mesh模式下，Trace功能是缺失的，而其他功能是完好的。這是在效率和功能完整性之間的平衡。當然，如果希望使用Trace功能，可以通過另外一套SkyWalking集群實現。
通用Service Mesh的協議保存在https://github.com/apache/skywalking-data-collect-protocol/blob/v6.6.0/service-mesh-probe/service-mesh.proto。目前SkyWalking僅僅支持Istio，如果用戶希望支持其他的Service Mesh平臺，可以使用該協議向SkyWalking寫入監控數據。
讓我們看一下協議的核心內容：
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; }如協議所示，主要內容都是寫入一次調用的雙端信息。這里要注意，要想獲得正確的拓撲圖，服務的ID要保持一致。假如需要生成A→B→C的拓撲圖，則需要產生如下兩條數據：
2、告警與可視化
Service Mesh的監控指標與分布式追蹤的指標是使用統一的引擎聚合計算的，故其告警體系完全可以復用。這里唯一需要注意的是維度的映射。
以Kubernetes環境為例，其內置資源非常豐富，到底用什么資源來映射到SkyWalking的Service呢？這里選擇范圍是很廣泛的，Deployment、Service、Statefulset看起來都可以，甚至一些Custom Resource也是可以的。這就需要使用者進行相關的設計，根據自己系統的狀況來將特定的目標進行映射。目前官方的做法是使用Statefulset來映射到Service，因為它可以指向多種二級資源，監控性非常好。如果用戶有定制化需求，也可以自行添加。
可視化與告警類似，只要維度定義得當，監控指標和拓撲圖就會依照維度進行完美展示。
3、分布式追蹤和日志
從理論上講，Service Mesh并不能給追蹤帶來任何變化。由于Service Mesh僅僅控制了流量的入口和出口，僅僅在proxy和sidecar上增加追蹤上下文的注入并不能將整個上下文在集群內傳播，所以服務本身需要被注入追蹤上下文。
可能有讀者會認為，既然如此，那么就不要在Service Mesh組件內增加傳播模塊了，還能減少額外的消耗而不影響追蹤鏈路。需要說明的是，追蹤標記點越多，其實越能更好地理解系統狀態，幫助定位問題。
這里舉一個例子來說明在Service Mesh組件上增加追蹤能力的作用。一個服務如果響應超時，傳統上我們是不能區分是網絡問題還是服務本身的問題的。但是有了Service Mesh的inbound agent，我們就可以從該agent有無數據來判斷是哪種問題：如果inbound有數據，說明是目標服務的問題；如果inbound沒有數據，則很可能是網絡問題。
對于日志，SkyWalking從系統設計上并不涵蓋日志的搜集和存儲，但是部分用戶在實踐中，會使用LocalSpan將業務日志寫入其中。同時由于7.0.0以后SkyWalking會引入業務擴展字段，可以預見未來將會有更多用戶將SkyWalking作為接收和分析日志的系統。日志、分布式追蹤與監控指標的結合也是SkyWalking后端分析的發展目標。
觀測Istio的監控指標
SkyWalking主要是接受Istio的監控指標來進行聚合分析。由于Istio并不支持SkyWalking的追蹤上下文傳播的功能，故這部分不在討論范圍內。現在讓我們討論一下SkyWalking與Istio的兩種集成模式。
1、Mixer模式集成
除了網絡流量控制服務以外，Istio同時提供了對Telemetry數據集成的功能。Telemetry組件主要通過Mixer進行集成，如圖13-2所示，而這恰恰就是SkyWalking首先與Istio集成的點。早期Istio可以進行進程內的集成，即將集成代碼添加到其源碼進行變異，以達到最高性能。后來Istio為了降低系統的集成復雜性，將該功能演變為進程外的適配器。目前SkyWalking就是采用這種進程外適配器進行集成的。
SkyWalking集成Mixer
未來Mixer 2.0版本將會采用Envoy的WASM系統模型進行構建，Mixer插件將可以二進制形式被Envoy進行動態的變異加載。SkyWalking社區會跟進該模式，以實現新的適配器模型。
集成后，我們就可以看到如圖中所示的監控指標頁面和服務拓撲圖了。
監控指標Dashboard
使用Mixer生成的服務拓撲圖
2、ALS模式集成
除了進行Mixer的集成以外，SkyWalking同時可以與Envoy的ALS（Access Log Service）進行相關的系統集成（見圖13-5），以達到Mixer類似的效果。與Envoy集成的優勢在于，可以非常高效地將訪問日志發送給SkyWalking的接收器，這樣延遲最小。但缺點是目前的ALS發送數據非常多，會潛在影響SkyWalking的處理性能和網絡帶寬；同時，所有的分析模塊都依賴于較為底層的訪問日志，一些Istio的相關特性不能被識別。比如這種模式下只能識別Envoy的元數據，Istio的虛擬服務等無法有效識別。對比圖13-6與圖13-4所示的拓撲圖，我們并沒有發現istio-policy組件，這是由于該組件與sidecar之間的通信是不通過Envoy轉發的，故從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 = A<br>...<br>destServiceId = B<br>sourceServiceId = B<br>...<br>destServiceId = C<br></code></pre></div>使用ALS生成的服務拓撲圖
觀測Istio的技術發展
目前Istio和SkyWalking都處于高速發展之中。Istio對于可觀測的演進主要有以下幾個方面。
Mixer被移除。Mixer由于其性能問題將被移除，上面介紹的第一種集成模式很快會成為歷史。
Envoy WASM將會替代Mixer成為可觀測的主力。未來，SkyWalking將會深度與Envoy WASM技術結合，它會帶來如下好處：
開發靈活。WASM技術類似Nginx的LuaJIT，依靠C++與Rust語言，可以獲得很好的靈活性。
性能優良。由于WASM代碼會被編譯到Envoy內部，其性能有很好的保證。
功能豐富。根據不能的場景，可以提供不同的插件組合，組合出更豐富的功能。基于以上的特點，SkyWalking對于Envoy和Istio可能有以下演進方向的影響。
使Envoy和Istio支持SkyWalking專用的追蹤傳播協議。
精細控制Envoy發送到OAP的數據粒度，目前ALS模式傳入的數據過于繁雜，且不能裁剪，使用WASM插件后希望可以進行更細的控制。
支持更多的控制平面。由于使用Envoy作為數據平面的Service Mesh系統已經有一定規模，使用WASM模式可以避免與特定控制平面綁定，從而支持更多的系統。
關于SkyWalking的實戰內容推薦閱讀《Apache SkyWalking實戰》一書，本文經出版社授權發布。
作者簡介：吳晟，Apache基金會會員，Apache SkyWalking創始人、項目VP和PMC成員，Apache孵化器PMC成員，Apache ShardingSphere PMC成員，Apache APISIX (incubating) PPMC成員，Apache ECharts (incubating)和Apache DolphinScheduler (incubating)孵化器導師，Zipkin成員和貢獻者，CNCF OpenTracing核心維護者。
#歡迎來留言#
對此，你怎么看？
留言點贊數量最多的前三名
CSDN攜手【機械工業出版社】送出吳晟撰寫的
《Apache?SkyWalking實戰》一本
截至8月14日12:00點
更多推薦閱讀
中臺架構詳解（上） | 大咖說中臺
游戲行業應該如何建設數據中臺？
30 年開源老兵，10 年躬耕 OpenStack，開源 1000 萬行核心代碼
Python再奪冠，上古語言COBOL大流行，IEEE Spectrum 2020年度編程語言排行榜出爐！
美國禁止與字節跳動及微信交易，騰訊股價暴跌，字節跳動回應了
總結
以上是生活随笔為你收集整理的赠书 | SkyWalking 观测 Service Mesh 技术大公开的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AWS拓展中国合作伙伴生态 加速企业数字
- 下一篇： Spring 从入门到入土——AOP 就