基于声明式API的数据传输系统资源调度的方法及存储介质与流程

基于声明式api的数据传输系统资源调度的方法及存储介质
技术领域
1.本发明涉及kubernetes环境下资源调度技术领域，具体地说是一种基于声明式api的数据传输系统资源调度的方法及存储介质。


背景技术：

2.kubernetes，简称k8s，是用8代替8个字符"ubernete"而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，kubernetes的目标是让部署容器化的应用简单并且高效(powerful),kubernetes提供了应用部署，规划，更新，维护的一种机制。传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更"透明"，这更便于监控和管理。
3.kubernetes是google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在kubernetes中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。
4.平时在部署一个简单的webserver到kubernetes集群中的时候，都需要先编写一个deployment的控制器，然后创建一个service对象，通过pod的label标签进行关联，最后通过ingress或者type＝nodeport类型的service来暴露服务，每次都需要这样操作略显麻烦。
5.故如何利用kubernetes资源编排能力实现对数据传输系统资源的方便快捷调度是目前亟待解决的技术问题。


技术实现要素：

6.本发明的技术任务是提供一种基于声明式api的数据传输系统资源调度的方法及存储介质，来解决如何利用kubernetes资源编排能力实现对数据传输系统资源的方便快捷调度的问题。
7.本发明的技术任务是按以下方式实现的，一种基于声明式api的数据传输系统资
源调度的方法，该方法具体如下：
8.自定义api资源类型crd：分别定义数据传输系统的采集端资源、入库端资源和消息中间件资源的资源类型crd；其中，资源类型crd的组为dts；
9.应用对应资源类型crd的资源描述文件对采集端资源、入库端资源和消息中间件资源进行调度，并通过自定义控制器捕获应用的资源文件实现对应的资源调度工作；
10.通过对资源文件的定义完成底层物理资源与业务逻辑资源的抽象，并通过自定义控制器实现对业务资源的调度。
11.作为优选，所述数据传输系统包括采集组件、消息中间件和入库组件，采集组件读取数据后写入消息中间件，消息中间件对读取的数据进行缓存，以保证数据的完整性，并将采集组件与消息中间部署在一个pod中；采集组件和消息中间件分别定义一个类型dtsreader的资源类型crd，入库组件定义一个类型dtswriter的资源类型crd；
12.其中，采集组件用于从源端数据库读取数据；
13.消息中间件用于数据的保存与传输；
14.入库组件用于将采集的数据写入目的数据库。
15.更优地，所述dtsreader与dtswriter的资源类型crd的字段具体如下：
16.taskid：数据传输任务的唯一标识；
17.version：产品版本号，后台数据库采集组件和入库组件的版本号与产品版本号一致；
18.isavailable：资源是否可用；
19.dbinfo：数据源信息，源端或目的端数据库的连接信息；
20.task：任务配置信息，任务配置信息包括表信息、字段信息及相关的传输策略参数；
21.resources：资源信息，资源信息包括需要拉起的pod的cpu信息、内存信息及存储信息。
22.作为优选，自定义控制器是指为资源类型crd创建一个对应的cdr控制器，实现当crd对象发生变化时，触发crd控制器里面的业务逻辑代码；具体如下：
23.数据传输系统创建自定义控制器dts-operator；
24.自定义控制器dts-operator使用reflector的listandwatch方法获取并监听对象实例的变化；
25.当任何一个实例有任何变化，reflector均会收到事件通知，并收到通知后把对象实例对应的事件和对象的组合存入一个先进先出的队列中；
26.自定义控制器dts-operator使用informer不断从先进先出的队列中读取对象,并判断事件的类型是dtsreader或dtswriter：
27.确定事件的类型后，根据事件的类型创建dtsreader或dtswriter所需要的资源。
28.更优地，创建dtsreader所需的资源具体如下：
29.自定义控制器dts-operator创建采集组件所依赖的消息中间件nats的pod及service资源；
30.在消息中间件nats中，创建jetstream及consumer资源；
31.在消息中间件nats资源部署完成后，部署采集组件的pod、service及存储资源；
32.通过监控对应事件，并可将物理资源及业务配置均按自定义的逻辑进行处理；
33.当处理完成后，数据传输任务所需的采集组件便可正常工作；
34.创建dtswriter所需的资源具体如下：
35.自定义控制器dts-operator创建入库组件所需要的pod及service物理资源以及生成数据传输任务相关的配置文件；
36.将消息中间件nats相关的信息写入到配置文件中；
37.通过监控对应事件，并可将物理资源及业务配置均按自定义的逻辑进行处理；
38.当处理完成后，数据传输任务所需的入库组件便可正常工作。
39.更优地，自定义控制器dts-operator依靠informer的代码块从kubernetes的apiserver里获取dtswriter对象和dtsreader对象，informer与api对象一一对应，数据传输过程中传递给自定义控制器dts-operator的是一个network对象的informer；
40.其中，创建informer工厂时，为informer工厂传递一个networkclient，network informer使用networkclient与apiserver建立连接，维护network informer与apiserver连接的是informer所使用的reflector包中的listandwatch机制，listandwatch机制用于获取并监听network对象实例的变化；
41.在listandwatch机制下，一旦apiserver端有新的network实例被创建、删除或者更新，reflector均会收到对应network实例的事件通知，该事件及该事件对应的api对象组合就被称为增量delta，并放入一个增量先进先出队列(delta fifo queue)中；同时，inform会不断地从增量先进先出队列读取增量，每读取一个增量，informer便会判断该增量里的事件类型，并创建或更新本地对象的缓冲。
42.更优地，informer具有如下功能：
43.①
、同步本地缓存；informer自带缓存和索引机制；触发handler的客户端库，本地缓存在kubernetes中被称为store，索引被称为index；informer使用reflector包，reflector包通过listandwatch机制获取并监视api对象变化的客户端封装；reflector包和informer之间用一个增量先进先出队列进行协同；
44.②
、根据事件类型，触发实现注册好的resourceeventhandler(资源事件处理程序)；通过监听到的事件变化，informer实时地更新本地缓存,并且调用事件对应的eventhandler(事件处理程序)，每经过resyncperiod指定的时间,informer维护的本地缓存均会使用最近一次list返回的结果强制更新一次,从而保证缓存的有效性；其中，创建自定义控制器dts-operator时，注册给resourceeventhandler对应的informer；
45.informer在编写的控制循环前,使用一个工作队列来进行协同；在实际应用中,除了控制循环之外的所有代码,实际上都是kubernetes自动生成的；其中，informer控制循环的逻辑具体如下：
46.等待informer完成一次本地缓存的数据同步操作；
47.通过goroutine启动一个或多个无限循环任务；
48.在每一个循环周期中，执行的就是数据传输业务逻辑代码；
49.若控制循环在informer缓存中获取不到相应的对象的信息，则说明要执行删除逻辑；
50.若从缓存中获取到对象信息，则执行控制器模式对比期望状态和实际状态，期望
状态来自于etcd实际状态来自于集群本身。
51.作为优选，自定义api资源类型crd还包括如下内容：
52.进行api对象的initializer操作和validation操作：validation操作验证对象中各个字段的合法性,验证后保存到registry数据结构中,一个api对象的定义能在registry里能查到,则说明该api对应是一个有效的k8sapi对象；
53.把superversion对象转换成用户提交版本的对象序列化后保存到etcd中。
54.作为优选，所述数据传输系统定义一个管理端服务dts-service，管理端服务dts-service用于接收前端发送的用户指令，通过声明式api方式与后端自定义控制器dts-operator交互，实现对数据传输任务资源的创建和任务的操作逻辑控制；
55.其中，资源的创建具体如下：
56.用户通过在前端界面创建任务，前端界面通过http请求调用管理端服务dts-service创建数据传输任务方法；
57.管理端服务dts-service通过访问kubernetes的api，按顺序应用该数据传输任务dtsreader及dtswriter的资源类型crd，资源类型crd中的name字段与任务编号一致用来区分不同任务的资源类型crd；
58.应用的资源类型crd会由自定义控制器dts-operator监听到并执行对应的创建资源逻辑；
59.资源创建后，数据库的采集组件、入库组件和消息中间件nats自动完成初始化工作；
60.管理端服务dts-service检测到任务的采集组件和入库组件资源已成功分配且正常初始化后，返回给用户创建成功消息；
61.业务的操作逻辑控制具体如下：
62.用户通过在前端界面进行数据传输任务的启动、停止、暂停、续传、变更密码及删除操作；前端界面通过http请求调用管理端服务dts-service中对应的方法；
63.管理端服务dts-service分别组装该数据传输任务对应的dtsreader及dtswriter的资源类型crd，资源类型crd的name字段与任务编号一致用来区分不同任务的资源类型crd；
64.在组装的资源类型crd中的operation字段对应用户的操作，比如停止操作时operation字段对应的值为stoptask；
65.管理端服务dts-service通过访问kubernetes的api，分别应用该任务dtsreader及dtswriter的资源类型crd；
66.管理端服务dts-operator监听到资源类型crd版本变化后，对operation字段的内容进行分析来判断用户的操作，根据操作类型分别调用采集组件及入库组件对应操作的grpc接口，从而完成用户的操作。
67.一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序可被处理器执行以实现如上述的基于声明式api的数据传输系统资源调度的方法。
68.本发明的基于声明式api的数据传输系统资源调度的方法及存储介质具有以下优点：
69.(一)本发明中数据传输系统使用crd来定义业务模型对应的资源，通过自定义控制器捕获应用的资源文件，自定义控制器根据编写的规则，完成所需资源的调度；
70.(二)本发明利用声明式api强大kubernetes资源编排能力，实现对数据传输系统的业务资源进行抽象并定义，对数据传输系统所需的资源进行调度；
71.(三)本发明通过使用声明式api来实现数据传输系统业务的资源调度，通过自定义资源能够更好的描述业务资源，通过自定义控制器能够更好高效的使用kubernetes项目编排能力，主要体现在以下几个方面：
72.①
本发明允许有多个api写端,以patch的方式对api对象进行修改,而无需关心本地原始yaml文件的内容；
73.②
本发明可以基于对api对象的增、删、改、查，在完全无需外界干预的情况下,完成对“实际状态”和“期望状态”的调谐(reconcile)过程。
附图说明
74.下面结合附图对本发明进一步说明。
75.附图1为基于声明式api的数据传输系统资源调度的方法的结构示意图。
具体实施方式
76.参照说明书附图和具体实施例对本发明的基于声明式api的数据传输系统资源调度的方法及存储介质作以下详细地说明。
77.实施例1：
78.本实施例提供了一种基于声明式api的数据传输系统资源调度的方法，该方法具体如下：
79.s1、自定义api资源类型crd：分别定义数据传输系统的采集端资源、入库端资源和消息中间件资源的资源类型crd；其中，资源类型crd的组为dts；
80.s2、应用对应资源类型crd的资源描述文件对采集端资源、入库端资源和消息中间件资源进行调度，并通过自定义控制器捕获应用的资源文件实现对应的资源调度工作；
81.s3、通过对资源文件的定义完成底层物理资源与业务逻辑资源的抽象，并通过自定义控制器实现对业务资源的调度。
82.本实施例中的数据传输系统包括采集组件、消息中间件和入库组件，采集组件读取数据后写入消息中间件，消息中间件对读取的数据进行缓存，以保证数据的完整性，并将采集组件与消息中间部署在一个pod中；采集组件和消息中间件分别定义一个类型dtsreader的资源类型crd，入库组件定义一个类型dtswriter的资源类型crd；
83.其中，采集组件用于从源端数据库读取数据；
84.消息中间件用于数据的保存与传输；
85.入库组件用于将采集的数据写入目的数据库。
86.本实施例中的dtsreader与dtswriter的资源类型crd的字段具体如下：
87.taskid：数据传输任务的唯一标识；
88.version：产品版本号，后台数据库采集组件和入库组件的版本号与产品版本号一致；
89.isavailable：资源是否可用；
90.dbinfo：数据源信息，源端或目的端数据库的连接信息；
91.task：任务配置信息，任务配置信息包括表信息、字段信息及相关的传输策略参数；
92.resources：资源信息，资源信息包括需要拉起的pod的cpu信息、内存信息及存储信息。
93.本实施例中的自定义控制器是指为资源类型crd创建一个对应的cdr控制器，实现当crd对象发生变化时，触发crd控制器里面的业务逻辑代码；具体如下：
94.(一)、数据传输系统创建自定义控制器dts-operator；
95.(二)、自定义控制器dts-operator使用reflector的listandwatch方法获取并监听对象实例的变化；
96.(三)、当任何一个实例有任何变化，reflector均会收到事件通知，并收到通知后把对象实例对应的事件和对象的组合存入一个先进先出的队列中；
97.(四)、自定义控制器dts-operator使用informer不断从先进先出的队列中读取对象,并判断事件的类型是dtsreader或dtswriter：
98.(五)、确定事件的类型后，根据事件的类型创建dtsreader或dtswriter所需要的资源。
99.本实施例中，创建dtsreader所需的资源具体如下：
100.(1)、自定义控制器dts-operator创建采集组件所依赖的消息中间件nats的pod及service资源；
101.(2)、在消息中间件nats中，创建jetstream及consumer资源；
102.(3)、在消息中间件nats资源部署完成后，部署采集组件的pod、service及存储资源；
103.(4)、通过监控对应事件，并可将物理资源及业务配置均按自定义的逻辑进行处理；
104.(5)、当处理完成后，数据传输任务所需的采集组件便可正常工作；
105.本实施例中，创建dtswriter所需的资源具体如下：
106.(1)、自定义控制器dts-operator创建入库组件所需要的pod及service物理资源以及生成数据传输任务相关的配置文件；
107.(2)、将消息中间件nats相关的信息写入到配置文件中；
108.(3)、通过监控对应事件，并可将物理资源及业务配置均按自定义的逻辑进行处理；
109.(4)、当处理完成后，数据传输任务所需的入库组件便可正常工作。
110.本实施例中的自定义控制器dts-operator依靠informer的代码块从kubernetes的apiserver里获取dtswriter对象和dtsreader对象，informer与api对象一一对应，数据传输过程中传递给自定义控制器dts-operator的是一个network对象的informer；
111.其中，创建informer工厂时，为informer工厂传递一个networkclient，network informer使用networkclient与apiserver建立连接，维护network informer与apiserver连接的是informer所使用的reflector包中的listandwatch机制，listandwatch机制用于
获取并监听network对象实例的变化；
112.在listandwatch机制下，一旦apiserver端有新的network实例被创建、删除或者更新，reflector均会收到对应network实例的事件通知，该事件及该事件对应的api对象组合就被称为增量delta，并放入一个增量先进先出队列(delta fifo queue)中；同时，inform会不断地从增量先进先出队列读取增量，每读取一个增量，informer便会判断该增量里的事件类型，并创建或更新本地对象的缓冲。
113.本实施例中的informer具有如下功能：
114.①
、同步本地缓存；informer自带缓存和索引机制；触发handler的客户端库，本地缓存在kubernetes中被称为store，索引被称为index；informer使用reflector包，reflector包通过listandwatch机制获取并监视api对象变化的客户端封装；reflector包和informer之间用一个增量先进先出队列进行协同；
115.②
、根据事件类型，触发实现注册好的resourceeventhandler(资源事件处理程序)；通过监听到的事件变化，informer实时地更新本地缓存,并且调用事件对应的eventhandler(事件处理程序)，每经过resyncperiod指定的时间,informer维护的本地缓存均会使用最近一次list返回的结果强制更新一次,从而保证缓存的有效性；其中，创建自定义控制器dts-operator时，注册给resourceeventhandler对应的informer；
116.informer在编写的控制循环前,使用一个工作队列来进行协同；在实际应用中,除了控制循环之外的所有代码,实际上都是kubernetes自动生成的；其中，informer控制循环的逻辑具体如下：
117.(1)、等待informer完成一次本地缓存的数据同步操作；
118.(2)、通过goroutine启动一个或多个无限循环任务；
119.(3)、在每一个循环周期中，执行的就是数据传输业务逻辑代码：
120.①
、若控制循环在informer缓存中获取不到相应的对象的信息，则说明要执行删除逻辑；
121.②
、若从缓存中获取到对象信息，则执行控制器模式对比期望状态和实际状态，期望状态来自于etcd实际状态来自于集群本身。
122.本实施例中，自定义api资源类型crd还包括如下内容：
123.①
、进行api对象的initializer操作和validation操作：validation操作验证对象中各个字段的合法性,验证后保存到registry数据结构中,一个api对象的定义能在registry里能查到,则说明该api对应是一个有效的k8sapi对象；
124.②
、把superversion对象转换成用户提交版本的对象序列化后保存到etcd中。
125.如附图1所示，本实施例中的数据传输系统定义一个管理端服务dts-service，管理端服务dts-service用于接收前端发送的用户指令，通过声明式api方式与后端自定义控制器dts-operator交互，实现对数据传输任务资源的创建和任务的操作逻辑控制；
126.本实施例中的资源的创建具体如下：
127.(1)、用户通过在前端界面创建任务，前端界面通过http请求调用管理端服务dts-service创建数据传输任务方法；
128.(2)、管理端服务dts-service通过访问kubernetes的api，按顺序应用该数据传输任务dtsreader及dtswriter的资源类型crd，资源类型crd中的name字段与任务编号一致用
来区分不同任务的资源类型crd；
129.(3)、应用的资源类型crd会由自定义控制器dts-operator监听到并执行对应的创建资源逻辑；
130.(4)、资源创建后，数据库的采集组件、入库组件和消息中间件nats自动完成初始化工作；
131.(5)、管理端服务dts-service检测到任务的采集组件和入库组件资源已成功分配且正常初始化后，返回给用户创建成功消息；
132.本实施例中的业务的操作逻辑控制具体如下：
133.(1)、用户通过在前端界面进行数据传输任务的启动、停止、暂停、续传、变更密码及删除操作；前端界面通过http请求调用管理端服务dts-service中对应的方法；
134.(2)、管理端服务dts-service分别组装该数据传输任务对应的dtsreader及dtswriter的资源类型crd，资源类型crd的name字段与任务编号一致用来区分不同任务的资源类型crd；
135.(3)、在组装的资源类型crd中的operation字段对应用户的操作，比如停止操作时operation字段对应的值为stoptask；
136.(4)、管理端服务dts-service通过访问kubernetes的api，分别应用该任务dtsreader及dtswriter的资源类型crd；
137.(5)、管理端服务dts-operator监听到资源类型crd版本变化后，对operation字段的内容进行分析来判断用户的操作，根据操作类型分别调用采集组件及入库组件对应操作的grpc接口，从而完成用户的操作。
138.实施例2：
139.本实施例还提供了一种计算机可读存储介质，其中存储有多条指令，指令由处理器加载，使处理器执行本发明任一实施例中的基于声明式api的数据传输系统资源调度的方法。具体地，可以提供配有存储介质的系统或者装置，在该存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机(或cpu或mpu)读出并执行存储在存储介质中的程序代码。
140.在这种情况下，从存储介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此程序代码和存储程序代码的存储介质构成了本发明的一部分。
141.用于提供程序代码的存储介质实施例包括软盘、硬盘、磁光盘、光盘(如cd-rom、cd-r、cd-rw、dvd-rom、dvd-rym、dvd-rw、dvd+rw)、磁带、非易失性存储卡和rom。可选择地，可以由通信网络从服务器计算机上下载程序代码。
142.此外，应该清楚的是，不仅可以通过执行计算机所读出的程序代码，而且可以通过基于程序代码的指令使计算机上操作的操作系统等来完成部分或者全部的实际操作，从而实现上述实施例中任意一项实施例的功能。
143.此外，可以理解的是，将由存储介质读出的程序代码写到插入计算机内的扩展板中所设置的存储器中或者写到与计算机相连接的扩展单元中设置的存储器中，随后基于程序代码的指令使安装在扩展板或者扩展单元上的cpu等来执行部分和全部实际操作，从而实现上述实施例中任一实施例的功能。
144.最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽
管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。