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

作者：Jeff Carpenter

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

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

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

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

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

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

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

1.混合持久化（Polyglot persistence）

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

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

將混合持久化應(yīng)用到微服務(wù)上。

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

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

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

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

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

2.單獨(dú)的服務(wù)需要混合嗎？

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

一個(gè)混合服務(wù)？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我希望上述內(nèi)容能夠?yàn)槟谒伎既绾螢樽约旱膽?yīng)用程序提供多模型支持，以及何時(shí)、何處用到多模型數(shù)據(jù)庫的時(shí)候提供一個(gè)實(shí)用的框架。

生成海報(bào)

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