在大多數(shù)具有簡單查詢的單體系統(tǒng)中，所有必要的數(shù)據(jù)可以在單個數(shù)據(jù)庫調(diào)用中檢索。然而，當數(shù)據(jù)分散到由不同服務擁有的單獨的數(shù)據(jù)庫或模式中時，讀操作的數(shù)據(jù)訪問開始變得困難。

示例

愿望單服務維護客戶可能希望最終購買的項目列表，并包括客戶ID、項目ID和項目添加日期在相應的愿望單表中。目錄服務負責維護公司銷售的所有項目，并包括項目ID、項目描述和靜態(tài)產(chǎn)品維度信息，如重量、高度、長度等。

在這個示例中，當客戶請求顯示他們的愿望單時，項目ID和項目描述（item_desc）都會返回給客戶。然而，愿望單服務的表中沒有項目描述；該數(shù)據(jù)由目錄服務擁有，在提供更改控制和數(shù)據(jù)所有權的緊密形成的有界上下文中。

服務間通信模式

服務間通信模式是分布式系統(tǒng)中最常見的用于訪問數(shù)據(jù)的模式。如果一個服務（或系統(tǒng)）需要讀取它無法直接訪問的數(shù)據(jù)，它只需通過某種遠程訪問協(xié)議向擁有該數(shù)據(jù)的服務或系統(tǒng)請求數(shù)據(jù)。

請注意，對于每個獲取客戶愿望單的請求，愿望單服務必須進行遠程調(diào)用以從目錄服務獲取項目描述。這種模式出現(xiàn)的第一個問題是由于網(wǎng)絡延遲、安全延遲和數(shù)據(jù)延遲而導致的性能較慢。

• 網(wǎng)絡延遲是到達和從服務的分組傳輸時間。
• 安全延遲發(fā)生在需要額外授權才能執(zhí)行請求的目標服務的端點。
• 數(shù)據(jù)延遲描述了需要進行多次數(shù)據(jù)庫調(diào)用以檢索傳遞給最終用戶所需信息的情況。

這種模式的另一個重要缺點是服務耦合。因為愿望單必須依賴于目錄服務是否可用，所以這兩個服務在語義上和靜態(tài)上都是耦合的，這意味著如果目錄服務不可用，愿望單服務也不可用。此外，由于愿望單服務與目錄服務之間的緊密靜態(tài)耦合，愿望單服務隨著需求量的增加而擴展，目錄服務也必須擴展。

列模式復制模式

使用列模式復制模式，列被復制到表格中，從而復制數(shù)據(jù)并使其可用于其他有界上下文。

數(shù)據(jù)同步和數(shù)據(jù)一致性是與列模式復制數(shù)據(jù)訪問模式相關的兩個最大問題。每當創(chuàng)建產(chǎn)品、從目錄中刪除產(chǎn)品或更改產(chǎn)品描述時，目錄服務必須以某種方式通知愿望單服務（和任何其他復制數(shù)據(jù)的服務）進行更改。通常，通過使用隊列、主題或事件流進行異步通信來完成這一點。

這種模式的另一個挑戰(zhàn)是很難管理數(shù)據(jù)所有權。因為數(shù)據(jù)復制在屬于其他服務的表格中，這些服務可以更新數(shù)據(jù)，即使它們并沒有正式擁有數(shù)據(jù)。這反過來又帶來了更多的數(shù)據(jù)一致性問題。

盡管一般情況下我們警告不要在愿望單服務和目錄服務示例等情況下使用這種數(shù)據(jù)訪問模式，但在某些情況下可能需要考慮使用它，例如數(shù)據(jù)聚合、報告或其他數(shù)據(jù)訪問模式不適合的情況，因為數(shù)據(jù)量大，響應要求高或容錯要求高。

復制緩存模式

這種模式利用復制的內(nèi)存緩存，使其他服務所需的數(shù)據(jù)可用于每個服務，而無需請求它們。復制緩存與其他緩存模型不同，因為數(shù)據(jù)保留在每個服務的內(nèi)存中，并持續(xù)同步，以便所有服務在任何時候都具有相同的數(shù)據(jù)。

讓我們與其他緩存模型進行比較，以更好地理解它。單個內(nèi)存緩存模型是最簡單的緩存形式，其中每個服務都有自己的內(nèi)部內(nèi)存緩存。使用這種緩存模型，內(nèi)存數(shù)據(jù)在緩存之間不進行同步，這意味著每個服務都有其自己的特定于該服務的唯一數(shù)據(jù)。盡管這種緩存模型有助于提高每個服務內(nèi)部的響應性和可伸縮性，但由于缺乏緩存之間的同步，對于共享數(shù)據(jù)而言并不有用。

在分布式架構(gòu)中使用的另一種分布式緩存。正如此緩存模型所示，數(shù)據(jù)不存儲。

在每個服務的內(nèi)存中，而是存儲在緩存服務器中。服務使用專有協(xié)議向緩存服務器發(fā)出請求以檢索或更新共享數(shù)據(jù)。請注意，與單個內(nèi)存緩存模型不同，數(shù)據(jù)可以在服務之間共享。

使用復制緩存，每個服務都有自己的內(nèi)存數(shù)據(jù)，在服務之間保持同步，允許多個服務之間共享相同的數(shù)據(jù)。

那么復制緩存是如何工作的呢？為了解決分布式數(shù)據(jù)訪問問題，讓我們回到愿望單服務和目錄服務的示例。目錄服務擁有產(chǎn)品描述的內(nèi)存緩存（這意味著它是唯一可以修改緩存的服務），愿望單服務包含相同緩存的只讀內(nèi)存副本。

有了這種模式，愿望單服務不再需要調(diào)用目錄服務以檢索產(chǎn)品描述 — 它們已經(jīng)在愿望單服務的內(nèi)存中。當目錄服務對產(chǎn)品描述進行更新時，緩存產(chǎn)品將更新愿望單服務中的緩存以使數(shù)據(jù)一致。

復制緩存模式的明顯優(yōu)勢在于響應性、容錯性和可伸縮性。由于服務之間不需要明確的服務間通信，數(shù)據(jù)隨時在內(nèi)存中可用，提供了對不擁有數(shù)據(jù)的服務最快的數(shù)據(jù)訪問。

這種模式的第一個權衡是與緩存數(shù)據(jù)和啟動時間相關的服務依賴性。由于目錄服務擁有緩存并負責填充緩存，所以在初始愿望單服務啟動時，目錄服務必須在運行時。如果目錄服務不可用，初始愿望單服務必須進入等待狀態(tài)，直到與目錄服務建立連接。

這種模式的第二個權衡是數(shù)據(jù)量。如果數(shù)據(jù)量太大（如超過500 MB），則這種模式的可行性會迅速減小，特別是對于需要數(shù)據(jù)的多個服務的多個實例。

第三個權衡是，如果數(shù)據(jù)的更改率（更新率）太高，復制緩存模型通常不能在服務之間保持數(shù)據(jù)完全同步。

總結(jié)

• 服務間通信模式：這是最常見的分布式系統(tǒng)中的數(shù)據(jù)訪問模式，其中一個服務需要讀取其他服務擁有的數(shù)據(jù)時，通過遠程訪問協(xié)議向擁有數(shù)據(jù)的服務請求數(shù)據(jù)。然而，這種模式存在性能較慢、服務耦合等問題。
• 列模式復制模式：這個模式涉及將數(shù)據(jù)列復制到不同的表中，以使數(shù)據(jù)可用于其他有界上下文。但它面臨數(shù)據(jù)同步和數(shù)據(jù)一致性的挑戰(zhàn)，因為數(shù)據(jù)的更改需要異步通信來通知其他服務，這可能導致數(shù)據(jù)一致性問題。
• 復制緩存模式：這種模式利用內(nèi)存緩存，使多個服務能夠共享相同的數(shù)據(jù)，而無需顯式請求。這提供了高響應性、容錯性和可伸縮性，但也帶來了服務依賴性和數(shù)據(jù)量等權衡問題。

每種模式都有其適用的場景和權衡，選擇合適的數(shù)據(jù)訪問模式取決于具體的需求和約束。