CAP 5.2 版本发布通告

前言

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

自从 5.1 版本发布预览版以来，也过去了几个月的时间，在这些的时间里，我们也发布了几个小版本(5.1.1, 5.1.2, 5.1.3)，感谢这些版本的使用者并向我们报告 Bug 和反馈问题的用户，另外我们还收到了非常多的 PR 改进，还要感谢这些使用者。

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

总览

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

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

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

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

• 支持 Apache Pulsar 作为传输器
• 改进支持 NATS JetStream
• 支持消费者组隔离处理
• 支持基于程序集查找订阅者
• 改进 Dashboard 支持自定义认证
• 改进内存的消息流控
• 更新依赖的 NuGet 包到最新版本
• 数个 Bug 修复

支持 Apache Pulsar 作为传输器

Apache Pulsar 是一个云原生、分布式消息传递和流媒体平台，具有多租户、高性能等优势。 Pulsar 最初是由雅虎开发，主要应用于雅虎邮件、金融、体育、Flickr、Gemin广告平台，目前由 Apache 软件基金会管理。

官网文档：https://pulsar.apache.org/docs/en/standalone/

CAP Pulsar 文档：https://cap.dotnetcore.xyz/user-guide/en/transport/pulsar/

Pulsar 在 CAP 的集成方式：

services.AddCap(x =>
{
    x.UsePulsar(opt => {
        //Pulsar options
    });
    // x.UseXXX ...
});

个人觉得 Pulsar 相比Kafka 的主要优势除了标准的 Broker功能之外，还提供了诸如多租户的功能，另外还有就是原生支持分层存储，这个特性在某些需要大量存储的场景可以将长期数据存储到诸如 S3 等地方来降低成本。

改进支持 NATS JetStream

在 5.0 版本中，我们对 NATS 提供了支持，由于之前版本的 NATS 发布订阅不支持消息的持久化，所以就没有 Acknowledge。 所以我们就使用的 Request-Reply 来变相实现消息确认。

在 NATS 2.0 时代，下一代 NATS Streaming 被命名为 NATS JetStream， JetStream 更加强大，功能也更加丰富，完全满足 CAP 的要求，于是在这个版本中我们就切换为了 JetStream 。

关于 JetStream 可以在这里查看：https://docs.nats.io/jetstream/jetstream

CAP在内部的切换到了 JetStream，使用方式还是和之前一样无任何变化。

CAP 的 NATS JetStream 支持文档：
https://cap.dotnetcore.xyz/user-guide/en/transport/nats/

支持消费者组隔离 Processor

我们知道，CAP在设计之初被定义为微服务或者SOA系统使用。但是这并不妨碍热情的人们在其他系统中对其的使用，一位波兰朋友在他的单体应用中使用 CAP 发件箱模式来存储消息。

简单说一下他的场景，他的单体应用分为很多模块，例如订单模块、消息模块、报表模块等等，他需要在这些模块之间广播消息，所以会利用到CAP提供的消费者组，这样生产者发送的消息可以让每个模块都能够消费到。在微服务中这没有问题，因为每个服务都是单独的组，都会有单独的进程去处理这些消息。
但是在单体应用中由于CAP内部统一接到消息然后在内存中做的多个 ConsumerThread 分发，所以这可能会导致由于某个组的消息消费时间过长从而导致将 所有的 ConsumerThread 耗尽，而那些需要被尽快处理的组的消息被积压。

所以，针对以上问题我们在这个版本对上述场景做了优化，我们新增加了 UseDispatchingPerGroup 选项，你可以将其设置为 True 来配置每个组都使用单独的消费者线程处理。

感谢 @Dariusz Lenartowicz 对此做出的 PR。

支持基于程序集查找订阅者

如果一个服务依赖了多个程序集，并且订阅者分布在依赖的程序集中，我们提供了一个新的 API 来支持从这些程序集中查找订阅者。

services.AddCap(x =>
{
    //...
}).AddSubscriberAssembly([...assemblies]);

改进 Dashboard 支持自定义认证

我们在5.1.0版本中重构了Dashboard，在这个版本中我们对身份认证进行了重构，现在你可以利用ASP.NET Core的身份认证体系来对Dashboard进行认证。

简单来说，就是实现 ASP.NET Core 认证中提供的 AuthenticationHandler<T> 然后在 HandleAuthenticateAsync 中添加自定义逻辑。

public class MyDashboardAuthenticationHandler : AuthenticationHandler<MyDashboardAuthenticationSchemeOptions>
{
    public MyDashboardAuthenticationHandler(IOptionsMonitor<MyDashboardAuthenticationSchemeOptions> options,
        ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock) : base(options, logger, encoder, clock)
    {
        options.CurrentValue.ForwardChallenge = "";
    }
    
    protected override Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        var testAuthHeaderPresent = Request.Headers["X-Base-Token"].Contains("xxx");
    
        var authResult = testAuthHeaderPresent ? AuthenticatedTestUser() : AuthenticateResult.NoResult();
    
        return Task.FromResult(authResult);
    }
    
    protected override Task HandleChallengeAsync(AuthenticationProperties properties)
    {
        Response.Headers["WWW-Authenticate"] = "MyDashboardScheme";
    
        return base.HandleChallengeAsync(properties);
    }
    
    private AuthenticateResult AuthenticatedTestUser()
    {
        var claims = new[] { new Claim(ClaimTypes.Name, "My Dashboard user") };
        var identity = new ClaimsIdentity(claims, "MyDashboardScheme");
        var principal = new ClaimsPrincipal(identity);
        var ticket = new AuthenticationTicket(principal, "MyDashboardScheme");
    
        return AuthenticateResult.Success(ticket);
    }
}

你可以在这里找到一个详细的示例：https://github.com/dotnetcore/CAP/tree/master/samples/Sample.Dashboard.Auth

改进发布订阅消息流控

在CAP内部实现上，发送和接收的消息都会先存储在内存中，然后统一来进行调度。在过去，内存中消息的数量可以无限增长，这会导致应用所占用的内存也会随之增加，特别是在一些压力测试的场景中会明显的看到。在这个版本中，我们对在内存中的消息进行了流控，也就是说如果内存的消息达到了最大值，将限制发送和接收的速率从而将内存控制在一个合理的范围内。

这也会和你设置的 ProducerThreadCount , ConsumerThreadCount 参数有关，使用的线程数越多，内存允许的消息数量就越多。

其他

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

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

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

总结

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

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

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

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

---

本文地址：http://www.cnblogs.com/savorboard/p/cap-5-2.html
作者博客：Savorboard
本文原创授权为：署名 - 非商业性使用 - 禁止演绎，协议普通文本 | 协议法律文本