分布式事件总线在分布式开发（或微服务开发）时，是极为重要的架构手段。它可以分解响应时长，可以削峰，可以做最终一致性的分布式事务，可以做业务水平扩展。
1、分解响应时长
比如我们的一个接口处理分为四段代码，别分耗时：A段(0.5s)，B段(1s)，C段(0.5s)，D段(3s)。如果同步响应的话，用户一共需要等待 5s，这个体验肯定不怎么好了。我们可以借分布式事件总线，做完A后，发一个事件，由事件订阅者再去完成B，C，D；那用户的感觉就是0.5S就完成了，体验就会比较好。(如果是单体，可以自己订阅；如果是分布式，可以由其它服务订阅)
2、 削峰
这个事情跟“响应时长”有极大的关系。比如一个接口响应需要5s，每秒请求数有200个，那舜间的并行请求就会有1000个（上一秒的未处理完，下一秒的又来了嘛），这个请求就会堆积如山，山峰也会越来越高。突然一波大流量就服务器可能挂了。
如果是0.5s，那并行处理就只会有100个。当前服务器的内存和cpu消耗也会10倍级的下降。
3、 做最终一致性的分布式事务
事件一但发送成功，中间件就会一直“盯”着你把事件消费成功为止。如果消费失败了，它会过段时间再发给你，直到你成功为止。（处理时，要注意“幂等性”控制。分布式环境，总会有不确定原因）
4、 业务水平扩展
这个是“分布式事件总线”的灵魂级妙处。你开发了一个用户注册的接口。一周后，产品说“用户注册完送5个Q币”，旧的生产环境不用动，你只需要开发一个新的服务，订阅注册完成事件做处理；一个月后，产品说“用户注册完成后，给他推送电信的大礼包活动”；后来产品又说“用户注册后7天后，如果有上线3次，再送10个Q币”。。。这个就是指“业务水平扩展”了。在不动原代码和原服务，就扩展业务。
如果我们还有一个FaaS平台，可以动态的扩展事务。产品爱怎么搞，就怎么搞。像 Water 就有这样的动态事件功能（在线编即，实时生效或删除）。
