xxl-job 调度中心源码解析 ( RPC请求客户端)
首先我们在调度中心里面通过add接口新增一个定时任务：
在库里面会保存相应的定时任务的信息，如下：
现在我们在调度中心点击启动，会调用start 接口：
在上图的接口中我们可以看到，它会添加一个job任务到quartz中，任务的执行类是RemoteHttpJobBean，现在我们查看一下这个类:
上图中我们可以看到会通过一个快慢线程池去执行trigger，1分钟内若有10次运行超过500ms就会启动慢线程池，继续进入XxlJobTrigger.trigger：
上述代码中首先通过jobId查询数据库中保存的定时任务信息，然后是失败重试次数和分片机制，我们先跳过，直接看 processTrigger:
上述代码中首先获取阻塞策略，默认是 Serial execution 串行执行，然后是路由策略，默认是FIRST 取第一台机器执行，然后是重点执行定时任务的函数 runExecutor:
我们直接看 XxlJobDynamicScheduler.getExecutorBiz(address) ， 这里的 address 是执行器管理中注册的ip地址,如下图:
这里实例化了一个 XxlRpcReferenceBean ：
这里初始化了一个 netty_http 服务端和客户端 
采用 HessianSerializer 作为序列化， CallType.SYNC 采用同步的请求方式， LoadBalance.ROUND 负载使用轮询的方式。
现在我们查看getObject 方法:
看到这里我们知道这是一个典型的动态代理的设计方式（ps: 不熟悉动态代理的，可以看这里我的这篇博客 动态代理白话解析）
我们继续往下看 executorBiz.run(triggerParam) ，在执行这个方法时会去调用代理处理类 InvocationHandler 中的 invoke 方法，我们直接看上图中的 invoke 方法：
前面一段是 如果代理 XxlRpcGenericService 的 invoke 方法时做的一些特殊处理，然后若 被代理类为Object 则会抛出异常，否则 就是通过路由策略路由到一个最终请求地址。最后是来到了RPC的请求调用处理
xxl-job 的 RPC请求调用处理
首先实例化了一个 XxlRpcRequest ，有 className 类名 ( 即 com.xxl.job.core.biz.ExecutorBiz )，methodName 方法名 ( 即run )，parameterTypes 参数类型名称，parameters 方法参数 这4个重要属性。我们继续看 XxlRpcReferenceBean.this.client.asyncSend(finalAddress, xxlRpcRequest) 这里会去调用 NettyHttpClient 的 asyncSend ：
在 getPool 方法中获取到NettyHttpClient 后，会执行它的 init 方法，也就是netty 的 http 客户端初始化 ：
然后这里通过连接池获取 NettyHttpConnectClient 连接，调用其send方法发送请求：
然后会通过 NettyHttpClientHandler 获取返回结果 ：
这里获取到返回结果后会调用 channelRead0 方法，将 XxlRpcResponse 放进 XxlRpcFutureResponse 中 ，我们继续往下走 看 futureResponse.get 查看获取结果的方法：
这里会加锁调用 wait 方法阻塞只到获取返回结果，我们查看 获取返回结果的响应方法 futureResponse.setResponse ：
在获取到返回结果后会调用 notifyAll 唤醒 wait 阻塞，继续往下执行 xxlRpcResponse.getResult() 得到返回结果，到这里 调度中心的请求就执行完成了。
xxl-job 执行器源码解析 ( RPC请求服务端)
现在我们看执行器任务执行的源码解析：
首先执行器在启动时会实例化 XxlJobSpringExecutor 类，调用其 start 方法进行初始化：
调用父类的 start 方法：
这里通过配置的ip , port ,appName 初始化了 XxlRpcProviderFactory，添加了 ExecutorBizImpl 执行类 ，继续往下看 start 方法:
这里 使用一个守护线程启动了一个netty 的 http 服务端， 在接受到调度中心调度请求后，会执行 NettyHttpServerHandler 的channelRead0 方法：
这里采用一个线程池处理请求，继续往下看 process 方法：
这里的调度请求uri 不是包含 services ，所以我们直接看 this.xxlRpcProviderFactory.invokeService 方法 :
我们看到它会通过请求过来的类名作为key 获取对应的 serviceBean ，由上文 的 xxlRpcProviderFactory.addService(ExecutorBiz.class.getName(), null, new ExecutorBizImpl()) 这个方法我们知道 serviceBean 是 ExecutorBizImpl ，methodName 为 run。通过反射调用 会去执行 ExecutorBizImpl 的 run 方法 ：
前面一段代码主要是 可以通过不同的脚本来执行对应的定时任务代码，默认是 GlueTypeEnum.BEAN ，这里的 newJobHandler会在 XxlJobSpringExecutor 初始化start方法时 放进 XxlJobExecutor 的 jobHandlerRepository 中：
也就是通过注解的 @JobHandler(value="demoJobHandler") 的 demoJobHandler类
我们直接看 XxlJobExecutor.registJobThread 方法 ：
这里会 实例化一个 JobThread 线程去调用，直接看其 run 方法 ：
这里直接会执行对应的 handler.execute ，在本例中也就是 DemoJobHandler 的 execute 方法：
我们继续回到 ExecutorBizImpl 的 run 方法中的最后一段 ：
将其放进触发器队列中，返回 ReturnT.SUCCESS 执行完成。
到这里，一次xxl-job 定时任务就处理完成了
扩展与发散：
上面解析了xxl-job 定时任务执行一次的过程，核心就是调度中心通过rpc请求调用执行器去执行一次任务。
其他的rpc框架依然通过类似的方式执行的，例如我们熟知的 dubbo 的服务之间的调用也是通过类似的方式执行rpc请求调用的， 只不过dubbo是采用的tcp请求，还有 springcloud 通过feign来完成各个服务之间的调用，底层也是通过动态代理+http调用的方式完成的。我们可以发散一下，java 基本所有的rpc框架都是通过类似的方式，还有thrift 和 java 的RMI等，可能会有一些扩展功能如负载、失败重试、监控、熔断、限流、降级、容灾等，但是核心就是通过rpc请求完成的。
总结：
xxl-job 底层就是通过封装quartz+netty http封装的rpc框架来完成每一次分布式定时任务的执行，源码调用的简易流程图如下:
