最爱嫣夜来

在分布式系统中，RPC（远程过程调用）框架需要设计心跳机制的主要原因是为了保持系统的稳定性和高可用性。心跳机制通常用于检测服务端与客户端之间的连接是否仍然有效，并及时处理因网络故障、服务器宕机、长时间无响应等原因导致的连接中断。1.检测连接是否正常网络不稳定：在分布式系统中，网络可能出现瞬时的波动或断开。如果没有心跳机制，客户端和服务端无法知道对方是否仍然在线，可能会误认为连接仍然有效，导致请求发送失败。服务器宕机：服务器可能由于崩溃、重启等原因失去响应。

之前我们就负载均衡的设计专门写了一篇文章来讲述框架中的所有核心设计，这些都是编码实现的i底层基础，大家在看源码时需要在脑海里需要对当前讲的这个东西在框架中所在的位置、所扮演的角色有一个充分的理解，真正翻阅源码的时候就会有条有理，知道他到底是用来解决问题的。很多人说源码看不懂，那是因为一直都是硬看， 不梳理，不思考，不带着实际的问题去看，那就无法理解框架设计的核心，看完一遍没多长时间就忘了。看源码的诀窍就时梳理核心，理出核心组件，找到整个框架的主线流程，看看这些核心组件是怎么在整个业务流程主线当中应用的，慢

RPC框架一般由服务提供者、服务消费者、注册中心和监控中心等服务组成。服务提供者启动后需要监听固定的域名/主机名/IP和端口，并且服务提供者作为一个基础服务，需要接收服务消费者发送过来的消息，后续对消息进行转发，调用目标方法后，向服务消费者响应结果数据。所以，服务提供者需要具备消息的首发功能，这是服务提供者应该具备的最基础的功能，今天这篇文章我们一起来探索一下dolphinscheduler框架中的RPC服务提供者的基础实现。

1.分布式集群RPC提供者肯定会被部署在多台主机节点上， 那么注册到注册中心的RPC提供者服务肯定会有多个，RPC消费者端服务是如何获取注册中心的RPC提供者服务列表的，源码中是如何实现的？2.既然RPC提供者服务列表，RPC消费者端服务肯定需要从列表中选择一个可用的主机节点来进行远程调用， 这个节点是怎么选择出来的？选择策略都有哪些？3.dolphinscheduler中默认的选择策略是什么？为什么默认用这种策略？

上一篇文章我们就Dolphinscheduler框架中注册中心的实现源码(主要是基于Zookeeper的注册中心插件的实现)进行了讲解说明， 我们知道了注册中心服务其实对应就提供了一个RegistryClient客户端工具类，其他应用服务的项目中如果有RPC提供者服务需要注册到Zookeeper或者其他注册中心， 只需要以来注册中心的工程，然后配置注册插件对应的配置参数信息，然后在在应用服务启动之后，就可以使用RegistryClient来进行服务注册及发现了。

DolphinScheduler的架构遵循分布式设计，其核心包括多个组件，每个组件负责特定的功能，这样可以避免单点故障并提供可扩展性。Zookeeper的高可用性、强一致性、临时节点、事件通知和分布式协调能力，使它成为一个理想的注册中心解决方案。它能够处理服务的注册、发现、健康检查等任务，确保服务在分布式环境中的高可用性和一致性。Zookeeper可以作为注册中心的原因主要与它的特性有关，特别是它的分布式协调能力、高可用性和强一致性。具体原因包括以下几点：今天咱们主要看的就是这个 工程，看看基于Zooke

下一篇文章我们开始讲解dolphinscheduler基于Zookeeper实现注册中心的源码解析。

通过前面的RPC框架源码系列的文章我们基本已经梳理了一个通用的RPC框架需要具备的核心功能。并通过源码进行这个设计实现流程的整体解析熟悉。本篇文章我们主要说的还是RPC框架如何与Spring框架进行整合。Spring是Java Web领域中最流行且最被广泛使用的框架，如果RPC框架需要使用在真实生产场景中，最好是能够支持与Spring框架框架整合。

上一篇文章dolphinscheduler服务RPC框架源码解析(六)RPC消费者服务设计实现我们只是进行了RPC消费者服务的构建过程进行了分析， 但是实际生产使用时，不可能让用户去封装请求报文对象，然后再去创建RPC消费者服务对象， 在进行请求发送， 这样肯定是不行的。成熟的RPC框架，必须能直接在本地调用某个接口的方法就实现了远程过程调用，使用门槛要低。使用方无需关注复杂的构建请求协议对象细节，无需关注RPC框架底层远程通信的细节。调用远程方法就像调用本地接口方法一样丝滑和顺畅。

通过以上分析我们基本梳理清楚了整个dolphinscheduler项目的一键安装启动逻辑， 我们现在在通过一张图正好理一下整个实现流程。关于一键停止集群服务及一件查询集群各个角色服务实例运行状态的实现也都在stop-all.sh/status-all.sh及dolphinscheduler-daemon.sh这三个脚本中， 有兴趣自行研究。写这篇文章的核心目的不仅在于给大家分享如何优秀的开源项目的一键安装部署的实现过程。

之前我们通过几篇文章讲解了Dolphinscheduler中RPC框架服务的一些底层实现设计以及RPC提供者服务端的设计实现, 下面我们继续来看看针对RPC消费者端看看，它又是怎么进行的设计实现。一个完整的RPC框架肯定是既包含提供者服务也包含消费者服务的，这样其他服务在使用我们的框架时只要启动我们的RPC提供者服务，然后再通过我们的RPC消费者服务对外暴露的API方法就可以进行应用层的业务数据交互了。

上一篇文章我们已经看过了RPC提供者服务的核心实现，知道了提供者服务如何创建、初始化、启动以及收发消息的处理流程，那么RPC提供者服务的核心实现到底是怎么实现真实方法调用的呢？那么本篇文章我们主要看看RPC提供者服务调用真实方法的具体实现。本篇文章主要讲解就是RPC服务提供者调用真实方法的设计实现，通过源码我们已经知道他是使用反射技术来进行实现的， 我个人觉得这里只使用反射还是不太灵活的， 一方面RPC框架的扩展性被限制了，另一方面也限制了框架性能优化的可能性。个人间接，不喜勿喷。

RPC服务提供者需要完成解析@RpcService、@RpcMethod注解、接收消息、发送消息、响应结果等功能。而且作为服务提供者，一定要启动并保持正常稳定运行，才能与服务消费者进行通信。

核心注解的扫描和解析一般都是有RPC的服务提供者进行，Dolphinscheduler中的RPC服务提供者是基于Netty的RpcServer。RpcServer启动时，会获取Spring容器中的所有被@RpcService注解的接口的实现类以及接口的方法被@RpcMethod注解修复的服务Bean注册中调用程序, 等待向客户端提供服务。这个注解需要再被@RpcService注解的接口类中定义的方法中进行使用，表明这个方法是一个RPC方法。这个注解的主要作用就是用来标记被它注解的接口是一个RPC服务接口。

如果让你设计一个网络传输协议， 你想想你会怎么设计？一般情况下，网络传输协议的设计基本都会包含消息头和消息体这两部分一个完整的网络传输协议可以分为消息头和消息体。消息头中主要存放的是一些对应整个消息的定义信息，比如协议的类型、状态、消息id、消息的长度等信息。消息体中主要存放的就是具体数据内容。我们一起来看看dolphinscheduler中RPC框架中自定义的网络传输协议的设计实现。dolphinscheduler 父项目。