.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到指定消費接口進行數據處理）

 

3、系統架構介紹

整個系統包括六部分：

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服務，就是多加些消費者，這個理解起來也比較簡單。

 

 

4、優化和展現

對於消息隊列系統目前還在開發中的功能是消息的數量統計，該系統是支持查看每一個隊列未消費的消息量，可是還沒開發完成，這邊博文會一直更新的。

下面是系統的部分界面：

 

 

 

 

 

 

定時任務界面：