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