如何為微服務選擇數(shù)據(jù)庫

作者：Jeff Carpenter, InfoWorld

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

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

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

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

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

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

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

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

混合持久化（Polyglot persistence）

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

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

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

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

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

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

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

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

也有可能的是，我們可以設計一個服務，這個服務需要多種數(shù)據(jù)庫支撐。例如，我們可以創(chuàng)建一個使用鍵值存儲模式作為索引的酒店服務，在酒店名稱和ID之間實現(xiàn)映射，而存將關于酒店的描述性數(shù)據(jù)存儲在Cassandra中。

注意，名稱映射到ID可以在Cassandra中采用規(guī)范化的設計方法去實現(xiàn)，其中一個單獨表去維護名稱至ID的映射關系。這使用了更多的存儲空間，但降低了管理單獨鍵值存儲的操作復雜性。

這是我推薦的做法-?針對某個微服務，只要可行，就應該堅持使用單一數(shù)據(jù)模型（數(shù)據(jù)庫）。如果你發(fā)現(xiàn)一種情況，認為單個服務需要兩個不同數(shù)據(jù)庫支撐，那么請考慮該服務的粒度是否可能變得太大。你可能需要考慮將該服務拆分為較小的服務。

混合持久化局限性的權(quán)衡

混合持久化的主要缺點在于支持多種技術的成本，無論是在最初的開發(fā)階段和將來的運營方面。

主要的開發(fā)成本，是在需要培訓每個開發(fā)人員去掌握每個新的數(shù)據(jù)庫技術。這是非常重要的，尤其是在開發(fā)人員頻繁流動團隊中。

另一個成本是支持多個數(shù)據(jù)庫的操作成本。這會成為一個問題，尤其是當數(shù)據(jù)庫是集中管理，并且團隊必須在多種技術的掌握上維持高水平，但這在DevOps環(huán)境下，該問題并不會太突出，因為開發(fā)團隊需要支持他們在生產(chǎn)環(huán)境中選擇的數(shù)據(jù)庫。

多模型數(shù)據(jù)庫(Multi Model Databases)

作為另外的選擇方案或混合持久化模式的補充， 數(shù)據(jù)庫廠商已經(jīng)開始建立和推廣多模型的數(shù)據(jù)庫。術語“模型”指的是數(shù)據(jù)存儲所提供的核心抽象，如表（關系和非關系）、列存儲、鍵值、文檔或圖。我們可以將一個多模型應用程序看作一個使用多個數(shù)據(jù)存儲類型的應用程序，而多模型數(shù)據(jù)庫是支持多個抽象模型的數(shù)據(jù)庫。

DataStax企業(yè)版（DSE）是多模型數(shù)據(jù)庫的典型例子，它核心支持Cassandra的分區(qū)行存儲（表格）模型，同時也支持基于在其之上的圖的抽象層（DSE圖）。DSE在核心模型之上構(gòu)建對應的鍵值和文檔模型也是很簡單的，如下圖所示。這樣，我們可以修改上面的混合持久化的方法，從而利用一個基礎數(shù)據(jù)庫引擎為我們所有的服務提供對應的服務，而使用單獨的Cassandra keyspaces在不同服務擁有的數(shù)據(jù)間維護清晰的邊界。

下面是它能實現(xiàn)的功能：
[list]

Cassandra，例如：
代碼

多模型數(shù)據(jù)庫的優(yōu)點和限制

在考慮是否投資使用多模型數(shù)據(jù)庫（或你已經(jīng)在使用的數(shù)據(jù)庫的多模型的特性）時，你要考慮我們前文討論的關于混合持久化中，同樣的開發(fā)和運營成本的問題。

使用多模型數(shù)據(jù)庫可以讓運營變得簡單。即使不同的開發(fā)團隊使用不同的API和不同的交互模式和后端數(shù)據(jù)庫平臺打交道，我們也只需要管理一個平臺而已，從而提高了效率。

在選擇多模型數(shù)據(jù)庫時要考慮的一個問題是如何支持各種模型。一種常見的方法，是基于單一的原生的基礎模型的數(shù)據(jù)庫引擎，而其他模型都是構(gòu)建在其之上。分層數(shù)據(jù)模型更能展現(xiàn)底層基本模型的特性。

例如，ThoughtWorks技術雷達第16期中，討論了基于Cassandra構(gòu)建的DSE圖數(shù)據(jù)庫的特性，并且也提到其中需要權(quán)衡的內(nèi)容：

引用

基于Cassandra 構(gòu)建的DSE圖數(shù)據(jù)庫定位是大規(guī)模的數(shù)據(jù)集，相比之下我們長期喜愛的Neo4j開始表現(xiàn)出一定的局限性。這是需要取舍的；比如，你會失去了ACID的事務特性和Neo4j運行時的模式自由的特性，但卻可以訪問Cassandra的基礎表，以及針對分析工作負載和Spark的整合，還有強大的TinkerPop/Gremlin查詢語言可以使用，這的確是一個值得考慮的選擇。
如果考慮Web應用中的各種數(shù)據(jù)類型，你可能會發(fā)現(xiàn)不同的數(shù)據(jù)類型對一致性有不同的需求，而且實際需要立即一致性的數(shù)據(jù)類型數(shù)量相對較少。

上面引用的ThoughtWorks的觀點中，還提到了在考慮多模型數(shù)據(jù)庫中另一個重要的因素?-?在不同的模型和數(shù)據(jù)引擎間的整合和交互問題，以及為訪問數(shù)據(jù)的各種操作和分析的用例。DSE支持通過Spark(DSE分析)訪問圖數(shù)據(jù)以進行數(shù)據(jù)分析，并且DSE搜索引擎提供了針對DSE數(shù)據(jù)庫中的數(shù)據(jù)創(chuàng)建各種查詢索引的能力。

微服務數(shù)據(jù)模型操作的四個步驟

既然我們已經(jīng)探討混合持久化和多模型兩種方式的優(yōu)缺點，我們應該如何去決定哪些數(shù)據(jù)模型適用于大規(guī)?？蓴U展的微服務應用呢？可以按照以下步驟：

我希望本文為讀者提供了一個有用的框架，來考慮在應用程序中如何和怎么樣去支持多數(shù)據(jù)模型，以及何時考慮使用多模型數(shù)據(jù)庫。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。