前言
今天，我們很高興宣佈 CAP 發佈 7.2 版本正式版，我們在這個版本中主要致力於 Dashboard 對 k8s 服務發現的支持。
從 7.1 版本以來，我們發佈了4個小版本，在這些版本中我們主要解決發現的Bug和添加一些小功能，這篇文章中可能也會提及我們在這些小版本中加的一些小功能。
下面，具體看一下我們新版本的功能吧。
總覽
可能有些人還不知道 CAP 是什麼，老規矩來一個簡介。
CAP 是一個用來解決微服務或者分佈式系統中分佈式事務問題的一個開源項目解決方案（https://github.com/dotnetcore/CAP）同樣可以用來作爲 EventBus 使用，該項目誕生於2016年，目前在 Github 已經有超過 6000+ Star 和 90+ 貢獻者，以及在 NuGet超 500 萬的下載量，並在越來越多公司的和項目中得到應用。
如果你想對 CAP 更多瞭解，請查看我們的 官方文檔。
本次在 CAP 7.2 版本中我們主要帶來了以下新特性：
- 消息發佈任務由.NET線程池管理
- Dashboard 添加對 Kubernetes 服務發現的支持
- Dashboard 支持自定義JWT認證登錄
- Dashboard Api 支持匿名訪問
- 破壞性改動
- 移除 ProducerThreadCount 配置項
- SnowflakeId 生成由靜態單例更改爲依賴注入單例
- 移除7.1版本事務異步方法的支持
- BUG 修復
- 修復 RabbitMQ BasicQos 配置項未按預期工作的問題
消息發佈任務由.NET線程池管理
在過去，我們消息發佈的Task是一條一條發送的，通過使用 ProducerThreadCount 配置項來控制同時發送的進程數來提高消息發送效率。在這個版本中，消息發佈任務將由 .NET 線程池調度，同時 ProducerThreadCount 配置項被移除，這將充分利用 .NET 線程池的能力來提高發送效率。
在消息的消費側，消費者的執行同樣是線性的，在過去通過使用 UseDispatchPerGroup 配置項來讓每個消費者組使用不同的隊列來實現跨消費者組的並行消費。
現在消費側同樣引入了線程池，不過沒有默認開啓，可以通過EnableConsumerPrefetch 來啓用，這樣所有的消費者都將並行執行，無論是否處於相同的組，UseDispatchPerGroup將不再需要。
Dashboard 添加對 Kubernetes 服務發現的支持
在CAP的前期階段，Kubernetes並沒有被廣泛使用。我們使用 Consul 進行儀表板發現，從其他節點收集數據，這大大簡化了在微服務中查看不同節點數據的過程。
根據我們社區的反饋，越來越多的人使用 Kubernetes 作爲他們的部署環境。所以我們在這個版本中支持 Kubernetes 作爲服務發現。我們引入了一個新的NuGet包 DotNetCore.CAP.Dashboard.K8s 來實現這一點。
在引入了NuGet包後，現在有一個新的 UseK8sDiscovery 配置項用於配置服務發現，以下是一個配置示例
services.AddCap(x =>
{
// ...
x.UseDashboard();
x.UseK8sDiscovery();
});
組件將會自動檢測是否處於集羣內部，如果處於集羣內部還需要賦予 Pod Kubernetes Api 的權限。
分配 Pod 訪問 Kubernetes Api
如果你的 Deployment 關聯的 ServiceAccount 沒有 K8s Api 訪問權限的話，則需要賦予 namespaces, services 資源的 get, list 權限。
所需配置項請參考我們的文檔。 https://cap.dotnetcore.xyz/user-guide/zh/monitoring/kubernetes/#dashboard
Kubernetes 發現頁和Consul發現頁使用的同一個，
將 Dashboard 獨立運行
如果你想將 Dashboard 作爲單獨的 Pod 來部署，專門負責查看集羣內其他服務的話，我們提供了一個單獨的擴展方法來實現這一點。
配置如下：
// 只需要這一行即可
builder.Services.AddCapDashboardStandalone();
這將使CAP Dashboard 作爲一個獨立的pod服務來運行，僅用作查看其他服務。
下面這個是一個Sample.Dashboard.Jwt這個示例項目，打包的一個可供測試的Docker鏡像
docker pull ghcr.io/yang-xiaodong/cap-dashboard:0.2
支持自定義JWT認證登錄
現在我們的 Dashboard 支持接入自定義 JWT 統一認證。
現在你可以和你自己的系統集成，使用你的自定義登錄頁，使用你自己的Token，來訪問 Dashboard。
你可以在 Sample.Dashboard.Jwt 示例中查看更多詳細。
Dashboard Api 支持匿名訪問
在將 CAP Dashboard 集成到現有項目的過程中，有些項目使用了 ASP.NET Core 全局認證過濾器，由於 CAP 的 API 也是基於 ASP.NET Core 路由機制實現的，所以會被全局過濾器限制，現在我們提供了一個新的配置項以允許API匿名訪問。
我們在 Dashboard 中提供了一個新的配置項 AllowAnonymousExplicit 以允許將目前的 Api 進行允許匿名訪問。
破壞性改動
移除 ProducerThreadCount 配置項
正如在第一節中介紹的一樣，我們的消息發送任務現在使用 .NET 線程池進行，所以 ProducerThreadCount 配置項現在已經無效被移除。
SnowflakeId 生成由靜態單例更改爲依賴注入單例
我們的自動生成 Published 和 Received 表主鍵的雪花算法現在已經由靜態單例模式更改爲使用依賴注入的方式進行，這允許用戶自行修改實現。
services.AddSingleton<ISnowflakeId, SnowflakeId>();
受改動影響，具體 Broker 中 CustomHeaders 配置項將由 CustomHeadersBuilder 替代， CustomHeadersBuilder 配置項提供了 IServiceProvider 允許從中獲得 ISnowflakeId 實例。
移除7.1版本事務異步方法的支持
在7.1版本中，我們添加了對開啓事務異步方法的支持，在這個版本中，我們將其移除。 原因是由於我們的事務狀態使用 AsyncLocal 存儲，AsyncLocal 不支持向上傳遞導致事務狀態丟失，所以這個版本將其移除。
BUG 修復
另外在這個版本中，我們修復了一些已知的Bug，以下是已經修復的問題列表。
- 修復 RabbitMQ BasicQos 配置項未按預期工作的問題
總結
以上，就是本版本我們做出的一些新特性和改動，感謝大家的支持，我們很開心能夠幫助到大家 。
大家在使用的過程中遇到問題希望也能夠積極的反饋，幫助CAP變得越來越好。😃
如果你喜歡這個項目，可以通過下面的連接點擊 Star 給我們支持。
如果你覺得本篇文章對您有幫助的話，感謝您的【推薦】。
本文地址：http://www.cnblogs.com/savorboard/p/cap-7-2.html
作者博客：Savorboard
本文原創授權爲：署名 - 非商業性使用 - 禁止演繹，協議普通文本 | 協議法律文本