CAP 6.2 版本发布通告

前言

今天，我们很高兴宣布 CAP 发布 6.2 版本正式版，在这个版本中我们主要做了一些功能优化，以及针对目前已经发现的几个 BUG 进行了修复了。

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

总览

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

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

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

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

Dashboard 添加中文支持
事务对象更友好的对接第三方ORM
消费执行消息头记录 InstanceId
启动时对位于相同组的订阅者进行警告
BUG 修复
- Snowflake Id 算法生成时排除虚拟，回环和禁用的网卡
- 修复 RabbitMQ 丢失连接并快速恢复时的健康检测Bug。
- 修复 Dashboard 代理查询缺失 QueryString 的问题。
- 修复 MongoDB 查询元素未注册不返回结果的Bug。
- 修复 Scoped 生命周期工厂模式注册的订阅者报错的Bug。

Dashboard 添加中文支持

我们在 5.1.1 版本中使用 Vue 重构了我们的 Dashboard，由于时间原因，我们的新版本的 Dashboard 只对英文提供了支持。

在该版本中我们重新提供了对中文的支持，目前可自动根据你的浏览器检测使用的语言并展示。

你也可以在右上方进行手动切换。

感谢 @tetris1128 对此提交的PR！

事务对接第三方 ORM 更加友好

在 CAP 中，事务对象需要交给 CAP 进行提交从而在事务实现提交后对缓存消息到 Broker 的 Flush 动作，而目前的Orm大部分都有自己的事务管理对象进行事务的提交。CAP官方直接原生支持使用 ADO.NET 和 EntityFrameworkCore 进行事务集成，而对于第三方ORM则需要自行扩展。

在本版本中，我们做了一个小调整（将 CapTransactionBase 中的 DbTransaction 设置为了 Virtual），没想到这个小调整让我们对第三方ORM的兼容性得到了大大增强，现在第三方ORM可以更加友好的对接CAP。

以下是2个第三方ORM的集成示例：

FreeSql Repository+UnitOfWork 事务模式和 CAP 的集成
Chloe Orm 和 CAP 的集成

FreeSql Repository+UnitOfWork 事务模式和 CAP 的集成示例如下：

public class FreeSqlRepositoryPatternTransaction : CapTransactionBase
{
    public FreeSqlRepositoryPatternTransaction(IDispatcher dispatcher, IUnitOfWork uow) : base(dispatcher)
    {
        Uow = uow;
    }
    public IUnitOfWork Uow { get; }
    public override object? DbTransaction => Uow.GetOrBeginTransaction();
    public override void Commit()
    {
        Uow.Commit();
        Flush();
    }
    public override Task CommitAsync(CancellationToken cancellationToken = default)
    {
        throw new NotImplementedException();
    }
    public override void Rollback()
    {
        Uow.Rollback();
    }
    public override Task RollbackAsync(CancellationToken cancellationToken = default)
    {
        throw new NotImplementedException();
    }
    public override void Dispose()
    {
        Uow.Dispose();
    }
}
public static class Extensions
{
      // 注意：你可以酌情修改此扩展以支持你的使用习惯
      public static ICapTransaction BeginTransaction(this IFreeSql freeSql,
          ICapPublisher publisher, out IRepositoryUnitOfWork uow, bool autoCommit = false)
      {
          var dispatcher = publisher.ServiceProvider.GetRequiredService<IDispatcher>();
          uow = freeSql.CreateUnitOfWork();
          var transaction = new FreeSqlRepositoryPatternTransaction(dispatcher, uow)
          {
              AutoCommit = autoCommit
          };
          return publisher.Transaction.Value = transaction;
      }
}

使用发送带有事务的消息。

[Route("~/with/test")]
public IActionResult WithTransaction()
{
      using (var transaction = _freeSql.BeginTransaction(_capBus, out var uow, false))
      {
          _capBus.Publish("sample.rabbitmq.mysql", DateTime.Now);
          var person = _freeSql.GetRepository<Person2>();
          person.UnitOfWork = uow;
          person.Insert(new Person2() { Name = "HelloWorld2" });
          transaction.Commit();
      }
    return Ok();
}

你可以在这里查看到 FreeSql DbContext 事务模式的对接方式。

Chloe Orm 和 CAP 进行集成如下：

public class ChloeTransaction : CapTransactionBase
{
    public ChloeTransaction(IDispatcher dispatcher, IDbSession session) : base(dispatcher)
    {
        DbSession = session;
    }
    public IDbSession DbSession { get; set; }
    public override object? DbTransaction => DbSession.CurrentTransaction;
    public override void Commit()
    {
        DbSession.CommitTransaction();
        Flush();
    }
    public override Task CommitAsync(CancellationToken cancellationToken = default)
    {
        throw new NotImplementedException();
    }
    public override void Rollback()
    {
        DbSession.RollbackTransaction();
    }
    public override Task RollbackAsync(CancellationToken cancellationToken = default)
    {
        throw new NotImplementedException();
    }
    public override void Dispose()
    {
        (DbTransaction as IDisposable)?.Dispose();
    }
}
public static class Extensions
{
    public static ICapTransaction BeginTransaction(this IDbContext dbContext,
        ICapPublisher publisher, bool autoCommit = false)
    {
        var dispatcher = publisher.ServiceProvider.GetRequiredService<IDispatcher>();
        dbContext.Session.BeginTransaction();
        var transaction =  new ChloeTransaction(dispatcher,dbContext.Session)
        {
            AutoCommit = autoCommit
        };
        return publisher.Transaction.Value = transaction;
    }
}

发送带有事务的消息：

[Route("~/with/test")]
public IActionResult WithTransaction()
{
    using (_dbContext.BeginTransaction(_capBus, true))
    {
        _dbContext.Insert(new Person2() { Name = "HelloWorld" });
        _capBus.Publish("sample.rabbitmq.mysql", DateTime.Now);
    }
    return Ok();
}

消费执行消息头记录 InstanceId

某天的一个下午，我的同事告诉我他在使用CAP进行本地的消息调试的时候，消息已经被消费执行了，而且状态也变成成功了，但是没进他的VS断点，他又说有时候又会进断点，他不知道怎么回事，于是就把我叫过去了。

我过去看了一下，发现开发服务器上也部署的有应用，并且使用的同一个RabbitMQ，他的消息被线上部署的其他实例给消费掉了，所以没进断点。之所以有时候又进断点则是因为消息是负载消费的，恰好又轮到了他本地。

基于以上原因，在这个版本中，我们在消费的消息头中记录了执行所在的 InstanceId，也就是机器的 Hostname，这样在查看消息就很方便的知道消息是被哪个实例给消费掉了，便于排查问题。

启动时对位于相同组的订阅者进行警告

某天的一个下午，我的同事又找到了我，说他在使用CAP进行消费的时候，调试的VS断点一直不进和上次不一样的是这次始终进不了，但是消息又消费成功了，他找了半天也不知道怎么回事，于是就把我又叫过去了。

我过去看了一下，他没有犯和上次一样的错误。于是我检查了一下，发现他在一个服务中弄了2个名称一样的订阅者，并且使用的默认组。由于2个订阅者位于不同的类中，所以他没有发现。熟悉CAP的都知道，CAP 在启动的时候由于进行了去重处理，所以只会使用其中的一个订阅者，对于另外一个会忽略掉。

基于以上原因，在这个版本中，我们在启动的时候进行了检测，如果发现在一个组中有2个以上的同名订阅者，我们会进行警告日志的打印进行提醒，但不会抛出异常来阻止你的启动。

BUG 修复

在这个版本中，我们进行了一些已发现的BUG修复，下面是修复的内容项。

Snowflake Id 算法生成时排除虚拟，回环和禁用的网卡
修复 RabbitMQ 丢失连接并快速恢复时的健康检测Bug。
修复 Dashboard 代理查询缺失 QueryString 的问题。
修复 MongoDB 查询元素未注册不返回结果的Bug。
修复 Scoped 生命周期工厂模式注册的订阅者报错的Bug。

总结

以上，就是本版本我们做出的一些支持和改动，感谢大家的支持，我们很开心能够帮助到大家。大家在使用的过程中遇到问题希望也能够积极的反馈，帮助CAP变得越来越好。

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

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

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

作者博客：Savorboard

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