分布式链路追踪专栏，分布式链路追踪：Skywalking集群管理设计

SkyWalking 是一个开源 APM 系统，包括针对 Cloud Native 体系结构中的分布式系统的监视，跟踪，诊断功能。核心功能如下：

服务、服务实例、端点指标分析；
根本原因分析，在运行时分析代码；
服务拓扑图分析；
服务，服务实例和端点依赖性分析；
检测到慢速服务和端点；
性能优化；
分布式跟踪和上下文传播；
数据库访问指标。检测慢速数据库访问语句（包括 SQL 语句）；
报警。

SkyWalking 目前是 Apache 顶级项目，作为这么优秀的开源项目，它的架构设计理念肯定会有很多值得我们借鉴。

本文会包含如下内容：

集群管理生态方法论；
SkyWalking 集群管理设计。

本篇文章适合人群：架构师、技术专家以及对全链路监控非常感兴趣的高级工程师。

集群管理生态方法论

集群管理的方法论有很多，当今社会又是一个信息膨胀的时代，所以会有很多书籍或者文章会去剖析一些方法论，我相信很多都具备很强的收藏价值。

比如我现在需要做一个缓存系统，最开始我们肯定会考虑使用本地单机缓存，因为这样性能高，实现简单，我们只需要使用一个容器来承载这些数据，然后相办法如何保证数据的读写线程安全就行了，于是我们就会考虑单虚拟机下的性能优化，比如如何用多线程操作替代单线程，如何用事件驱动去替换同步，如何转换成异步，其实这些都会是在单机本地缓存上效果最明显，因为没有网络开销。

但是随着服务能力的提升以及运营给力，我们的应用程序单机的流量越来越大，线上单机根本不够用，我们需要主从部署，这样问题就来了，我们需要数据同步，slave 需要从 master 上同步数据，涉及到跨进程的数据同步，也就是这个时候就需要保证数据同步的高可用、高性能、高并发等特性，那么这个时候就需要集群管理了，需要我们去管理这些数据同步的操作。

那么我们首先会想到，我们原先是基于内存的，我们可以改成基于 openAPI 模式，如果一台机器上的内存数据变化了，我就通过 openAPI 实时的同步到其他集群节点上，然后更新对应机器节点的内存数据，这样数据就保证一致性了，只是说这个数据不会持久化，一旦有节点挂掉了，数据就全丢失了。

怎么办？程序员是很聪明的，我们可以持久化啊，把内存中的数据同步到磁盘文件，做备份，如果节点挂掉，再重新启动会去加载已经备份的文件。那么问题又来了，如果每次更新内存都会去持久化文件，如果有大量的请求，这样整个集群抗并发的能力会非常的差，所以又发明了异步刷盘机制以及机器硬盘的缓存机制。

其实上面所说的集群间数据的管理功能，在分布式领域里面属于 AP 模式，只会保证最终一致性。

那么如何保证 CP 的强一致性了，那么程序员的进阶之路，我们肯定需要刨根问底，这个时间基于 Raft 算法的分布式能力，就是 CP 算法，所以现在有很多框架的集群管理都会采用分布式算法 Raft，因为这个算法高效并且稳定。

使用 Raft 算法来保证集群管理能力的有很多优秀的框架，比如：

Nacos；
Rocket MQ；
蚂蚁金服的 JRaft。

所以上升到集群管理，业界一般都会采用 CP 或者 AP 模式，很少有框架能够同时实现 CAP 模式的。

Skywalking集群管理设计

SkyWalking 集群管理支持能力点包括：基于 Consul 的集群管理，基于 etcd 的集群管理，基于 Kubernetes 的集群管理，基于 Nacos 的集群管理，基于 ZooKeeper 的集群管理。SkyWalking 的集群管理又是靠 Selector 来做配置切换的。

selector: ${SW_CLUSTER:nacos}
standalone:

基于 Consul 的集群管理

既然可以用 Consul 做集群管理，肯定是要先加载配置文件，SkyWalking 定义了 ClusterModuleConsulConfig，会加载 Consul 的基础配置信息。

serviceName：服务名称；
hostPort：IP + 端口；
internalComHost：内部通信 IP；
aclToken：acl 认证 token；
internalComPort：内部通信端口。

对 SkyWalking 比较了解的人会知道，它所有的功能都是按照模块来加载的，所以 Consul 也会自定义一个模块 ClusterModuleConsulProvider。

定义模块的名称为 Consul，定义模块的基础类模块为 ClusterModule，绑定模块的配置文件 ClusterModuleConsulConfig，重写 prepare() 方法，方便整个 OAP- SERVER 初始化的时候，完成 Consul 集群的加载。

加载的过程中就会植入集群能力，比如 ConsulCoordinator，集群能力肯定是具备服务注册和服务发现功能，SkyWalking 统一封装了 ClusterRegister 和 ClusterNodesQuery 接口能力，ClusterRegister 具备 registerRemote 能力，ClusterNodesQuery 具备能力。

ConsulCoordinator 初始化 Consul 客户端 client，并获取到 Consul 集群选举出来的 HealthClient，并通过客户端获取到健康的数据节点列表，并将节点列表转换为平台能够识别的远程节点信息列表，并返回。（从 ServiceHealth 转换为 RemoteInstance）。

基于 etcd 的集群管理

加载集群配置信息 ClusterModuleEtcdConfig 继承 ModuleConfig：

serviceName：服务名称；
hostPort：IP 加端口；
isSSL：是否开启 SSL 认证；
internalComHost：内部通信 IP 地址；
internalComPort：内部通信端口号。

集群能力初始化模块：ClusterModuleEtcdProvider，继承基础模块 ModuleProvider，这点和 Consul 集群管理的原理是一样的。加载配置文件 ClusterModuleEtcdConfig，并初始化 EtcdClient，赋值模块名称为 etcd，并通过 prepare() 方法完成集群能力加载。解析配置文件，并和 EtcdClient 绑定，并通过 EtcdCoordinator 和 EtcdClient 绑定一起完成集群的能力。

EtcdCoordinator 是集群管理的核心能力，通过客户端以及 serviceName 来获取指定服务的节点信息列表，并将 Etcd 集群能够识别的节点信息 EtcdNode 转换为平台能够识别的节点信息 RemoteInstance。

基于 Kubernetes 的集群管理

K8s 集群管理配置文件加载：

watchTimeoutSeconds：监听超时时间；
namespace：命名空间；
labelSelector：标签选择器；
uidEnvName：uid 环境名称。

ClusterModuleKubernetesProvider，基于 K8s 的能力加载模块。配置集群模块名称 Kubernetes，绑定集群模块和配置文件 ClusterModule 和 ClusterModuleKubernetesConfig。模块在初始化过程中会初始化 KubernetesCoordinator，基于 K8s 的集群选举核心能力。这里有一个小细节，基于 K8s 的集群管理，是假想 Skywalking 自身本身就是 K8s 里面的一个服务，依托于 K8s 的服务治理能力，所以，集群选举能力，在注册 IP 的过程中，是和 K8s 共用一套 API。

通过 Provider 中的 notifyAfterCompleted 完成 coordinator.start()，开启集群选举，集群选举通过一个 SingleThreadExecutor 并结合定时器去执行监听器方法，实时的维护注册节点缓存，供 Skywalking 节点使用。

基于 Nacos 的集群管理

加载 ClusterModuleNacosConfig 配置，配置中会加载如下属性：

serviceName：服务名称；
hostPort：IP + 端口；
namespace：命名空间。

集群模块加载器 ClusterModuleNacosProvider，命名为 Nacos 模块，构建 NamingService 模块，NamingService 这个是分布式集群管理 Nacos 的服务发现的 API，依托这个 API 可以找到对应服务名称所属的集群信息，包含 IP + 端口。

NacosCoordinator 集群选举模块，通过 NamingService 的方法 registerInstance 和 selectInstances 去注册和发现服务元数据信息。

基于 ZooKeeper 的集群管理

ZooKeeper 的集群管理，基本原理就是节点信息 + 监听器机制，这里也会加载基础配置信息 ClusterModuleZookeeperConfig：

nameSpace：命名空间；
hostPort：IP + 端口；
baseSleepTimeMs：休眠时间；
maxRetries：最大重试次数；
internalComHost：内部通信 IP 地址；
internalComPort：内部通信端口号；
enableACL：是否开启 ACL 认证；
schema：数据库 schema；
expression：匹配表达式。

集群选举加载模块 ClusterModuleZookeeperProvider，封装 CuratorFramework 客户端，熟悉 ZooKeeper 的人都知道，这个是 curator 框架针对 ZooKeeper 客户端的封装，也是一个高性能的中间件框架，配置 ZooKeeper 模块。那么模块初始化会加载哪些信息，比如 ACL 认证信息，初始化客户端，初始化 ZookeeperCoordinator 选举 API，绑定配置文件和客户度，完成集群选举能力的初始化。

ZookeeperCoordinator 是 Skywalking 封装的真正的集群选举能力，包括集群信息的适配等。

Skywalking集群管理总结

集群管理，我们总得了解 Skywalking 为什么要用集群管理，在它的架构设计理念中，整个 OAP 平台的角色主要分为如下：

CoreModuleConfig.Role.Mixed；
CoreModuleConfig.Role.Aggregator；
CoreModuleConfig.Role.Receiver。

这里简单的解释下，Mixed 是混合模式，既包含 Aggregator 和 Receiver。Aggregator，是聚合器模式，也就是说数据收集到 OAP 平台之后，数据需要做过滤、清晰和聚合然后再存储。Receiver 是收集器模式，也就是原始数据会直接存储，不做任何处理，当然这个肯定会有最核心的链路数据，就不会产生很多通过聚合之后产生的指标数据了。

那么 Skywalking 中的集群管理主要是针对 Aggregator 模式，当然肯定也会包含 Mixed 模式。那么为什么 Aggregator 模式需要分布式集群管理功能，这个我们应该能够理解，因为需要处理数据，那么肯定需要保证 CAP 或者 BASE 理论了，也就是要保证集群节点之间的分布式特性，所以 Skywalking 就针对你所需要的集群功能，然后通过选择器架构模式，来充分满足平台的深度用户可以任意的挑选符合自己业务场景的。

再聊聊 Skywalking 集群管理服务的能力有哪些，首先我们聚焦在服务发现，因为用到了集群能力，肯定是要服务发现，找到集群上注册的服务提供者的基础元数据。

ClusterNodesQuery.queryRemoteNodes() 能力，在 Skywalking 中如何被利用，首先我们关注下 RemoteClientManager ，这个类管理 OAP 服务节点集群之间的连接。有一个任务调度会自动查询服务节点列表从集群模块。比如 ZooKeeper 集群模块或 Kubernetes 集群模块。

从集群模块查询 OAP 服务器列表，并为新节点创建一个新连接。创建 OAP 服务器有序，因为每个服务节点会通过哈希码互相发送流数据。通过 queryRemoteNodes 的集群能力，找到集群中的节点信息列表。

由于 OAP 服务器注册由 UUID 与进程号一对一映射，注册信息没有立即删除后，进程关闭，因为总是发生网络故障，不是真的关闭过程。因此，集群模块必须等待几秒钟来确认。然后有多个注册的集群中的信息。

所以在拿到集群信息列表之后，需要去重（distinct）并排序，然后比较目前使用的集群远程客户端列表和当前最新的集群节点信息列表，如果不同就会做同步更新。比较现有客户端和远程实例收集之间的客户端。将客户机移动到新的客户机集合中避免创建新的通道。关闭在集群配置中找不到的客户端。为除自实例外的远程实例创建一个 gRPC 客户端。

Skywalking 集群管理的能力是 gRPC 客户端集群，也就是说节点之间的 RPC 通信通道是 gRPC，其实这点和 Dubbo 的集群管理本质上也是一样的，因为 Dubbo 管理的是 Dubbo 自己的 RPC，比如 Netty。

然后又是怎么植入到 Skywalking 的功能领域的呢，这个就得通过 RemoteSenderService，这个类包装了 RemoteClientManager，首先从它里面获取到 RemoteClient 列表，然后拿到了列表之后，我们只能说知道了集群的能力，还需要考虑负载均衡，这点 Skywalking 就简单的封装了负载的能力，包含如下几种：

HashCode：通过 HashCodeSelector 完成按照 hash 取模的负载均衡算法；
Rolling：通过 RollingSelector 完成按照轮询的负载均衡算法；
ForeverFirst：通过 ForeverFirstSelector 完成简单的总是第一个节点的负载均衡算法。

那么问题又来了，这里也是只是封装了集群负载的能力，那么到底是哪部分能力在用集群的功能了，这里有说明如下两个类：MetricsRemoteWorker 和 RegisterRemoteWorker，前者是从 agent 客户端收集到的度量信息，也就是聚合分析产出的数据，后者是本节点能力的分布式注册，比如 MetricsPersistentWorker 等。

另外我的新书RocketMQ消息中间件实战派上下册，在京东已经上架啦，目前都是5折，非常的实惠。

https://item.jd.com/14337086.html编辑https://item.jd.com/14337086.html

“RocketMQ消息中间件实战派上下册”是我既“Spring Cloud Alibaba微服务架构实战派上下册”之后，又一本历时超过1年半的巨无霸技术实战类型的书籍。

为了提高读者阅读本书的体验性，本书总共设计了十个特色，下面我一一的给技术小伙伴阐述一下。

【特色一】由浅到深

本书将RocketMQ的技术原理和最佳实践体系化，按照由浅到深的顺序呈现给读者，使读者可以按照章节顺序按部就班地学习。当学习完全书内容之后，读者不仅能熟悉RocketMQ的核心原理，还能充分理解RocketMQ的“根”。

【特色二】技术新

本书不仅包括RocketMQ4.x（4.9.2版本）的核心原理分析和最佳实践，还包括RocketMQ5.x（5.1. 0版本）的新特性分析和最佳实践。

【特色三】精心设计的主线：零基础入门，循序渐进，直至彻底掌握RocketMQ

本书精心研究了程序类、架构类知识的认知规律，全书共分为6篇：①基础；②进阶；③高级；④高并发、高可用和高性能；⑤应用；⑥新特性，是一条相对科学的主线，让读者快速从“菜鸟”向“RocketMQ分布式架构实战高手”迈进。

【特色四】绘制了大量的图，便于读者理解RocketMQ的原理、架构、流程

一图胜于文，书中在涉及原理、架构、流程的地方配有插图，以便读者更加直观地理解。

【特色五】从架构师和技术专家的视角分析RocketMQ

本书创造性地分析了RocketMQ具备高并发、高可用和高性能的功能及原理，并从架构的视角展开分析，这些也是程序员进阶为技术专家或架构师必备的技能。

以下为从架构师和技术专家的视角分析RocketMQ典型案例，读者阅读完本书之后，也能够达到这样的水准。

【特色六】不仅有原理分析，还有大量的实战案例

本书介绍了大量的实战案例，能让读者“动起来”，在实践中体会功能，而不只是一种概念上的理解。

在讲解每一个知识模块时，我在思考：在这个知识模块中，哪些是读者必须实现的“标准动作”（实例）；哪些“标准动作”是可以先完成的，以求读者能快速有一个感知；哪些“标准动作”具有一定难度，需要放到后面完成。读者在实践完书中的案例之后，就能更容易理解那些抽象的概念和原理了。

本书的目标之一是，让读者在动手中学习，而不是“看书时好像全明白了，一动手却发现什么都不会”。通过体系化的理论和实战案例去培养读者的主动学习能力，这样本书的价值就会被最大化。

本书相信“知行合一”的理念，而不是“只知，而不行”，避免开发人员出现眼高手低的现象。尤其是在技术面试过程中，面试官更加看重的是既懂原理，又能够主动是实践技术的技术人。

【特色七】深入剖析原理

本书以系统思维的方式，从业务功能视角剖析 RocketMQ 底层的技术原理，使读者具备快速阅读 RocketMQ 框架源码的能力。读者只有具备了这种能力，才能举一反三，实现更复杂的功能，应对更复杂的应用场景。

【特色八】从运维的视角分析 RocketMQ 的最佳实践

【特色九】参与开源

本书向读者展示了如何修改 RocketMQ 源码，并快速验证案例分析。这样，读者可以从中学到参与开源的技能，并为后续自己能够参与开源做准备。

【特色十】双色印刷，读者体验会更好

为了提高读者阅读本书的体验，在有上下两册的前提下（巨无霸，超过800页），出版社不吝啬印刷成本，依然采用双色印刷。

【推荐】本书的最佳学习路径

为了提高读者学习RocketMQ的效率，我这边结合我自身从RocketMQ小白到RocketMQ专家的经历，为读者汇总了一条最佳学习路径。

【寄语】作者寄语

RocketMQ是我深度参与研究的一款开源消息中间件，无论是从源码，还是架构场景，我都提炼了很多最佳实践。

在开源领域，技术小伙伴可以使用的开源消息中间件非常的多，比如Kafka、Pulsar等，我之所以选择研究RocketMQ，除了工作内容和角色需要之外，更多的还是自己感兴趣，因此我建议技术小伙伴一定要先培养自己的兴趣，兴趣才是提升技术硬实力的第1要素。

当然我并不止研究了RocketMQ，还研究了Pulsar和Kafka等（包括开源消息中间件生态中的主流框架），只是本书作为一本关于RocketMQ实战派的书籍，我必须要以RocketMQ为主。

假如技术小伙伴想成为Java领域的架构师或者技术专家，我强烈建议你去研究RocketMQ，它会给你带来很多意想不到的技术和架构方法论的收获，这个也是我写本书的主要目的之一。

建议技术小伙伴按照本书设计的学习路线，逐章的去阅读和实战，这样学习效果会更好。

如果技术小伙伴有技术交流的，可以通过博文视点官方的读者群找到我的联系方式，并与我沟通，我会实时的解答读者的疑问。

本文公众号“架构随笔录”

本人视频号“架构随笔录”

【博文视点】2021年度优秀作者

2021年我和博文视点合作了一本技术类型的书籍“Spring Cloud Alibaba微服务架构实战派上下册”，它是我涉足知识输出领域以来的第一本书，同时它也是我自己积累的技术池中部分技术的产出。

为了写好那本书，我几乎花费了所有的休息时间，并主动的承担了书的售后技术辅导和咨询的职责（几乎是有问必答，坚持了整整两年）。

所谓有付出总会有回报，Alibaba这本书的销量还不错，我也因此获得了博文视点颁发的2021年度优秀作者。

我很清楚，这个是博文视点为了鼓励我继续去用心写书，因此我又花了接近1年半的时间去写了RocketMQ消息中间件实战派上下册这本书。

所谓一分耕耘一份收获，我将我对RocketMQ的理解体系化的输出给喜欢技术的技术人，希望真的对大家有帮助。

【博文视点】2023技术成长领路人

2022年，我开始涉足技术直播和技术讲师领域，并和博文视点合作几次技术直播，直播效果还不错，再加上我孜孜不倦的布道“Spring Cloud Alibaba微服务架构实战派上下册”这本书相关的技术，并且这些技术都是有助于“技术人”快速成长的，因此也获得了博文视点颁发的“2023技术成长领路人”这个技术奖项，这个奖项也是为了鼓励我继续通过技术直播的方式给技术人去布道技术，因此只要我有时间，我就会孜孜不倦的去讲和聊技术。