分布式中间件架构.docx

分布式中间件架构在互联网应用中，各式各样的定时任务存于系统各个角落。我们希望由一个平台统一将这些作业管理起来。通过这个系统，作业的宕机、崩溃等状态就可收入运维同学掌控，直接对接报警系统，将发现的挂掉作业再启动就好。但一旦平台中运行大量的作业，发现异常作业并手动处理难免会感到繁琐，而且人工处理带来的误操作以及时间差和7*24小时在线支持的要求都带来了额外的成本。什么是分布式定时任务中间件 最大限度的减少人工干预不仅是分布式定时任务中间件，也是所有的分布式中间件的核心价值所在。解决这个问题的方式就是高可用，让作业在被系统发现宕机之后能自动切换。高可用和马上要聊的弹性化可以一起看，弹性化可以认为是高可用的进阶版本，在高可用的同时还能够提升效率和充分利用资源。如果作业处理的数据较多或计算量较大，单一实例效率不足的时候，最好可以做到增加一台服务器就能提升一部分的处理能力，也就是动态扩容。而一旦有运行中的服务器宕机，也不会影响整体的作业运行，无非是由于运行资源的减少而导致运行效率下降而已，这就是动态缩容。这通常采用分片的方式实现。它需要将一个任务拆分为多个独立的任务项，然后由分布式的服务器分别执行某一个或几个分片项。例如：有一个遍历数据库某张表的作业，现有2台服务器。为了快速的执行作业，那么每台服务器应执行作业的50%。 为满足此需求，可将作业分成2片，每台服务器执行1片。作业遍历数据的逻辑应为：服务器A遍历ID以奇数结尾的数据；服务器B遍历ID以偶数结尾的数据。 如果分成10片，则作业遍历数据的逻辑应为：每片分到的分片项应为ID%10，而服务器A被分配到分片项0,1,2,3,4；服务器B被分配到分片项5,6,7,8,9，直接的结果就是服务器A遍历ID以0-4结尾的数据；服务器B遍历ID以5-9结尾的数据。而将将分片总数设置为1，并使用多于1台的服务器执行作业，作业将会以1主n从的方式执行。一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。另外还有一些作业完整性的需求，如：当作业执行时间过长造成下次该执行的作业的时间被错过时，需要提供被错过作业重执行机制；当一个作业分片失效时，需要立即在其他可运行节点运行，即失效转移功能等。无论是高可用、分片还是错过作业重执行、失效转移，都需要依托于一个注册中心，用于记录作业的状态并且能够进行分布式组件的协调，一般使用ZooKeeper居多。使用ZooKeeper的临时节点和监听功能可以有效的做到分布式的协调，用于发现新上线节点和处理已下线节点。总结一下，分布式定时任务中间件的关注点从易到难是：集中化 - 高可用 – 弹性化。去中心化和中心化 介绍完了关键功能点，接下来我们聊一下实现分布式定时任务中间件的两种架构方案，去中心化和中心化。去中心化架构是指所有的作业节点都是对等的。每个作业从注册中心拉取自己的执行时间并且各自定时执行，执行时均使用作业服务器的本地时钟，在作业无需分片调整时并不会对注册中心产生写操作，进而不会导致注册中心更新缓存，因此执行效率很高，对注册中心产生的压力非常小。每个作业执行实例在执行时拉取仅属于自己实例的作业分片（通过本地缓存即可，并不直接读取注册中心），并传递给业务代码，供其根据所得分片项编写业务逻辑。去中心化架构需要一个被选举出来的主节点处理分片行为，仅分片行为不是去中心化的，需要集中处理。主节点是通过选举获得的非永久节点，一旦主节点的服务器宕机，则需要重新选举主节点。当作业服务器的在线状态发生变化时，则触发ZooKeeper监听，并设置需要重新分片的标记。在下次作业运行时，主节点将根据这个标记确定是否重分片并在需要时分片，分片时其他从节点一律处于阻塞状态。主节点的唯一特别之处就是负责作业运行之前的分片，其他方面的运行节点别无二致，主节点也是一个作业运行节点。去中心化架构的优点是轻量级，仅提供一个lib就可以与业务代码一同工作，部署成本低，只需搭建注册中心即可。缺点是如果各作业服务器时钟不一致会产生同一作业的不同分片运行有先有后，缺乏统一调度。并且不能跨语言。中心化架构将系统分为调度节点和执行节点。由调度节点发起作业的分片和执行，然后通过RPC发布给作业执行节点，或者通过写注册中心让监听注册中心的作业执行节点主动触发。同样可以采用注册中心来协调作业调度节点和执行节点的状态，也可以将注册中心退化为配置中心，专门用于存储作业配置元数据，转而由调度中心负责监听各个执行节点的状态。中心化架构模式可以解决服务器时间差以及跨语言的问题（如果采用跨语言RPC或REST发送执行信令的方式）。缺点是部署和运维稍复杂，需要单独部署调度节点并需要维护其高可用，这也会造成一定的资源浪费。无论是中心化还是去中心化，在分布式的场景下由于网络重试造成的顺序不一致等原因，可能导致ZooK