CAP 2.6 版本釋出通告
前言
今天，我們很高興宣佈 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<CapTransactionBase>();
// 傳遞 dbTransaction 事務物件給 CAP 的事務物件介面
var capTransaction = publisher.Transaction.Value.Begin(dbTransaction, autoCommit);
return (IDbTransaction)capTransaction.DbTransaction;
}支援多個消費者執行緒
我們收到使用者反饋，在使用 CAP 進行一些高資料量傳輸的專案中 ( 這些專案不太需要對訊息進行嚴格的事務保證 )，消費者一個執行緒可能不能及時的進行處理，這可能導致消費者訊息堆積嚴重。
在以前如果想要提高消費者處理速度，需要起多個消費者例項以進行負載均衡，但是對於單個例項來說並沒有達到系統瓶頸。
在新版本中，我們提供了一個選項，以支援使用多個消費者執行緒進行訊息的處理。你可以如下這樣配置：
services.AddCap(x =>
{
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變得越來越好。:)
如果你喜歡這個專案，可以通過下面的連線點選 Star 給我們支援。
如果你覺得本篇文章對您有幫助的話，感謝您的【推薦】。
如果你對 .NET Core 有興趣的話可以關注我，我會定期的在部落格分享我的學習心得。
本文地址：http://www.cnblogs.com/savorboard/p/cap-2-6.html
作者部落格：Savorboard
本文原創授權為：署名 - 非商業性使用 - 禁止演繹，協議普通文字 | 協議法律文字