在微服務中使用事件溯源的六大原因 - Herath

什麼是事件溯源
事件溯源是一種持久化資料的替代方法。與其他狀態持久化方法（如面向狀態的持久化）相比，事件溯源將所有狀態突變儲存為稱為事件的單獨記錄。例如，當客戶將商品放入線上購買平臺中的購物車時，事件溯源會將購物車中的所有狀態更改儲存為狀態更改事件列表。每當實體的狀態發生變化時，都會將新事件附加到事件列表中。

1. 從領域驅動設計的平滑過渡
在專案的設計階段，開發人員和設計師分析領域並進行事件風暴/事件建模。這裡的目標是從純粹的設計角度來識別專案。但是，對話的一部分是高度面向事件的。因此，努力的結果是開發人員將構建的微服務。因此，命令和事件進入這些不同的微服務。事件溯源進入實施階段。首先，程式碼和系統的資料流是使用事件溯源實現的，因為設計是使用事件思維方式完成的。

2. 減少耦合
假設兩個微服務鬆散耦合的場景。如果在一個微服務中發生設計、實現或行為更改，則不會導致另一次更改。

但是，當涉及到微服務時，可能會發生耦合。例如，如果對微服務進行更改，它將導致所有其他微服務直接或間接與第一個微服務協作。

3. 最佳化讀寫效能瓶頸
想象一個典型的系統，其中包含許多可能是多​​年來構建並由單個資料庫管理的操作。但是，在執行 CRUD 操作時，可以針對讀取和寫入最佳化資料庫。但這始終是一種權衡。如果您針對讀取進行最佳化，則會以寫入為代價。如果您針對寫入進行最佳化，則會帶來昂貴的讀取。因此，存在明顯的、重大的權衡取捨。然而，事件溯源解決了這個問題。在事件溯源方面，它使用隔離永續性。也就是說，我們得到了正在插入事件的事件儲存。所有的 CRUD 操作都變成了儲存和事件。所有這些事件都聚合到開發人員需要執行的當前操作狀態。這裡事件儲存的真正優勢在於使用者的開銷，讀寫操作的瓶頸會減少。

4. 提升併發障礙
在大型企業應用程式中出現流量峰值的可能性更大。這種情況會影響應用程式資料庫，解決它們可能會很痛苦。是的，這些問題可以透過花費三到四個星期來解決。但是，您仍然會遇到資料庫剛剛被推到極限的情況。
這是事件溯源越來越成為一種流行方法的另一個原因。事件溯源透過將峰值中的記錄寫入事件日誌並將其插入事件日誌而不讓讀取端等待來處理此問題。

5. 簡化和強化訊息傳遞
微服務中訊息傳遞的語義可以分為三類。

• In most once — 訊息可能無法送達的情況，在某些情況下您會丟失訊息。在考慮我們構建的微服務時，這不是一個可接受的特性。
• 至少一次——該類別是最容易實現的。在這種情況下，一條訊息至少可以傳遞一次。另一方面，某條訊息可以傳遞兩次以上。
• 恰好一次——一種相當神秘的方法，難以實施，但從消費者的角度來看仍然可行。

在某些情況下，訊息不會第一次傳遞。因此解決方案將實施重試邏輯。當開發人員實現重試邏輯時，他們必須開始考慮像生產者服務試圖釋出資料這樣的情況。它必須能夠處於某些訊息尚未傳遞的模式。此外，服務等案例也會下降。當該服務返回時，它能否從中斷的地方繼續並繼續重試傳送這些訊息？這種情況給生產者帶來了很大的複雜性。

另外，想象一下服務首先執行資料庫事務，然後呼叫 Kafka 的場景。由於這是兩個獨立的事務，首先會發生資料庫事務。但是，Kafka 中的訊息不會透過。所以這是管道洩漏，消費者有潛在的脆弱性。當服務在該暴露期間出現故障時，訊息將丟失。使用事件溯源時，開發人員無需擔心訊息失敗。所以在這裡，訊息不會推送給 Kafka 消費者。Kafka 消費者拉取，並且更容易實現這種拉取模式。

6.消除服務耦合
想象一下我們有客戶服務幫助其他一些服務的情況。如果客戶服務下降，其他服務也會下降。

使用事件溯源時，方法是客戶釋出，其他服務消費。在這種情況下，如果客戶服務出去了，直到它回來才沒有傷害。

結論
微服務架構是後端開發中常用的架構之一。但是，瞭解如何以最佳化和輕鬆的方式使用它至關重要。在這篇文章中，我解釋了為什麼你應該使用事件源和微服務來避免常見的陷阱的 6 個原因。我希望本文能幫助您以更最佳化的方式開發微服務。感謝您的閱讀。