NCC CAP 7.2 版本发布通告，控制板新增支持 k8s 服务发现

今天，我们很高兴宣布 CAP 发布 7.2 版本正式版，我们在这个版本中主要致力于 Dashboard 对 k8s 服务发现的支持。

从 7.1 版本以来，我们发布了4个小版本，在这些版本中我们主要解决发现的Bug和添加一些小功能，这篇文章中可能也会提及我们在这些小版本中加的一些小功能。

下面，具体看一下我们新版本的功能吧。

总览

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

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

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

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

• 消息发布任务由.NET线程池管理

• Dashboard 添加对 Kubernetes 服务发现的支持

• Dashboard 支持自定义JWT认证登录

• Dashboard Api 支持匿名访问

• 破坏性改动

  • 移除 ProducerThreadCount 配置项

  • SnowflakeId 生成由静态单例更改为依赖注入单例

  • 移除7.1版本事务异步方法的支持

• BUG 修复

  • 修复 RabbitMQ BasicQos 配置项未按预期工作的问题

消息发布任务由.NET线程池管理

在过去，我们消息发布的Task是一条一条发送的，通过使用 ProducerThreadCount 配置项来控制同时发送的进程数来提高消息发送效率。在这个版本中，消息发布任务将由 .NET 线程池调度，同时 ProducerThreadCount 配置项被移除，这将充分利用 .NET 线程池的能力来提高发送效率。

在消息的消费侧，消费者的执行同样是线性的，在过去通过使用 UseDispatchPerGroup 配置项来让每个消费者组使用不同的队列来实现跨消费者组的并行消费。

现在消费侧同样引入了线程池，不过没有默认开启，可以通过EnableConsumerPrefetch 来启用，这样所有的消费者都将并行执行，无论是否处于相同的组， UseDispatchPerGroup将不再需要。

在 7.2.1 版本中， UseDispatchPerGroup 将和 EnableConsumerPrefetch 同时工作，参考 issue #1399 了解更多详情。

Dashboard 添加对 Kubernetes 服务发现的支持

在CAP的前期阶段，Kubernetes并没有被广泛使用。我们使用 Consul 进行仪表板发现，从其他节点收集数据，这大大简化了在微服务中查看不同节点数据的过程。

根据我们社区的反馈，越来越多的人使用 Kubernetes 作为他们的部署环境。所以我们在这个版本中支持 Kubernetes 作为服务发现。我们引入了一个新的NuGet包 DotNetCore.CAP.Dashboard.K8s来实现这一点。

在引入了NuGet包后，现在有一个新的 UseK8sDiscovery 配置项用于配置服务发现，以下是一个配置示例

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

组件将会自动检测是否处于集群内部，如果处于集群内部还需要赋予 Pod Kubernetes Api 的权限。

分配 Pod 访问 Kubernetes Api

如果你的 Deployment 关联的 ServiceAccount 没有 K8s Api 访问权限的话，则需要赋予 namespaces, services 资源的 get, list 权限。

所需配置项请参考我们的文档。https://cap.dotnetcore.xyz/user-guide/zh/monitoring/kubernetes/#dashboard

Kubernetes 发现页和Consul发现页使用的同一个，

CAP 仪表盘

将 Dashboard 独立运行

如果你想将 Dashboard 作为单独的 Pod 来部署，专门负责查看集群内其他服务的话，我们提供了一个单独的扩展方法来实现这一点。

配置如下：

 // 只需要这一行即可 builder.Services.AddCapDashboardStandalone(); 

这将使CAP Dashboard 作为一个独立的pod服务来运行，仅用作查看其他服务。

下面这个是一个Sample.Dashboard.Jwt这个示例项目，打包的一个可供测试的Docker镜像

 docker pull ghcr.io/yang-xiaodong/cap-dashboard:0.2 

支持自定义JWT认证登录

现在我们的 Dashboard 支持接入自定义 JWT 统一认证。

现在你可以和你自己的系统集成，使用你的自定义登录页，使用你自己的Token，来访问 Dashboard。

你可以在 Sample.Dashboard.Jwt 示例中查看更多详细。

Dashboard Api 支持匿名访问

在将 CAP Dashboard 集成到现有项目的过程中，有些项目使用了 ASP.NET Core 全局认证过滤器，由于 CAP 的 API 也是基于 ASP.NET Core 路由机制实现的，所以会被全局过滤器限制，现在我们提供了一个新的配置项以允许API匿名访问。

我们在 Dashboard 中提供了一个新的配置项 AllowAnonymousExplicit 以允许将目前的 Api 进行允许匿名访问。

破坏性改动

移除 ProducerThreadCount 配置项

正如在第一节中介绍的一样，我们的消息发送任务现在使用 .NET 线程池进行，所以 ProducerThreadCount 配置项现在已经无效被移除。

SnowflakeId 生成由静态单例更改为依赖注入单例

我们的自动生成 Published 和 Received 表主键的雪花算法现在已经由静态单例模式更改为使用依赖注入的方式进行，这允许用户自行修改实现。

 services.AddSingleton<ISnowflakeId, SnowflakeId>(); 

受改动影响，具体 Broker 中 CustomHeaders 配置项将由 CustomHeadersBuilder 替代， CustomHeadersBuilder 配置项提供了 IServiceProvider 允许从中获得 ISnowflakeId 实例。

移除7.1版本事务异步方法的支持

在7.1版本中，我们添加了对开启事务异步方法的支持，在这个版本中，我们将其移除。原因是由于我们的事务状态使用 AsyncLocal 存储，AsyncLocal 不支持向上传递导致事务状态丢失，所以这个版本将其移除。

BUG 修复

另外在这个版本中，我们修复了一些已知的Bug，以下是已经修复的问题列表。

• 修复 RabbitMQ BasicQos 配置项未按预期工作的问题