事件溯源是否屬於過度營銷的銀彈？ - Alexey

banq發表於2020-07-11
事件

大多數微服務架構都需要事件溯源嗎？微服務之間使用RESTful依賴是表明還是一個單體架構嗎？

1. 事件溯源不是架構或體系結構模式，它是儲存實體狀態的方式，僅此而已。
如果你有一個倉庫介面，喜歡OrderRepository用類似的方法Add和Update，你可以將其轉換為使用事件溯源。如果您的儲存庫中有查詢-會遇到麻煩。我不喜歡僅在儲存庫中進行查詢，因為儲存庫表示實體的集合，而查詢通常需要超出此範圍。這時候需要CQRS！
CQRS僅保證：更新實體狀態時您可以最佳化事務的操作；執行查詢時您可以對其進行最佳化以進行報告。這就是為什麼我不建議在儲存庫中查詢的確切原因。報表模型通常對您的域模型不感興趣，但對整個系統的狀態卻很感興趣。因此，查詢通常超出實體的界限，並且限制查詢只能使用一種實體型別成為一種負擔。
CQRS具有其雙重性質。一方面，Greg Young多次表示CQRS只是邁向事件採購的墊腳石。同時，CQRS也不是事件源的一部分。構建事件源系統時，它變得非常有用。

2. 事件溯源隱藏大量複雜性。
這不是真的，事件溯源社群根據他們自己的經驗，不斷展示問題和克服問題的方法。DDD Europe組織了第一場專門用於事件源的活動，我榮幸地策劃了這一活動，並且我們進行了很多案例研究和經驗分享會議。例如，Dennis Doomen經常在許多論壇上分享他的經驗，因此請檢視。
驗豐富的開發人員（在本文的後面引用）使用的ORM工具是否不具有大量的複雜性？
在設計和構建事件源系統時，我犯了很多錯誤，直到我意識到大多數複雜性是人為的並且可以避免的。

3.使用RPC互動的微服務主要有什麼問題？
RPC本質上引入的高度耦合。如果僅其中一項服務停止工作，則整個服務組甚至整個系統都可能崩潰。這種方法減少了獨立元件的整個想法。
微服務的鬆散耦合是透過使用REST模式透過https進行通訊並對微服務公開的端點進行版本控制來實現的。微服務之間的這些依賴關係並不理想。其他微服務可能會關閉，基於HTTP的同步RESTful請求由於其阻塞性質而無法很好地擴充套件。
即使沒有事件溯源，我們也可以使用事件驅動非同步通訊並在服務之間交換資訊。

4.事件是不變的，不能修改的
有人說事件溯源為您提供了時間旅行：您可以返回以前事件日誌，檢視發生了什麼以及出於什麼原因。我想說的是，出於相同的目的，它為您提供了您的域的故事。時間旅行的悖論在於，當您回到“現在的時間”時，您會扭曲改變過去事件並遇到無法預料的後果。我聲稱這就是在面向狀態的系統世界中發生的事情。
我們更改“現在”，希望我們將其糾正為應有的狀態，而忽略之前發生的事情。可以肯定的是，我們相信大多數時候我們都會“糾正”系統狀態，但是它與欺騙財務數字，試圖將債務調整為利潤有何不同？我們卻不知道系統是如何到達這種糾正後狀態的，我們認為這是不正確的，
不同於基於事實溯源的分類帳系統，但是您可以進行有針對性的糾正措施，也稱為補償措施，也可以記錄下來，並可以用作糾正措施的證據。我們可能會爭辯說它更復雜，但是與更改表中的資料相比呢？後者不會留下任何此類入侵的痕跡。
通常，當我選擇了錯誤的模型並使用基於狀態的永續性時，我發現自己處在這種情況下，因為它很“容易”：我不需要記錄事件，而是不斷更改系統狀態。

5. 資料庫CRUD與DDD
使用微服務構建分散式系統並保持CRUD模型？我簡直不敢相信它真的可以工作。檢視以下一些影片以瞭解更多資訊：


微服務之間討論事件驅動通訊與RPC呼叫的這種想象中的複雜性的全部原因可能是由於服務邊界不正確導致的，而錯誤的服務邊界又導致了過多的跨服務通訊以及它們之間的迴圈依賴性，從而導致高度耦合的分散式沒有一個元件真正具有凝聚力的系統。
實際上，DDD和事件源是正交的。確實，格雷格·楊（Greg Young）積極地倡導這兩者，只是因為這很有意義。DDD與微服務無關，也與架構無關。它與瞭解軟體的領域，業務和使用者有關。這些都是任何軟體質量的基本方面，除非您要構建Hello World應用程式。
熟悉領域會導致目的明確的軟體。我們都處理過這樣的系統，其中的動作是秘密的，一切看起來都像是RDMBS中表的表示。沒有人喜歡這種軟體。我們喜歡漂亮的現代應用程式：其中所有內容是結構化的且具有針對性，都能快速有效地完成我們想要的事情。我很難想象，如果沒有對領域的正確理解，開發人員團隊能構建出任何接近該目標的東西？

6. Apache Kafka似乎非常適合事件源
不，它沒有，僅僅是因為它沒有事件流的概念，而是處理主題和分割槽。(banq注：作者可能不瞭解Kafka, Kafka Stream是一種事件流)
請檢視JesperHammarbäck 的Apache Kafka不是有關事件源的文章，以瞭解更多資訊。
諸如EventStoreDB之類的專用構建軟體可能是從一開始就做好事情並在以後解決規模問題時的選擇。


 

相關文章