CAP 2.6 版本发布通告

前言

今天，我们很高兴宣布 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进行修正。

文档：https://cap.dotnetcore.xyz

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&lt;CapTransactionBase&gt;();    // 传递 dbTransaction 事务对象给 CAP 的事务对象接口   var capTransaction = publisher.Transaction.Value.Begin(dbTransaction, autoCommit); return (IDbTransaction)capTransaction.DbTransaction;
}

支持多个消费者线程

我们收到用户反馈，在使用 CAP 进行一些高数据量传输的项目中 ( 这些项目不太需要对消息进行严格的事务保证 )，消费者一个线程可能不能及时的进行处理，这可能导致消费者消息堆积严重。

在以前如果想要提高消费者处理速度，需要起多个消费者实例以进行负载均衡，但是对于单个实例来说并没有达到系统瓶颈。

在新版本中，我们提供了一个选项，以支持使用多个消费者线程进行消息的处理。你可以如下这样配置：

services.AddCap(x =&gt;
{   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变得越来越好。:)

打赏一杯酒，削减三分愁。

跟着我们走，脱发包你有。

组织打赏账户为柠檬的账户，请标注「NCC」，并留下您的名字，以下地址可查看收支明细：https://github.com/dotnetcore/Home/blob/master/Statement-of-Income-and-Expense.md

OpenNCC，专注.NET技术的公众号

https://www.dotnetcore.xyz

微信ID：OpenNCC

长按左侧二维码关注

欢迎打赏组织

给予我们更多的支持