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

最新推荐文章于 2024-06-12 17:06:59 发布

nidongla

最新推荐文章于 2024-06-12 17:06:59 发布

阅读量236

点赞数

原文链接：https://www.cnblogs.com/savorboard/p/cap-5-1.html

版权

前言

购物返利 m.cpa5.cn

今天，我们很高兴宣布 CAP 发布 5.1 版本正式版，在这个版本里我们同样引入了更多令人激动的新特性和改进，同时也得到越来越多人的喜爱。

得益于社区的反馈和贡献者的支持，在过去的两个月里，我们NuGet的下载量增加了20万，贡献者团队达到了57人，同时我们也发现了非常多的国外贡献者的参与，这说明 CAP 在海外的用户也正在迅速增长，在此我表示非常的感谢。

在 5.1 版本中，我们带来了大家期待已久的 Filter 功能，以及对 Redis Streams 的支持，同时我们重写了 Dashboard，下面我们就具体来看一下吧。

总览

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

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

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

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

增加了对订阅者 Filter 的支持
增加了对 Redis Streams Transport 的支持
改进新版基于 Vue 的 Dashboard
改进 Kafka Transport 对通配符的订阅的支持
改进 RabbitMQ 对异构系统的支持
其他功能改进和若干 Bug 修复

增加了对订阅者 Filter 的支持

根据社区得到的反馈，在一些场景下需要对订阅者方法应用一些 AOP 拦截功能以达到某种目的，例如记录日志或自动开启事务等功能。

在过去，我们通过对第三方 AOP 组件提供支持来做到这一点，例如我们写了一篇博客来描述如何在 CAP 5.0版本中使用 Castle 来对订阅方法进行拦截，这使我们得到了一些赞扬。但同时我们也发现了这种方式存在一些缺点，例如无法方便的在代理类中进行构造函数注入以及方法需要设定为 virtual 另外还有拦截器生命周期控制等问题。

基于以上原因，现在 CAP 直接提供了对订阅者 Filter 的支持，这使得问题大大简化以及获得了配置体验上的提升，下面简单看一下如何使用。

新建一个自定义过滤器类，继承 ISubscribeFilter 接口

public class MyCapFilter: ISubscribeFilter
{
    public void OnSubscribeExecuting(ExecutingContext context)
    {
        // 订阅方法执行前
    }

    public void OnSubscribeExecuted(ExecutedContext context)
    {
        // 订阅方法执行后
    }

    public void OnSubscribeException(ExceptionContext context)
    {
        // 订阅方法执行异常
    }
}

在CAP配置中添加上面的自定义过滤器类

services.AddCap(opt =>
{
    // ***
}.AddSubscribeFilter<MyCapFilter>();

以上就是全部的集成工作，是不是变得非常容易。

增加了对 Redis Streams Transport 的支持

首先感谢来自埃及的 Mahmoud Samir 对此功能提供的 PR 支持。

我们知道，根据可用性原则，你的系统依赖的组件数量越少，那么整体出现问题的概率就越低，你越能够对其进行控制。那么这也是我们此次考虑对引入 Redis 的考虑之一，对于小型系统来说引入额外的中间件会增加复杂性，很多用户并不愿意。

那么，为什么我们在过去没有对Redis支持呢？这主要是一段时间以来，Redis 发布/订阅模式的功能有限，也就是 pub/sub 无法满足需求，该功能的典型缺点是没有一种确认（Acknowledge）机制来保证消息是被送达的。

Stream 是 Redis 5.0 引入的一种新的数据类型，它以一种更抽象的方式建模日志数据结构。除了提供确认功能外，还提供了我们所需的 Consumer Groups 功能，所以我们将其放到了我们的支持列表中。

集成方式：

PM> Install-Package DotNetCore.CAP.RedisStreams

services.AddCap(x =>
{
    // ...
    x.UseRedis(...);
});

新版基于 Vue 的 Dashboard

在这个版本中，我们对我们的Dashboard进行了更换，熟悉 hangfire的同学可能知道CAP的dashboard最初来自于改写的hangfire ui，这主要是由于在 .NET Core的早期阶段没有一种合适的方式来将 Razor 页面嵌入到 (DLL) NuGet 包中，Hangfire采用了一种将 Razor页面生成为 C# 代码并且编译到程序集中的方式来解决这一问题，这主要利用到了一款第三方 Visual Studio 扩展工具，但该工具自2019年以来已经没有继续更新。

另外的原因是由于 Dashbaord 目前的生成方式不利于对代码进行维护，有时会出现莫名其妙的编译问题，而且需要安装VS扩展工具，这让我们的贡献者参与其中变得沮丧。

在新版本重写开始之前，我们调研了 Blazor 的方案，但最终没有采纳。这是由于 Blazor 集成需要额外配置的东西太多而且较为分散，很难提供一种非常简便的配置方式，这对于CAP作为一个库来说不是非常合适。在此感谢 BootstrapBlazor 的作者张同学对此提供的支持和建议。

所以，我们最终选择了使用 Vue 来重写我们的 Dashboard ，但这对于我来说这是一项较为挑战的工作，因为我从没写过前端代码，最终花了一周左右的时间完成了整个工作，ps: 代码可能较为粗糙，前端好的同学欢迎提交 PR 重构。

样例图：

Transport 中的改动

改进 Kafka 对通配符的订阅的支持

过去只有 RabbitMQ 支持此功能，那么现在在 Kafka 订阅方法中，你也可以使用 * 和 # 通配符来进行批量订阅。

* 可以代替一个或多个词
# 可以代替零或多个词

看图理解（图片来源 RabbitMQ 官网）：

在这个例子中，我们将发送所有描述动物的消息。消息将使用由三个词（两个点）组成的路由名称发送。名称中的第一个词将描述敏捷(celerity)，第二个词描述颜色(colour)，第三个词描述物种(species)：“ .. ”。
我们创建了三个绑定：Q1 与绑定键“ .orange. ”绑定，Q2 与“ ..rabbit ”和“ lazy.# ”绑定。
这些绑定可以总结为：
Q1 对所有橙色动物都感兴趣。
Q2 想收听关于兔子的一切，以及关于懒惰动物的一切。

改进 RabbitMQ 对异构系统的支持

由于CAP处理消息需要有一些固定的信息，如果发送过来的消息没有携带这些信息，那么就会报错。然而如果你的上游不使用CAP，或者需要其他系统进行对接，那么怎么办呢？

在这个版本中，我们对 RabbitMQ 增加了 CustomHeaders 配置项，你可以使用这个配置对必须的头信息进行填充，用法如下：

cap.UseRabbitMQ(x =>
{
  x.HostName = "xxxx";
  x.UserName = "xxxx";
  x.Password = "xxxx";
  x.CustomHeaders = e => new List<KeyValuePair<string, string>>
  {
      new KeyValuePair<string, string>(Headers.MessageId, SnowflakeId.Default().NextId().ToString()),
      new KeyValuePair<string, string>(Headers.MessageName, e.RoutingKey),
  };
});