本文只是有關事件驅動的體系結構的一些想法。 這里沒有代碼，只有觀察和建議。 明確地說，我將使用事件驅動一詞，但如果您閱讀上面的Wikipedia參考，則會發現我也錯誤地混入了消息驅動系統。

TLDR；

這是關于復雜性的討論，顯然是說，強大的力量伴隨著巨大的責任。

基于事件的架構

基于事件的體系結構范式的核心是事件的產生，檢測，消耗和反應的解耦。它們應該在反映這一點的代碼中進行組織，即與生產，檢測，消耗和反應相關的代碼應分別分組，并且通常還通過多個應用程序進行分發。盡管事情是有條理的，并且肯定有明確的因果關系，但通過系統的分派機制進行的每次轉換都會充當信息壁壘。在許多體系結構中，如果您從第一段代碼開始，則可以跟蹤在給定情況下從頭到尾遵循的代碼路徑，通常可以使用調試器實時進行。使用基于事件的系統，通過事件分配器的第一跳更有可能使您感冒。您立即面臨一個問題，即許多現有的聽眾/訂戶中的哪些人將對事件做出響應，他們是否都在此過程中進行響應，是否可以保證收據，以及確定性發生的順序？

它實際上是一個公開喊價（outcry）系統，在通常情況下，出價（通話）和要約（響應）易于觀察和配對，但是在混亂的時期，以觀察員的身份進行的所有呼喊變得幾乎不可能。

我指的是我正在替換的當前事件驅動系統，稱為彈球機，因為球會大量涌入，在周圍瘋狂反彈，有的會導致獎品彈出，而有的則會消失殆盡。 您必須是粒子物理學家才能認為系統是可預測的和可理解的。

級聯混沌的真實示例

我記得讀過一次關于航空公司系統停機的事后調查，我相信那是英國航空公司的UPS故障，恢復工作花了幾天的時間。為什么？他們的系統都是事件驅動的，并掛在一條通用的消息總線上。隨著時間的流逝以及通過企業收購，IT系統的有機增長意味著他們根本不知道到底在聽什么，而且系統實施在容錯方面也不一致。許多系統需要重新啟動以重新建立通信，并且盡管UI可以快速檢測和處理，但在不能解決所有問題時，他們顯然會蠻力地"重新啟動所有"。但是，由于系統之間的相互依賴性以及幾乎同時進行的重啟，因此并非所有重啟均能正常工作。只是隨著時間的流逝，通過注意到非功能性功能才發現了一些問題。例如，也許您可以預訂航班，選擇座位，登記行李，但行李標簽不會在希思羅機場的柜臺打印。因此，他們必須確定應該發生什么事件鏈，哪些鏈斷裂了，沒有發生什么事件反應以及最后應該由哪個系統執行。

我是否要注意事件驅動系統？

不。它們功能強大，并且在許多情況下絕對是正確的解決方案。 哎呀，我們正在用另一種事件驅動的架構替換彈球機。 什么？！ 是的，這是我們方案中的正確工具。

因此，如果我不是說不使用事件驅動的體系結構，那是什么意思？

確保它們是可追蹤的

從第零天開始進行跟蹤和恢復：

· 將關聯標識符和發起者信息維護到事件中。

· 統一審核/記錄命令和事件。

· 請勿使用Blob或任何方案文本（如JSON）。 您希望始終使用通用語言，因為許多分布式部分正在監聽。 集中定義事件，并在所有地方使用這些定義。 您想知道更改對整個系統的影響。 提前計劃事件的演變變化。 在可能的情況下，請避免對現有字段進行結構更改，而應采用"狂暴/吹掃"方法，在這種情況下，您僅進行累加并直到要清理。

· 研究Zipkin和監視工具之類的東西，以顯示跟蹤信息。

· 如果另一個系統取決于您的事件，但又不能訂閱您的調度程序，而是從某個持久性日志中掃描事件，請確保它們也遵循這些規則，不要在異構邊界上停止這些最佳做法。

這些建議似乎過于嚴格，但是我一次又一次地看到人們認為他們可以在獲得一定收入后再解決這些問題，然后當問題確實出現時，發現沒有APM或快速解決方案可以追溯地真正修復生態系統。