分布式事件總線在分布式開發（或微服務開發）時，是極為重要的架構手段。它可以分解響應時長，可以削峰，可以做最終一致性的分布式事務，可以做業務水平擴展。

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 就有這樣的動態事件功能（在線編即，實時生效或刪除）。