CN116841705A - 一种基于云原生的分布式调度监控系统及其部署方法 - Google Patents
一种基于云原生的分布式调度监控系统及其部署方法 Download PDFInfo
- Publication number
- CN116841705A CN116841705A CN202310554659.0A CN202310554659A CN116841705A CN 116841705 A CN116841705 A CN 116841705A CN 202310554659 A CN202310554659 A CN 202310554659A CN 116841705 A CN116841705 A CN 116841705A
- Authority
- CN
- China
- Prior art keywords
- scheduling
- cloud
- message
- service
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 83
- 238000000034 method Methods 0.000 title claims abstract description 42
- 230000008569 process Effects 0.000 claims abstract description 29
- 230000009471 action Effects 0.000 claims abstract description 11
- 238000001514 detection method Methods 0.000 claims abstract description 4
- 238000007726 management method Methods 0.000 claims description 23
- 230000002159 abnormal effect Effects 0.000 claims description 19
- 238000006243 chemical reaction Methods 0.000 claims description 11
- 238000012550 audit Methods 0.000 claims description 9
- 238000005516 engineering process Methods 0.000 claims description 9
- 230000010354 integration Effects 0.000 claims description 8
- 230000001360 synchronised effect Effects 0.000 claims description 7
- 230000007246 mechanism Effects 0.000 claims description 6
- 239000008186 active pharmaceutical agent Substances 0.000 claims description 4
- 238000012423 maintenance Methods 0.000 claims description 4
- 238000004458 analytical method Methods 0.000 claims description 3
- 239000008358 core component Substances 0.000 claims description 3
- 238000009826 distribution Methods 0.000 claims description 3
- 230000000694 effects Effects 0.000 claims description 3
- 238000002360 preparation method Methods 0.000 claims description 3
- 230000000750 progressive effect Effects 0.000 claims description 3
- 238000011084 recovery Methods 0.000 claims description 3
- 239000007921 spray Substances 0.000 claims description 3
- 238000003860 storage Methods 0.000 claims description 3
- 230000001105 regulatory effect Effects 0.000 claims 1
- 238000012806 monitoring device Methods 0.000 abstract 1
- 238000010586 diagram Methods 0.000 description 22
- 230000006870 function Effects 0.000 description 6
- 238000000227 grinding Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000006978 adaptation Effects 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 3
- 230000003247 decreasing effect Effects 0.000 description 3
- 230000007547 defect Effects 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
- G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Quality & Reliability (AREA)
- Mathematical Physics (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于云原生的分布式调度监控系统及其部署方法，属于云原生及应用部署技术领域，基于消息中间件承载大并发请求任务，基于并发线程池执行调度任务；通过服务发现中心支撑整个集群的ETL调度服务发现，包括调度侧和执行侧；执行侧跟调度侧服务器完全解耦，配置执行侧线程池节点服务与服务发现中心集群建立保持连接关系，通过心跳检测发现服务，一旦发现某个服务挂掉，由服务发现中心立即切换到其他服务节点，切换动作对用户透明，整个过程都是在云上完成。本发明能够解决并优化完善现行基于kettle的任务调度监控的问题。
Description
技术领域
本发明涉及云原生及应用部署技术领域，具体地说是一种基于云原生的分布式调度监控系统及其部署方法。
背景技术
ETL(Extract-Transform-Load)是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起。Kettle是一款国外开源的ETL工具，当前很多数据分析行业以及业务系统数据对接借助Kettle来实现，目前业内有的使用调度平台(Kettle Manager)或Tank工具来管理这些作业或转换任务，而且也基于Kettle封装了一些功能，方便了用户操作，提升了部分管理能力，但对于支持云上灵活部署(Flexible deployment)、功能易用性(Accessibility)、安全性(Security)、可扩展性(Scalability)、高并发策略(High Concurrency Strategy)等方面确实存在着如下明显缺陷：
高可用性(High Availability)依然存在局限性,目前Tank支持的Carte集群无法自主切换主从功能，一旦Master宕机，那么整个系统将不可用；
通信成本高(High Communication Cost)，Tank调度过程网络成本要求很高，Tank使用Carte集群，由于主、子节点分布在不同的虚拟机上，整个调度过程要进行不间断的通信，数据不停的传输，业务量骤增、数据请求徒增的场景下，单Carte节点服务器依然会出现卡顿的情况；
扩展成本(High Scalability Cost)比较高，Tank使用Carte集群需要更多的服务器，每增加一台子服务器，都会增加人为因素的运维、配置、调试成本，效率极低，出错率斗升，KettleManager直接是单机，更不可能扩展集群；
任务编排不方便(Inconvenient Configuration)，Tank以及KettleManager作业、转换等任务编排还要依赖于Kettle的GUI(Graphical User Interface，又称图形用户接口)，性能极低、而且无法跨平台，仅限于windows操作系统，遇到linux、Ubuntu、unix等操作系统完全失去作用；
有一定的安全风险(Security Risk)，Tank使用的Carte集群服务器用户名、密码等全都裸露在外部，对于十分注重安全的大型国有企业是不能接受的，一旦信息泄露可能会遭受DDoS等攻击；
部署不灵活(Inflexible Deployment)，Tank以及KettleManager使用原始的jar包部署方式，手动维护基础参数、配置，整个部署过程都需要人为的上传服务器、修改命令、执行命令等一大堆冗余、繁杂操作，对运维侧支持力度较差，极大降低部署、运行效率，节点越多、子服务器越多配置过程越复杂，也越容易出错。
图1所示是KettleManager当前使用的技术架构图，图2是Tank当前使用的技术架构图，图1是单节点服务器，所有业务系统以及业务库等都与监控调度平台在一台服务器上，有单节点故障(Single Node Failure)的可能性，图2虽然使用了Carte服务器作为集群，但集群服务器之间需要额外增加数据同步工作才能确保两边数据一致，而且采用文件库存储数据会频繁的对硬盘I/O操作，CPU也是一个瓶颈，尤其高并发、大批量作业的情况下，异常数据无法实时体现到页面，容易出现异常抖动，使得整个ETL过程变得不可控。
发明内容
本发明的技术任务是针对以上不足之处，提供一种基于云原生的分布式调度监控系统及其部署方法，能够解决并优化完善现行基于kettle的任务调度监控的问题。
本发明解决其技术问题所采用的技术方案是：
一种基于云原生的分布式调度监控系统，基于消息中间件承载大并发请求任务，基于并发线程池执行调度任务；通过服务发现中心支撑整个集群的ETL调度服务发现，包括调度侧、执行侧；
调度侧接受各个业务系统的并发调度请求，每个请求都包含一个消息主题(Topic)，由消息集群根据所述消息主题(Topic)来决定分发到哪台节点服务器的主节点(Master)上，根据消息分发机制，大量的业务调度请求平均分散到不同的节点服务器，每台节点服务器之间进行消息的同步；
执行侧使用并发线程池(Concurrency Thread Pool)实现任务执行；调度侧将调度消息同步至任务队列，执行侧线程池根据自身策略从任务队列获取调度请求，整个任务获取过程是并行进行，并发线程池(Concurrency Thread Pool)执行具体的任务；
执行侧跟调度侧服务器完全解耦，不存在资源竞争的情况，配置执行侧线程池节点服务与服务发现中心(Name Server)集群建立保持连接关系，通过心跳检测发现服务，一旦发现某个服务挂掉，由服务发现中心立即切换到其他服务节点，切换动作对用户透明，丝毫不需要考虑数据硬性同步问题，也不需要人工介入，整个过程都是在云上完成。
优选的，所述消息中间件承载大并发请求任务，消息集群节点数至少为2个，即Nodes＝2+N(N＝0,1,2,3…),每个节点又包含一个主节点(Master)、一个从节点(Slave)，主节点(Master)将会采用同步或者异步方式将ETL调度消息分发给子节点(Slave)，即使主节点(Master)挂了，任务也不会丢失，任务将会保留一份到子节点(Slave)，如果出现主子节点同步失败，则会启用补偿机制，实现调度任务请求的找回，来redo异常调度请求，避免重复动作，保证集群的高可用性(High Availability)。
优选的，所述并发线程池，继承自ThreadPoolTaskExecutor，对其进行了扩展、性能提升，并增加了线程活跃实时监测、线程池动态拓展的能力，默认配置核心线程数(CorePool Size)20、最大线程数(Max Pool Size)100、队列最大容量(Queue Capacity)200,000、线程池预警阀值(Alarm Pool Size Rate)20％(即当前最大可用线程数量低于20％就预警并发送短信提醒)、队列预警阀值(Alarm Queue Capacity Rate)20％(即当前队列可用容量低于总容量的20％就预警并发送短信提醒)，
执行侧节点服务可以根据需要自行调节，只需要增加或减小Pod副本数就能实现服务节点的增加或减少，配置共享、横向扩展。
优选的，通过设置资源管理模块管理消息集群以及线程池，由消息集群的服务发现中心(Name Server Center)自动发现待执行业务并通知给业务调用端；
所述资源管理模块提供消息集群地址维护(配置集群地址)、消息类型管理(兼容不同消息中间件，不限于RocketMQ、RabbitMQ、ActiveMQ等)、服务发现注册(服务发现中心(Name Server)地址)等，提供线程池基础配置包括核心线程数(Core Pool Size)20、最大线程数(Max Pool Size)100、队列最大容量(Queue Capacity)200,000、线程池预警阀值(Alarm Pool Size Rate)20％(即当前最大可用线程数量低于20％就预警并发送短信提醒)、队列预警阀值(Alarm Queue Capacity Rate)20％(即当前队列可用容量低于总容量的20％就预警并发送短信提醒)。
优选的，设置告警监控模块，监控信息包括集群状态、线程状态、调度状态、节点状态，消息集群出现异常调度请求时，比如主、子节点同步异常的情况，写入到告警监控模块，系统将会redo这些异常，线程池出现异常情况时反馈给告警监控模块，及时提醒管理员进行扩容。
优选的，设置在线编排管理模块，通过浏览器实现编排加调度监控的能力；
所述在线编排管理模块，基于原开源Web Spoon实现，借助Vue2、iview以及微服务深度集成技术(Deep Integration)实现与系统用户、权限、菜单、角色的深度集成，通过本调度监控系统来统一管理用户、权限、菜单、角色，并实现底层kettle资源库的打通、同步，扩展兼容不同的ketle版本、以及大数据Spark、Flink、Kafka插件的支持。可根据需要通过docker实时构建不同的编排版本，无缝集成到smartKettle，借助docker等云原生技术实现多节点、轻量级部署，能够跨平台、跨浏览器，无任何操作系统负担。
优选的，设置API核心调度管理模块，调度任务包括作业调度、转换调度、Spark调度及Kafka调度，调度监控系统对所述调度任务进行操作包括新建、删除、远程执行、停止、暂停、加入队列、移除队列、设置定时；
任务请求加入到消息集群，消息集群根据任务的消息主题Topic按照负载、轮询、权重策略挑选服务器节点，发送到服务器，然后消息队列通知并发线程池，线程池根据策略分配执行任务，不需要人为指定某个节点服务器；
上述的调度过程，会产生调度日志，借助WebSocket流的优势，将线程执行调度任务的具体过程通过WebSocket流的原理推送至前端，实现实时监控和查看，日志的级别可以自行调节。
优选的，主节点(Master)正常情况下通过消息集群Broker同步ETL调度消息至子节点(Slave)，子节点接收到消息存入消息队列，由并发线程池(Concurrency ThreadPool)按策略获取消息并发执行请求，一旦出现主节点同步至子节点异常，会把该条消息写入内存数据库，执行侧并发线程池将会新开启一个定时任务，定时从内存数据库拉取未同步的异常调度请求，重新执行该调度请求，保证了消息调度及时性、完整性，上述皆是跟Tank以及其他调度监控平台最大的区别。
优选的，采用微服务架构部署，前端使用响应式、渐进式框架实现，包括VUE、iview、ElementUI、WebSocket框架，实现完全融合云原生架构体系；
后端使用消息中间件处理业务端大批量的调度请求，使用并发线程池执行调度任务，通过定时任务设置实现任务的定时执行，使用内存数据库Redis实现数据的缓存及会话的共享，使用链路追踪跟踪审计接口调用日志，使用德鲁伊Druid分析数据库执行情况，使用Spring Security实现登录、身份的认证。
本发明还要求保护一种基于云原生的分布式调度监控系统部署方法，该方法对上述基于云原生的分布式调度监控系统进行部署，包括一个云环境(Docker环境或kubernetes环境等其他云环境)、一个消息中间件集群(RocketMQ等不限于此)、一个关系数据库(MySql)以及所述分布式调度监控系统镜像；其后端逻辑步骤如下：
Step1：部署消息中间件集群，节点副本按照节点数至少为2个，即Nodes＝2+N(N＝0,1,2,3…)原则构建，并在云环境(Docker环境或kubernetes环境等其他云环境)上暴露出该消息中间件集群地址；
Step2：在云环境(Docker环境或kubernetes环境等其他云环境)上安装MySql数据库，并在上述环境上暴露出该数据库地址；
Step3：配置分布式调度监控系统的环境变量，首先配置消息集群参数，消息集群承担了整个调度的核心工作，本发明已经无缝集成了消息中间件RocketMQ，本例以两个节点为例来说明具体配置过程，配置好之后，指定两个数据库，一个是XTL，一个是ETL，XTL用于存储Kettle的基本配置，是资源库的元数据库，ETL是分布式调度监控系统的系统库，用以支撑整个系统核心部件的存储；
Step4：配置并发线程池核心参数，所述调度监控系统优先使用默认配置参数，来作为其执行侧的并发线程池，后续还可以根据实际需要进行弹性伸缩扩展：
Step5：经过上述几个关键步骤配置好核心参数，然后在云环境(Docker或kubernetes等不限)启动所述分布式调度监控系统，启动方式使用docker run-p 9800:9800-t-d--name smart-kettle镜像名称，系统将会自动从云端拉取基础数据并完成xtl以及etl基础数据的初始化动作，同时分布式调度监控系统调度侧根据消息集群配置情况完成集群初始化工作，调度侧执行节点也可根据实际业务场景对Pod副本数进行弹性伸缩扩展；
Step6：上述核心流程设置完毕，访问系统首页，通过内置超级管理员身份进入到系统首页，采集并发线程池监控信息，汇总各个节点ETL调度运行详情、实例详情、运行趋势分析统计数据，消息集群配置在系统启动的时候就已经初始化完毕，状态进入到任务消息接收准备阶段。
本发明的一种基于云原生的分布式调度监控系统及其部署方法与现有技术相比，具有以下有益效果：
本发明摒弃Carte服务集群，引入消息集群broker结合并发线程池，在大并发、大数据量场景下，将调度侧、执行侧隔离开来、借助云原生技术手段，实现ETL调度集群的高可用、安全性、易用性、部署的灵活性、节点的弹性扩展以及使用的方便性，解决了传统使用Carte集群方式大并发、大数据量场景下请求单节点卡顿、调度消息丢失、无法实时补偿、无法自动节点扩展、配置信息不安全、无法云化部署等的问题。
本发明还基于开源WebSpoon做了深度改造，解决现有基于kettle的ETL调度平台依然线上调度监控，下线使用kettle客户端编排任务，上传服务器的弊端，无法统一编排、调度的问题，提供了一种完全在线上进行编排、调度、监控的统一思路，并进行了kettle不同版本、大数据插件适配，对WebSpoon做了权限、认证、角色等的控制，深度集成到smartKettle，加入安全审计、调度日志监控，完全摒弃客户端kettle，实现了跨平台、跨操作系统的安全调度、监控。
附图说明
图1是本发明提供的背景技术中KettleManager当前使用的技术架构图；
图2是本发明提供的背景技术中Tank当前使用的技术架构图；
图3是本发明一个实施例提供的smartKettle分布式调度监控系统整体架构图；
图4是本发明一个实施例提供的smartKettlesmartKettle分布式调度监控系统调度架构图；
图5是本发明一个实施例提供的分布式调度监控系统云端部署架构图；
图6是本发明一个实施例提供的在线编排实现原理图；
图7是本发明一个实施例提供的补偿架构实现原理图；
图8是本发明一个实施例提供的大屏监控页页面示图；
图9是本发明一个实施例提供的作业调度页面示图；
图10是本发明一个实施例提供的转换调度页面示图；
图11是本发明一个实施例提供的Web版的编排界面示图；
图12是本发明一个实施例提供的在线编排资源库登录界面示图；
图13是本发明一个实施例提供的拦截到的针对用户行为的所有操作日志审计记录示图。
图14是本发明一个实施例提供的拦截到的针对ETL调度请求的所有日志审计记录示图。
图15是本发明一个实施例提供的拦截到的针对ETL调度请求每个环节步骤的执行监控示图。
图16是本发明一个实施例提供的作业或转换定时调度执行操作页面示图。
图17是本发明一个实施例提供的作业或转换实时调度监控日志示图。
具体实施方式
下面结合具体实施例对本发明作进一步说明。
本发明实施例提供了一种基于云原生的分布式调度监控系统，取名叫smartKettle，本调度监控系统基于云原生(Cloud Primitive)开发，云原生强调最初的开发就是为了最终部署到云环境上。在公有云(Public Cloud)、私有云(Private Cloud)和混合云(Hybrid Cloud)等新型动态环境中，赋能组织或企业去构建和部署可弹性扩展的应用的，而当前基于Kettle API封装的ETL监控平台，KettleManger或Tank等在高可用性(HighAvailability)、易用性(Accessibility)、灵活部署(Flexible Deployment)、扩展性(Scalability)、高并发场景(High Concurrency)、安全性(Security)等方面无法完全兼容云原生架构，而本调度监控系统正式从此方面做了完善、优化，也符合互联网发展前景，紧跟新技术趋势，适应复杂、多变的业务场景，如图4所示是本系统的调度架构图。
本系统基于消息中间件承载大并发请求任务，基于并发线程池执行调度任务；通过服务发现中心支撑整个集群的ETL调度服务发现，包括调度侧、执行侧。
本系统摒弃Carte服务集群，Carte集群无法承载急剧增长的业务调度请求，会有单机节点通信故障、执行过程阻塞、执行请求丢失、重复执行等弊端，本系统使用消息中间件联合自研并发线程池(Concurrency Thread Pool)来解决上述但不限于上述的问题。
其中消息中间件(不限于RocketMQ、RabbitMQ、ActivieMQ等)承载大并发请求任务，消息集群节点数至少为2个，即Nodes＝2+N(N＝0,1,2,3…),每个节点又包含一个主节点(Master)、一个从节点(Slave)，主节点(Master)将会采用同步或者异步方式将ETL调度消息分发给子节点(Slave)，即使主节点(Master)挂了，任务也不会丢失，任务将会保留一份到子节点(Slave)，如果出现主子节点同步失败，则会启用补偿机制，实现调度任务请求的找回，来redo异常调度请求，避免重复动作，保证集群的高可用性(High Availability)。
调度侧接受各个业务系统的并发调度请求，每个请求都包含一个消息主题(Topic)，由消息集群根据所述消息主题(Topic)来决定分发到哪台节点服务器的主节点(Master)上，根据消息分发机制，大量的业务调度请求平均分散到不同的节点服务器，而每台节点服务器之间进行消息的同步；调度侧的节点与服务发现中心(Name Server)集群建立保持连接关系，时刻检测当前服务状态，一旦发现某个服务挂掉，由服务发现中心自主切换至其他服务节点，切换动作对用户透明，丝毫不需要考虑数据硬性同步问题，也不需要人工介入，这个过程都是在云上完成。
执行侧使用并发线程池(Concurrency Thread Pool)实现任务执行；该线程池继承自ThreadPoolTaskExecutor，对其进行了扩展、性能提升，并增加了线程活跃实时监测、线程池动态拓展的能力，默认配置核心线程数(Core Pool Size)20、最大线程数(Max PoolSize)100、队列最大容量(Queue Capacity)200,000、线程池预警阀值(Alarm Pool SizeRate)20％(即当前最大可用线程数量低于20％就预警并发送短信提醒)、队列预警阀值(Alarm Queue Capacity Rate)20％(即当前队列可用容量低于总容量的20％就预警并发送短信提醒)，执行侧节点服务可以根据需要自行调节，只需要增加或减小Pod副本数就能实现服务节点的增加或减少，配置共享、横向扩展。
执行侧跟调度侧服务器完全解耦，不存在资源竞争的情况，配置执行侧线程池节点服务与服务发现中心(Name Server)集群建立保持连接关系，通过心跳检测发现服务，一旦发现某个服务挂掉，由服务发现中心立即切换到其他服务节点，切换动作对用户透明，整个过程都是在云上完成。调度侧将调度消息同步至任务队列，本发明执行侧线程池根据自身策略从任务队列获取调度请求，整个任务获取过程是并行进行，并发线程池(Concurrency Thread Pool)执行具体的任务。
本分布式调度监控系统的整体架构如图3所示，采用微服务架构思想，前端使用VUE、iview、ElementUI、WebSocket等流行响应式、渐进式框架实现，完全融合云原生架构体系，后端使用自研x-common-base以及MyBatis搭建，使用消息中间件(不限于RocketMQ、ActivieMQ、RabbitMQ等)来处理业务端大批量的调度请求，使用自研并发线程池(Concurrency Thread Pool)来执行调度任务，使用自研simple-job来实现任务的定时执行，使用内存数据库Redis实现数据的缓存、会话的共享，使用链路追踪(SkyWalking)来跟踪审计接口调用日志，使用德鲁伊(Druid)来分析数据库执行情况，使用Spring Security实现登录、身份的认证。
相比上述Tank调度平台使用Carte集群，smartKettle摒弃Carte方式，设置管理消息集群以及线程池的资源管理模块，也不需要额外指定某个节点执行，皆由消息集群的服务发现中心(Name Server Center)自动发现待执行业务并通知给业务调用端，整个过程不需要人为参与；所述资源管理模块提供消息集群地址维护(配置集群地址)、消息类型管理(兼容不同消息中间件，不限于RocketMQ、RabbitMQ、ActiveMQ等)、服务发现注册(服务发现中心(Name Server)地址)等，提供线程池基础配置包括核心线程数(Core Pool Size)20、最大线程数(Max Pool Size)100、队列最大容量(Queue Capacity)200,000、线程池预警阀值(Alarm Pool Size Rate)20％(即当前最大可用线程数量低于20％就预警并发送短信提醒)、队列预警阀值(Alarm Queue Capacity Rate)20％(即当前队列可用容量低于总容量的20％就预警并发送短信提醒)。
设置告警监控模块，监控信息包括集群状态、线程状态、调度状态、节点状态，消息集群出现异常调度请求时，比如主、子节点同步异常的情况，写入到告警监控模块，smartKettle将会redo这些异常，线程池出现异常情况时反馈给告警监控模块，及时提醒管理员进行扩容。
设置在线编排管理模块，Tank及其他调度平台任务编排需要依赖GUI(即kettle客户端)端，本地编排之后将作业、转换上传到文件服务器，用户体验极差，需要频繁切换windows或linux，无法做到编排、调度统一。smartKettle设计开发了在线编排功能，摒弃GUI(即kettle客户端)端，完全融合了smartKettle，只需要一个浏览器就能实现编排加调度监控的能力。
所述在线编排管理模块，基于原开源Web Spoon实现，借助Vue2、iview以及微服务深度集成技术(Deep Integration)实现与系统用户、权限、菜单、角色的深度集成，通过本调度监控系统来统一管理用户、权限、菜单、角色，并实现底层kettle资源库的打通、同步，扩展兼容不同的ketle版本、以及大数据Spark、Flink、Kafka插件的支持。可根据需要通过docker实时构建不同的编排版本，无缝集成到smartKettle，借助docker等云原生技术实现多节点、轻量级部署，能够跨平台、跨浏览器，无任何操作系统负担。如图6所示在线编排本系统的实现原理。
设置API核心调度管理模块，调度任务包括作业调度(Kettle Job)、转换调度(Kettle Trans)、Spark调度及Kafka调度，smartKettle对所述调度任务进行新建、删除、远程执行、停止、暂停、加入队列、移除队列、设置定时等操作，任务执行架构图请参考图4，任务请求加入到消息集群，消息集群根据任务的消息主题Topic按照负载、轮询、权重策略挑选服务器节点，发送到服务器，然后消息队列通知并发线程池，线程池根据策略分配执行任务，不需要人为指定某个节点服务器。上述的调度过程，会产生调度日志，借助WebSocket流的优势，将线程执行调度任务的具体过程通过WebSocket流的原理推送至前端，实现实时监控和查看，日志的级别可以自行调节。
由于Tank使用Carte子服务器集群，调度请求到了某台子服务器上，一旦发生故障，正在执行的请求就会丢失掉，导致业务库产生大量冗余数据，为解决此问题本发明提供了一种解决高并发、大数据量场景下ETL调度请求丢失的问题，如图7所示的补偿架构原理图，主节点(Master)正常情况下会通过消息集群Broker同步ETL调度消息至子节点(Slave)，子节点接收到消息存入消息队列，由并发线程池(Concurrency Thread Pool)按策略获取消息并发执行请求，一旦出现主节点同步至子节点异常，会把该条消息写入内存数据库，执行侧并发线程池将会新开启一个定时任务，定时从内存数据库拉取未同步的异常调度请求，重新执行该调度请求，保证了消息调度及时性、完整性，上述皆是跟Tank以及其他调度监控平台最大的区别。
另外，API核心调度管理功能中定时管理使用自研的simple-job，该架构集成了Quartz2.3版本，对其做了扩充、优化，借助Quartz2.3特性，simple-job提供了界面化操作更加方便，新增定时任务，将任务请求发送到线程池队列中，线程池根据策略分配活跃线程，活跃线程执行具体的调度任务，完成调度请求。
综上所述，本发明实施过程提供的smartKettle调度系统及其提供的详细的调度架构、整体架构、补偿架构方法中，本发明摒弃Carte服务集群，引入消息集群broker结合并发线程池，在大并发、大数据量场景下，将调度侧、执行侧隔离开来、借助云原生技术手段，实现ETL调度集群的高可用、安全性、易用性、部署的灵活性、节点的弹性扩展以及使用的方便性(在线编排)，解决了传统使用Carte集群方式大并发、大数据量场景下请求单节点卡顿、调度消息丢失、无法实时补偿、无法自动节点扩展、配置信息不安全、无法云化部署等的问题。
本发明实施例还提供一种基于云原生的分布式调度监控系统部署方法，该方法对上述实施例所述的基于云原生的分布式调度监控系统进行部署，请参考图5的云端调度系统部署架构图，本发明借助云原生架构，结合微服务思路实现了一种分布式调度监控系统及其部署方法(取名叫smartKettle)，摒弃传统的脚本式编写部署、运行，整个调度系统上云，满足大数据业务场景下的部署、扩展需求，这也是与Tank等ETL调度系统部署方式较为明显区别，另外本发明分布式调度系统开发方式采用前后端完全分离，部署解耦，与Tank等ETL调度系统相比，部署更加灵活、更易于节点扩展、更容易提升执行性能，而且配置参数等都是以环境变量方式“隐藏式”配置，数据库密码、初始化数据等都进行了加密处理，调度侧消息中间件服务地址也使用了内部集群方式调用，真实IP地址对外不可见，不像Tank等ETL调度系统直接将Carte服务器节点基础配置裸露在服务器上，smartKettle配置方式更加安全。
本部署方法至少要准备一个Docker环境(或kubernetes环境等其他云环境)、一个消息中间件集群(RocketMQ等不限于此)、一个关系数据库(MySql)以及本发明系统(smartKettle)镜像，由于本发明是基于微服务的调度，前后端完全分离，前端部署访问较为简单均为已知技术，重点说明后端的逻辑步骤：
Step1：部署消息中间件集群，节点副本按照Nodes＝2+N(N＝0,1,2,3…)原则构建，并在Docker环境(或kubernetes环境等其他云环境)上暴露出该消息集群地址；
Step2：在Docker环境(或kubernetes环境等其他云环境)上安装MySql数据库，并在上述环境上暴露出该数据库地址；
Step3：配置smartKettle系统环境变量，首先要配置消息集群参数，消息集群承担了整个调度的核心工作，本发明已经无缝集成了消息中间件RocketMQ，本例以两个节点为例来说明具体配置过程：
#指定调度系统消息集群
-Dorg.yaukie.mq.namesrvAddr＝smart-mq_1:9876；smart-mq_2:9876
#生产者实例名称
-Dorg.yaukie.mq.producerInstanceName＝smartKettle_producer_instan ce
#事务生产者实例名称
-Dorg.yaukie.mq.transactionProInstanceName＝smartKettle_producer_transacition
#一次最大消费多少数量消息
-Dorg.yaukie.mq.counsumerBatchSize＝1
#广播消费
-Dorg.yaukie.mq.consumerBroadcasting＝false
上述配置好之后，还需要指定两个数据库，一个是XTL，一个是ETL，前者用于存储Kettle的基本配置，是资源库的元数据库，后者是smartKettle的系统库，用以支撑整个系统核心部件的存储，截取部分系统参数配置：
-DXTL_KETTLE_DB_USERNAME＝root
-DXTL_KETTLE_DB_PORT＝3306
-DXTL_KETTLE_DB_PASS＝*****
-DXTL_KETTLE_DB_NAME＝etl
-DXTL_KETTLE_DB_HOST＝smart_mysql_etl
-DXTL_APP_NAME＝smart-kettle
-DXTL_APP_MASTER_DATASOURCE_USERNAME＝root
-DXTL_APP_MASTER_DATASOURCE_URL＝jdbc:mysql://smart_mysql_xtl:3306/xtl？useUniCode＝true&characterEncoding＝UTF-8&zeroDateTimeBehavior＝convertToNull&useSSL＝false&serverTimezone＝GMT％2B8
-DXTL_APP_MASTER_DATASOURCE_PASS＝****
-DXTL_APP_LOG_PATH＝/opt/apps/xtl-server/log
Step4：然后配置并发线程池核心参数，本调度监控系统会优先使用默认配置参数，来作为其执行侧的并发线程池，后续还可以根据实际需要进行弹性伸缩扩展：
-DSMART.POOL.COREPOOLSIZE＝10
-DSMART.POOL.MAXPOOLSIZE＝50
-DSMART.POOL.QUEUECAPACITY＝200000
-DSMART.POOL.KEEPALIVESECONDS＝60
-DSMART.POOL.ALLOWCORETHREADTIMEOUT＝FALSE
Step5：经过上述几个关键步骤配置好核心参数，然后在云环境(Docker或kubernetes等不限)启动smartKettle，启动方式使用docker run-p 9800:9800-t-d--namesmart-kettle镜像名称，系统将会自动从云端拉取基础数据并完成xtl以及etl基础数据的初始化动作，同时本发明调度侧将会根据消息集群配置情况完成集群初始化工作，调度侧执行节点也可以根据实际业务场景对Pod副本数进行弹性伸缩扩展；
Step6，上述核心流程设置完毕，访问系统首页，通过内置超级管理员身份进入到系统首页，图8是大屏监控页，采集并发线程池监控信息，汇总各个节点ETL调度运行详情、实例详情、运行趋势分析等统计数据，消息集群配置在系统启动的时候就已经初始化完毕，状态进入到任务消息接收准备阶段。
本发明区分于其他ETL调度系统是支持在线编排(smartSpoon)，摒弃传统GUI(Graphical User Interface)，并实现kettle不同版本、不同插件的更新、适配，资源库、权限、认证做了深入改造集成，界面完全适配Vue，兼容H5特性，适合云端无缝衔接部署，如图9、10分别是作业调度、转换调度，直接点击在线编排，将会在smartKettle系统中打开Web版编排界面，参考图11Web版的编排界面，已经通过权限、角色等控制集成到smartKettle中，作业、转换等核心调度编排不再依赖kettle客户端，只需一个浏览器就能实现实时编排、在线验证，性能得到极大提升。
本发明还支持在线编排的多资源库调度请求拦截、安全审计等，图12是在线编排资源库登录界面，允许设置资源库地址，资源信息、管理员信息等皆由smartKettle统一管理，在线编排所有操作、执行请求都经过smartKettle，如图13、图14是拦截到的针对ETL调度请求的所有日志审计记录以及用户操作行为日志审计记录，记录内容包括任务启动、终止任务、添加定时、远程启动、远程停止、在线测试、用户赋权等类型以及是哪台调度节点(远程IP)、调度结果、调度时间、谁去调度的等详细信息，相比Tank更加安全可靠，图15则是拦截到的针对ETL调度请求每个执行环节、执行步骤的实时监控日志，及时预警执行情况，反馈给实施人员，从而更加准确判断调度侧出现的实际问题，避免出现更大风险。本发明资源库允许有多个、并且支持不同类型的文件系统(SFTP、FTP、FILE、HDFS、IPFS等)，支持不同的数据库(Mpp等主流关系型数据库)适配，所有调度请求对用户是透明的，都可以发送到消息集群，由消息集群broker来决定由哪台节点来执行调度请求。
本发明还支持自定义定时任务设置，如图16是实施例提供的针对作业或转换的定时调度设置示图，本发明定时任务管理借助线程池以及消息队列的优势，摒弃kettle自身限制，使用自研simple-job定时管理器，优化了定时执行规则，所有定时请求都已消息的形式加入队列，后端异步使用并发线程池调度，定时调度过程可调整、可监控。图17则是实施例提供的作业或转换实时调度日志图，拦截到的所有ETL调度请求执行情况，都能借助WebSocket流实时推送到用户端，使得用户能够及时掌握业务调度请求执行情况，提升了业务端管理效率以及ETL调度效率。
通过上面具体实施方式，所述技术领域的技术人员可容易的实现本发明。但是应当理解，本发明并不限于上述的具体实施方式。在公开的实施方式的基础上，所述技术领域的技术人员可任意组合不同的技术特征，从而实现不同的技术方案。
除说明书所述的技术特征外，均为本专业技术人员的已知技术。
Claims (10)
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调度，调度监控系统对所述调度任务进行操作包括新建、删除、远程执行、停止、暂停、加入队列、移除队列、设置定时；
任务请求加入到消息集群，消息集群根据任务的消息主题按照负载、轮询、权重策略挑选服务器节点，发送到服务器，然后消息队列通知并发线程池，线程池根据策略分配执行任务；
上述的调度过程，会产生调度日志，将线程执行调度任务的具体过程通过WebSocket流的原理推送至前端，实现实时监控和查看，日志的级别可自行调节。
8.根据权利要求2所述的一种基于云原生的分布式调度监控系统，其特征在于，主节点正常情况下通过消息集群Broker同步ETL调度消息至子节点，子节点接收到消息存入消息队列，由并发线程池按策略获取消息并发执行请求；一旦出现主节点同步至子节点异常，会把该条消息写入内存数据库，执行侧并发线程池将会新开启一个定时任务，定时从内存数据库拉取未同步的异常调度请求，重新执行该调度请求。
9.根据权利要求1或2所述的一种基于云原生的分布式调度监控系统，其特征在于，采用微服务架构部署，前端使用响应式、渐进式框架实现，包括VUE、iview、ElementUI、WebSocket框架，实现完全融合云原生架构体系；
后端使用消息中间件处理业务端大批量的调度请求，使用并发线程池执行调度任务，通过定时任务设置实现任务的定时执行，使用内存数据库Redis实现数据的缓存及会话的共享，使用链路追踪跟踪审计接口调用日志，使用德鲁伊Druid分析数据库执行情况，使用Spring Security实现登录、身份的认证。
10.一种基于云原生的分布式调度监控系统部署方法，其特征在于，该方法对权利要求1至9任一项所述基于云原生的分布式调度监控系统进行部署，包括一个云环境、一个消息中间件集群、一个关系数据库以及所述分布式调度监控系统镜像；其后端逻辑步骤如下：
Step1：部署消息中间件集群，节点副本按照节点数至少为2个的原则构建，并在云环境上暴露出该消息中间件集群地址；
Step2：在云环境上安装MySql数据库，并在上述环境上暴露出该数据库地址；
Step3：配置分布式调度监控系统的环境变量，首先配置消息集群参数，配置好之后，指定两个数据库，一个是XTL，一个是ETL，XTL用于存储Kettle的基本配置，是资源库的元数据库；ETL是分布式调度监控系统的系统库，用以支撑整个系统核心部件的存储；
Step4：配置并发线程池核心参数，所述调度监控系统优先使用默认配置参数，来作为其执行侧的并发线程池：
Step5：配置好核心参数后，在云环境上启动所述分布式调度监控系统，启动方式使用docker run-p 9800:9800-t-d--name smart-kettle镜像名称，系统将会自动从云端拉取基础数据并完成xtl以及etl基础数据的初始化动作，同时分布式调度监控系统的调度侧根据消息集群配置情况完成集群初始化工作，调度侧执行节点根据实际业务场景对Pod副本数进行弹性伸缩扩展；
Step6：访问系统首页，通过内置超级管理员身份进入到系统首页，采集并发线程池监控信息，汇总各个节点ETL调度运行详情、实例详情、运行趋势分析统计数据，消息集群配置在系统启动的时候初始化完毕，状态进入到任务消息接收准备阶段。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310554659.0A CN116841705A (zh) | 2023-05-17 | 2023-05-17 | 一种基于云原生的分布式调度监控系统及其部署方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310554659.0A CN116841705A (zh) | 2023-05-17 | 2023-05-17 | 一种基于云原生的分布式调度监控系统及其部署方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116841705A true CN116841705A (zh) | 2023-10-03 |
Family
ID=88167817
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310554659.0A Pending CN116841705A (zh) | 2023-05-17 | 2023-05-17 | 一种基于云原生的分布式调度监控系统及其部署方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116841705A (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117082058A (zh) * | 2023-10-18 | 2023-11-17 | 国网信息通信产业集团有限公司 | 一种数据库隔离装置环境下的文件传输方法 |
| CN117170985A (zh) * | 2023-11-02 | 2023-12-05 | 武汉大学 | 面向开放式地理信息网络服务的分布式监测方法及系统 |
| CN117221331A (zh) * | 2023-11-08 | 2023-12-12 | 成都新希望金融信息有限公司 | 一种多通道分组并发配置方法 |
-
2023
- 2023-05-17 CN CN202310554659.0A patent/CN116841705A/zh active Pending
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117082058A (zh) * | 2023-10-18 | 2023-11-17 | 国网信息通信产业集团有限公司 | 一种数据库隔离装置环境下的文件传输方法 |
| CN117082058B (zh) * | 2023-10-18 | 2024-01-23 | 国网信息通信产业集团有限公司 | 一种数据库隔离装置环境下的文件传输方法 |
| CN117170985A (zh) * | 2023-11-02 | 2023-12-05 | 武汉大学 | 面向开放式地理信息网络服务的分布式监测方法及系统 |
| CN117170985B (zh) * | 2023-11-02 | 2024-01-12 | 武汉大学 | 面向开放式地理信息网络服务的分布式监测方法及系统 |
| CN117221331A (zh) * | 2023-11-08 | 2023-12-12 | 成都新希望金融信息有限公司 | 一种多通道分组并发配置方法 |
| CN117221331B (zh) * | 2023-11-08 | 2024-01-19 | 成都新希望金融信息有限公司 | 一种多通道分组并发配置方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11914486B2 (en) | Cloning and recovery of data volumes | |
| CN109803018B (zh) | 一种基于Mesos和YARN结合的DCOS云管理平台 | |
| US11249815B2 (en) | Maintaining two-site configuration for workload availability between sites at unlimited distances for products and services | |
| US11074143B2 (en) | Data backup and disaster recovery between environments | |
| CN111290834B (zh) | 一种基于云管理平台实现业务高可用的方法、装置及设备 | |
| CN116841705A (zh) | 一种基于云原生的分布式调度监控系统及其部署方法 | |
| US10084858B2 (en) | Managing continuous priority workload availability and general workload availability between sites at unlimited distances for products and services | |
| US20180026867A1 (en) | Monitoring of replicated data instances | |
| CA2778456C (en) | Failover and recovery for replicated data instances | |
| CN111522628A (zh) | 一种基于OpenStack的Kubernetes集群搭建部署方法、架构及存储介质 | |
| Soundararajan et al. | Challenges in building scalable virtualized datacenter management | |
| CN103677967B (zh) | 一种数据库的远程数据服务系统及任务调度方法 | |
| CN107220100A (zh) | 一种开发运维方法、装置及云计算PaaS平台 | |
| US20200026786A1 (en) | Management and synchronization of batch workloads with active/active sites using proxy replication engines | |
| CN113569987A (zh) | 模型训练方法和装置 | |
| CN103064742A (zh) | 一种hadoop集群的自动部署系统及方法 | |
| CN112817791A (zh) | 一种工作面集群开采状态的移动端监控方法 | |
| CN103414712A (zh) | 一种分布式虚拟桌面管理系统和方法 | |
| Huang et al. | Enhancing the availability of docker swarm using checkpoint-and-restore | |
| CN116737560B (zh) | 基于智能导控的智慧训练系统 | |
| CN105468446A (zh) | 一种基于Linux的HPC作业调度实现高可用的方法 | |
| CN116723077A (zh) | 一种分布式it自动化运维系统 | |
| Hao | Edge computing on low availability devices with K3S in a smart home IoT system | |
| CN112468349B (zh) | 适用于FT2000+平台部署Ceph的主节点 | |
| Chen et al. | Architecture Design of Enterprise Information System Based on Docker and DevOps Technology |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |