.NET Core 开发实战
  • 目录
  • 第1课:课程介绍
  • 第2课:内容综述
  • 第3课:.NET Core的现状、未来以及环境搭建
  • 第4课:Startup:掌握ASP.NET Core的启动过程
  • 第5课:依赖注入:良好架构的起点
  • 第6课:作用域与对象释放行为
  • 第7课:用Autofac增强容器能力
  • 第8课:配置框架:让服务无缝适应各种环境
  • 第9课:命令行配置提供程序
  • 第10课:环境变量配置提供程序
  • 第11课:文件配置提供程序
  • 第12课:配置变更监听
  • 第13课:配置绑定:使用强类型对象承载配置数据
  • 第14课:自定义配置数据源:低成本实现定制化配置方案
  • 第15课:选项框架:服务组件集成配置的最佳实践
  • 第16课:选项数据热更新:让服务感知配置的变化
  • 第17课:为选项数据添加验证:避免错误配置的应用接收用户流量
  • 第18课:日志框架:聊聊记日志的最佳姿势
  • 第19课:日志作用域:解决不同请求之间的日志干扰
  • 第20课:结构化日志组件Serilog:记录对查询分析友好的日志
  • 第21课:中间件:掌控请求处理过程的关键
  • 第22课:异常处理中间件:区分真异常与逻辑异常
  • 第23课:静态文件中间件:前后端分离开发合并部署骚操作
  • 第24课:文件提供程序:让你可以将文件放在任何地方
  • 第25课:路由与终结点:如何规划好你的Web API
  • 第26课:工程结构概览:定义应用分层及依赖关系
  • 第27课:定义Entity:区分领域模型的内在逻辑和外在行为
  • 第28课:工作单元模式(UnitOfWork):管理好你的事务
  • 第29课:定义仓储:使用EF Core实现仓储层
  • 第30课:领域事件:提升业务内聚,实现模块解耦
  • 第31课:APIController:定义API的最佳实践
  • 第32课:集成事件:解决跨微服务的最终一致性
  • 第33课:集成事件:使用RabbitMQ来实现EventBus
  • 第34课:MediatR:轻松实现命令查询职责分离模式(CQRS)
  • 第35课:MediatR:让领域事件处理更加优雅
Powered by GitBook
On this page

第32课:集成事件:解决跨微服务的最终一致性

学习分享 丨作者 / 郑 子 铭 丨公众号 / DotNet NB / CloudNative NB

Previous第31课:APIController:定义API的最佳实践Next第33课:集成事件:使用RabbitMQ来实现EventBus

Last updated 3 years ago

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

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

集成事件的实现方式有两种,一种是图上显示的发布订阅的方式,通过 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,我们应用程序的版本控制,比如说我们发布新版本的时候,新旧版本的事件的发布和订阅都会受到影响,这个时候我们没办法使我们的应用程序成为一个单纯的无状态的程序,在更新新版本的时候,那么就会带来新的负担,兼容性方面我们会需要做更多的工作

GitHub源码链接:

https://github.com/witskeeper/geektime