分層API架構中隔離狀態
除了合併微服務架構的數據交換模式(例如，合併爲事件)之外，還有一種獲得一致性的方法是合併每個微服務的內部一致性。相比較於期望通過數據交換獲得一致性，不如期望查詢時數據的一致性。
通常，這是通過隔離狀態來實現的，換句話說，“每個微服務都包含它自己的狀態”。在這種隔離狀態模式中，每個微服務都包含一個內部數據存儲，它不斷地與外部存儲（無論是事件日誌還是企業資產）進行協調，使內部存儲成爲“單一真實源”。實際上，這可能是很困難的，因爲單一真實源的模式往往反映了主數據管理的複雜性及其相關挑戰。
相比而言，使用外部存儲作爲微服務的單一真實源要實際得多，因爲給定微服務通常具有單一用途的特性。例如，隔離客戶的狀態很困難，但是隔離客戶電子郵箱地址的狀態並不困難。因此，隔離狀態模式必須支持非常細粒度的微服務才能成功。並且，隔離狀態模式往往還需要異步事件傳播，將狀態更改從一個點傳遞到另個一點。隔離狀態模式也可以看作是某種“分佈式數據庫”，對於傳統的RDBMS設計來說，每個微服務幾乎都代表一列數據。
微服務包含一個數據存儲，它是微服務所代表的實體的真實源。例如，“產品”微服務可以包含一個MySQL數據庫，該數據庫包含有關產品的所有信息，並且是查詢或更新“產品”概念的唯一方法。
與接近於SOA的模式不同，重用性在隔離狀態模式設計中並不是優先考慮的問題。當然，該模式中每個微服務都有一個“用途”，並經常在不同的場景中被訪問。但是每個微服務的設計並沒有考慮到重用性。如果發生了重用，那將是偶然的，而不是SOA架構設計附帶的意圖。
問題：
當存在多個真實源時，很難實現數據完整性。
解決方案：
爲每個給定的業務實體指定一個代表單一真實源的微服務，並將狀態封裝在微服務中。
應用：
微服務包含一個數據存儲，它是微服務所代表的實體的真實源。例如，“產品”微服務可以包含一個MySQL數據庫，該數據庫包含有關產品的所有信息，並且是查詢或更新“產品”概念的唯一方法。
影響：
1.爲了確保狀態數據不被複制或其他方式訪問，隔離狀態模式需要某種治理。
2.在處理現有資產（如ERP）時，必須使用“扼殺”模式，用新的微服務架構逐個替換現有系統的數據存儲。
3.隔離狀態模式迴避了數據同步的問題，所以如果數據實體不同步，就無法輕鬆回退。
目標：
1.內聚性：由於其標準化的特性，隔離狀態模式的架構非常容易使用和理解。
2.可伸縮性：隔離狀態模式的架構具有很強的可伸縮性（每個小組件都可以實現自己的伸縮模型）。
3.更改速度：由於架構的強內聚性，隔離狀態模式具有快速的更改速度，但是需要治理來確保該架構不會被破壞。
主要特點：
1.異步通信機制將帶來高效的IPC（Inter-Process Communication，進程間通信）。
2.這種模式的設計非常靈活，所以具有快速的更改速度。
3.這種模式只有單一的真實源，所以數據一致性很好。
4.可伸縮性可能會帶來挑戰，因爲同時需要擴展數據存儲。
5.在規模上，很難將數據模型劃分爲完全獨立的模塊。在某些階段，視圖之間的一致性變得非常重要。
隔離狀態模式如何與現有系統、SOA或API共存？
無法共存。如果您構建一個具有隔離狀態的微服務架構，那麼對於前面講過的目標來說，微服務是“真實數據和功能的來源”是很重要的。如果現有系統也處理相同的數據或功能，您將需要在邊界之外同步它，在這裏實現雙向同步通常是一個糟糕的模式。
隔離狀態模式通常與“扼殺”模式很好地結合在一起，在“扼殺”模式中，您試圖減少對給定企業應用程序或其他系統的使用，因爲這些應用程序或系統沒有給您足夠的時間來評估所需的價值。隨着時間的推移，您將用這些隔離的微服務替換原始系統中的功能，並停用原始系統中的那些特定功能。
換句話說，這不是集成模式。這裏的目標是使用微服務創建一個新的、快速移動的部分實現，這將使您獲得現有系統無法提供的速度和規模優勢。
未經同意，本文禁止轉載或摘編。