這一輪，skywalking勝出

原創：小姐姐味道（微信公衆號ID：xjjdog），歡迎分享，轉載請保留出處。

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

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

若是你不瞭解探針是何方神聖，xjjdog之前也普及過一篇文章。

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

1、概述

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

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

答：

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

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

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

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

2、對比(skywalking&pinpoint)

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

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

	PinPoint	Skywalking
項目發起人	Woonduk Kang (韓囯）	吳晟（中囯）
性能損耗	高	低
用戶	很是多	很是多
社區	非 apache + —般	apache孵化+ QQ官方交流羣+活躍
文檔	詳細	詳細
跟蹤粒度	細	通常
代碼侵入性	無	無
告警	支持	支持
JVM監控	支持	支持
UI豐富度	很高	通常
實現方式	字節碼注入	字節碼注入
兼容 OpenTracing	否	是
擴展性	低	高
Traceld 查詞	不支持	支持
發佈包	war	jar
協議	thrift	gRPC
支持語言	Java, PHP	Java, C#, PHP, Node.js
存儲	HBase+MySQL	ES, H2, MySQL, TiDB, Sharding-Sphere
過濾追蹤	filter配置	agent.config + apm-trace-ignore-plugin
組件	collector+Web+agent+存儲	OAP+Web+agent+存儲+zk
GitHub Star	9.4k	10.8k+

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

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

3、skywalking

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

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

名詞解釋

服務(Service)： 表示對請求提供相同行爲的一系列或一組工做負載. 在使用打點代理或 SDK 的時候, 你能夠定義服務的名字. 若是不定義的話, SkyWalking 將會使用你平臺上定義的名字

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

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

架構

SkyWalking 邏輯上分爲四部分: 探針, 平臺後端, 存儲和用戶界面。

探針基於不一樣的來源多是不同的, 但做用都是收集數據, 將數據格式化爲 SkyWalking 適用的格式

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

存儲是開放式的. 你能夠選擇一個既有的存儲系統, 如 ElasticSearch, H2 或 MySQL 集羣(Sharding-Sphere 管理), 也能夠選擇本身實現一個存儲系統. 固然, 咱們很是歡迎你貢獻新的存儲系統實現

用戶界面對於 SkyWalking 的最終用戶來講很是炫酷且強大. 一樣它也是可定製以匹配你已存在的後端的

4、限制

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

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

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

github.com/apache/skyw…

跨線程可能並不是老是奏效 如上所述, 每一個請求的代碼大都運行在一個線程以內, 對於業務代碼來講尤爲如此. 可是在其餘一些場景下, 它們也會在不一樣線程下工做, 好比指派任務到其餘線程, 任務池, 以及批處理. 對於一些語言, 可能還提供了協程或相似的概念如 Goroutine, 使得開發者能夠低開銷地來執行異步操做, 在這些場景下, 自動打點可能會遇到一些問題。

5、使用

主界面

除一些圖表、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，又多了一個推薦選項。任何東西，仍是要試一試，才知道它究竟是不是美妙呀。

做者簡介：小姐姐味道 (xjjdog)，一個不容許程序員走彎路的公衆號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高併發世界，給你不同的味道。個人我的微信xjjdog0，歡迎添加好友，​進一步交流。​