你的微服務(wù)架構(gòu)需要多種數(shù)據(jù)模型。你是應(yīng)該選擇混合持久化呢還是多模型數(shù)據(jù)庫？

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

在本文中，我們將探討如何為根據(jù)應(yīng)用程序去選擇核實(shí)的數(shù)據(jù)庫模式。（是的，可以有一個以上的選擇?。覀円矔纯磳?shù)據(jù)模式的選擇可以幫助確定在數(shù)據(jù)層中將選用哪些技術(shù)。

云架構(gòu)，NoSQL 和微服務(wù)架構(gòu)

隨著開發(fā)人員開始創(chuàng)建可擴(kuò)展的Web應(yīng)用，歷史上在數(shù)據(jù)架構(gòu)上占主導(dǎo)地位的關(guān)系型數(shù)據(jù)庫，開始顯示出很大的壓力。我們開發(fā)了非常流行的社交應(yīng)用，并開始將越來越多的設(shè)備連接到物聯(lián)網(wǎng)（IoT）。用戶大量的讀取和寫入數(shù)據(jù)導(dǎo)致了必須擴(kuò)展數(shù)據(jù)層，從而出現(xiàn)了新型的數(shù)據(jù)庫來滿足這些高可擴(kuò)展性需求。

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

與此同時，和數(shù)據(jù)庫技術(shù)的變革一樣，在本世紀(jì)初的SOA（面向服務(wù)的架構(gòu)），正逐漸演變?yōu)槲⒎?wù)架構(gòu)的體系架構(gòu)，許多企業(yè)也開始逐漸拋棄重量級的SOA體系架構(gòu)如企業(yè)服務(wù)總線（ESB），并傾向使用“去中心化”的架構(gòu)方法。微服務(wù)架構(gòu)的魅力在于其開發(fā)、管理和擴(kuò)展服務(wù)都是相對獨(dú)立的。這給了我們很多在實(shí)施方面的靈活性，包括基礎(chǔ)架構(gòu)技術(shù)，如數(shù)據(jù)庫。

舉個例子，我們假設(shè)正在為微服務(wù)架構(gòu)做開發(fā)工作，并期待著大規(guī)模的可擴(kuò)展性的需求。無論這個項(xiàng)目是一個新的應(yīng)用還是對現(xiàn)有應(yīng)用的重構(gòu)，我們都有機(jī)會針對數(shù)據(jù)庫做出新的選擇。

混合持久化（Polyglot persistence）

微服務(wù)架構(gòu)風(fēng)格的一個關(guān)鍵的好處，是持久性的封裝。我們可以根據(jù)每個服務(wù)的需要，去選擇不同的持久化技術(shù)。根據(jù)每種數(shù)據(jù)類型的特點(diǎn)而去選擇數(shù)據(jù)存儲的方法，被稱為混合持久化，這一術(shù)語起初是由Martin Fowler等人推廣起來的?；旌铣志没臀⒎?wù)架構(gòu)可謂是天作之合。

下圖中，展示了一系列的微服務(wù)，以及我們?nèi)绾螢槊總€服務(wù)選擇不同的數(shù)據(jù)模式。我不想在本文中，為每種類型的數(shù)據(jù)庫去選擇合適的用例。我的意圖是要突出各類型數(shù)據(jù)庫的優(yōu)勢，以及為什么混合持久化的方法是值得稱道的.

其中，開發(fā)服務(wù)A的團(tuán)隊(duì)，因?yàn)樵摲?wù)是基于大規(guī)模數(shù)據(jù)管理的核心應(yīng)用，可能使用如Apache Cassandra這樣的表格模型數(shù)據(jù)庫。例如，一個零售應(yīng)用庫存應(yīng)用，可能很適合使用Apache Cassandra。Cassandra提供了一系列協(xié)調(diào)機(jī)制工具，如可調(diào)一致，批處理和輕量級的事務(wù)機(jī)制，可以作為完整ACID事務(wù)機(jī)制的替代。

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

服務(wù)C可能主要關(guān)注半結(jié)構(gòu)化內(nèi)容，例如Web站點(diǎn)的表單或頁面，而文檔存儲可能非常適合該類型數(shù)據(jù)。文檔存儲與鍵值存儲有許多相似之處，但是一個關(guān)鍵的區(qū)別是文檔型數(shù)據(jù)支持?jǐn)?shù)據(jù)上增加結(jié)構(gòu)，例如對特定屬性進(jìn)行索引以支持快速檢索。

服務(wù)D可能涉及數(shù)據(jù)之間的復(fù)雜關(guān)系導(dǎo)航，例如客戶數(shù)據(jù)和與組織中各部門的客戶聯(lián)系歷史數(shù)據(jù)。這可能涉及其他服務(wù)所擁有的數(shù)據(jù)類型之間的關(guān)系。這是一個有趣的案例，因?yàn)樗_始與上面提到的服務(wù)有各自的數(shù)據(jù)類型的約束相反。在這種情況下，你可以選擇為你的服務(wù)創(chuàng)建一個具有對底層表的只讀訪問的圖，然后通過這個“前門”處理所有的變化——即通過這個“前門”去調(diào)用那些“擁有”這些數(shù)據(jù)類型的其他服務(wù)的API。

最后，我們可能還有一個使用關(guān)系數(shù)據(jù)庫技術(shù)的遺留系統(tǒng)或服務(wù)，或者我們有一個服務(wù)來管理那些數(shù)據(jù)量較少，或者不經(jīng)常變更的數(shù)據(jù)。關(guān)系數(shù)據(jù)庫可能完全適合于這些場景。

單個服務(wù)是否應(yīng)該使用混合持久化？