---

前言

今天，我們很高興宣布 CAP 發布 2.6 版本正式版。同時我們也很高興的告訴你 CAP 在 GitHub 已經突破了3000 Star.

自從上次 CAP 2.5 版本發布 以來，已經過去了幾個月的時間，關注的朋友可能知道，在這幾個月的時間里，也發布了幾個預覽版的 2.6 版本的NuGet包。

簡介

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

CAP 是一個用來解決微服務或者分布式系統中分布式事務問題的一個開源項目解決方案（https://github.com/dotnetcore/CAP）同樣可以用來作為EventBus使用，目前已經2歲了，目前已經應用到了很多的公司和項目中， 想對 CAP 更多了解的同學可以看下官方文檔。

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

• 啟用新 Logo

• 更加完善的文檔支持（英文，中文）

• 單例的 ICapPublisher

• 支持多個消費者線程

• Diagnostic特性的改進

• 其他改進

下面我們就來逐一看一下這些新的特性。

啟用新 Logo

我們終于有自己的 Logo 了，這個Logo由四個顏色的 C 組成，我來簡單介紹下。

紫色：紫色是 NCC 組織 Logo 的顏色，代表了 CAP 的發源。

完善文檔支持

我們深知文檔對于一個開源項目的重要性，在上一版我們的文檔寫的比較亂而且對于目錄結構的規劃不合理，這導致我們的用戶不能快速的找到他們想要了解的內容，我們已經意識到了這一點。

在新版本中，我們完善了我們的文檔，我們對文檔進行了一輪新的重新梳理，以便于閱讀更加方便，以及快速找到需要的內容。

以下是我們新的文檔的目錄結構：

Monitoring 章節目前還在完善中，我們會等到下一個版本中完善。

英文文檔對于CAP國際化也非常的重要，所以我們的文檔以雙語形式提供，在此也非常感謝上一版中對CAP文檔進行翻譯的小伙伴們。

你可以在下面的鏈接中找到我們最新的文檔信息，如果您發現有錯誤的地方，歡迎點擊頁面右上角修改按鈕提交PR進行修正。

文檔：https://cap.dotnetcore.xyz

ICapPublisher 默認為單例

經過一些用戶的反饋，我們了解到將 ICapPubliser 默認注冊為 Scoped 會存在一些問題，特別是對于依賴注入容器生命周期不是特別了解的同學，可能會造成線程安全問題。

另外，對于在控制臺(Console)應用程序中使用 CAP 的同學來說， Scoped 這種作用域的生命周期并不能起到應有作用，而且會造成在一些單例的對象中引用 ICapPubliser 造成無法釋放的問題。

針對以上問題，我們在這一個版本中進行了調整。

調整?ICapPublisher?默認注冊為單例。

更改?ICapPublisher? 接口中?Transaction?屬性為?

AsyncLocal<ICapTransaction>。

針對于第 1 點，你現在可以在任何你需要的地方注入 ICapPublisher 進行使用而不用擔心對象生命周期的問題。

針對于第 2 點，由于 ICapPublisher 現在為單例，所以我們將 Transaction 屬性調整為了 AsyncLocal<ICapTransaction> 以便于能夠進行釋放。對于使用 CAP 封裝的高級 API 的同學來說這個調整對你沒有影響，如果您進行了一些自定義的事務對象接入的話，那么需要進行修改一下。

修改示例可以參考下面代碼，注意注釋部分：

public static IDbTransaction BeginTransaction(this IDbConnection dbConnection, ICapPublisher publisher, bool autoCommit = false) { if (dbConnection.State == ConnectionState.Closed) { dbConnection.Open(); } var dbTransaction = dbConnection.BeginTransaction(); // 從ServiceProvider中拿到 CapTransactionBase 賦值給 publisher.Transaction publisher.Transaction.Value = publisher.ServiceProvider.GetService&lt;CapTransactionBase&gt;(); // 傳遞 dbTransaction 事務對象給 CAP 的事務對象接口 var capTransaction = publisher.Transaction.Value.Begin(dbTransaction, autoCommit); return (IDbTransaction)capTransaction.DbTransaction; }

支持多個消費者線程

我們收到用戶反饋，在使用 CAP 進行一些高數據量傳輸的項目中 ( 這些項目不太需要對消息進行嚴格的事務保證 )，消費者一個線程可能不能及時的進行處理，這可能導致消費者消息堆積嚴重。

在以前如果想要提高消費者處理速度，需要起多個消費者實例以進行負載均衡，但是對于單個實例來說并沒有達到系統瓶頸。

在新版本中，我們提供了一個選項，以支持使用多個消費者線程進行消息的處理。你可以如下這樣配置：

services.AddCap(x =&gt; { x.ConsumerThreadCount = 線程數量 }

改進 Diagnostics 支持

感謝 @gfx687 這位俄羅斯朋友對此貢獻的 PR#380,#382。

現在，你可以利用 CAP 提供的 Diagnostics 特性對于 Header 進行自定義寫入。

也就是說可以利用此特性對消息進行全鏈路的追蹤，從 Controller/Service-->Message Queue--> Consumer。

如果你感興趣，可以查看我的這篇文章了解更多關于 Diagnostics 的信息。

其他改進

• 性能提升

在此版本中，我們進行了一些小范圍的代碼優化。

感謝 @hetaoos 的 PR#365 ，感謝 @liuzhenyulive 的 PR#390 。

• Bug修復

在此版本中，修復了一些bug。具體可以查看這里的 release 日志了解更多。

• 依賴的 NuGet 包更新

總結

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

打賞一杯酒，削減三分愁。

跟著我們走，脫發包你有。

組織打賞賬戶為檸檬的賬戶，請標注「NCC」，并留下您的名字，以下地址可查看收支明細：https://github.com/dotnetcore/Home/blob/master/Statement-of-Income-and-Expense.md

OpenNCC，專注.NET技術的公眾號

https://www.dotnetcore.xyz

微信ID：OpenNCC

長按左側二維碼關注

歡迎打賞組織

給予我們更多的支持

總結

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

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