什麼是實現鬆耦合系統架構的神器?

沈什麼是事件?

  根據百科的定義,事件是比較重大、對一定的人羣會產生一定影響的事情。那麼對於一個軟件系統來說,事件就是系統中發生的某個變化,可能是一個數據發生了變化,也可能是某個命令被觸發了。
  在軟件系統架構中,對事件最常見的應用場景就是事件通知。
  當領域內有變化發生時,發送事件消息來通知其它系統。事件通知的一個關鍵點是源系統並不關心外部系統的響應。通常它根本不期待任何結果,即使有也是間接的。發送事件的邏輯流與響應該事件的邏輯流之間會有顯著的隔離。
  事件通知非常有用,因爲它意味着低耦合,並且結構也非常簡單。但是,當邏輯處理流跨越各種事件通知時,它也可能成爲問題。因爲沒有任何代碼顯式地描述這個流程,所以這個流程是不可見的。通常,唯一的辦法是通過監控系統來觀察它。這會導致調試和修改流程變得很困難。
  事件不需要包含太多數據,通常只有一些ID信息和一個指向發送方、可供查詢更多信息的鏈接。接收方知道它已發生變化,並且接收到關於變化的最少信息,隨後會向發送方發出請求,以決定下一步該做什麼。
  第二種模式是攜帶狀態轉移的事件,採用此模式時,可以在不需要訪問源系統的情況下,更新客戶端的信息。例如客戶管理系統可能在客戶修改自己的詳細信息(如地址)時拋出事件,事件包含了詳細的修改數據。因此,接收方無需與客戶管理系統通信,就可以更新自己的客戶數據副本,以進行下一步的操作。
  這種模式的優點是我們獲得了更好的彈性,因爲即使客戶管理系統不可用時,接收方系統仍然可以正常工作。我們減少了延遲,因爲訪問客戶信息不需要遠程調用。我們也不必擔心所有來自消費端的查詢給客戶管理系統帶來的負載。
  還有一個應用事件的模式是事件溯源,事件溯源(Event Sourcing)的核心思想是,每當系統狀態發生變化時,都將狀態更改記錄爲事件,這樣我們就有信心在任何時間都能夠通過重新處理事件來重建系統狀態。事件庫成爲事實的主要來源,系統狀態完全來源於它。對於程序員來說,最好的例子就是版本控制系統。所有的提交日誌就是事件庫,源碼樹的工作副本是系統狀態。考慮一下版本控制系統帶來的價值,就很容易明白事件源有許多有趣的收益。事件日誌提供了強大的審計功能(賬戶交易是帳戶餘額的事件源)。我們可以重放事件日誌到某個點來重新創建歷史狀態。在重放時注入假設事件可以探索不一樣的歷史。
  最後一個使用事件的架構模式是CQRS,命令查詢職責分離(CQRS)是指讀取和寫入分別擁有單獨的數據結構。嚴格地說,CQRS跟事件沒有關係,因爲你完全不需要任何事件就可以使用CQRS.但通常人們會將CQRS與之前的事件驅動模式結合起來。
  使用CQRS的理由是,在複雜領域中,使用單一模型處理讀取和寫入過於複雜,我們可以通過分離模型來簡化。當訪問模式有區別時(例如大量讀取和非常少的寫入),這一點尤其具有吸引力。但是,需要注意平衡CQRS的收益和分離模型所帶來的額外複雜度。
  綜上所訴,應用事件的場景基本上有這四種:把事件作爲消息通知、帶有狀態轉移的事件作爲業務驅動、基於事件庫的事件溯源、基於事件驅動的CQRS架構。
  那麼,進入正題。業務中臺的事件中心,能支持哪幾個場景呢?支撐日均500萬事件分發量的事件中心又是如何保證高性能?
  首先看一下事件中心的應用架構:
什麼是實現鬆耦合系統架構的神器?
  事件中心包含兩大塊:事件引擎和事件管理。事件管理功能又包括事件類型、事件源註冊,監聽器註冊,事件查詢,看板,本地事件管理。事件引擎包括事件接受服務,事件消費服務,事件重試服務,以及事件庫。
  事件中心支持的特性包括:
  ·支持可靠事件發佈,保證事件不丟失。
  ·支持大併發下處理效率。
  ·支持限流功能,保證訂閱者服務的安全可控。
  ·支持事件庫持久化,能夠基於歷史事件進行事件的管理和跟蹤查詢。
  ·支持開發配置界面進行事件類型註冊和監聽器註冊。
  爲保證可靠事件,以及大併發場景下的高性能,事件中心的技術架構:
  什麼是實現鬆耦合系統架構的神器?

  通過本地部署EOS服務來實現本地可靠事件,保證事件不丟。
  同時按照監聽者動態分配消息隊列,能支持大併發下保持較高性能。從微服務部署形態上看,事件中心拆爲了事件中心管理微服務,接受事件微服務,消費事件微服務,重試微服務,以更小的粒度進行服務實例的動態擴展。
  回到關於事件的四個場景,事件中心可以支持一、二兩個場景。同時對事件做了持久化,維護事件庫,那麼就可以基於事件庫來實現事件溯源,所以事件中心也間接的支持了第三個場景。
  那麼,有了事件中心,我們還可以做什麼?
  基於事件中心,我們還可以實現有序事件管理,比如場景要求必須事件1投遞之後,事件2纔可以投遞,那麼可以設置事件2的前置事件是事件1,通過綁定鍵值來找到相關的事件1和事件2,做前置控制。
  基於事件中心,也可以實現數據最終一致性控制。可以實現中心式的Saga管理器,在事件中心定義以事件組成的業務流程,同時定義事件監聽失敗的補償命令,通過Saga的算法來實現最終一致性。
  最後說明一點,業務中臺的核心思想是通過快速組裝若干個標準化能力,來實現快速變化的前臺場景。那麼業務中臺的這一特性就要求了各能力中心必須是鬆耦合的,可裝配的,而達到這一架構要求的,也必然是基於事件中心的事件驅動架構最爲合適。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章