前言

今天,我们很高兴宣布 CAP 发布 8.0 版本正式版,从 2016 年 12 月 14 日CAP立项到 2023 年 12 月14 日发布 8.0 版本刚好满 7 年,祝 CAP 7 岁生日快乐,巧的是这一天也是我生日,真是意想不到啊!

那就做一个 Overview 吧,在这7年间,我们一共发布了 61 个版本,在 Github 上有 6.3K 的 Star,有 108 个贡献者以及 DotNetCore.CAP 核心包在 NuGet 上有 640 万的下载量。这个数据讲道理说作为一个非基础库组件来说真的还不错,不知道你怎么看。

还没有 Star 的朋友如果你能访问 Github,动手点个 Star 是对7年来我们最大的支持,一件事情坚持7年真的不容易。如果你不能访问Github,可以在评论区回复 “ 祝CAP 7岁生日快乐! ” 表示支持。

如果你想在你的公司讲解分布式事务或引入CAP 给同事做介绍,可以使用2周前我在 .NET Conf 2023 成都会场分享的分布式事务的PPT,这是pptx版本没有版权,你可以随意进行更改使用。

总览

我们宣布 CAP 发布 8.0 版本正式版,这个版本我们一方面是对.NET 8 的支持,另外一方面主要是对 Dashboard 的认证授权方式做了大的调整,另外我们也修复了一些BUG。

从 7.2 版本以来,我们发布了2个小版本,因为小版本我们不会有发布通告,所以这篇文章中也会提及我们在之前的这些小版本中加的一些小功能。

下面,具体看一下我们新版本的功能吧。

在我们构建 SOA 或者 微服务 系统的过程中,会遇到分布式系统下事务一致性的问题,我们通常需要使用事件来对各个服务进行集成,在这过程中简单的使用消息队列并不能保证数据的安全性,CAP作为一个分布式事务解决方案采用的是和当前数据库集成的本地消息表的方案来解决在各个服务通讯环节可能出现的异常,它能够保证任何情况下数据都是不会丢失的,同样可以用来作为 EventBus 使用,它轻量简单易于使用。

对 CAP 更多了解,请查看我们的 官方文档

本次在 CAP 8.0 版本中我们主要带来了以下改进或新特性:

  • 对.NET 8 的全面支持
  • 添加 FallbackWindowLookbackSeconds 配置项以支持自定义回溯时间窗。
  • 改进 EnableConsumerPrefetch 和 UseDispatchingPerGroup 配置项以共同工作。
  • DotNetCore.CAP.NATS 支持配置 DeliverPolicy,默认为 New。
  • 破坏性改动
    • 在 DotNetCore.CAP.Dashboard 中移除 DefaultAuthenticationSchemeUseChallengeOnAuthDefaultChallengeSchemeAuthorizationPolicy 配置项。
  • BUG 修复
    • 修复消息无限重试的问题(PR #1456 - 感谢 @bschwehn):这一修复解决了订阅者移除后消息重试机制的问题。
    • 修复 Open Telemetry 上下文丢失(PR #1452 - 同样感谢 @bschwehn):这个修复确保了在消费者重试和Baggage传播过程中上下文的完整性。
    • 修复 NATS 连接重连处理问题(PR #1449 - 感谢 @davidterins)。
    • 修复 DotNetCore.CAP.InMemoryStorage 发件箱模式消息恢复问题(PR #1439 - 同样感谢 @davidterins)。
    • 修复 Azure Service Bus 事件处理程序的双重注册问题(PR #1427 - 同样感谢 @demorgi)。
    • 修复 SQL Server 事务中发布延迟消息的问题(PR #1422 - 感谢 @xiangxiren。

全面支持 .NET 8

在这个版本中,我们添加了新的 .NET 8 版本框架,同时我们对于 .NET 6 保持了兼容性,在 NuGet的依赖项中将同时显示 net6.0 和 net8.0,如下图:

在 .NET 8 中依赖注入引入了 KeyedService,在这个版本中我们进行了支持,你的订阅方法现在可以位于 KeyedService 中,如果使用的旧版本在过去则会引发异常。

支持自定义回溯时间窗

添加 FallbackWindowLookbackSeconds 配置项以支持自定义回溯时间窗。

在过去,我们在重试时会从数据库中获取4分钟前存储的消息,这一设定是为了保证新加入的消息不会被获取到从而避免重复发送或消费的问题,现在这个值可以进行配置。但是如果这个值配置太小则可能会带来副作用,所以我们在启动时如果检测到配置的值小于30秒则会打印警告日志进行提醒。

适用的场景:如果你的系统在某个时间点才会一次性发送大量消息,并且这些消息不能在4分钟内处理完成,那么可以将此配置值调大以保证消息尽可能不重复。

EnableConsumerPrefetch,UseDispatchingPerGroup 同时工作

在 7.2.0 版中,我们将 UseDispatchingPerGroup 选项标记为 [Obsolete],并计划在未来的版本中删除它,并打算将其功能替换为 EnableConsumerPrefetch 选项。但是,根据用户反馈,UseDispatchingPerGroup 有自己独特的使用场景。因此,在 7.2.1 版本中,我们将继续支持 UseDispatchingPerGroup 选项,并且 EnableConsumerPrefetch 也将同时生效。

下图描述了这两个配置项不同的组合下,消费者任务的执行方式。

NATS 支持配置 DeliverPolicy,默认为 New

NATS 现在支持对 Stream 的 DeliverPolicy 参数进行自定义,可选项有 DeliverAll, DeliverLast, DeliverNew, DeliverByStartSequence, DeliverByStartTime, or DeliverLastPerSubject,默认为 DeliverPolicy.New

另外,NATS 出了一个新的 V2 版本的 .NET 驱动,我们有计划迁移到新的版本,如果有人愿意贡献请联系我或提交PR。

破坏性改动

在 DotNetCore.CAP.Dashboard 中移除 DefaultAuthenticationSchemeUseChallengeOnAuthDefaultChallengeSchemeAuthorizationPolicy 配置项。

现在将基于于 ASP.NET Core 的认证和授权中间件来工作,你可以在 Repo 的 Sample.Dashboard.Auth 示例项目下查看如何和 ASP.NET Core中间件进行集成。

BUG 修复

另外在这个版本中,我们修复了一些已知的Bug,以下是已经修复的问题列表。

  • 修复消息无限重试的问题(PR #1456 - 感谢 @bschwehn):这一修复解决了订阅者移除后消息重试机制的问题。
  • 修复 Open Telemetry 上下文丢失(PR #1452 - 同样感谢 @bschwehn):这个修复确保了在消费者重试和Baggage传播过程中上下文的完整性。
  • 修复 NATS 连接重连处理问题(PR #1449 - 感谢 @davidterins)。
  • 修复 DotNetCore.CAP.InMemoryStorage 发件箱模式消息恢复问题(PR #1439 - 同样感谢 @davidterins)。
  • 修复 Azure Service Bus 事件处理程序的双重注册问题(PR #1427 - 同样感谢 @demorgi)。
  • 修复 SQL Server 事务中发布延迟消息的问题(PR #1422 - 感谢 @xiangxiren。

总结

以上,就是本版本我们做出的一些新特性和改动,感谢大家的支持,我们很开心能够帮助到大家 。

大家在使用的过程中遇到问题希望也能够积极的反馈,帮助CAP变得越来越好。

如果你喜欢这个项目,可以通过下面的连接点击 Star 给我们支持。

如果你觉得本篇文章对您有帮助的话,感谢您的【推荐】。


本文地址:http://www.cnblogs.com/savorboard/p/cap-8-0.html

作者博客:Savorboard

本文原创授权为:署名 - 非商业性使用 - 禁止演绎,协议普通文本 | 协议法律文本

CAP 8.0 版本发布通告 - CAP 7岁生日快乐!的更多相关文章

  1. CAP 3.0 版本发布通告

    前言 大家好,我们很高兴宣布 CAP 发布了 3.0 版本正式版. 自从上次 CAP 2.6 版本发布 以来,已经过去了几个月的时间,关注的朋友可能知道,在这几个月的时间里,也发布了几个预览版的 3. ...

  2. CAP 5.0 版本发布通告

    前言 今天,我们很高兴宣布 CAP 发布 5.0 版本正式版.同时我们也很高兴的告诉你 CAP 已经有越来越多的用户并且变得越来越流行. 在 5.0 版本中,我们主要致力于更好的支持 .NET 5 以 ...

  3. CAP 6.0 版本发布通告 - 支持 OpenTelemetry

    前言 今天,我们很高兴宣布 CAP 发布 6.0 版本正式版,在这个版本中,我们主要致力于对 OpenTelemetry 提供支持,以及更好的适配 .NET 6. 那么,接下来我们具体看一下吧. 总览 ...

  4. CAP 7.0 版本发布通告 - 支持延迟消息,性能炸了?

    前言 今天,我们很高兴宣布 CAP 发布 7.0 版本正式版,我们在这个版本中带来了大批新特性以及对性能的优化和改进. 自从今年 1月份发布 6.0 版本以来,已经过去了快1年的时间.在过去的将近1年 ...

  5. CAP 3.1 版本发布通告

    前言 今天,我们很高兴宣布 CAP 发布 3.1 版本正式版.同时我们也很高兴的告诉你 CAP 在 GitHub 已经突破了 4000 Star. CAP 3000 Star 还是去年8月份的时候,最 ...

  6. CAP 5.1 版本发布通告 - 你期待的 Redis 来了

    前言 今天,我们很高兴宣布 CAP 发布 5.1 版本正式版,在这个版本里我们同样引入了更多令人激动的新特性和改进,同时也得到越来越多人的喜爱. 得益于社区的反馈和贡献者的支持,在过去的两个月里,我们 ...

  7. CAP 2.6 版本发布通告

    前言 今天,我们很高兴宣布 CAP 发布 2.6 版本正式版.同时我们也很高兴的告诉你 CAP 在 GitHub 已经突破了3000 Star. 自从上次 CAP 2.5 版本发布 以来,已经过去了几 ...

  8. CAP 5.2 版本发布通告

    前言 今天,我们很高兴宣布 CAP 发布 5.2 版本正式版,在这个版本中,我们主要致力于更好的优化使用体验以及支持新的 Transport,同时在该版本也进行了一些 bug 修复的工作. 自从 5. ...

  9. CAP 6.1 版本发布通告

    前言 今天,我们很高兴宣布 CAP 发布 6.1 版本正式版,在这个版本中我们主要针对目前已经发现的几个BUG进行了修复了以及添加了一些小特性. 那么,接下来我们具体看一下吧. 总览 可能有些人还不知 ...

  10. CAP 6.2 版本发布通告

    前言 今天,我们很高兴宣布 CAP 发布 6.2 版本正式版,在这个版本中我们主要做了一些功能优化,以及针对目前已经发现的几个 BUG 进行了修复了. 那么,接下来我们具体看一下吧. 总览 可能有些人 ...

随机推荐

  1. 通过API接口获取到数据后的使用方法以及储存方法

    API接口是许多应用程序和服务所必需的,可以将多个应用程序连接起来,允许不同应用程序之间的数据共享.在本文中,我们将探讨如何使用API接口获取数据,以及如何储存这些数据. 1.使用API接口获取数据 ...

  2. 自定义注解,实现请求缓存【Spring Cache】

    前言 偶尔看到了spring cache的文章,我去,实现原理基本相同,哈哈,大家可以结合着看看. 简介 实际项目中,会遇到很多查询数据的场景,这些数据更新频率也不是很高,一般我们在业务处理时,会对这 ...

  3. lattice crosslink开发板mipi核心板csi测试dsi屏lif md6000 fpga

    1. 概述 CrossLink开发板,是用Lattice的芯片CrossLink 家族系列的,LIF-MD6000-6JM80I.该芯片用于桥接视频接口功能,自带2路MIPI硬核的功能,4 LANE  ...

  4. 音频格式轻松转 - foobar2000

    一.foobar2000简介 foobar2000 是一款免费的专业级别音频解码播放器,支持的诸多音频格式,可加载附加组件扩展更多支持. 除了解码以外,可轻松实现对音频格式的转换,支持几乎所有主流格式 ...

  5. 2022 ICPC 杭州站

    gym 知乎 尝试先读题而不是写缺省源感觉不太好 E 一头雾水.F 是签到就先上去写了,结果读错题交了个样例都没过的代码,小改了一下就过了.G 不太会做.zsy 把 M 丢给我想了一下 然后 gjk ...

  6. 爬虫系列——Scrapy

    文章目录 一 介绍 二 安装 三 命令行工具 四 项目结构以及爬虫应用简介 五 Spiders 六 Selectors 七 Items 八 Item Pipeline 九 Dowloader Midd ...

  7. C静态库的创建与使用--为什么要引入静态库?

    C源程序需要经过预处理.编译.汇编几个阶段,得到各自源文件对应的可重定位目标文件,可重定位目标文件就是各个源文件的二进制机器代码,一般是.o格式.比如:util1.c.util2.c及main.c三个 ...

  8. 【源码解读(一)】EFCORE源码解读之创建DBContext查询拦截

    引言 在网上很少看到有关于系统讲解EFCore源码的,可能大概也许是因为EFCore的源码总体是没有asp.net web的源码流程清晰,正如群友所说,EFCore的源码大致看起来有点凌乱,与其说凌乱 ...

  9. P8679 [蓝桥杯 2019 省 B] 填空问题 题解

    P8679 [蓝桥杯 2019 省 B] 填空问题 题解 题目传送门 欢迎大家指出错误并联系这个蒟蒻 更新日志 2023-05-25 21:02 文章完成 2023-05-27 11:34 文章通过审 ...

  10. 比赛总结:Japan Registry Services (JPRS) Programming Contest 2023 (AtCoder Beginner Contest 324)

    比赛:Japan Registry Services (JPRS) Programming Contest 2023 (AtCoder Beginner Contest 324) A-same 1.常 ...