.Net Core 商城微服務項目系列（十五）: 構建定時任務調度和消息隊列管理系統

2019 年 10 月 7 日
筆記

一.系統描述

嗨，好久不見各位老哥，最近有點懶，技術部落格寫的太少了，因為最近在寫小說，寫的順利的話說不定就轉行了，哈哈哈哈哈哈哈哈哈。

今天要介紹的是基於.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服務，就是多加些消費者，這個理解起來也比較簡單。

四、優化和展示

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

下面是系統的部分介面：