CAP 2.6 版本發布通告
- 2019 年 10 月 3 日
- 筆記
前言
今天,我們很高興宣布 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進行修正。
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
本文原創授權為:署名 – 非商業性使用 – 禁止演繹,協議普通文本 | 協議法律文本