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来为收集器集群做命名查询。