如何為您的微服務選擇混合和多模型數(shù)據(jù)庫

作者：Jeff Carpenter

近十年來，大規(guī)模分布式系統(tǒng)得到了爆炸式增長，已經產生了一股可以說是對整個軟件業(yè)開先河式的，數(shù)據(jù)庫界的創(chuàng)意旋風。市場上也涌現(xiàn)了大量的頗具競爭力的數(shù)據(jù)庫平臺。

在本文中，我們將探討如何為您的應用去選擇合適的數(shù)據(jù)庫模型（是的，完全可以選擇不止一個?。?。我們也會討論到這些數(shù)據(jù)模型的選擇將如何幫助您去確定數(shù)據(jù)層面的各種技術。

一、云架構，NoSQL和微服務

在軟件開發(fā)人員開始創(chuàng)建Web架構的應用時，那些在歷史上一直主導著我們多年的關系型數(shù)據(jù)庫架構，已經開始表現(xiàn)出“壓力山大”了。特別是在我們開發(fā)那些被頻繁使用的社交應用，和將越來越多的設備連接到物聯(lián)網(wǎng)（IOT）的時候，客戶端大量地讀取和寫入數(shù)據(jù)導致了數(shù)據(jù)層面的擴展需求。而與此同時，為了滿足這些高擴展性的需求，新的數(shù)據(jù)庫類型隨之出現(xiàn)。

在許多情況下，這些新的數(shù)據(jù)庫是“非結構化查詢語言（NoSQL）”或“非關系型”的數(shù)據(jù)模型解決方案。它們并非顯性的關系模型，如文檔、鍵-值、面向整列的、甚至是圖表數(shù)據(jù)庫。通常，這些數(shù)據(jù)庫犧牲了一些在傳統(tǒng)關系型數(shù)據(jù)庫上為我們所熟悉的特性，如：強一致性、ACID事務和各種連接（joins）。

同時，作為革命性的數(shù)據(jù)庫技術，SOA（面向服務的架構）已經日趨向微服務架構的風格進行發(fā)展，許多組織開始摒棄諸如企業(yè)服務總線（ESB）的重量級SOA架構，而改用更為分散的實現(xiàn)方法。微服務架構的吸引力在于其獨立的開發(fā)、管理和擴展各種服務的能力。這使得我們在考慮數(shù)據(jù)庫架構實現(xiàn)等方面的技術上，具有大量的實施選擇靈活性。

舉例而言，假設我們根據(jù)一項大規(guī)模可擴展性的需求，正在從事一個重要的微服務架構的開發(fā)。那么，無論該項目是一項新的應用，還是對現(xiàn)有應用的重構，我們都有機會來選擇新的數(shù)據(jù)庫。

1.混合持久化（Polyglot persistence）

微服務模式的一項優(yōu)勢是封裝的持久性，我們可以自由地根據(jù)每個服務的需求來選擇不同的持久化技術。Martin Fowler等人提出的混合持久化這一術語，特指根據(jù)不同的數(shù)據(jù)類型來選擇數(shù)據(jù)存儲的方法，可以說混合持久化天生就十分契合微服務。

下面的例圖顯示了一組微服務，我們該如何為每一項服務來選擇使用不同的數(shù)據(jù)模型呢？在此，我不一一列舉每種數(shù)據(jù)庫類型的適當用例，只會突出這些數(shù)據(jù)庫類型和混合方法的優(yōu)勢所在。

將混合持久化應用到微服務上。

開發(fā)服務A的小組可能會選擇使用表格型數(shù)據(jù)庫（tabular database），如Apache Cassandra，因為它能大規(guī)模地管理核心應用的數(shù)據(jù)。例如，零售應用的庫存類數(shù)據(jù)可能就非常適合于Cassandra的表格形式。Cassandra提供了一套協(xié)調機制的工具集，包括能夠批量調整一致性，和作為全面ACID事務替代品的輕量級事務等。

服務B可能只需要支持通過well-known鍵來查詢參考值，這樣簡單的語義，比如說一個產品編錄的描述性數(shù)據(jù)。這是一個很好的鍵-值（key-value）存儲的案例，我們可以通過產品ID的well-known鍵-值來查找一個BLOB（二進制對象文件的容器）類型的數(shù)據(jù)。那么大量的內存空間會被用來緩存鍵-值類型的數(shù)據(jù)，從而支持大規(guī)模、且超快速地讀取訪問。

服務C主要考慮的是提供半結構化的內容，例如：網(wǎng)站的網(wǎng)頁或表格，以及文檔存儲，這些類型的數(shù)據(jù)都是非常適合的。文檔的存儲有“許多鍵-值類型相似，僅有某個鍵不同”的數(shù)據(jù)結構，例如只要索引某些特殊屬性項，便可加快各種搜索的能力。

服務D則涉及到導航各種數(shù)據(jù)間的復雜關系，例如：客戶數(shù)據(jù)與組織內不同部門的客戶聯(lián)系人之間的歷史數(shù)據(jù)。這可能潛在地涉及到：各種不同服務所擁有的數(shù)據(jù)類型之間的各種關系。比如說在這種情況下，您可以選擇讓您的服務創(chuàng)建一個對于各種底層表格都是只讀的視圖，然后通過調用其他“擁有著”自身數(shù)據(jù)類型的服務API這樣的“front door”，來過濾實現(xiàn)任何預期的轉換。

最后，我們還可能會有一些使用著關系型技術的傳統(tǒng)系統(tǒng)與服務，或者我們有一個管理著少量且不經常更改的數(shù)據(jù)服務。那么關系型數(shù)據(jù)庫對于此類用例就是再好不過的了。

2.單獨的服務需要混合嗎？

也有一種可能：我們設計出一個放置在多數(shù)據(jù)庫之上的服務。例如說，我們可以創(chuàng)建一個使用的鍵-值存儲索引的酒店服務，它映射名稱和ID之間的關系。同時它用Cassandra的表格樣式來存儲關于酒店的描述性數(shù)據(jù)。

一個混合服務？

注意：使用非規(guī)范化的設計方法，同樣可以在Cassandra中實現(xiàn)名稱與ID的映射，當然您需要用一張單獨的表格來維持名稱與ID的映射。這樣雖然會用到更多的存儲空間，但是簡化了我們在管理一個單獨的鍵-值存儲操作上的復雜性。

所以我的建議是：只要可行，完全可以把一個給定的微服務與一個單一的數(shù)據(jù)模型（和數(shù)據(jù)庫）相連接。如果您碰到需要將單一的服務放置在兩個不同的數(shù)據(jù)庫之上的情況，請判斷該服務的范圍是否過大。如果太大，您可能就需要考慮將其拆分成多個更小的服務了。

3.混合持久化的限制與利弊

混合持久化的主要劣勢是：在最初化開發(fā)和運營方面，需要支持多種技術的成本。

開發(fā)的成本主要來自于培訓各個開發(fā)人員熟悉每種新的數(shù)據(jù)庫技術的成本。如果您的開發(fā)團隊流動性較大的話，這種劣勢會更加明顯。

而另一個弊端是支持多個數(shù)據(jù)庫的運營成本。如果數(shù)據(jù)庫的管理是集中化的，并且整體團隊必須對多種技術保持較高的維護水平時，這就可能會出現(xiàn)問題。但是當開發(fā)團隊僅支持他們已選定的生產環(huán)境所用到的數(shù)據(jù)庫，從而形成了真正的Devops運作模式時，該問題會得到適當?shù)木徑狻?/p>

4.多模型數(shù)據(jù)庫

數(shù)據(jù)庫提供商已經開始著手打造與提升一些多模型的數(shù)據(jù)庫，作為混合持久化方法的一種替代或補充了。術語“模型”是指由諸如表格（包括關系和非關系型）、列存儲、鍵-值、文檔或圖表之類的數(shù)據(jù)存儲所提供的抽象模型。我們可以理解為：多模型應用使用的是一種類型以上的數(shù)據(jù)存儲，而多模型數(shù)據(jù)庫則能夠支持多種抽象。

DataStax Enterprise（DSE）是一個多模型數(shù)據(jù)庫的例子，其核心使用一種建立在頂端圖表的抽象（DSE圖表），來支持Cassandra分區(qū)的行存儲（表格）模式。如下圖所示，在此核心模型上創(chuàng)建您自己的鍵-值和各種文檔類型的抽象是非常簡單的。通過這種方式，我們可以修改上述的混合方法，利用單一的底層數(shù)據(jù)庫引擎來提供我們的所有服務。與此同時，我們還可以使用單獨的Cassandra鍵值空間，來維持那些由不同服務所擁有的數(shù)據(jù)之間的清晰界限。

與DataStax Enterprise交互，作為一個多模型的數(shù)據(jù)庫。

我們下面來看看它是如何工作的：

表格：服務A之類的主要應用服務可以使用Cassandra的查詢語言（CQL），來與DSE數(shù)據(jù)庫直接進行交互。

鍵-值：雖然Apache和DataStax的Cassandra版本都無法提供一個明確的鍵-值API，但是像服務B之類的服務卻能夠通過設計來限制表格只與Cassandra互動實現(xiàn)鍵-值的存儲。例如：

CREATE?TABLE?hotel.hotels?(?key?uuid?PRIMARY?KEY,?value?text);?//?or?if?you?prefer,?“blob”

文件：通過各種JSON文件，Cassandra能夠支持文檔類型的交互，這可以被用于服務C之類的服務。注意：因為Cassandra的確需要有表的schema模式，因此您不能插入任意的JSON來隨便定義新的列，也就是說通常需要具有與文檔數(shù)據(jù)庫相關聯(lián)的特性。

圖表：對于像服務D之類高度支持數(shù)據(jù)互連的服務來說，DSE圖表是一個高度可擴展的圖表數(shù)據(jù)庫，它直接建立在DSE數(shù)據(jù)庫之上。DSE圖表通過Apache TinkerPop 項目來支持強大的、且易于表現(xiàn)的Gremlin API。

5.多模型數(shù)據(jù)庫的優(yōu)勢和局限性

在考慮是否要使用多模型數(shù)據(jù)庫的時候（或使用你已有數(shù)據(jù)庫的多模型功能時），你需要兼顧考慮我們上述所討論的有關混合持久化方法所帶來的開發(fā)和運營成本。

使用多模型數(shù)據(jù)庫可以簡化運營。無論是不同的開發(fā)團隊使用不同的API，還是不同的后端數(shù)據(jù)庫平臺交互模式，我們都會從只需要管理單一的平臺來受益。

在選擇多模型數(shù)據(jù)庫時，需要考慮的一個方面就是：各種模型如何能夠被支持。一種常用的處理方式是：一個基于單一本地的底層模型與其上面分層的其他模型共同組成一個數(shù)據(jù)庫引擎。分層的數(shù)據(jù)模型用于展示其底層主模型的各種特征。

例如，在ThoughtWorks的技術雷達第16卷（Technology Radar Vol. 16）（https://assets.thoughtworks.com/assets/technology-radar-vol-16-en.pdf）中，就討論展示了在Cassandra頂端分層的DSE圖表模型的特性和所涉及的取舍：

我們所長期鐘愛和使用的Neo4j（譯者注：Neo4j是一種高性能的NOSQL類型圖表數(shù)據(jù)庫，它將結構化數(shù)據(jù)存儲在網(wǎng)絡中而不是本地表里。）已經在大型的數(shù)據(jù)集類型中逐漸顯露出了局限性，而建立在Cassandra頂端的DSE圖表則應運而生。

當然，這種模式也有其自己的取舍，例如：您會失去ACID事務和Neo4j的獨立于架構運行（run-time schema-free）特性；但是DSE通過訪問底層的Cassandra各種表格，Spark對分析負載的集成，以及強大的TinkerPop/Gremlin查詢語言，都使得它還是很值得考慮和選擇的。

如果您在自己的Web架構應用中考慮使用不同的數(shù)據(jù)類型，那么您可能就會發(fā)現(xiàn)到：不同的數(shù)據(jù)類型有著不同的一致性需求，而實際需要立即進行一致化的數(shù)據(jù)類型并不多。

另一個需要重點考慮的是：多模型的空間問題，即不同數(shù)據(jù)庫模型和引發(fā)的集成與交互，以及訪問數(shù)據(jù)的各種操作和分析用例。DSE支持通過Spark（DSE分析）來訪問圖表數(shù)據(jù)以實現(xiàn)其分析的目的，而DSE搜索則提供了用于創(chuàng)建那些存儲在DSE數(shù)據(jù)庫中數(shù)據(jù)的各種搜索索引的能力。

二、微服務數(shù)據(jù)模型的四步驟

既然我們已經了解了混合與多模型方法的各類優(yōu)點，那么我們應該如何為大規(guī)模的微服務應用來選定數(shù)據(jù)模型呢？請參考下列的步驟：

我希望上述內容能夠為您在思考如何為自己的應用程序提供多模型支持，以及何時、何處用到多模型數(shù)據(jù)庫的時候提供一個實用的框架。

生成海報

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