Apache SkyWalking提供了一個功能強大而且很輕量級的後端。在此,將介紹爲何採用如下方式來設計它,以及它又是如何工做的。數據庫
架構圖後端
對於APM而言,agent或SDKs僅是如何使用libs的技術細節。手動或自動的形式與架構無關,所以在本文中,咱們不講這些內容,可將這些當作爲Client lib。api
基本原理服務器
關於SkyWalking架構設計的基本原則就是:session
1)易於維護;架構
2)可控;併發
3)基於流;app
爲了達到此目的,SkyWalking後端提供了以下設計:異步
1)模塊化設計;模塊化
2)爲客戶端提供多種鏈接方式;
3)集羣發現機制;
4)流模式;
5)可切換的存儲實現;
1、模塊化
SkyWalking收集器(collector)是基於模塊化設計,用戶能夠根據本身的須要,更改或集成收集器的功能。
2、模塊
模塊定義了一組特性,其中可包括一些技術上的實現(如:grpc/jetty服務器管理)、跟蹤分析(如:trace segment或者zipkin span解析器)或聚合特徵。總而言之,這些都是由模塊來定義和實現的。
每一個模塊均可以經過Java接口定義自身的服務,而實現類均要實現這些服務。而且這些實現類要根據實現的功能定義所依賴的類有哪些。這意味着,即便是模塊的兩個不一樣的實現,也能夠依賴於不一樣的模塊。
另外,收集器中的模塊化核心會檢查啓動序列,若是沒有發現循環依賴或者依賴項,該核心功能會終止收集器。
收集器會啓動全部模塊,這些模塊在application.yml文件中定義。此文件結構以下:
1)根節點是模塊名稱,如:cluster,naming;
2)次級節點是此模塊的功能實現名稱,如:zookeeper是cluster模塊;
3)第三級節點是功能實現的屬性,如:hostPort和sessionTimeout是zookeeper須要的屬性;
3、多鏈接方式
首先,收集器提供兩種類型的鏈接,也就是兩種協議的支持:HTTP和gRPC。
1)在HTTP中命名服務,在後端集羣中,返回全部可用的收集器;
2)Uplink服務支持gRPC(主要用於SkyWalking的本地代理)和HTTP,它跟蹤和度量收集器。每一個客戶端只向單個收集器發送監測數據(跟蹤和度量)。若鏈接的收集器斷線,,則嘗試鏈接其餘的收集器。
客戶端lib和收集器集羣之間的處理流示例
4、收集器集羣發現
當收集器以集羣模式運行時,收集器必須以某種方式發現彼此。在默認狀況下,SkyWalking使用zookeeper進行協調,並以此做爲發現的註冊中心。
如此說來,客戶端的lib將不會使用zookeeper來查找集羣。建議用戶不要這樣作。由於集羣發現機制是可切換的,由模塊化核心提供。基於這一點,就打破了可切換的能力。
咱們但願社區可以提供更多的關於集羣發現的功能實現。如如今有的Eureka,Consul,Kubernate。
5、流模式
流模式傾向於輕量級的storm/spark實現,並容許使用api來構建流過程圖(DAG),以及每一個節點的輸入/輸出的數據約定。
新模塊能夠找到並擴展已有的過程圖。
在處理過程當中有三種狀況:
1)同步過程。傳統的方法調用。
2)異步過程,基於隊列緩衝區的a.k.a批處理過程。
3)遠程過程,聚合矩陣收集器,經過這種方式,選擇器在節點中定義,以決定如何在集羣中找到收集器。(HashCode,Rolling,ForeverFirst是三種支持的方式)
經過這些特性,收集器就像一個流動的網同樣運行。經過聚合指標和不依賴於存儲實現功能來支持同時編寫一樣的id。
6、可切換的存儲實現
由於流模式負責併發,因此存儲實現的職責是提供高速寫和組查詢。
如今,支持ElasticSearch,也支持H2預覽版,同時支持ShardingSphere項目用於MySql關係數據庫集羣的管理。
7、Web UI
除了收集器設計的原則以外,UI也是SkyWalking中的另外一個核心部分。它基於React、Antd和Zuul代理來提供收集器集羣發現、查詢分派和可視化。
Web UI使用localhost:10800來爲收集器集羣作命名查詢。