CAP 5.0 版本发布通告

前言

今天，我们很高兴宣布 CAP 发布 5.0 版本正式版。同时我们也很高兴的告诉你 CAP 已经有越来越多的用户并且变得越来越流行。

在 5.0 版本中，我们主要致力于更好的支持 .NET 5 以及支持新的 Transport，同时在该版本也进行了一些 Bug 修复的工作。

自从 5.0 版本发布预览版以来，也过去了几个月的时间，在这些的时间里，我们也发布了几个预览版本，感谢这些使用预览版并向我们报告 Bug 和反馈问题的用户。

那么，接下来我们具体看一下吧。

总览

可能有些人还不知道 CAP 是什么，老规矩来一个简介。

CAP 是一个用来解决微服务或者分布式系统中分布式事务问题的一个开源项目解决方案（https://github.com/dotnetcore/CAP）同样可以用来作为 EventBus 使用，该项目诞生于2016年，目前在 Github 已经有超过 4500 Star以及超过 75万的下载量，已经在越来越多公司的和项目中得到应用。

如果你想对 CAP 更多了解，请查看我们的官方文档。

本次在 CAP 5.0 版本中我们主要带来了以下新特性：

适配 .NET 5 和 .NET Standard 2.1
增加了对 NATS Transport 的支持
替换 Newtonsoft.Json 为 System.Text.Json
在 RabbitMQ 中启用发布确认
在 RabbitMQ 中支持创建 lazy 队列的选项。
在 Kafka 中，启动将会自动创建 Topic。
添加自定义 Group 和 Topic 前缀的选项。
更新依赖的 NuGet 包到最新版本
数个 Bug 修复

适配 .NET 5 和 .NET Standard 2.1

虽然上一个版本也能够在 .NET 5 的项目中使用，但是在这个版本中我们升级到了我们以来的 NuGet 包到 .NET 的版本，并且调整到了对 .NET Standard 2.1 的支持以便于我们可以利用新特性。

感谢 @rezabayesteh 对此提提交的 PR.

增加了对 NATS Transport 的支持

根据我们的 issue 投票，我们决定在这个版本中对NATS提供支持。

NATS 是一个简单，安全，高性能的开源消息传递系统，适用于云原生应用，IoT消息传递和微服务架构，目前也是 CNCF 下的一个项目。

你可以在文档中看到更多介绍：https://cap.dotnetcore.xyz/user-guide/zh/transport/nats/

集成方式：

services.AddCap(x =>

{

    ...

    x.UseNATS("");

});

替换 Newtonsoft.Json 为 System.Text.Json

在这个版本中，我们将 Newtonsoft.Json 替换为了 System.Text.Json。

System.Text.Json 由.NET 官方提供，它提供高性能，低分配且符合标准的功能来处理Json，其中包括使用内置的UTF-8支持将对象序列化为JSON文本和反序列化JSON文本为对象。它还提供用于读取和写入编码为UTF-8的JSON文本的类型，以及创建内存中文档对象模型（DOM）的类型，以便在数据的结构化视图中随机访问JSON元素。

Transport 中的改动

RabbitMQ

在 RabbitMQ 中启用发布确认

以下内容来自官方网站：

如果RabbitMQ节点在将消息写入磁盘之前失败，则可能会丢失持久消息。例如，请考虑以下情形：

客户端将持久消息发布到持久队列

客户端使用队列中的消息（请注意消息是持久的，队列是持久的），但确认未激活，

代理节点发生故障并重新启动，并且

客户端重新连接并开始使用消息

此时，客户端可以合理地假设该消息将再次传递。情况并非如此：重新启动已导致代理丢失消息。为了保证持久性，客户应使用确认。如果发布者的频道处于确认模式，则发布者不会收到丢失消息的确认消息（因为该消息尚未写入磁盘）。

基于以上原因，我们启动了发布确认，很明显这会降低一定的性能。

在 RabbitMQ 中支持创建 lazy 队列的选项

RabbitMQ 在 3.1.6 引入了 lazy queue的概念，用于将消息尽早的转移到磁盘，然后在消费的时候才加载到 RAM 中。

具体可以查看这里的介绍： https://www.rabbitmq.com/lazy-queues.html

集成方式：

services.AddCap(x =>

{

    ...

    x.UseRabbitMQ(aa =>

    {

        ...

        aa.QueueArguments.QueueMode = "lazy";

    });

}

Kakfa

Kafka 中，启动将会自动创建 Topic

由于 confluent-kafka-dotnet#1366 的原因，在首次启动 Kakfa 客户端的时候会出现

Error: Broker: Unknown topic or partition 的异常，我们没有再等待官方修复这个问题，而且采取了其他的解决办法。

在 Kafka Transport 启动的时候，我们会自动向 Kakfa Broker 进行 Topic 的注册，以便于当消息来时候可以及时接收到而不必多次启动应用程序来创建Topic。

添加自定义 Group 和 Topic 前缀的选项

在一些场景中需要对Group或者Topic 进行区分，特别是AWS SQS由于不同项目都是使用的同一个云服务来共享SNS和SQS，所以这种情况下进行添加前缀就更加直观的看出来。

在本版本中，我们支持了自定义对Group和Topic的前缀添加功能，感谢 @AndriiLab 对此PR提供的支持。

其他

其他的一些改进项目包括：

1、我们将所有的 nuget 的依赖包都升级到了最新版本。

2、修复了一些已知的Bug，你可以在这里看到。

总结

以上，就是本版本中支持的一些新特性，感谢大家的支持，我们很开心能够帮助到大家

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

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

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

如果你对 .NET Core 有兴趣的话可以关注我，我会定期的在博客分享我的学习心得。

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

作者博客：Savorboard

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