转载

.Net Core 商城微服务项目系列（十五）: 构建定时任务调度和消息队列管理系统

一.系统描述

嗨，好久不见各位老哥，最近有点懒，技术博客写的太少了，因为最近在写小说，写的顺利的话说不定就转行了，哈哈哈哈哈哈哈哈哈。

今天要介绍的是基于.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管理界面，以上两者所有的增删改查都在这里。

以下是定时任务调度系统间的交互：

.Net Core 商城微服务项目系列（十五）: 构建定时任务调度和消息队列管理系统

简单描述一下，用户在MI.Monitor.Web系统中通过界面化的操作创建定时任务，其会调用API接口也就是MI.Service.Blade服务，将操作的数据写入数据库，对于增删改，数据库写入完成后会发送一条MQ消息，Windows服务MI.Biz.Blade收到MQ消息后，根据消息中的数据添加或更改Quartz配置信息，对于定时任务Quartz完全基于代码动态化创建和删除。这样交互的好处一方面是解耦，这个比较明显，这里解耦带来的一个好处是异常隔离，本身三者之间的分工不同，对于发生问题的一方只在内部消化；第二点好处是方便横向扩展，无论是Windows服务还是API都可以根据自身的负载动态加减机器。当然，对于WIndows服务我们要做集群，通过Zookeeper可以实现，防止单点故障。

以下是消息队列系统的交互：

.Net Core 商城微服务项目系列（十五）: 构建定时任务调度和消息队列管理系统

看起来和上面的定时任务调度交互好像差不多，不过这个地方的麻烦点其实在于基础组件的编写，就是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服务，就是多加些消费者，这个理解起来也比较简单。