1 Crane 架构图
Crane在部署上根据BG进行隔离，共拆成7个BG，包含部署在上海侧的默认集群和点综集群、部署在北京侧的外卖集群、酒旅集群、金融集群、猫眼集群和餐饮集群。
通过appKey决定任务所归属调度集群。
每个模块都是可水平扩展，采用3机房部署实现高可用。
2 Crane 最小部署图
最小部署图是Crane从BG粒度水平扩容的最小单位，新增一个BG集群，只需要部署对应BG所需的各内部模块即可，对其他BG无影响，实现BG级别的隔离。
3 Crane 内部模块
3.1 Portal 模块
Portal提供统一的UI操作界面以及HTTP服务接口，可以任意水平扩展，北上2地4机房部署。
对于用户针对任务的请求，Portal端通过HTTP与调度器进行交互，此时Portal端会根据appKey确定请求应该分发到哪个BG集群，然后根据任务名定位BG内部所属调度器IP。
3.2 Scheduler 模块
任务调度模块，负责对任务进行周期性调度。
3.2.1 调度模型
采用原生Java提供的延迟队列，对于每个任务，预先生成下一次调度实例放入延迟队列，当调度实例被消费后，随即生成下一次实例重新放入队列，如此循环，驱动任务周期性调度。
3.2.2 基于租约的分布式调度器
对于每个BG内部，调度器单侧3机房部署，可以任意水平扩展。
调度器下线时，主动从Zookeeper中删除注册节点，上线时，主动注册节点到Zookeeper中，Manager通过监听Zookeeper，实时感知调度器上下线。
Manager通过引入虚拟Slots层，在调度器上下线时，重新为每个调度器分配Slots。调度器通过分配到的Slots，通过对任务名取hash，判断某个任务是否由自己调度，从而实现了一个任务只由一个调度负责调度。
当调度器出现宕机，无法主动从Zookeeper中删除自身注册的节点时，就需要Manager进行被动删除。Manager通过对调度器进行心跳检测，从而摘除宕机节点，进而进行任务重新分配。
心跳检测解决了调度器宕机时摘除节点的目的，但是如果调度器出现网络不通，此时会出现Manager认为调度器宕机，但调度器任务自己正常的不一致判断，从而导致任务被重复调度；解决这一问题的方法就是调度器基于租约进行调度，Manager对调度器发放租约，如果调度器没有响应，就无法续租，当租约到期时，Manager认为调度器宕机，调度器由于自身没有租约也不会再进行调度，从而实现状态判断的一致性。
3.3 Zookeeper 模块
Crane 注册中心，单侧5节点3机房部署。
客户端启动时会注册自身信息，包含该节点下注册的任务、appKey已经泳道和Set信息。
调度器启动时会注册自身节点，供Manager管理，从而进行任务分配；调度器从注册中心读取客户端信息，从而进行调度。
Monitor启动时会注册自身节点，从而各Monitor可以平均分配客户端，从而对客户端进行心跳检测。
3.4 Manager 模块
Manager负责管理调度器，从而实现任务的动态迁移，单侧3机房部署。
Manager 通过Zookeeper进行选主，主节点对调度进行租约发放。
当主节点宕机时，会在6s后进行切换，选举出新的主节点，继续对调度器进行租约发放。
每个Manager会定时去检测Zookeeper上是否存在主节点，在Zookeeper不可用时，无法通过Zookeeper选出主节点，此时所有Manager都会对调度器进行心跳检测，避免由于调度器租约到期，自动中止调度。
3.5 Monitor 模块
Monitor负责管理客户端，单侧3机房部署。
Monitor启动后会注册自己节点，并且定时更新时间戳。所有存活的Monitor都会对客户端进行心跳检测，N个Monitor理论上每个Monitor会负责的1/N的客户端。当某个Monitor宕机时，其他Monitor检测到时间戳1分钟未更新，会自动删除注册节点，从而将其所负责的客户端接管过来。
Monitor会每隔10s对客户端进行心跳检测，连续6次不通后，会认为客户端宕机，从而将节点从Zookeeper中摘除。
