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