如何版本在分佈式事件來源的系統

Question

例

我的分佈式事件來源的系統模擬房屋正在建造和購買過一段時間的邏輯。爲了簡單起見，我們將使用年份作爲分佈式時鐘值（現在忘記向量時鐘）。

房子服用1年就建立該系統的1.0版本，但只要兩次參加第2版。這是邏輯而非結構的變化。

爲了應對此更改，版本1中記錄的事件在重建狀態/快照時還必須由版本1重播。當達到版本2的日誌時，應用程序切換到版本2的邏輯並繼續重播殘餘事件。構建有效的快照。

問題

在我的分佈式系統中的節點將在不同的時間更新爲版本2，創建一個窗口，由此多個版本同時運行。我目前的理解是，這個窗口只能通過諸如功能切換等技術來減少，但不能完全刪除（除非通過將整個系統降爲升級來犧牲可用性）。

合併來自分佈式節點的事件日誌時會產生問題。事件版本互相滲透，無法在重放期間從版本1升級到2。例如：

Node Clock Event 

... pre-merge ... 

A  2000 HouseBuildStarted('Alpha') 
A  2001 HousePurchased('Alpha') <- 'HouseBuilt' event is implicit (inferred through logic). 
A  2002 NodeUpgradedTo('V2') 
B  2002 HouseBuildStarted('Bravo') 
B  2003 HousePurchased('Bravo') 
B  2004 NodeUpgradedTo('V2') 

... post-merge ... 

A  2000 HouseBuildStarted('Alpha') 
A  2001 HousePurchased('Alpha') 
B  2002 HouseBuildStarted('Bravo') 
A  2002 NodeUpgradedTo('V2')   
B  2003 HousePurchased('Bravo') <- 'Bravo' does not exist yet (1 year early) 
B  2004 NodeUpgradedTo('V2') 

這是怎麼通常處理的系統中，所有的節點都不能接受？

Answer 1

升級邏輯和分發升級的問題是不同的。如果您需要升級事件流（例如，您的「HouseBuilt事件是隱含的」），那麼您應該這樣做。您的閱讀模型將不得不通過再次播放事件流來進行重建，而邏輯則可以進行升級。在升級程序時，這實際上與修補數據庫概念沒有什麼不同。關於持久數據的事實現在需要根據新的表示重新考慮（默認值可能必須替換，忽略過時的事件等）

如何確定哪個節點運行哪個版本的代碼是單獨的題。如果您有無停機升級政策，您通常會做什麼？有一些客戶使用舊版本和一些新版本？同樣的事情可能發生，建立新的讀取模型，而舊的在線，爲新的聚合和應用服務提供服務，同時部署新的模型等。