专业剑 : 事件驱动架构

场景：服务A完成了一次交易。服务B需要知道交易的状态和详情。

方案一：请求响应架构，服务B调用服务A的接口；

方案二：服务A在交易完成后调用服务B，通知B交易信息。

方案一的问题是效率低，服务B不知道服务A交易是否已经完成，需要轮训A。

方案二的问题是服务B可能有多个，比如日志，审计，通知，报表等，导致服务A需要调用多个服务。

方案三：这种场景通过事件驱动架构可以更好解决：服务A完成交易后，发送事件（生产），订阅了该事件的服务都可以消费该事件。生产和消费之间是解耦的，异步的。消费该事件的服务之间也是解耦的，异步的。

不适用的场景：

需要消费事件的服务之间需要的信息不同，权限不同。

操作的执行次序需要很严格，不允许异步。

请求需要及时，同步获得响应。得到响应之后才可以继续下一步。

可能会产生分布式事务，处理复杂。

比如用户填写手机号码后请求OTP；服务A发送请求：生成OTP；服务B生成OTP，并返回给服务A；服务A发送请求：发送OTP；服务C发送OTP，并返回结果给服务A；

再比如用户下单；服务A把库存商品减一；服务B把已售商品加一；

适用的场景：

在业务上服务A和B之间依赖低，服务A生产数据，发布事件，订阅了该事件的服务B消费事件和数据。

比如用户注册，然后点击submit；服务A处理完业务逻辑后，发布submit事件；订阅了该事件的服务B1，开始生成pdf；订阅了该事件的服务B2，开始发送邮件通知用户，等等。服务A只需要发布事件，不需要知道有哪些服务订阅该事件，也不需要知道哪些服务的具体业务处理是什么，是否处理成功。

优势：

异步方式的消息传递比同步方式具有更强的容错性，能够保障在系统故障时消息正常可靠地传输。异步消息传递模式分为点对点模式和发布订阅模式。前者用于生产者和消费者之间点对点的通信。

注意：上述方案属于发布订阅模型。处理过程通过事件的发布订阅实现解耦，减少了延迟，提升了效率，该过程不需要用户等待。

依赖于消息中间件。如果业务模型要求可靠性很高，需要考虑消息中间件是否满足。

需要消费者自己控制消费能力，控制获取待消费消息的速率。

另：微服务之间rest调用属于请求响应模型。

问题：可能削弱自动扩缩的能力。因为被调用方从消息总线中获取消息，不会获取超过自身处理能力的消息数量。

服务之间更加松散，实现接口调用的解耦。

服务可以异步方式响应事件。

Attachments: