EDA, Event-Driven Architecture
What is an event?
Event, something that happens at a given place and time.
Simply put, the event is a significant change in state, which is triggered when a user takes an action.
事件，本質上就是運動，變化，跟“函數”、“消息”、“操作”、“調用”、“算子”、“映射”等概念全息。
For example:
When a customer buys a car and its state changes from For Sale to Sold is an event.
After a successful transaction, when an amount gets deducted from your account is an event.
Once clicking on the book cab button, when a cab is booked from your account is an event.
Every event may trigger one or more than one options in response.
事件，在計算機領域裡指：可以被控件識别的操作，如按下确定按鈕，選擇某個單選按鈕或者複選框。每一種控件有自己可以識别的事件，如窗體的加載、單擊、輕按兩下等事件，編輯框（文本框）的文本改變事件，等等。
事件有系統事件和使用者事件。系統事件由系統激發，如時間每隔24小時，銀行儲戶的存款日期增加一天。使用者事件由使用者激發，如使用者點選按鈕，在文本框中顯示特定的文本。事件驅動控件執行某項功能。
觸發事件的對象稱為事件發送者；接收事件的對象稱為事件接收者。
事件就是使用者對視窗上各種元件的操作。
使用事件機制可以實作：當類對象的某個狀态發生變化時，系統将會通過某種途徑調用類中的有關處理這個事件的方法或者觸發控件事件的對象就會調用該控件所有已注冊的事件處理程式等。
在.net架構中，事件是将事件發送者（觸發事件的對象）與事件接受者（處理事件的方法）相關聯的一種代理類，即事件機制是通過代理類來實作的。當一個事件被觸發時，由該事件的代理來通知（調用）處理該事件的相應方法。
C#中事件機制的工作過程如下：
（1）将實際應用中需通過事件機制解決的問題對象注冊到相應的事件處理程式上，表示今後當該對象的狀态發生變化時，該對象有權使用它注冊的事件處理程式。
（2）當事件發生時，觸發事件的對象就會調用該對象所有已注冊的事件處理程式。
什麼是事件驅動？
By the end of 2020, Gartner projects that over 50% of applications will be on EDA.
The Internet of Things, real-time applications, and the sharing economy require “super” distributed processing. This means that cloud servers and edge computing are united seamlessly by an architecture that enables event-driven computing. The existing database architecture has two shortcomings for the Internet of Things systems. First, storage is inflated with endless log data and 99% of data is not used. And second, high latency in data look-up makes real-time computing impossible. Event-Driven Architecture (EDA) addresses these issues.
物聯網、實時應用和共享經濟需要“超級”分布式處理。這意味着雲伺服器和邊緣計算通過一個支援事件驅動計算的架構無縫地結合在一起。物聯網系統現有的資料庫體系結構存在兩個缺陷。首先，無限的日志資料膨脹了存儲空間，99%的資料沒有被使用。其次，資料查找的高延遲使實時計算變得不可能。事件驅動的體系結構(EDA)解決了這些問題。
What is EDA? EDA is a software architecture that promotes production, detection, processing, and reaction to events. Events can be as varied as a driver picking up a package, a machine measurement hitting a threshold, or a specific customer arriving at a retail outlet. EDA is defined by three properties. First, it selectively transfers relevant events from incoming data to the database. Second, it processes complex events from multiple sources that can impact each other in real-time. And third, it simplifies real-time services with push-type operations. Examples of use cases for event-driven architecture include asset sharing solutions such as DiDi and Uber, prescriptive maintenance systems that allocate maintenance personnel and spare parts, or dynamic customer service applications.
EDA是什麼?EDA是一種軟體體系結構，用于促進事件的生産、檢測、處理和響應。事件可以是多種多樣的，比如一個司機拿起一個包，一個機器測量達到一個門檻值，或者一個特定的客戶到達一個零售店。EDA由三個屬性定義。首先，它有選擇地将相關事件從傳入資料傳輸到資料庫。其次，它處理來自多個源的複雜事件，這些事件可以實時地互相影響。第三，它通過推式操作簡化了實時服務。事件驅動架構的用例示例包括滴滴和Uber等資産共享解決方案、配置設定維護人員和備件的規定維護系統或動态客戶服務應用程式。
說白了，“if A then B”語句中的A 就是 ‘事件’，B就是“響應”。
事件驅動跟消息驅動機制相比
事件驅動和異步IO
通常，我們寫伺服器處理模型的程式時，有以下幾種模型：
（1）每收到一個請求，建立一個新的程序，來處理該請求；
（2）每收到一個請求，建立一個新的線程，來處理該請求；
（3）每收到一個請求，放入一個事件清單，讓主程序通過非阻塞I/O方式來處理請求
上面的幾種方式，各有千秋，
第（1）中方法，由于建立新的程序的開銷比較大，是以，會導緻伺服器性能比較差,但實作比較簡單。
第（2）種方式，由于要涉及到線程的同步，有可能會面臨死鎖等問題。
第（3）種方式，在寫應用程式代碼時，邏輯比前面兩種都複雜。
綜合考慮各方面因素，一般普遍認為第（3）種方式是大多數網絡伺服器采用的方式
在UI程式設計中，常常要對滑鼠點選進行相應，首先如何獲得滑鼠點選呢？
方式一：建立一個線程，該線程一直循環檢測是否有滑鼠點選，那麼這個方式有以下幾個缺點：
- CPU資源浪費，可能滑鼠點選的頻率非常小，但是掃描線程還是會一直循環檢測，這會造成很多的CPU資源浪費；如果掃描滑鼠點選的接口是阻塞的呢？
- 如果是堵塞的，又會出現下面這樣的問題，如果我們不但要掃描滑鼠點選，還要掃描鍵盤是否按下，由于掃描滑鼠時被堵塞了，那麼可能永遠不會去掃描鍵盤；
-
如果一個循環需要掃描的裝置非常多，這又會引來響應時間的問題；
是以，該方式是非常不好的。
方式二：就是事件驅動模型
目前大部分的UI程式設計都是事件驅動模型，如很多UI平台都會提供onClick()事件，這個事件就代表滑鼠按下事件。事件驅動模型大體思路如下：
- 有一個事件（消息）隊列；
- 滑鼠按下時，往這個隊列中增加一個點選事件（消息）；
- 有個循環，不斷從隊列取出事件，根據不同的事件，調用不同的函數，如onClick()、onKeyDown()等；
- 事件（消息）一般都各自儲存各自的處理函數指針，這樣，每個消息都有獨立的處理函數；
事件驅動架構
事件驅動架構模式是一種非常流行的分布式異步架構模式，經常被用與建構高可伸縮性的應用程式。當然它也适合小型應用，複雜應用和規模比較大的應用。這種架構模式由一系列高度解耦的、異步接收和處理事件的單一職責的元件所組成。
事件驅動架構由兩個主要的拓撲組成，分别是調停者拓撲和代理者拓撲。調停者拓撲通過一個中央的調停者來編排各種處理步驟。然而代理者拓撲适用于那些當你想将事件鍊式的聚在一起但不使用中央調停者的情況。由于這兩種模式特性以及實作均不一樣，是以了解哪一個模式最适合你的實際情況是非常重要的。
調停者拓撲
調停者拓撲适合那些有很多步驟需要處理，并且需要按照某種程度的編排來處理的事件。舉個例子，一個處理股票交易的事件首先需要你首先驗證交易的本身合法性，然後檢查這個股票交易是否合規，然後把股票交給股票代理商，計算傭金，然後通過代理商将股票移送給客戶。這些步驟都需要一個編排中心來決定這些步驟的順序，并且決定哪些能是串行的，哪些是并行的。
調停者拓撲主要有4個主要的架構元件組成：事件隊列（Event Queue）、調停者（Mediator）、事件通道（Event Channel）和事件處理器（Event Processor）。
事件流通過用戶端發送到消息隊列，事件隊則傳遞消息到調停者。調停者接收到隊列傳遞過來的原始消息，然後編排成異步的消息發送到事件通道，事件通道則通過事件處理器執行處理過程的每一步。事件處理器則監聽事件通道，根據自身不同的業務邏輯來處理從調停者接受的事件。
If event Then handler，實際上包含三個元素：
1.事件(event);
2.響應(handler);
3.事件與響應的“邏輯關系”
其中的'事件'常常是固定的；而“邏輯關系”往往展現的是業務規則或者核心邏輯，也常常是固定不變的。
隻有'響應'是可變的，或者說是可以配置或者需要改變的。
軟體開發的OCP原則告訴我們：“軟體應該對修改關閉，但要對擴充開放”。而事件驅動就是在保持了事件和核心邏輯的穩定性和不被修改的前提下，通過定義不同的“響應”進而達到了對“擴充的開放”。
Event-driven architecture components
An event-driven architecture typically consists of four components:
-
Event
The significant change in the state of an object that occurs when users take action.
-
Event Handler
A software routine, which handles the occurrence of an event.
-
Event Loop
Event loop handles the flow of interaction between an event and the event handler.
-
Event Flow Layers
The event flow layer is built on three logical layers: Event Producer, Event Consumer, and Event Channel (also called Event Bus).
Producer which is responsible for detecting and generating events.
Consumer which consumes the events produced by the event producer.
Event Channel which transfers events from the event generator to the event consumer.
關于最終一緻性
響應事件而不是“及時”查詢權限系統會讓我們更具有自主性，更有容錯能力和彈性，但也有一點其他影響，會影響自治事件驅動系統的是“延遲”。
如果你立即注意到某一事件，你可以立即做出反應。例如，如果一輛車轉彎進入你的車道，你看到這個，你可以很快刹車或者調整駕駛避免不發生碰撞。但是，如果有一些延遲，在觀察到這個事件後，你的反應可能是緩慢的（也許有駕駛障礙？或者你在玩手機？或是在你的孩子們做某事，等等）。
這也可能發生在IT系統。比如在亞馬遜訂購商品。這會對其他自主服務（如訂單處理，帳單，庫存等）釋出一個事件或事實。這些系統可以觀察到這一事件，但如果此時庫存系統從網絡斷開幾分鐘/小時？當他們重新恢複正常運作後，他們最終會看到這個事件并繼續檢查庫存，釋出任何它認為必要的事件（即反應）像“inventoryreserved事件”或“inadequateinventory”事件。這是一組自主系統“最終”變得一緻的一個簡單例子。
最後一件事是關于事件，延遲和自主權。如果我們能夠捕捉到它們并觀察它們的順序，事件就是有用的。也就是說，在我們的系統中必須保留一組事件的總排序，這樣我們才能如何對它們做出反應有信心。
現在你已經明白：事件的順序在分布式系統中建構事務是如何的重要，如果事件變得無序，那麼我們就無從獲得最終一緻性，除非再次需要人工介入。
小結
Event-Driven Architecture
Domain Events 領域事件
Event Sourcing
Command and Query Responsibility CQRS
Segregation (CQRS) pattern
Event Stream Processing 簡稱ESP
Messaging 消息系統
Enterprise Service Bus ESB總線
Actors
Enterprise Integration Architecture (EIA)
Event Sourcing事件溯源
每個狀态的改變都可以表達為事件。事件觸發狀态改變。
所有的事件被發往EventProcessor
EventProcessor 将所有事件儲存在 Event Log
系統能夠被複位，這樣Event Log 會重播。
不再需要ORM, 隻要持久化Events。
很多不同的EventListeners被加到EventProcessor，對其監聽(or listen directly on the Event log)
CQRS特點
所有狀态改變由Domain Events驅動
聚合根接受 Commands，然後釋出 Events
報表系統 (資料庫查詢) 将作為一個釋出後事件published Events的結果
所有來自表現層查詢直接走報表系統。
CQRS優點
充分封裝了業務領域，隻暴露行為。
查詢不使用 domain model
沒有對象和關系不比對問題。
易于跟蹤審計和曆史
易于和外部系統整合。
性能與可伸縮性。
參考資料
https://www.softobiz.com/understanding-the-event-driven-architecture/https://medium.com/@prashunjaveri/architectural-patterns-for-iot-event-driven-architectures-557be35fa626
https://www.eda-consortium.cn/abouteventdrivenarchitecture
https://www.jdon.com/artichect/scalable8.html
Kotlin開發者社群
專注分享 Java、 Kotlin、Spring/Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、函數式程式設計、程式設計思想、"高可用，高性能，高實時"大型分布式系統架構設計主題。