知識星球前言
首先，恭喜 CAP 已經成為 eShopOnContainers 官方推薦的生產環境可用的 EventBus 之一。
自從上次 CAP 2.4 版本釋出 以來，已經過去了幾個月的時間，關註的朋友可能知道，在這幾個月的時間裡，也釋出了幾個預覽版的 2.5 版本的NuGet包。
簡介
可能有些人還不知道 CAP 是什麼，老規矩來一個簡介。
CAP 是一個用來解決微服務或者分散式系統中分散式事務問題的一個開源專案解決方案（https://github.com/dotnetcore/CAP）同樣可以用來作為EventBus使用，目前已經2歲了，目前已經應用到了很多的公司和專案中，
想對 CAP 更多瞭解的同學可以看下官方檔案。
在 CAP 2.5版本中主要帶來了以下新特性：
- 支援記憶體儲存
- 支援Azure Service Bus
- 社群支援的記憶體佇列
下麵我們就來逐一看一下這些新的特性。
支援記憶體儲存（In-Memory Storage）
應一些使用者的要求，我們在事件的儲存方面，我們添加了基於記憶體的事件儲存。因為在一些場景下對資料的一致性要求不是很高，或者說可以接受訊息丟失的這種情況，但是他們想提高訊息的吞吐量，所以在這個情境下，我們提供了支援記憶體儲存的方案。
那麼，記憶體儲存有哪些優缺點呢？
優點
- 吞吐量的提高，這也意味著可以容忍訊息有丟失的情況存在
- 在測試專案或者學習的過程中能夠快速入門或者進行試驗。
缺點
- 不對事務提供支援
因為我們需要利用資料庫的ACID特性來保證資料強一致性，很顯然記憶體儲存不具備這樣的特性，所以在發訊息的時候就不需要接管業務的事務了，直接發就行了。
支援 Azure Service Bus
在新的 2.5版本中，我們添加了對 Azure Service Bus 的支援， Azure Service Bus 是一種完全託管的企業整合訊息中介軟體。
Azure Service Bus 最常用於將應用程式與服務彼此解耦，是一種用於非同步資料和狀態傳輸的可靠且安全的平臺。 資料透過訊息在不同的應用程式和服務之間傳輸。 訊息採用二進位制格式，可能包含 JSON、XML 或純文字。
下麵說一下如果使用 Azure Service Bus 對接CAP。
- 在 Azure 市場中搜索 Service Bus，然後選擇建立名稱空間。
- 在名稱填寫你的專案或者應用名稱，定價層選擇“標準”或者“高階”因為基本的不支援Topic功能，然後選擇要建立的位置，根據需要選擇即可。如下圖：
- 建立完成之後，在共享訪問策略(Shared access policies)中找到主連線字串，填到CAP的配置中即可。
下麵為使用記憶體儲存和Azure Service Bus 配合的配置示例，同樣你可以在這裡找到示例程式。
services.AddCap(x =>
{
x.UseInMemoryStorage();
x.UseAzureServiceBus("Endpoint=sb://testcap.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=");
x.UseDashboard();
});最後需要說明的是，在 Azure Service Bus 中，CAP會自動建立 Topic 而不需要人工幹預，當然你可以透過配置項來自定義建立的名稱。
社群支援的記憶體佇列
在我們支援 In-Memory Storage 的過程中，有同學提出他們在跑整合測試的過程中需要使用真實的訊息佇列來做測試，這樣非常不方便，問能不能夠提供一個記憶體版的訊息佇列供測試使用。 現在，社群已經提供了相關對記憶體佇列支援的CAP擴充套件專案。
專案地址：https://github.com/yang-xiaodong/Savorboard.CAP.InMemoryMessageQueue
配置方式：
services.AddCap(x =>
{
x.UseInMemoryStorage();
x.UseInMemoryMessageQueue();
});需要註意的是，此專案僅僅使用者開發環境和測試使用，請不要用於生產環境。
總結
以上，就是本版本中支援的一些新特性，感謝大家的支援，我們很開心能夠幫助到大家。大家在使用的過程中遇到問題希望也能夠積極的反饋，幫助CAP變得越來越好。:)
如果你喜歡這個專案，可以透過下麵的連線點選 Star 給我們支援。
