xxl-job 执行器端服务器的简单搭建
先讲一下我们平时怎么使用 xxl-job 的，再引出背后是如何实现的。
我觉得对于一款成功的框架来说，好用，是非常重要的一个特性。
框架要便于接入，便于使用。对于用户来说，不要有太多的使用成本，最好是能够开箱即用，快速上手的。
Java 为什么这么流行呢？
因为它的生态好。说是生态好，其实就是 Spring 那一套嘛，后面又有了 SpringBoot。
你想要使用什么组件，市面上基本上都有对应开源成熟的框架，而且框架设计的时候，也大都会适配 SpringBoot
xxl-job 也正是如此设计的。
我们使用者，只要使用的时候，只要在一个 Bean 对象中，写定时任务的逻辑就可以了，然后在方法上添加一个 @xxljob 注解，然后在 web 页面上配置一下定时任务就 ok 了。
好的，接下来让我们从使用层面来引出底层的实现原理。
使用层面：
1、执行器端启动的时候，要把 ip port 等信息注册到调度中心
2、执行器端要能够接收到调度中心发送过来的远程调度通知，然后执行具体的任务
分析得出：
执行器端，不仅要能够发送消息(a)，而且要能够接收消息(b)，然后执行具体的任务©
实现层面：
a、发送消息很简单，使用 http 协议即可。
b、接收消息，可以搭建一个 netty 服务器，在启动 netty 服务器的时候，执行注册执行器的逻辑；在消息的入站处理器，来接收到调度中心发送过来的消息，拿到任务名称，然后执行具体的任务。
c、Spring 容器初始化之后，要去遍历所有的 bean 对象，然后判断内部方法上是否添加了 @xxljob 注解，然后通过注解拿到任务的名称 jobHandler，然后将方法对象 method 和目标对象 target，一起封装到一个 map 中，key 是任务名称，value 是方法对象 method 和目标对象 target 封装成的一个对象。
做好这些初始化工作之后，执行器端就能够根据任务的名称，然后通过反射 method.invoke(target) 来执行任务了。
当然 xxl-job 代码中，并没有说的这么简单，其中还是有很多亮点的设计：
● netty 消息入站处理，使用自定义的业务线程池，避免单线程执行器被拖累，导致工作效率低下
● 执行器端在启动的时候，初始化好定时任务名称和对应方法的数据结构，并结合反射机制来执行定时任务
● 引入了工作线程机制，并在内部封装了阻塞队列。这一设计旨在解决两个关键问题：一是避免耗时较短的任务因耗时较长的任务而被延迟执行，二是防止任务执行时出现乱序，进而导致数据混乱
执行器这边源码重点看，jobThread 工作线程这边的设计，定时任务和工作线程一一对应，一个工作线程只负责执行一种定时任务。
阻塞策略也是基于这块实现的。