贈書 | 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的拓撲圖，則需要產生如下兩條數據：
sourceServiceId = A
...
destServiceId = B
sourceServiceId = B
...
destServiceId = 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點
更多推薦閱讀