分散式事件匯流排在分散式開發（或微服務開發）時，是極為重要的架構手段。它可以分解響應時長，可以削峰，可以做最終一致性的分散式事務，可以做業務水平擴充套件。
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 就有這樣的動態事件功能（線上編即，實時生效或刪除）。
