一种基于云原生的分布式调度监控系统及其部署方法技术方案

本发明专利技术公开了一种基于云原生的分布式调度监控系统及其部署方法，属于云原生及应用部署技术领域，基于消息中间件承载大并发请求任务，基于并发线程池执行调度任务；通过服务发现中心支撑整个集群的ETL调度服务发现，包括调度侧和执行侧；执行侧跟调度侧服务器完全解耦，配置执行侧线程池节点服务与服务发现中心集群建立保持连接关系，通过心跳检测发现服务，一旦发现某个服务挂掉，由服务发现中心立即切换到其他服务节点，切换动作对用户透明，整个过程都是在云上完成。本发明专利技术能够解决并优化完善现行基于kettle的任务调度监控的问题。化完善现行基于kettle的任务调度监控的问题。化完善现行基于kettle的任务调度监控的问题。

【技术实现步骤摘要】
一种基于云原生的分布式调度监控系统及其部署方法


[0001]本专利技术涉及云原生及应用部署
，具体地说是一种基于云原生的分布式调度监控系统及其部署方法。

技术介绍

[0002]ETL(Extract
‑
Transform
‑
Load)是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起。Kettle是一款国外开源的ETL工具，当前很多数据分析行业以及业务系统数据对接借助Kettle来实现，目前业内有的使用调度平台(Kettle Manager)或Tank工具来管理这些作业或转换任务，而且也基于Kettle封装了一些功能，方便了用户操作，提升了部分管理能力，但对于支持云上灵活部署(Flexible deployment)、功能易用性(Accessibility)、安全性(Security)、可扩展性(Scalability)、高并发策略(High Concurrency Strategy)等方面确实存在着如下明显缺陷：
[0003]高可用性(High Availability)依然存在局限性,目前Tank支持的Carte集群无法自主切换主从功能，一旦Master宕机，那么整个系统将不可用；
[0004]通信成本高(High Communication Cost)，Tank调度过程网络成本要求很高，Tank使用Carte集群，由于主、子节点分布在不同的虚拟机上，整个调度过程要进行不间断的通信，数据不停的传输，业务量骤增、数据请求徒增的场景下，单Carte节点服务器依然会出现卡顿的情况；
[0005]扩展成本(High Scalability Cost)比较高，Tank使用Carte集群需要更多的服务器，每增加一台子服务器，都会增加人为因素的运维、配置、调试成本，效率极低，出错率斗升，KettleManager直接是单机，更不可能扩展集群；
[0006]任务编排不方便(Inconvenient Configuration)，Tank以及KettleManager作业、转换等任务编排还要依赖于Kettle的GUI(Graphical User Interface，又称图形用户接口)，性能极低、而且无法跨平台，仅限于windows操作系统，遇到linux、Ubuntu、unix等操作系统完全失去作用；
[0007]有一定的安全风险(Security Risk)，Tank使用的Carte集群服务器用户名、密码等全都裸露在外部，对于十分注重安全的大型国有企业是不能接受的，一旦信息泄露可能会遭受DDoS等攻击；
[0008]部署不灵活(Inflexible Deployment)，Tank以及KettleManager使用原始的jar包部署方式，手动维护基础参数、配置，整个部署过程都需要人为的上传服务器、修改命令、执行命令等一大堆冗余、繁杂操作，对运维侧支持力度较差，极大降低部署、运行效率，节点越多、子服务器越多配置过程越复杂，也越容易出错。
[0009]图1所示是KettleManager当前使用的技术架构图，图2是Tank当前使用的技术架构图，图1是单节点服务器，所有业务系统以及业务库等都与监控调度平台在一台服务器上，有单节点故障(Single Node Failure)的可能性，图2虽然使用了Carte服务器作为集
群，但集群服务器之间需要额外增加数据同步工作才能确保两边数据一致，而且采用文件库存储数据会频繁的对硬盘I/O操作，CPU也是一个瓶颈，尤其高并发、大批量作业的情况下，异常数据无法实时体现到页面，容易出现异常抖动，使得整个ETL过程变得不可控。

技术实现思路

[0010]本专利技术的技术任务是针对以上不足之处，提供一种基于云原生的分布式调度监控系统及其部署方法，能够解决并优化完善现行基于kettle的任务调度监控的问题。
[0011]本专利技术解决其技术问题所采用的技术方案是：
[0012]一种基于云原生的分布式调度监控系统，基于消息中间件承载大并发请求任务，基于并发线程池执行调度任务；通过服务发现中心支撑整个集群的ETL调度服务发现，包括调度侧、执行侧；
[0013]调度侧接受各个业务系统的并发调度请求，每个请求都包含一个消息主题(Topic)，由消息集群根据所述消息主题(Topic)来决定分发到哪台节点服务器的主节点(Master)上，根据消息分发机制，大量的业务调度请求平均分散到不同的节点服务器，每台节点服务器之间进行消息的同步；
[0014]执行侧使用并发线程池(Concurrency Thread Pool)实现任务执行；调度侧将调度消息同步至任务队列，执行侧线程池根据自身策略从任务队列获取调度请求，整个任务获取过程是并行进行，并发线程池(Concurrency Thread Pool)执行具体的任务；
[0015]执行侧跟调度侧服务器完全解耦，不存在资源竞争的情况，配置执行侧线程池节点服务与服务发现中心(Name Server)集群建立保持连接关系，通过心跳检测发现服务，一旦发现某个服务挂掉，由服务发现中心立即切换到其他服务节点，切换动作对用户透明，丝毫不需要考虑数据硬性同步问题，也不需要人工介入，整个过程都是在云上完成。
[0016]优选的，所述消息中间件承载大并发请求任务，消息集群节点数至少为2个，即Nodes＝2+N(N＝0,1,2,3
…
),每个节点又包含一个主节点(Master)、一个从节点(Slave)，主节点(Master)将会采用同步或者异步方式将ETL调度消息分发给子节点(Slave)，即使主节点(Master)挂了，任务也不会丢失，任务将会保留一份到子节点(Slave)，如果出现主子节点同步失败，则会启用补偿机制，实现调度任务请求的找回，来redo异常调度请求，避免重复动作，保证集群的高可用性(High Availability)。
[0017]优选的，所述并发线程池，继承自ThreadPoolTaskExecutor，对其进行了扩展、性能提升，并增加了线程活跃实时监测、线程池动态拓展的能力，默认配置核心线程数(Core Pool Size)20、最大线程数(Max Pool Size)100、队列最大容量(Queue Capacity)200,000、线程池预警阀值(Alarm Pool Size Rate)20％(即当前最大可用线程数量低于20％就预警并发送短信提醒)、队列预警阀值(Alarm Queue Capacity Rate)20％(即当前队列可用容量低于总容量的20％就预警并发送短信提醒)，
[0018]执行侧节点服务可以根据需要自行调节，只需要增加或减小Pod副本数就能实现服务节点的增加或减少，配置共享、横向扩展。
[0019]优选的，通过设置资源管理模块管理消息集群以及线程池，由消息集群的服务发现中心(Name Server Center)本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种基于云原生的分布式调度监控系统，其特征在于，基于消息中间件承载大并发请求任务，基于并发线程池执行调度任务；通过服务发现中心支撑整个集群的ETL调度服务发现，包括调度侧和执行侧；调度侧接受各个业务系统的并发调度请求，每个请求都包含一个消息主题，由消息集群根据所述消息主题来决定分发到哪台节点服务器的主节点上，根据消息分发机制，大量的业务调度请求平均分散到不同的节点服务器，每台节点服务器之间进行消息的同步；执行侧使用并发线程池实现任务执行；调度侧将调度消息同步至任务队列，执行侧线程池根据自身策略从任务队列获取调度请求，整个任务获取过程是并行进行的，并发线程池执行具体的任务；执行侧跟调度侧服务器完全解耦，配置执行侧线程池节点服务与服务发现中心集群建立保持连接关系，通过心跳检测发现服务，一旦发现某个服务挂掉，由服务发现中心立即切换到其他服务节点，切换动作对用户透明，整个过程都是在云上完成。2.根据权利要求1所述的一种基于云原生的分布式调度监控系统，其特征在于，所述消息中间件承载大并发请求任务，消息集群节点数至少为2个，每个节点又包含一个主节点、一个从节点，主节点采用同步或者异步方式将ETL调度消息分发给子节点；如果出现主子节点同步失败，则会启用补偿机制，实现调度任务请求的找回，来redo异常调度请求，避免重复动作，保证集群的高可用性。3.根据权利要求1或2所述的一种基于云原生的分布式调度监控系统，其特征在于，所述并发线程池，对ThreadPoolTaskExecutor进行扩展、性能提升，并增加了线程活跃实时监测、线程池动态拓展的能力，默认配置核心线程数20、最大线程数100、队列最大容量200,000、线程池预警阀值20％、队列预警阀值20％；执行侧节点服务根据需要自行调节，只需要增加或减小Pod副本数就能实现服务节点的增加或减少，配置共享、横向扩展。4.根据权利要求3所述的一种基于云原生的分布式调度监控系统，其特征在于，通过设置资源管理模块管理消息集群以及线程池，由消息集群的服务发现中心自动发现待执行业务并通知给业务调用端；所述资源管理模块提供消息集群地址维护、消息类型管理、服务发现注册，提供线程池基础配置，包括核心线程数、最大线程数、队列最大容量、线程池预警阀值、队列预警阀值。5.根据权利要求4所述的一种基于云原生的分布式调度监控系统，其特征在于，设置告警监控模块，监控信息包括集群状态、线程状态、调度状态、节点状态，消息集群出现异常调度请求时，写入到告警监控模块；线程池出现异常情况时反馈给告警监控模块。6.根据权利要求4所述的一种基于云原生的分布式调度监控系统，其特征在于，设置在线编排管理模块，通过浏览器实现编排加调度监控的能力；所述在线编排管理模块，基于原开源Web Spoon实现，借助Vue2、iview以及微服务深度集成技术实现与系统用户、权限、菜单、角色的深度集成，通过本调度监控系统来统一管理用户、权限、菜单、角色，并实现底层kettle资源库的打通、同步，扩展兼容不同的ketle版本、以及大数据Spark、Flink、Kafka插件的支持。7.根据权利要求4所述的一种基于云原生的分布式调度监控系统，其特征在于，设置API核心调度管理模块，调度任务包括作业调度、转换调度、Spark调度及Kafka调度，调度监
控系统对所述调度任务进...

【专利技术属性】
技术研发人员：于恩彬，林大伟，郑斌，张永刚，孙守伟，
申请(专利权)人：山东浪潮数字商业科技有限公司，
类型：发明
国别省市：