一种复杂事件处理单元部署系统

本发明涉及一种基于kubernetes的复杂事件处理单元部署系统，属于计算机软件。

背景技术：

1、复杂事件处理(complex event processing，cep)是一种在动态环境中对事件的实时流处理分析技术，此处的事件通常指对于系统或环境有意义的状态变化。复杂事件处理的模型一般是由一系列处理单元(operator)组成的有向无环图，即处理单元图(operator graph)。借助该技术，用户通过对事件间关系的理解向处理单元制定规则，实现对事件的实时过滤、关联、聚合，得到对事件流的分析，并期望从中获取有价值的复杂事件序列或信息，从而做出响应。该技术广泛应用于防止犯罪、风险识别、营销决策等领域。在分布式计算模型中，如何将复杂事件的处理单元部署在各个计算节点上，从而满足用户对系统的响应时间、负载均衡的期望，在学术上被归类为处理单元部署问题(operatorplacement problem)。现有技术中对于处理单元部署问题的研究，通常采用软件仿真环境，例如omnet++或ns3等，相比于真机环境，软件仿真在对链路时延、拥塞控制等方面的模拟效果存在一定不足，需要真机环境对研究的算法或内容进行进一步的验证。

技术实现思路

1、发明目的：针对现有技术中存在的问题与不足，本发明提供一种基于kubernetes的复杂事件处理单元部署系统，借助容器集群管理平台kubernetes，有效解决了复杂事件处理单元部署问题(operator placement problem)相关领域的研究人员在进行研究时对部署算法验证与比较的需求，实现了对复杂事件处理模型的简易部署。用户可以通过该系统实现处理单元在真机环境下的简易部署，高效完成部署算法的验证与比较工作。

2、技术方案：一种基于kubernetes的复杂事件处理单元部署系统，主要由四个部分组成，分别是集群抽象层cluster、复杂事件处理单元模型models、算法模块methods和部署模块core。

3、集群抽象层cluster，通过kubetools模块实现了对kubernetes集群的虚拟化，屏蔽了许多来自硬件节点本身或者kubernetes的配置细节。kubetools模块主要是对kubernetes api的封装，还包含了用于模拟链路时延的delayrules模块。

4、复杂事件处理单元模型models，该模块是一个将所有由用户编写的处理单元operator、编排的处理单元图graph和事件描述类event、数据生成模块data、运行启动器starter打包成的容器镜像。复杂事件处理单元模型models将会依据用户编写好的dockerfile的指示被docker打包上传到镜像仓库。dockerfile是docker打包时所用到的配置文件，docker是一个开源的应用容器引擎。

5、算法模块methods，该模块主要由一个抽象算法基类和若干个继承了该基类的实际算法样例组成。抽象算法基类规定了部署算法的输入输出，用户可以通过继承抽象算法基类的形式实现自己想要的部署算法。部署算法从集群获取状态信息，生成部署策略，出来的结果最终被部署模块core所调用，应用于部署。

6、部署模块core，该模块主要由部署实验的配置模块config、集群初始化模块initialize、负责执行部署的deploy模块和计算响应时间的delaycalculate模块组成。其中配置模块config是对系统中诸多参数的抽取集中。集群初始化模块initialize会通过kubetools为集群中每一个节点部署一个用于测量节点间链路时延的nginx容器。而deploy模块则负责通过用户所选择的部署算法返回的部署策略对集群执行部署。

7、集群抽象层cluster通过kubetools模块实现了对kubernetes集群的虚拟化，屏蔽了许多来自硬件节点本身或者kubernetes的配置细节。kubernetes集群的每个节点上都会部署一个以容器形式存在的nginx服务器，主要用于拓展一些kubernetes api没有提供的功能，当需要获取节点间的响应时延时，就可以借助kubernetes api进入容器内部执行curl命令来获取。

8、集群抽象层cluster通过kubetools模块中的delayrules模块约定了kubernetes集群节点间链路时延的放大倍数，这些放大倍数会在复杂事件处理单元模型models中的处理单元operator中被调用，并用于实现链路等效时延模拟。

9、复杂事件处理单元模型models中的所有处理单元operator、编排的处理单元图graph都由各自对应的抽象基类继承而来。处理单元operator的抽象基类中实现了处理单元间的通信模型、链路等效时延模拟、输入率等效负载等级等功能，用户只需继承基类并覆盖其中用于处理事件的方法即可制定其所需要的处理单元operator。处理单元图graph的抽象基类中实现了各种供部署和算法使用的方法，并对子类提供一个需要被覆盖的、会被构造方法所调用的方法，称为覆盖调用方法。该覆盖调用方法返回若干处理单元operator的类型、名称和各自之间拓扑描述，用以完成编排的处理单元图graph的初始化。用户只需要在继承抽象基类时覆盖此覆盖调用方法，即可编排出所需要的处理单元图graph。

10、复杂事件处理单元模型models将会依据用户编写好的dockerfile的指示被docker打包上传到镜像仓库。在部署中，部署模块core中的deploy模块会指挥kubetools发送不同的指令填充复杂事件处理单元模型models的容器的entrypoint(相当于运行指令)，并将容器部署到各自对应的节点上，最后复杂事件处理单元模型models中的运行启动器starter会根据指令内容实例化对应的处理单元operator，最终实现在不同的节点上使用相同的容器镜像但却能运行不同的处理单元实例的效果。

11、算法模块methods中包含了若干个继承了抽象算法基类的各种实际部署算法样例，其中包括greedy算法、loadbalance算法、responsetimeaware算法和reinforcementlearning算法等。

12、部署模块core中的delaycalculate模块通过对kubernetes日志的分析计算了部署模型在不同部署算法下的响应时间。同时部署模块core内部各模块间耦合松散，用户可自行定义类似delaycalculate的模块以进行拓展，以获取对部署实验更多维度的分析。

13、处理单元operator的抽象基类中实现了处理单元operator间的通信模型。该通信模型主要借助于kubernetes的pod间通信原理和tcp网络编程实现。在kubernetes中，所有的容器都被打包在pod里，不同节点上部署的pod间是无法直接通信的，因为他们各自处在不同的虚拟地址空间。不过kubernetes提供了一种名为service的api对象。service的本质就像是一个路由表，可以在集群内部暴露一个访问地址，并将所有数据转发到与其具有相同标签的pod上。只要为每一个pod创建一个专属的service，即可实现pod之间的通信。

14、处理单元operator的抽象基类中实现了链路等效时延模拟，其主要原理是，假设目前集群内有n个节点，定义mij为第i个节点到第j个节点之间时延要放大的倍数(mij≥1)。先让用户编排好集群内所有节点之间时延放大的倍数(在delayrules模块中)。当系统开始运行时，在数据包中记录发送时间ts和发送节点i，然后在接收端再次记录接收时间tr和当前节点j，让接收线程等待一段长度为(ts–tr)×(mij–1)的时间，之后再将数据包交给负责事件处理的方法，从而达到模拟链路时延的效果。

15、处理单元operator的抽象基类中实现了输入率等效负载等级。由于在真实环境中，复杂事件处理模型面临的事件流输入率往往是动态变化的，在集群内部无法完全模拟出外部数据源动态产生事件的效果。需要通过特殊的处理单元担任数据源和数据消费者的角色。这时则会出现由于输入率存在上限导致无法模拟高压状态的情况。因此，我们定义系统状态值为事件输入率与集群算力的比值，视相同值的系统状态为等效状态，这样就能通过延长事件处理的时间降低集群算力，从而让事件输入率不变、集群算力下降的方式去等效模拟集群算力不变、事件输入率升高的状态。假设需要模拟的事件输入率的变化范围为rl到rh，则可将这个范围划分为i(i≥0)个区间，用0、1、2、…、i共i+1个等效负载等级的变化去取代事件输入率的变化，这里的i越大，划分出的等效结果就越精细。假设一个处理单元operator中处理完当前事件所用的时间为tprocess，然后让负责事件处理的线程方法在每处理完一个事件后等待twait长度的时间即可实现对集群算力的等效下降，则在第i(i＝0,1,2,…,i)级的等效负载等级下，等待时间twait的计算公式为：

16、

17、本发明具备以下有益效果：可以帮助解决复杂事件处理单元部署问题(operatorplacement problem)相关领域的研究人员在进行研究时对部署算法验证与比较的需求。相较于以往，用户只需要编写处理单元operator、编排处理单元图graph、实现自己的算法、配置基本参数即可实现对复杂事件处理模型的简易部署。同时还具备链路等效时延模拟、输入率等效负载等级等功能，支持多样化的自定义和拓展。相比于从头编写分布式程序、实现各种底层技术细节，该系统能帮助用户更专注于部署问题本身；相比于单机运行的网络仿真环境，该系统能在真实的物理机集群上部署，使得实验效果更加精确、真实。