前言

今天，我們很高興宣布 CAP 發布 5.0 版本正式版。同時我們也很高興的告訴你 CAP 已經有越來越多的用戶并且變得越來越流行。

在 5.0 版本中，我們主要致力于更好的支持 .NET 5 以及支持新的 Transport，同時在該版本也進行了一些 Bug 修復的工作。
自從 5.0 版本發布預覽版以來，也過去了幾個月的時間，在這些的時間里，我們也發布了幾個預覽版本，感謝這些使用預覽版并向我們報告 Bug 和反饋問題的用戶。

那么，接下來我們具體看一下吧。

總覽

可能有些人還不知道 CAP 是什么，老規矩來一個簡介。

CAP 是一個用來解決微服務或者分布式系統中分布式事務問題的一個開源項目解決方案（https://github.com/dotnetcore/CAP）同樣可以用來作為 EventBus 使用，該項目誕生于2016年，目前在 Github 已經有超過 4500 Star以及超過 75萬 的下載量，已經在越來越多公司的和項目中得到應用。

如果你想對 CAP 更多了解，請查看我們的?官方文檔。

本次在 CAP 5.0 版本中我們主要帶來了以下新特性：

• 適配 .NET 5 和 .NET Standard 2.1

• 增加了對 NATS Transport 的支持

• 替換 Newtonsoft.Json 為 System.Text.Json

• 在 RabbitMQ 中啟用發布確認

• 在 RabbitMQ 中支持創建 lazy 隊列的選項。

• 在 Kafka 中，啟動將會自動創建 Topic。

• 添加自定義 Group 和 Topic 前綴的選項。

• 更新依賴的 NuGet 包到最新版本

• 數個 Bug 修復

適配 .NET 5 和 .NET Standard 2.1

雖然上一個版本也能夠在 .NET 5 的項目中使用，但是在這個版本中我們升級到了我們以來的 NuGet 包到 .NET 的版本，并且調整到了對 .NET Standard 2.1 的支持以便于我們可以利用新特性。

感謝?@rezabayesteh?對此提提交的 PR.

增加了對 NATS Transport 的支持

根據我們的 issue 投票，我們決定在這個版本中對NATS提供支持。

NATS 是一個簡單，安全，高性能的開源消息傳遞系統，適用于云原生應用，IoT消息傳遞和微服務架構，目前也是 CNCF 下的一個項目。

你可以在文檔中看到更多介紹：https://cap.dotnetcore.xyz/user-guide/zh/transport/nats/

集成方式：

services.AddCap(x => {...x.UseNATS(""); });

替換 Newtonsoft.Json 為 System.Text.Json

在這個版本中， 我們將 Newtonsoft.Json 替換為了 System.Text.Json。

System.Text.Json 由.NET 官方提供，它提供高性能，低分配且符合標準的功能來處理Json，其中包括使用內置的UTF-8支持將對象序列化為JSON文本和反序列化JSON文本為對象。它還提供用于讀取和寫入編碼為UTF-8的JSON文本的類型，以及創建內存中文檔對象模型（DOM）的類型，以便在數據的結構化視圖中隨機訪問JSON元素。

Transport 中的改動

RabbitMQ

在 RabbitMQ 中啟用發布確認

以下內容來自官方網站：

如果RabbitMQ節點在將消息寫入磁盤之前失敗，則可能會丟失持久消息。例如，請考慮以下情形：

• 客戶端將持久消息發布到持久隊列

• 客戶端使用隊列中的消息（請注意消息是持久的，隊列是持久的），但確認未激活，

• 代理節點發生故障并重新啟動，并且

• 客戶端重新連接并開始使用消息

此時，客戶端可以合理地假設該消息將再次傳遞。情況并非如此：重新啟動已導致代理丟失消息。為了保證持久性，客戶應使用確認。如果發布者的頻道處于確認模式，則發布者不會收到丟失消息的確認消息（因為該消息尚未寫入磁盤）。

基于以上原因，我們啟動了發布確認，很明顯這會降低一定的性能。

在 RabbitMQ 中支持創建 lazy 隊列的選項

RabbitMQ 在 3.1.6 引入了 lazy queue的概念，用于將消息盡早的轉移到磁盤，然后在消費的時候才加載到 RAM 中。

具體可以查看這里的介紹：https://www.rabbitmq.com/lazy-queues.html

集成方式：

services.AddCap(x => {...x.UseRabbitMQ(aa =>{...aa.QueueArguments.QueueMode = "lazy";}); }

Kakfa

Kafka 中，啟動將會自動創建 Topic

由于?confluent-kafka-dotnet#1366?的原因，在首次啟動 Kakfa 客戶端的時候會出現
Error: Broker: Unknown topic or partition?的異常，我們沒有再等待官方修復這個問題，而且采取了其他的解決辦法。

在 Kafka Transport 啟動的時候，我們會自動向 Kakfa Broker 進行 Topic 的注冊，以便于當消息來時候可以及時接收到而不必多次啟動應用程序來創建Topic。

相關 issue :?https://github.com/dotnetcore/CAP/issues/795

添加自定義 Group 和 Topic 前綴的選項

在一些場景中需要對Group或者Topic 進行區分，特別是AWS SQS由于不同項目都是使用的同一個云服務來共享SNS和SQS，所以這種情況下進行添加前綴就更加直觀的看出來。

在本版本中，我們支持了自定義對Group和Topic的前綴添加功能，感謝?@AndriiLab 對此PR提供的支持。

其他

其他的一些改進項目包括：

1、我們將所有的 nuget 的依賴包都升級到了最新版本。

2、修復了一些已知的Bug，你可以在這里看到。

總結

以上，就是本版本中支持的一些新特性，感謝大家的支持，我們很開心能夠幫助到大家
。大家在使用的過程中遇到問題希望也能夠積極的反饋，幫助CAP變得越來越好。????

如果你喜歡這個項目，可以通過下面的連接點擊 Star 給我們支持。

總結

以上是生活随笔為你收集整理的CAP 发布 5.0 版本正式发布的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。