前言
今天，我們很高興宣布 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 給我們支持。
如果你覺得本篇文章對您有幫助的話，感謝您的【推薦】。
如果你對 .NET Core 有興趣的話可以關注我，我會定期的在博客分享我的學習心得。
本文地址：http://www.cnblogs.com/savorboard/p/cap-5-0.html
作者博客：Savorboard
本文原創授權為：署名 - 非商業性使用 - 禁止演繹，協議普通文本 | 協議法律文本