一. 系统描述
嗨, 好久不见各位老哥, 最近有点懒, 技术博客写的太少了, 因为最近在写小说, 写的顺利的话说不定就转行了, 哈哈哈哈哈哈哈哈哈.
今天要介绍的是基于. Net Core 的定时任务调度和消息队列管理系统. 相信大家对这两个肯定都已经很熟悉了, 在开发过程中, 这两个组件扮演了不可或缺的角色:
消息队列帮助我们进行 "解耦","异步","削峰"
定时任务帮助我们进行 "后台","监控","补偿"
定时任务调度系统大家都介绍过很多次了, 园子里的很多文章我也都拜读过, 我相信大家实际的工作中肯定也都在频繁的使用它. 目前主流的组件有 Quartz 和 Hangfire 两种, 在两者的选择上来说建议大家熟悉哪个用哪个就可以, Hangfire 是自带 UI 管理界面的, 所以如果想直接接入系统并且不想再进行二次开发做 UI, 可以直接选择 Hangfire.
因为我对于 Quartz 更熟悉, 所以本系统的定时任务调度基于 Quartz 开发, 消息队列基于 RabbitMQ, 同时有一套 UI, 用于可视化操作定时任务调度和管理消息队列配置.
本系统是开发自用的, 原型是公司工作中使用的系统, 私下里重写了一套后台代码, 但是 UI 还是公司的那一套, 因为是自用, 所以无法达到直接开箱即用的效果, 写这篇的目的只是希望分享两者的使用方式和场景, 帮助各位在遇到相同应用场景的问题时能够有更多解决思路.
二. 功能介绍
1.MQ 界面化动态配置, 对代码几乎无入侵.(当然你还是需要引用 nuget 用来 Publish 消息的)
2. 提供定时任务调度功能.(基于 Quartz, 可以精确到秒, 执行方式包括接口, sql 脚本, elk)
3. 基于数据库脚本的异常数据监控.(通过定时任务调度系统执行监控的 sql 脚本)
3. 自动补偿.(当异常数据通过 sql 脚本监控出来后, 发送 MQ 到指定消费接口进行数据处理)
三, 系统架构介绍
整个系统包括六部分:
1. MI.MessageQueue: 消息队列基础组件, 就是我们用来操作 RabbitMQ 的一系列方法.
2.MI.MQStationServer: 消息队列管理服务, 提供包括消息队列的增删改查接口, 消费 MQ 消息.
3.MI.Service.Blade: 定时任务调度管理服务, 提供定时任务相关的一系列操作接口.
4.MI.Biz.MQStation: 消息队列 Windows 服务, 用于消费 MQ, 主要是建立相关的消息消费者, 并转发消息到消息队列管理服务.
5.MI.Biz.Blade: 定时任务 Windows 服务, 用于创建及转发相应的任务, 真正的执行在 MI.Service.Blade 服务.
6.MI.Monitor.web:UI 管理界面, 以上两者所有的增删改查都在这里.
以下是定时任务调度系统间的交互:
简单描述一下, 用户在 MI.Monitor.Web 系统中通过界面化的操作创建定时任务, 其会调用 API 接口也就是 MI.Service.Blade 服务, 将操作的数据写入数据库, 对于增删改, 数据库写入完成后会发送一条 MQ 消息, Windows 服务 MI.Biz.Blade 收到 MQ 消息后, 根据消息中的数据添加或更改 Quartz 配置信息, 对于定时任务 Quartz 完全基于代码动态化创建和删除. 这样交互的好处一方面是解耦, 这个比较明显, 这里解耦带来的一个好处是异常隔离, 本身三者之间的分工不同, 对于发生问题的一方只在内部消化; 第二点好处是方便横向扩展, 无论是 Windows 服务还是 API 都可以根据自身的负载动态加减机器. 当然, 对于 Windows 服务我们要做集群, 通过 Zookeeper 可以实现, 防止单点故障.
以下是消息队列系统的交互:
看起来和上面的定时任务调度交互好像差不多, 不过这个地方的麻烦点其实在于基础组件的编写, 就是 MI.MessageQueue 里面的一系列 RabbitMQ 操作, 目前支持单消息, 批量消息, 延时消息, 延时消费需要借助 RabbitMQ 官方提供的 "rabbitmq_delayed_message_exchange" 插件, 有需要的话可以去了解以下, 官方的 API 支持该操作.
还是照例描述一下消息队列的数据交互流程, 用户在 MI.Monitor.Web 系统中通过界面化的操作创建或者更新消息队列, 其会调用 API 接口也就是 MI.MQStationServer 服务, 将操作的数据写入数据库, 写入完成后会创建交换器 (Exchange), 然后发送 MQ 消息, Windows 服务 MI.Biz.MQStation 收到消息后, 将队列和 RouteKey 绑定到对应的交换器, 同时创建消费者, 绑定监听回调, 该回调只是当作一个转发, 收到消息后会通过接口将数据发送到 MI.MQStationServer 服务, 根据在 UI 中配置的 RouteKey 和要消费的接口进行消费处理.
消息队列这样设计的好处之一是解耦, 同时异常隔离, 这个就不说了, 大家都明白; 当然最重要的好处就是可以动态扩展, 消费压力大, 多启动几个 Windows 服务和 API 服务, 就是多加些消费者, 这个理解起来也比较简单.
四, 优化和展示
对于消息队列系统目前还在开发中的功能是消息的数量统计, 该系统是支持查看每个队列未消费的消息量, 但是还没开发完成, 这边博文会一直更新的.
下面是系统的部分界面:
定时任务界面:
来源: https://www.cnblogs.com/weiBlog/p/11628912.html