领域事件和集成事件没那么高大上

前言

随着系统架构的演变，有很多名词也随之涌现，如：微服务、灰度发布、资源隔离、容器、领域/集成事件等，听着的确高大上，让很多小伙伴有一种无法征服的感觉；其实很多东西可能之前就已经用过了，只是名字不这么叫而已，就算没应用上也别慌，现在很多轮子都很成熟，用起来很容易上手的。这里就来说说比较常见的领域事件和集成事件。

正文

1.概述

微服务和DDD盛行的时代，领域事件和集成事件经常被提及到；对于事件，小伙伴可以根据不同场景去理解，比如点击一个按钮时，这个就是一个事件(点击事件)，又或者说当购买商品时付款成功，也可以理解为一个事件，就像咱们在生活中对每一件事的定义是一样的。

1.1 领域事件

领域事件（Domain Event）是在一个特定领域由一个动作触发的，是发生在过去的行为产生的事件(行为可以是人操作的，也可以是系统自动的) ；

其实在项目中，通常咱们会把领域事件用在一个应用程序进程内，比如说在用户管理时，当用户注册成功时，需要发送邮件或短信提醒；其中用户管理可以简单理解为一个领域，用户注册成功就是事件，而发送提醒就是针对事件的处理方式。

这里可能对领域的比喻不是特别恰当，如果小伙伴想更多了解，可以看看DDD(领域驱动设计)相关资料。

对于我个人的理解，我认为领域事件的主要目的是为了让代码更加容易维护，让业务更加容易扩展，也就是对代码业务层面的优化。如下图：

对于原始这种方式，相信很多小伙伴也和我曾经一样写过这样的代码逻辑，不用想什么代码顺序，直接撸码就行了，但是这样扩展性不好，比如我想加一个微信发送怎么办，还得在原来基础上继续加，如果过两天不要短信发送了，还得去改原来代码。这样是不是违背了软件开发的开闭原则，尽量还是少改原有逻辑的代码，避免重复修改、重复测试。

对于优化后的这种方式，只需要在注册成功之后发布一个事件出来就行了，至于后面要发送什么样的消息不用管，只要捕获到事件消息，只需新增额外扩展的处理器类即可，就算是取消，只需不捕获对应的事件就行，无需改动原有用户注册代码的逻辑。这种方式的事件就可以理解为领域事件。

小伙伴回想一下，之前在优化代码的时候是不是也这样做过，只是当时不称它为领域事件。

1.2 集成事件

集成事件(IntegrationEvent)同样也是指在过去的行为产生的事件(行为可以是人操作的，也可以是系统自动的)，一般用于跨多个微服务或外部系统。

比如现在的电商系统，订单模块和物流模块会拆分为不同微服务，通常在订单支付成功之后，物流模块需要知道订单相关的明细，这样才会根据订单进行物流跟踪。所以订单在付款成功之后，就会发布一个事件出去，物流系统订阅到事件之后就可以处理对应业务逻辑。

对于集成事件的主要目的我认为就是为了让服务模块之间或系统之间的对接耦合性变低，只要约定好事件类型，发事件模块和处理事件的模块就会有很少对接，便于扩展和维护。如图：

原始的这种方式，像我有点年长的小伙伴应该之前都用过，当然现在有很多传统企业项目也是这种方式。这种方式主要是通过接口的形式进行模块或系统之间的对接，这样对接成本稍微偏高，因为订单服务还需要开发调用物流服务接口的逻辑，还要各种联调，考虑接口超时、失败等各种情况；另外如果还有其他业务模块的系统需要对接怎么办，如果接口规范不一样，还得重复再开发一套调用逻辑，这样后面订单服务这个模块就变得很臃肿，而且模块间的耦合性比较高。

优化后的方式就相对来说比较好，对订单付款成功之后，只需将事件发布出去就行了，剩下的不用过多干涉，对应的业务模块订阅到消息之后进行相关业务处理即可；这种模式就算有其他业务模块加入也会很便捷，模块间的耦合性比较低。由于模块间的消息需要传输，所以就需要EventBus来做这个事了。这种方式看上去不错，但需要第三方的消息中间件做消息转发和存储，如RabbitMq、Kafka等；另外使用过程中，消息的持久化、消息丢失的情况都需要考虑，后续会单独出相关系列的文章说这块。

2.演示

对于技术落地，大神都把轮子造好了，咱们拿来就可以用啦。

2.1 领域事件

技术简介

MediatR是用.Net实现的简单中介者模式，无需其他依赖就能处理进程内的消息传递，支持请求/响应、命令、查询、通知和事件的同步或异步传递，通过C#的泛型智能调度。

这里就不详细说了，详细说明小伙伴们可以看我之前分享的这篇文章《跟我一起学.NetCore之MediatR好像有点火》
案例实操

准备一个API项目，引入对应的Nuget包，并注册相关服务，如下：

模拟用户注册成功发布领域事件，这里在默认的控制器里添加一个接口进行测试，代码如下：

发布的事件信息其实就是一个对象信息，只是该类按照MediatR约定继承对应的接口即可，如下：

增加对事件的处理逻辑，即捕获到事件之后如何处理，代码如下：

这个处理类可以根据需要增加，这里增加一个邮件的和短信的，如果还需要其他方式的，只需要按照约定继承对应的接口，并实现对应的方法处理业务逻辑即可。

运行起来看效果：

是不是用起来很Easy~~~，集成事件也是一样。

2.2 集成事件

技术简介

这块自己比较常用是CAP和Masstransit，关于CAP自己也分享过一篇文章《分布式事务最终一致性-CAP框架轻松搞定》，也可以用其进行事件的发布，这里就不在赘述。

Masstransit是一个免费的、开源的.NET 分布式应用程序框架，轻量级的消息总线(EventBus) ，即专门用来传输和接收消息的；集成很多消息中间件，如：RabbitMQ、AcitveMQ、Azure Service Bus、Kafka、Redis等，这里我们主要说应用，更多详情小伙伴们查看官网，如下：

官网地址：http://masstransit-project.com/getting-started/

开源地址：https://github.com/MassTransit/MassTransit
案例实操

其实可以用内存的方式进行演示，但为了更符合真实场景，这里采用RabbitMQ的方式进行演示，所以首先需要安装RabbitMQ，为了方便，还是用Docker的方式进行安装，如果对Docker还不了解的小伙伴，可以查阅我分享的系列文章《Docker系列》。

在确保有Docker的环境下，执行如下命令即可：
```
docker run -di --name myrabbit -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin -p 15672:15672 -p 5672:5672 -p 25672:25672 -p 61613:61613 -p 1883:1883 rabbitmq:management
```
这个命令指定了默认用户为admin，默认密码也是admin，如果能正常登陆RabbitMQ系统，代表安装成功了，如下：

注：我这里用的是阿里云服务器，所以需要在安全组和防火墙中开启端口15672和5672的访问，15672是RabbitMQ的Web界面，5672是程序之间通信需要用到的。

准备两个API项目，一个模拟订单发布事件，一个模拟物流订阅事件，首先都需要引入相关的Nuget包：MassTransit、MassTransit.RabbitMQ，并注册相关服务，如下：

模拟订单发布付款成功事件，在默认的控制器中增加对应的接口进行演示，如下：

事件的定义这里为了方便直接定义为公共的类库，同样就是一个简单的类，里面的内容如下：

物流模块

模拟物流订阅付完款成功事件，这里需要稍微注意一下，因为订阅到事件之后需要进行相关的业务处理，所以在注册服务的时候，需要把对应的处理器也注册上，处理类的逻辑如下：

将处理器也进行注册，如下：

启动时候订单的端口为5001，物流模块的端口为5000，只要避免两个模块的端口不一样就行，端口不能重复用，这样就可以运行看效果了，两个模块都启动起来：

在订单模块访问发布接口，物流模块收到事件消息之后就会马上处理如下：

注：以上演示方式没有指定对应队列，所以采用的是RabbitMQ中的Fanout模式，Fanout是一种广播机制的发布与订阅模式，也就是所有的订阅者都可以收到生产者发布的事件，实际场景中这种模式用的不多，通常比较常用的是direct模式，小伙伴可以根据实际情况指定即可；关于RabbitMQ系列的文章我正在整理，后续会分享给大家。