.NET Core 分布式事務 CAP 發(fā)布 6.1 正式版
前言
我們很高興宣布 CAP 發(fā)布 6.1 版本正式版，在這個版本中我們主要針對目前已經(jīng)發(fā)現(xiàn)的幾個BUG進行了修復了以及添加了一些小特性。
那么，接下來我們具體看一下吧。
總覽
可能有些人還不知道 CAP 是什么，老規(guī)矩來一個簡介。
CAP地址：https://github.com/dotnetcore/CAP)
是一個用來解決微服務或者分布式系統(tǒng)中分布式事務問題的一個開源項目解決方案（https://github.com/dotnetcore/CAP）同樣可以用來作為 EventBus 使用，該項目誕生于2016年，目前在 Github 已經(jīng)有超過 5500+ Star 和 70+ 貢獻者，以及在 NuGet超 250 萬的下載量，并在越來越多公司的和項目中得到應用。
如果你想對 CAP 更多了解，請查看我們的
官方文檔：http://cap.dotnetcore.xyz/
本次在 CAP 6.1 版本中我們主要帶來了以下新特性：
優(yōu)化雪花算法 Dashboard 支持自定義 Authorization Policy Azure Service Bus 添加對延遲消息的支持 支持配置失敗消息過期刪除時間 BUG 修復 修復 Dashbaord 啟用 Challenge 驗證順序問題 修復 RabbitMQ 在網(wǎng)絡抖動時偶發(fā)健康檢查錯誤的問題 修復 MySQL 8.0 重試查詢時 SQL日期格式錯誤的問題 修復 Redis Streams 讀取或創(chuàng)建流時冪等檢查的問題
優(yōu)化雪花算法
在過去我們使用標準版雪花算法，會出現(xiàn)時鐘敏感問題。
因為ID生成總是和當前操作系統(tǒng)的時間戳綁定的（利用了時間的單調(diào)遞增性）），因此若操作系統(tǒng)的時鐘出現(xiàn)回撥，生成的ID就會重復，一般不會人為地去回撥時鐘，但服務器會有偶發(fā)的"時鐘漂移"現(xiàn)象。
也就是說在多節(jié)點部署時，如果某些服務器時間不準確會導致重復鍵生成而導致寫入消息到數(shù)據(jù)庫時報錯。
在本版本中，解除與操作系統(tǒng)時間戳的時刻綁定，生成器只在初始化時獲取了系統(tǒng)當前的時間戳，作為初始時間戳， 但之后就不再與系統(tǒng)時間戳保持同步了。它之后的遞增，只由序列號的遞增來驅(qū)動。
比如序列號當前值是4095，下一個請求進來， 序列號+1溢出12位空間，序列號重新歸零，而溢出的進位則加到時間戳上，從而讓時間戳+1。
在此版本更新后，生成的Id可能會出現(xiàn)和之前版本出現(xiàn)較大差值，大家注意下就行，沒啥影響。
Dashboard 支持自定義 Authorization Policy
在這個版本中，我們的Dashboard 配置項中新增了一個名為 AuthorizationPolicy 的配置項，用于想要在授權過程中使用例如基于角色的授權驗證等場景。
用法如下，主要是有注釋的部分。
services.AddAuthorization((options =>
{
// only if you want to apply role filter to CAP Dashboard user
options.AddPolicy("PolicyCap", policy => policy.RequireRole("admin.events"));
}))
.AddAuthentication(options =>
{
options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
.AddCookie()
.AddOpenIdConnect(options =>
{
options.Authority = "https://demo.identityserver.io/";
options.ClientId = "interactive.confidential";
options.ClientSecret = "secret";
options.ResponseType = "code";
options.UsePkce = true;
options.Scope.Clear();
options.Scope.Add("openid");
options.Scope.Add("profile");
});
services.AddCap(cap =>
{
cap.UseDashboard(d =>
{
d.UseChallengeOnAuth = true;
d.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
d.UseAuth = true;
// only if you want to apply policy authorization filter to CAP Dashboard user
d.AuthorizationPolicy = "PolicyCap";
});
// ***
}Azure Service Bus 添加對延遲消息的支持
在 Azure Service Bus 中原生提供了對延遲發(fā)送消息的支持，也就是利用其 ScheduledEnqueueTimeUtc 屬性設置。
在本版本中通過 CAP 在發(fā)送過程中指定頭消息以利用此特性。
示例如下：
[HttpPost("publish")]
public async Task Publish()
{
await _publisher.PublishAsync("demo-publish", string.Empty, new Dictionary<string, string?>
{
[AzureServiceBusHeaders.ScheduledEnqueueTimeUtc] = DateTimeOffset.UtcNow.AddSeconds(60).ToString(),
});
}順便說一下，有一些同學之前也提起了在 RabbitMQ 中對延遲消息的支持，我們一致沒有對其進行支持，一是因為需要它配置插件才可以不是原生支持，二是還是希望大家能使用調(diào)度器（Quartz，Hangfire）等來做這件事情，專業(yè)的事情交給專業(yè)的組件做。
支持配置失敗消息過期刪除時間
我們新增了一個配置項 FailedMessageExpiredAfter 用于配置失敗的消息過期時間，到達過期時間后，消息會被刪除。之前這個是寫死的值 15 天，現(xiàn)在你可以利用此配置項進行配置。
BUG 修復
在這個版本中，我們進行了一些已發(fā)現(xiàn)的BUG修復，下面是修復的內(nèi)容項。
修復 Dashbaord 啟用 Challenge 驗證順序問題。 修復 RabbitMQ 在網(wǎng)絡抖動時偶發(fā)健康檢查錯誤的問題。 修復 MySQL 8.0 重試查詢時 SQL日期格式錯誤的問題 修復 Redis Streams 讀取或創(chuàng)建流時冪等檢查的問題
總結(jié)
以上，就是本版本我們做出的一些支持和改動，感謝大家的支持，我們很開心能夠幫助到大家 。
大家在使用的過程中遇到問題希望也能夠積極的反饋，幫助CAP變得越來越好。
如果你喜歡這個項目，可以通過下面的連接點擊 Star 給我們支持。
GitHub：https://github.com/dotnetcore/CAP/stargazers
轉(zhuǎn)自：Savorboard
鏈接：cnblogs.com/savorboard/p/cap-6-1.html