源宝导读：MIP集成平台是为了解决企业大量异构系统之间快速、稳定集成的需要，助力企业数字化转型，明源云自主研发的平台系统。本文将对"事件任务分派"场景的架构设计以及实践成果进行分享。

背景

MIP集成平台是为了解决企业大量异构系统之间快速、稳定集成的需要，助力企业数字化转型，明源云自主研发的平台系统。在MIP中，事件中心组件提供了低耦合、准实时、高可靠的数据或消息传输服务，解决企业信息系统之间的异步的通知和数据同步需求。在事件管理中，用户可以通过创建事件源和事件订阅者，来实现事件的订阅与发布，最终实现数据或消息在应用之间进行传递。后台系统会通过调度模块进行事件任务的分配，然后下发到运行模块进行事件任务的运行（监听和订阅），本文将对"事件任务分派"场景的架构设计以及实践成果进行分享。基于篇幅，本次主要分享分派调度策略的处理逻辑的这个层面。

一、需求分析

基于上面的描述，我们可以认为这是一个分布式任务调度的场景，相对简单且有其特点。

调度分配以事件为单位，调度时只需要根据分配原则把指定的事件在运行模块节点上启动即可。
持续运行，不需要Job形式的定时调度，为了保证准实时性，事件任务一旦启动，将会持续运行，除非重新被分配。
一致性，为了保证消息和数据不会重复，同一时间一个事件只能在一个运行节点中执行。
故障转移，当一个运行节点不可用时，需要把上面正在运行的事件任务转移到其它的运行节点中运行。
动态平衡，当有新的运行节点加入时，需要转移部分事件任务到新的节点，以保证各节点的任务数平衡；同时当有事件被新发布或下线时，也要执行平衡。
.net core技术栈和Consul中间件，MIP采用.net core进行开发，同时引入了Consul来支持集群一致性，所以尽量在已有条件基础上考虑解决方案。

二、架构设计

通过上面的分析和权衡考虑，我们没有选择现成的第三方调度框架，而是进行自主研发，而集群一致性方面则依赖于Consul作为基础。
所有的调度结果保存成一份清单数据，存储在Consul中，然后再根据清单数据下发事件任务的启动/停止命令，清单数据的结构类似于这样：

我们把主要功能分为"调度模块"和"运行模块"两个部分，参考图1。

2.1 调度模块：

调度模块主要负责事件任务的分配逻辑，并发送相应的事件任务启动/停止命令到运行模块。

事件任务调度，调度模块从Consul中获取正在运行的运行模块服务信息，把事件任务平均分配到运行模块节点中。
一致性，因为调度逻辑占用资源较小，所以不需要所有的节点都执行逻辑，各节点通过争抢Consul的KV锁来完成Leader的选举，由Leader来执行调度逻辑。
根据运行模块各节点的状态，动态的调整分配（超过一定时间持续无法连接的节点认为是故障节点）。
事件任务调度的清单数据存储到Consul中。
接收从"事件管理"发送过来的事件发布、下线通知，重新调度。
事件任务调度的三个触发点：第一次启动初始化，事件变化通知，定时触发。

2.2 运行模块：

运行模块则接收调度模块的命令，负责执行事件任务，并把启动/停止的状态结果返回给调度模块，并提供查询事件任务状态的API。

事件任务运行，接收调度命令，启动/停止事件任务的运行，并且保证在接收并完成事件任务的启动命令后事件持续运行（即如果事件任务异常退出则重新启动）。
一致性，由调度模块来保证，根据调度模块的命令来执行任务。
提供当前正在运行的事件任务的状态查询API。
把自身服务注册到Consul，反映节点的健康状态。
当发现自身不健康时（无法连接到Consul），超过一定时间后（需要小于调度模块认为运行节点故障的间隔时间），停止当前节点上的所有事件任务运行。

图1 架构示意图

三、调度场景分析

3.1 第一次启动初始化：

第一次启动时，事件任务清单数据为空，所以全新获取所有的事件信息和所有的运行节点信息，按照平均分配的逻辑分配事件任务，先把分配结果保存到清单，再根据清单逐个去调用运行节点启动事件任务。

图2 第一次启动初始化

3.2 运行节点新增：

当运行节点新增时，根据已经运行的事件任务清单，还是采取平均分配的原则，从正在运行的节点上，移出部分事件任务到新节点上启动。

图3 运行节点新增

3.3 运行节点故障/下线：

当判断出某个节点的状态为不可用时，把该节点上所有的任务转移到其它节点上执行。

图4 运行节点故障/下线

3.4 事件发布/下线：

当调度模块接收到事件的发布/下线通知时，重新执行调度逻辑，去相应的启动或停止事件任务。

图5 事件发布/下线

四、实现逻辑

通过前面的分析，接下来就是考虑如何去实现了。我们分析了几种调度发生的场景，是不是按照这个逻辑把代码实现出来就可以了呢？其实不然，细想一下，我们会发现还有一些其它特性需要考虑，主要从扩展性、可靠性和性能方面考虑。

我们发现每一种调度场景下做的事情都很类似，比如都需要重新获取运行模块节点信息和任务清单，并去最终都是去调用运行模块节点的api去执行操作，那么我们是不是需要在实现设计时再往上抽象一层？如果再抽象是否只是把通用逻辑提取出来，在不同的调度场景调用呢？
我们现在的处理思路是，根据分配逻辑生成任务清单，再根据清单去调用运行模块的api执行任务的启动/停止，但是如果在两次调度的间隔内，某一个运行模块节点上的某一个或某几个任务异常停止了（比如某个运行节点执行了重启，但是因为我们是定时调度，没有检测到节点的一次下线和一次上线动作），我们如何保证最终一定是按照清单在运行任务？
还是运行节点重启了，我们检测到了下线和上线，但是因为节点下线超过一定时间我们才认为是真正的下线了，并且马上又有一次新节点的上线，那这个逻辑是不是又变的复杂了，我们的程序到底应该如何处理呢？重启运行节点是不是需要单独列为一个场景呢？
上面我们单独分析了每个调度的场景，逻辑看上去也还简单，但是如果是多个场景同时发生，我们又该如何实现逻辑呢？相互之间是否会有冲突，又如何保证可靠性呢？
目前每一个事件的发布/下线都会发送一次通知，如果在批量操作时，会频繁触发调度，有没有办法在不改变事件通知的情况下，尽量合并调度呢？

我们回过头来仔细想一想，其实从计算机的角度看，我们的程序主要做了两件事情：

根据当前的情况，计算出任务分配清单，生成事件任务操作命令。
根据生成好的命令，调用运行节点api。

接下来就比较清晰了，我们的程序就是要保证上面两件事件稳定、可靠、高效的完成，大体的处理逻辑如下：

图6 实现逻辑

接下来我们再把两种特殊场景接入到这种日常调度逻辑里面来：

第一次初始化时，在最开始的时候根据节点和总的事件清单，生成一个完整的节点任务清单，然后直接进入日常调度逻辑。
当有新的事件发布/下线通知进来的时候，根据通知内容去更新节点任务清单，同时对内存变量进行一个标记，然后直接进入日常调度逻辑。并且目前调度的定时器是2秒触发一次，但是不会每次都执行调度逻辑，而是会判断是否达到定时调度的时间，或者是事件变更通知的内存标记为已变更，也避免频繁调度造成的性能和稳定性风险。

五、结束
经过我们的分析设计，我们把一个看似繁杂的分布式调度的场景变的简单了，提炼出其中的核心逻辑，然后去实现和完善它，以不变应万变，只要保证其中的核心逻辑的稳定，不管外面的接入场景如何多变，我们都能从容的应对。
在本篇中，我们没有去涉及什么很高深的框架和组件以及具体的实现代码，主要还是对我们在实现这个分布式调度过程中的思路进行了一些分享。我们不敢说一定是最对最好的，但是当思路清楚了，实现起来也就不复杂了。

------ END ------

作者简介

王同学： 架构师，目前负责ERP集成平台架构的规划与设计工作。

也许您还想看

MIP服务发现的高可用架构实践

基于消息的高稳定集成架构方案

一个全栈式的应用集成平台，打破“信息孤岛”

研发协同平台持续集成2.0架构演进