CAP 2.5 版本中的新特性

前言

首先，恭喜 CAP 已经成为 eShopOnContainers 官方推荐的生产环境可用的 EventBus 之一。

自从上次 CAP 2.4 版本发布以来，已经过去了几个月的时间，关注的朋友可能知道，在这几个月的时间里，也发布了几个预览版的 2.5 版本的NuGet包。

简介

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

CAP 是一个用来解决微服务或者分布式系统中分布式事务问题的一个开源项目解决方案（https://github.com/dotnetcore/CAP）同样可以用来作为EventBus使用，目前已经2岁了，目前已经应用到了很多的公司和项目中，

想对 CAP 更多了解的同学可以看下官方文档。

在 CAP 2.5版本中主要带来了以下新特性：

支持内存存储
支持Azure Service Bus
社区支持的内存队列

下面我们就来逐一看一下这些新的特性。

支持内存存储（In-Memory Storage）

应一些用户的要求，我们在事件的存储方面，我们添加了基于内存的事件存储。因为在一些场景下对数据的一致性要求不是很高，或者说可以接受消息丢失的这种情况，但是他们想提高消息的吞吐量，所以在这个情境下，我们提供了支持内存存储的方案。

那么，内存存储有哪些优缺点呢？

优点

吞吐量的提高，这也意味着可以容忍消息有丢失的情况存在
在测试项目或者学习的过程中能够快速入门或者进行试验。

缺点

不对事务提供支持

因为我们需要利用数据库的ACID特性来保证数据强一致性，很显然内存存储不具备这样的特性，所以在发消息的时候就不需要接管业务的事务了，直接发就行了。

支持 Azure Service Bus

在新的 2.5版本中，我们添加了对 Azure Service Bus 的支持， Azure Service Bus 是一种完全托管的企业集成消息中间件。

Azure Service Bus 最常用于将应用程序与服务彼此解耦，是一种用于异步数据和状态传输的可靠且安全的平台。数据通过消息在不同的应用程序和服务之间传输。消息采用二进制格式，可能包含 JSON、XML 或纯文本。

下面说一下如果使用 Azure Service Bus 对接CAP。

在 Azure 市场中搜索 Service Bus，然后选择创建命名空间。
在名称填写你的项目或者应用名称，定价层选择“标准”或者“高级”因为基本的不支持Topic功能，然后选择要创建的位置，根据需要选择即可。如下图：

创建完成之后，在共享访问策略(Shared access policies)中找到主连接字符串，填到CAP的配置中即可。

下面为使用内存储存和Azure Service Bus 配合的配置示例，同样你可以在这里找到示例程序。

services.AddCap(x =>

{

    x.UseInMemoryStorage();

    x.UseAzureServiceBus("Endpoint=sb://testcap.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=<your-key>");

    x.UseDashboard();

});

最后需要说明的是，在 Azure Service Bus 中，CAP会自动创建 Topic 而不需要人工干预，当然你可以通过配置项来自定义创建的名称。

社区支持的内存队列

在我们支持 In-Memory Storage 的过程中，有同学提出他们在跑集成测试的过程中需要使用真实的消息队列来做测试，这样非常不方便，问能不能够提供一个内存版的消息队列供测试使用。现在，社区已经提供了相关对内存队列支持的CAP扩展项目。

项目地址：https://github.com/yang-xiaodong/Savorboard.CAP.InMemoryMessageQueue

配置方式：

services.AddCap(x =>

{

    x.UseInMemoryStorage();

    x.UseInMemoryMessageQueue();

});

需要注意的是，此项目仅仅用户开发环境和测试使用，请不要用于生产环境。

总结

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