CAP帶你輕鬆玩轉Asp.Net Core訊息佇列

CAP是什嗎？

CAP是由我們園子裡的楊曉東大神開發出來的一套分散式交易的決絕方案，是.Net Core Community中的第一個千星項目（目前已經1656 Star），具有輕量級、易使用、高效能等特點。

github.com/dotnetcore/CAP

本部落客要針對易用性這一點，展開敘述，一起看看CAP如何結合EF Core和RabbitMQ帶領小白輕鬆走入分布式訊息佇列的世界。

準備

首先，你需要搭建一套RabbitMQ系統，搭建過程在此不再敘述，如果大家覺得麻煩，可以用我搭好的。

HostName: coderayu.cn  UserName:guest Password:guest  (僅僅可用作實驗，資料丟失不負責)

建立Asp.Net Core 項目，並引入Nuget包

你可以運行以下下命令在你的項目中安裝 CAP。

PM> Install-Package DotNetCore.CAP

如果你的訊息佇列使用的是 Kafka 的話，你可以：

PM> Install-Package DotNetCore.CAP.Kafka

如果你的訊息佇列使用的是 RabbitMQ 的話，你可以：

PM> Install-Package DotNetCore.CAP.RabbitMQ

CAP 提供了 Sql Server, MySql, PostgreSQL 的擴充作為資料庫儲存：

// 按需選擇安裝你正在使用的資料庫PM> Install-Package DotNetCore.CAP.SqlServerPM> Install-Package DotNetCore.CAP.MySqlPM> Install-Package DotNetCore.CAP.PostgreSql

建立DbContext

因為我採用的是EF Core，所以首先要建立一個DbContext上下文，代碼如下：

public class CapDbContext:DbContext    {        public CapDbContext(DbContextOptions options) : base(options)        {        }    }

Startup配置

首先需要在ConfigureServices函數中進行相關服務的注入，對應的操作和功能解釋如下：

public void ConfigureServices(IServiceCollection services)        {            //注入DbContext上下文，如果用的是Mysql可能還需要添加Pomelo.EntityFrameworkCore.MySql這個Nuget包            services.AddDbContext<CapDbContext>(options =>                options.UseMySql("Server=127.0.0.1;Database=testcap;UserId=root;Password=123456;"));            //配置CAP            services.AddCap(x =>            {                x.UseEntityFramework<CapDbContext>();                //啟用操作面板                x.UseDashboard();                //使用RabbitMQ                x.UseRabbitMQ(rb =>                {                    //rabbitmq伺服器位址                    rb.HostName = "coderayu.cn";                    rb.UserName = "guest";                    rb.Password = "guest";                    //指定Topic exchange名稱，不指定的話會用預設的                    rb.ExchangeName = "cap.text.exchange";                });                //設定處理成功的資料在資料庫中儲存的時間（秒），為保證系統新能，資料會定期清理。                x.SucceedMessageExpiredAfter = 24 * 3600;                //設定失敗重試次數                x.FailedRetryCount = 5;            });            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);        }

 

最後還要再Congiure中啟用CAP中介軟體

public void Configure(IApplicationBuilder app, IHostingEnvironment env)        {            if (env.IsDevelopment())            {                app.UseDeveloperExceptionPage();            }            //啟用cap中介軟體            app.UseCap();            app.UseMvc();        }

利用EF Core產生CAP資料庫

再程式包管理主控台中依此輸入以下命令列

PM> Add-Migration Init

PM> update-database

如果成成功執行，那麼開啟資料庫，就可以看到用來儲存CAP發送和接收資料的表格了。

表格中每列的含義如下：

 

訊息的發送和訂閱

我們直接在ValuesController的基礎上進行改造。

在 Controller 中注入 ICapPublisher 然後使用 ICapPublisher 進行訊息發送

private readonly ICapPublisher _publisher;        public ValuesController(ICapPublisher publisher)        {            _publisher = publisher;        }

發送訊息

[HttpGet]        public string Get(string message)        {            //"cap.test.queue"是發送的訊息RouteKey，可以理解為訊息管道的名稱            _publisher.Publish("cap.test.queue",message);            return "發送成功";        }

訂閱訊息

       //"cap.test.queue"為發送訊息時的RauteKey，也可以模糊比對        //詳情https://www.rabbitmq.com/tutorials/tutorial-four-dotnet.html        [CapSubscribe("cap.test.queue")]        public void HandleMessage(string message)        {            Console.Write(DateTime.Now.ToString()+"收到訊息:"+message);        }

Run

啟動程式後，首先看到CAP啟動成功

緊隨其後，消費者也就是我們的訂閱者法在RabbitMQ伺服器上註冊成功。

發送訊息，發送成功，如下

發送後，立即在控制台看到了訂閱者法輸出的結果。

 

訊息的失敗重試

在訂閱者法中，如果拋出異常，那麼CAP就會認為該條訊息處理失敗，會自動進行重試，重試次數在前方已經進行了配置。

我們把訂閱者法做一個改動，列印接收的資訊到控制台中，並拋出異常

//"cap.test.queue"為發送訊息時的RauteKey，也可以模糊比對        //詳情https://www.rabbitmq.com/tutorials/tutorial-four-dotnet.html        [CapSubscribe("cap.test.queue")]        public void HandleMessage(string message)        {            Console.WriteLine(DateTime.Now.ToString()+"收到訊息:"+message);            throw new Exception("測試失敗重試");        }

 

可以看到，立即進行了三次重試

可是在前面，我們設定的失敗重試次數是5次，為什麼這裡只重試三次嗎？是不是要叫曉東過來改BUG了呢？當然不是。

觀察發現，CAP重試的前三次是立即進行的，而後面的重試，是每隔一段時間進行的，當在分布式通訊的過程中，可能出現了問題確實不會立即修複解決，可能過了一定時間，系統就自動回復了，如網路抖動。

 

CAP儀錶盤

發送成功了五條訊息，成功接收處理了三條，兩條處理失敗，處理失敗的任務，我們可以直接在面板中進行重新消費，可謂非常方便。

同時，處理失敗的訊息，點擊訊息的編號後，可以查看到訊息的內容和異常原因。

 

CAP如此強大，讓訊息佇列這種高大上產品操作So Easy，學會了CAP,也可以吹牛說，我也懂分布式任務處理啦。

感謝曉東開發出如此強大的項目，同時感謝.Net Core Community。

參考 CAP Github wiki

github.com/dotnetcore/CAP/wiki

本部落格Demo代碼