32 | 集成事件：解决跨微服务的最终一致性

首先看一下集成事件的工作原理

它的目的时为了实现系统的集成，它主要是用于系统里面多个微服务之间相互传递事件

集成事件的实现方式有两种，一种是图上显示的发布订阅的方式，通过 EventBus，还有一种方式是通过观察者模式，由观察者将事件发送给关注事件的人

接着看一下代码上的定义

在 Application 目录下面定义了一个集成事件的目录 IntegrationEvents

OrderCreatedIntegrationEvent

namespace GeekTime.API.Application.IntegrationEvents
{public class OrderCreatedIntegrationEvent{public OrderCreatedIntegrationEvent(long orderId) => OrderId = orderId;public long OrderId { get; }}
}

得益于基础设施的发展，现在实际上可以借助一些开源框架，很轻松的实现集成事件的发布和订阅的能力

在发布端可以看一下这里的代码

namespace GeekTime.API.Application.DomainEventHandlers
{public class OrderCreatedDomainEventHandler : IDomainEventHandler<OrderCreatedDomainEvent>{ICapPublisher _capPublisher;public OrderCreatedDomainEventHandler(ICapPublisher capPublisher){_capPublisher = capPublisher;}public async Task Handle(OrderCreatedDomainEvent notification, CancellationToken cancellationToken){await _capPublisher.PublishAsync("OrderCreated", new OrderCreatedIntegrationEvent(notification.Order.Id));}}
}

这里我们定义了一个领域事件，它的作用就是将我们的集成事件发送出去，具体是要发送到 RabbitMQ 还是 kafka 这些消息队列中间件里面是可配置的，对于业务逻辑来讲的话，它是透明的

这里有一个 ICapPublisher 接口，这个接口实际上是由中国的开源社区开发的一个框架，借助这个框架，我们可以轻松的实现消息的发布和订阅

那我们如何来订阅其他微服务发出的消息呢？

namespace GeekTime.API.Application.IntegrationEvents
{public class SubscriberService : ISubscriberService, ICapSubscribe{IMediator _mediator;public SubscriberService(IMediator mediator){_mediator = mediator;}[CapSubscribe("OrderPaymentSucceeded")]public void OrderPaymentSucceeded(OrderPaymentSucceededIntegrationEvent @event){//Do SomeThing}[CapSubscribe("OrderCreated")]public void OrderCreated(OrderCreatedIntegrationEvent @event){//Do SomeThing}}
}

我们可以通过订阅服务，它同样也是借助了 Cap 的组件，我们实现了 ICapPublisher 这个接口，就可以将服务标记成我们的订阅服务

另外我们的订阅方法，订阅的处理函数上面，标记 CapSubscribe 这个属性，将我们要订阅的事件名放在这里，我们就可以订阅到这个事件了

namespace GeekTime.API.Application.IntegrationEvents
{public class OrderPaymentSucceededIntegrationEvent{public OrderPaymentSucceededIntegrationEvent(long orderId) => OrderId = orderId;public long OrderId { get; }}
}

我们可以看到集成事件定义的话，它是没有接口和基类的约束的，因为在异构的系统里面，对于集成事件来讲的定义是相对比较灵活的，我们的建议是用这种简单的类型来承载它即可

总结一下

集成事件实际上也是由领域的业务逻辑驱动的，它本质上也是领域事件，只是说它是跨服务的领域事件

另外一个集成事件大部分场景是领域事件驱动的，也有可能是一些比如说定时任务触发的，由于集成事件是跨微服务来传递信息的，所以我们没办法通过事务来处理，那就需要借助 Cap 这样的框架来实现最终的一致性

当然我们建议仅在必要的情况下定义和使用集成事件，因为一旦引入集成事件，比如 EventBus，我们应用程序的版本控制，比如说我们发布新版本的时候，新旧版本的事件的发布和订阅都会受到影响，这个时候我们没办法使我们的应用程序成为一个单纯的无状态的程序，在更新新版本的时候，那么就会带来新的负担，兼容性方面我们会需要做更多的工作