分層API架構中的狀態複製（事件源）
本質上，狀態複製模式是用來解決狀態隔離模式產生的問題；具體來說，狀態複製模式跟狀態隔離模式一樣，也需要數據的一致性。舉個簡單的例子，假設有一個包含目錄、價格和貨幣三個模塊的微服務架構，如果該架構中的每一個模塊都包含各自事件的隔離狀態，那目錄、價格和貨幣就會變得相互依賴。這也就意味着，架構中目錄、價格和貨幣的任何一個出現故障或者更改，都會導致另一個功能的失敗。
上面所講的模塊間相互依賴的問題是可以通過複製狀態來解決的；換句話說，提供一個單獨的位置來存儲所有狀態變化，每個獨立的微服務都可以根據這些變化來重建其內部狀態。通常情況下，狀態複製與事件源的代碼共存，基於事件驅動的微服務僅通過一個不可變的事件日誌進行通信——這提供了一個獨立且單一的狀態數據源，數據一致但難以查詢，因此完成了事件日誌的 “物化視圖”工作。
狀態複製模式的設計，本質上是爲了實現最終一致性。雖然在傳統的事務設計中，最終一致性似乎是一個問題，但是通過深入瞭解設計的本質是可以改進這個問題的。比如，人們可能認爲銀行賬戶的借記是固有的交易，但大多數現代銀行已經意識到，與其花費精力確保每一筆交易都是一致的，還不如創建一個最終一致的借記（如果賬戶存在則借記，然後確保產生資金不可用的可能時的正確性）。這代表了對IT系統的一種新的思考方式，但它能夠帶來更大的靈活度和更改速度，從而加快價值實現的速度。
當然，狀態複製模式具有一定的挑戰性。它需要對其管理的狀態以及每個微服務的行爲有深入的瞭解，以便能夠預測。然而，狀態複製模式也直接解決了在其他模式中產生的問題，因此，這種模式可以看作是一個非常具體的權衡。這種模式能夠帶來最終一致性（而不是直接的）、自上而下設計的內聚性和可預測的更改速度。
問題：
當存在多個狀態數據源時，很難實現數據的完整性。
解決方案：
對數據的所有更改保持單一的數據源，並根據需要複製數據。
應用：
1.將所有的狀態更改作爲事件發送到永久事件日誌。當需要查詢數據時，通過計算事件日誌中的所有更改來構建物化視圖。
2.通常，事件日誌的計算是通過沿着視圖創建快照來簡化的，這樣就不需要每次都進行完整的重新計算。
影響：
1.狀態複製模式具備強內聚性。
2.由於設計中固有的命令-查詢請求分離原則，複製狀態模式具有很強的可伸縮性。
3.狀態複製模式很難可視化和理解其邏輯依賴性（物理依賴性已明顯減少）。
目標：
1.內聚性：由於其標準化的特性，複製狀態模式的架構非常容易使用和理解。
2.可伸縮性：具有很強的可伸縮性。
3.更改速度：非常快速。
主要特點：
1.異步通信機制將帶來高效的IPC（Inter-Process Communication，進程間通信）。
2.這種模式的設計非常靈活，所以具有非常快速的更改速度。
3.數據的一致性很好，但是有一個單一的真實源（通常是事件日誌）。
4.很強的可伸縮性；這種模式的設計優先考慮獨立擴展每個部件的能力。
5.自主性非常高，但同時帶來了非常複雜的設計。
複製狀態模式如何與現有系統、SOA或API共存？
與狀態隔離模式不同，狀態複製模式只需要一個關鍵的更改，就可以很好地與現有的IT系統共存：這種模式中的事件日誌必須成爲它所包含的任何內容的唯一真實源。這意味着，只要現有的IT系統和API在更新事件日誌的同時並從中更新，它們就可以繼續使用。
狀態複製模式還可以以一種“扼殺”的方式來使用：通過將事件逐個遷移到這種模式，爲服務獲得更改速度和高伸縮能力。如果你願意的話，這將用一個穩定的方式逐步替換現有的實現，並與現有的IT系統保持同步。
未經同意，本文禁止轉載或摘編。