這一輪，skywalking勝出

• 2019 年 11 月 10 日
• 筆記

了解xjjdog的都知道，在微服務trace方面，我在兩家公司實施了uber的jaeger。但是，jaeger雖然可以搜集調用鏈資訊並查詢，但統計圖表相對欠缺，尤其對於服務間調用關係部分，不夠直觀。

今天，我們來看一下skywalking，以及和它很像的pinpoint。說它們是近親，是因為它們都是基於agent探針技術進行實施的。

如果你不了解探針是何方神聖，xjjdog以前也普及過一篇文章。

《冷門instrument包，功能吊炸天》

一、概述

引入微服務雖然解決了一部分問題，但大大增加了系統維護難度及複雜度。而調用鏈監控正是解決微服務複雜性所帶來的一系列問題的強效手段。

那麼問題來了：調用鏈有啥用？為什麼上調用鏈？不上隔壁產品會不會來打我？

答：

1.解決出現問題後，難以定位。——對整個調用鏈路有個完善的監控

2.解決鏈路複雜。——清晰的鏈路圖譜反映服務之間的依賴、調用關係

3.整體系統性能及運行情況，需要明確的體現，才能根據實際情況調整資源

目前市面面上主流的調用鏈有：jaeger,pinpoint,Zipkin,CAT,skywalking等等，本次僅針對需求進行介紹。

二、對比(skywalking&pinpoint)

以上提到的調用鏈監控功能都大差不差，那關鍵就在於我們想要的——服務拓撲，以及更加直觀的展示。

於是其他選手被一波帶走，這樣場上就只剩兩位參賽者了。到底誰nb，且聽我慢慢道來。

當看到Hbase……唔……嗯。走好……不送……告辭…… 勝者——skywalking！ 這麼草率當然有人不服，放出pinpoint的ui，諸位感受一下。

坐標： https://naver.github.io/pinpoint/ 感興趣的小夥伴可私下嘗試。

三、skywalking

不要問為啥是它，問就是信仰！就像裝機用asus一樣。但姑且還是介紹一下……

skywalking是一個開源的觀測平台, 用於從服務和雲原生基礎設施收集, 分析, 聚合以及可視化數據，它提供了一種簡便的方式來清晰地觀測分散式系統, 甚至可以觀測橫跨不同雲的系統.

名詞解釋

服務(Service)： 表示對請求提供相同行為的一系列或一組工作負載. 在使用打點代理或 SDK 的時候, 你可以定義服務的名字. 如果不定義的話, SkyWalking 將會使用你平台上定義的名字

服務實例(Service Instance)： 上述的一組工作負載中的每一個工作負載稱為一個實例. 就像 Kubernetes 中的 pods 一樣, 服務實例未必就是作業系統上的一個進程. 但當你在使用打點代理的時候, 一個服務實例實際就是作業系統上的一個真實進程

端點(Endpoint)： 對於特定服務所接收的請求路徑, 如 HTTP 的 URI 路徑和 gRPC 服務的類名 + 方法簽名.

架構

SkyWalking 邏輯上分為四部分: 探針, 平台後端, 存儲和用戶介面。

探針基於不同的來源可能是不一樣的, 但作用都是收集數據, 將數據格式化為 SkyWalking 適用的格式

平台後端是一個支援集群模式運行的後台, 用於數據聚合, 數據分析以及驅動數據流從探針到用戶介面的流程. 平台後端還提供了各種可插拔的能力, 如不同來源數據(如來自 Zipkin)格式化, 不同存儲系統以及集群管理. 你甚至還可以使用觀測分析語言來進行自定義聚合分析

存儲是開放式的. 你可以選擇一個既有的存儲系統, 如 ElasticSearch, H2 或 MySQL 集群(Sharding-Sphere 管理), 也可以選擇自己實現一個存儲系統. 當然, 我們非常歡迎你貢獻新的存儲系統實現

用戶介面對於 SkyWalking 的最終用戶來說非常炫酷且強大. 同樣它也是可訂製以匹配你已存在的後端的

四、限制

那麼skywalking是否真的就天下無敵呢？成也探針，敗也探針，限制就在它身上。

進程內傳播在大多數情況下成為可能。許多高級程式語言(如 Java, .NET)都是用於構建業務系統. 大部分業務邏輯程式碼對於每一個請求來說都運行在同一個執行緒內, 這使得傳播是基於執行緒 ID 的, 以確保上下文是安全的.

僅僅對某些框架和庫奏效。因為是代理來在運行時修改程式碼的, 這也意味著代理插件開發者事先就要知道 所要修改的程式碼是怎麼樣的. 因此, 在這種探針下通常會有一個已支援的列表清單.支援服務列表：

https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Supported-list.md

跨執行緒可能並非總是奏效 如上所述, 每個請求的程式碼大都運行在一個執行緒之內, 對於業務程式碼來說尤其如此. 但是在其他一些場景下, 它們也會在不同執行緒下工作, 比如指派任務到其他執行緒, 任務池, 以及批處理. 對於一些語言, 可能還提供了協程或類似的概念如 Goroutine, 使得開發者可以低開銷地來執行非同步操作, 在這些場景下, 自動打點可能會遇到一些問題。

五、使用

主介面

除一些圖表、top榜之外。還可查看全局 或 某個服務 或某個節點的詳細資訊。(如 請求、JVM等)

拓撲圖

如下圖所示，為當前服務調用關係拓撲。但存在一定局限性，具體說明如下：

1.服務間必須要存在流量關係才會顯示 2.默認顯示10分鐘內，最大顯示1小時內服務調用。（後期可能會有優化） 3.需使用chrome，firefox等正經瀏覽器。搜狗/360等瀏覽器，無法顯示拓撲 4.點擊某個服務節點，將顯示依賴關係 5.點擊連線中點將顯示請求資訊 6.刷新按鈕 將顯示最近10分鐘拓撲，並重置當前所有查詢 及 操作 7.根據線條流向，可獲知調用 <-> 被調用關係 8.因探針無法支援，部分服務顯示為ip。如mysql，postgresql，memcached，redis，mongodb，kafka，xxl-job（顯示圖標） 9.紅色節點表示最近存在請求失敗的情況 10.顯示的服務名，與發布系統名一致。若eureka服務名 & 發布系統名不同可能難以檢索服務

若想看order-rpc服務的調用關係，可進行搜索，結果如下圖【不要開自動刷新，會被無限重置】

調用鏈

通過【追蹤】進入調用鏈查看介面，可通過服務、實例、請求狀態等進行查詢。具體說明如下： 1.查詢默認按持續時間倒序 2.可按追蹤id查詢相關介面 3.可切換調用鏈展現形式以進行不同分析 4.可單機某個節點查看具體資訊，如sql、堆棧資訊等

End

以上就是skywalking的常用功能，更多方式各位大佬可自由探索。嗯嗯，現在我手裡，除了jaeger，又多了一個推薦選項。任何東西，還是要試一試，才知道它到底是不是美妙呀。