你的微服務架構需要多種數據模型。你是應該選擇混合持久化呢還是多模型數據庫？

在過去的十年，大規模的分布式系統呈現爆炸式增長。這一趨勢促使在數據庫領域產生了一股巨大的創造力，這在軟件業的歷史上無疑是沒有先例的。其結果是誕生了一個健康和充滿競爭的數據庫市場，我們可以因此在大量的平臺中各取所需。但是我們應該如何抉擇？

在本文中，我們將探討如何為根據應用程序去選擇核實的數據庫模式。（是的，可以有一個以上的選擇！），我們也會看看對數據模式的選擇可以幫助確定在數據層中將選用哪些技術。

云架構，NoSQL 和微服務架構

隨著開發人員開始創建可擴展的Web應用，歷史上在數據架構上占主導地位的關系型數據庫，開始顯示出很大的壓力。我們開發了非常流行的社交應用，并開始將越來越多的設備連接到物聯網（IoT）。用戶大量的讀取和寫入數據導致了必須擴展數據層，從而出現了新型的數據庫來滿足這些高可擴展性需求。

在許多情況下，這些新的數據庫“NoSQL”或“非關系”的解決方案，所基于的數據模型和傳統的關系數據庫模型不同。NoSQL數據庫包括有文檔型、鍵值對型（key-value）、列式數據庫甚至圖數據庫。通常來說，這些數據庫犧牲了一些關系數據庫的常見的的特性，如強一致性、ACID事務特性和join連接。

與此同時，和數據庫技術的變革一樣，在本世紀初的SOA（面向服務的架構），正逐漸演變為微服務架構的體系架構，許多企業也開始逐漸拋棄重量級的SOA體系架構如企業服務總線（ESB），并傾向使用“去中心化”的架構方法。微服務架構的魅力在于其開發、管理和擴展服務都是相對獨立的。這給了我們很多在實施方面的靈活性，包括基礎架構技術，如數據庫。

舉個例子，我們假設正在為微服務架構做開發工作，并期待著大規模的可擴展性的需求。無論這個項目是一個新的應用還是對現有應用的重構，我們都有機會針對數據庫做出新的選擇。

混合持久化（Polyglot persistence）

微服務架構風格的一個關鍵的好處，是持久性的封裝。我們可以根據每個服務的需要，去選擇不同的持久化技術。根據每種數據類型的特點而去選擇數據存儲的方法，被稱為混合持久化，這一術語起初是由Martin Fowler等人推廣起來的。混合持久化和微服務架構可謂是天作之合。

下圖中，展示了一系列的微服務，以及我們如何為每個服務選擇不同的數據模式。我不想在本文中，為每種類型的數據庫去選擇合適的用例。我的意圖是要突出各類型數據庫的優勢，以及為什么混合持久化的方法是值得稱道的.

其中，開發服務A的團隊，因為該服務是基于大規模數據管理的核心應用，可能使用如Apache Cassandra這樣的表格模型數據庫。例如，一個零售應用庫存應用，可能很適合使用Apache Cassandra。Cassandra提供了一系列協調機制工具，如可調一致，批處理和輕量級的事務機制，可以作為完整ACID事務機制的替代。

服務B支持用眾所周知的關鍵字查找值的方式，例如針對產品目錄的描述性數據。對于鍵值存儲模型來說，這是一個很好的例子，在這里，我們通過一個眾所周知的鍵值（如產品ID）查找一系列的數據。很多內存緩存都使用鍵值對數據模式去支持大規模的快速讀取。

服務C可能主要關注半結構化內容，例如Web站點的表單或頁面，而文檔存儲可能非常適合該類型數據。文檔存儲與鍵值存儲有許多相似之處，但是一個關鍵的區別是文檔型數據支持數據上增加結構，例如對特定屬性進行索引以支持快速檢索。

服務D可能涉及數據之間的復雜關系導航，例如客戶數據和與組織中各部門的客戶聯系歷史數據。這可能涉及其他服務所擁有的數據類型之間的關系。這是一個有趣的案例，因為它開始與上面提到的服務有各自的數據類型的約束相反。在這種情況下，你可以選擇為你的服務創建一個具有對底層表的只讀訪問的圖，然后通過這個“前門”處理所有的變化——即通過這個“前門”去調用那些“擁有”這些數據類型的其他服務的API。

最后，我們可能還有一個使用關系數據庫技術的遺留系統或服務，或者我們有一個服務來管理那些數據量較少，或者不經常變更的數據。關系數據庫可能完全適合于這些場景。

單個服務是否應該使用混合持久化？