如何為您的微服務選擇混合和多模型數據庫?
譯文【51CTO.com快譯】近十年來，大規模分布式系統得到了爆炸式增長，已經產生了一股可以說是對整個軟件業開先河式的，數據庫界的創意旋風。市場上也涌現了大量的頗具競爭力的數據庫平臺。
在本文中，我們將探討如何為您的應用去選擇合適的數據庫模型（是的，完全可以選擇不止一個！）。我們也會討論到這些數據模型的選擇將如何幫助您去確定數據層面的各種技術。
一、云架構，NoSQL和微服務
在軟件開發人員開始創建Web架構的應用時，那些在歷史上一直主導著我們多年的關系型數據庫架構，已經開始表現出“壓力山大”了。特別是在我們開發那些被頻繁使用的社交應用，和將越來越多的設備連接到物聯網（IOT）的時候，客戶端大量地讀取和寫入數據導致了數據層面的擴展需求。而與此同時，為了滿足這些高擴展性的需求，新的數據庫類型隨之出現。
在許多情況下，這些新的數據庫是“非結構化查詢語言（NoSQL）”或“非關系型”的數據模型解決方案。它們并非顯性的關系模型，如文檔、鍵-值、面向整列的、甚至是圖表數據庫。通常，這些數據庫犧牲了一些在傳統關系型數據庫上為我們所熟悉的特性，如：強一致性、ACID事務和各種連接（joins）。
同時，作為革命性的數據庫技術，SOA（面向服務的架構）已經日趨向微服務架構的風格進行發展，許多組織開始摒棄諸如企業服務總線（ESB）的重量級SOA架構，而改用更為分散的實現方法。微服務架構的吸引力在于其獨立的開發、管理和擴展各種服務的能力。這使得我們在考慮數據庫架構實現等方面的技術上，具有大量的實施選擇靈活性。
舉例而言，假設我們根據一項大規模可擴展性的需求，正在從事一個重要的微服務架構的開發。那么，無論該項目是一項新的應用，還是對現有應用的重構，我們都有機會來選擇新的數據庫。
1.混合持久化（Polyglot persistence）
微服務模式的一項優勢是封裝的持久性，我們可以自由地根據每個服務的需求來選擇不同的持久化技術。Martin Fowler等人提出的混合持久化這一術語，特指根據不同的數據類型來選擇數據存儲的方法，可以說混合持久化天生就十分契合微服務。
下面的例圖顯示了一組微服務，我們該如何為每一項服務來選擇使用不同的數據模型呢？在此，我不一一列舉每種數據庫類型的適當用例，只會突出這些數據庫類型和混合方法的優勢所在。
將混合持久化應用到微服務上。
開發服務A的小組可能會選擇使用表格型數據庫（tabular database），如Apache Cassandra，因為它能大規模地管理核心應用的數據。例如，零售應用的庫存類數據可能就非常適合于Cassandra的表格形式。Cassandra提供了一套協調機制的工具集，包括能夠批量調整一致性，和作為全面ACID事務替代品的輕量級事務等。
服務B可能只需要支持通過well-known鍵來查詢參考值，這樣簡單的語義，比如說一個產品編錄的描述性數據。這是一個很好的鍵-值（key-value）存儲的案例，我們可以通過產品ID的well-known鍵-值來查找一個BLOB（二進制對象文件的容器）類型的數據。那么大量的內存空間會被用來緩存鍵-值類型的數據，從而支持大規模、且超快速地讀取訪問。
服務C主要考慮的是提供半結構化的內容，例如：網站的網頁或表格，以及文檔存儲，這些類型的數據都是非常適合的。文檔的存儲有“許多鍵-值類型相似，僅有某個鍵不同”的數據結構，例如只要索引某些特殊屬性項，便可加快各種搜索的能力。
服務D則涉及到導航各種數據間的復雜關系，例如：客戶數據與組織內不同部門的客戶聯系人之間的歷史數據。這可能潛在地涉及到：各種不同服務所擁有的數據類型之間的各種關系。比如說在這種情況下，您可以選擇讓您的服務創建一個對于各種底層表格都是只讀的視圖，然后通過調用其他“擁有著”自身數據類型的服務API這樣的“front door”，來過濾實現任何預期的轉換。
***，我們還可能會有一些使用著關系型技術的傳統系統與服務，或者我們有一個管理著少量且不經常更改的數據服務。那么關系型數據庫對于此類用例就是再好不過的了。
2.單獨的服務需要混合嗎？
也有一種可能：我們設計出一個放置在多數據庫之上的服務。例如說，我們可以創建一個使用的鍵-值存儲索引的酒店服務，它映射名稱和ID之間的關系。同時它用Cassandra的表格樣式來存儲關于酒店的描述性數據。
一個混合服務？
注意：使用非規范化的設計方法，同樣可以在Cassandra中實現名稱與ID的映射，當然您需要用一張單獨的表格來維持名稱與ID的映射。這樣雖然會用到更多的存儲空間，但是簡化了我們在管理一個單獨的鍵-值存儲操作上的復雜性。
所以我的建議是：只要可行，完全可以把一個給定的微服務與一個單一的數據模型（和數據庫）相連接。如果您碰到需要將單一的服務放置在兩個不同的數據庫之上的情況，請判斷該服務的范圍是否過大。如果太大，您可能就需要考慮將其拆分成多個更小的服務了。
3.混合持久化的限制與利弊
混合持久化的主要劣勢是：在最初化開發和運營方面，需要支持多種技術的成本。
開發的成本主要來自于培訓各個開發人員熟悉每種新的數據庫技術的成本。如果您的開發團隊流動性較大的話，這種劣勢會更加明顯。
而另一個弊端是支持多個數據庫的運營成本。如果數據庫的管理是集中化的，并且整體團隊必須對多種技術保持較高的維護水平時，這就可能會出現問題。但是當開發團隊僅支持他們已選定的生產環境所用到的數據庫，從而形成了真正的Devops運作模式時，該問題會得到適當的緩解。
4.多模型數據庫
數據庫提供商已經開始著手打造與提升一些多模型的數據庫，作為混合持久化方法的一種替代或補充了。術語“模型”是指由諸如表格（包括關系和非關系型）、列存儲、鍵-值、文檔或圖表之類的數據存儲所提供的抽象模型。我們可以理解為：多模型應用使用的是一種類型以上的數據存儲，而多模型數據庫則能夠支持多種抽象。
DataStax Enterprise（DSE）是一個多模型數據庫的例子，其核心使用一種建立在頂端圖表的抽象（DSE圖表），來支持Cassandra分區的行存儲（表格）模式。如下圖所示，在此核心模型上創建您自己的鍵-值和各種文檔類型的抽象是非常簡單的。通過這種方式，我們可以修改上述的混合方法，利用單一的底層數據庫引擎來提供我們的所有服務。與此同時，我們還可以使用單獨的Cassandra鍵值空間，來維持那些由不同服務所擁有的數據之間的清晰界限。
與DataStax Enterprise交互，作為一個多模型的數據庫。
我們下面來看看它是如何工作的：
表格：服務A之類的主要應用服務可以使用Cassandra的查詢語言（CQL），來與DSE數據庫直接進行交互。
鍵-值：雖然Apache和DataStax的Cassandra版本都無法提供一個明確的鍵-值API，但是像服務B之類的服務卻能夠通過設計來限制表格只與Cassandra互動實現鍵-值的存儲。例如：
- CREATE TABLE hotel.hotels (
- key uuid PRIMARY KEY,
- value text); // or if you prefer, “blob”
文件：通過各種JSON文件，Cassandra能夠支持文檔類型的交互，這可以被用于服務C之類的服務。注意：因為Cassandra的確需要有表的schema模式，因此您不能插入任意的JSON來隨便定義新的列，也就是說通常需要具有與文檔數據庫相關聯的特性。
圖表：對于像服務D之類高度支持數據互連的服務來說，DSE圖表是一個高度可擴展的圖表數據庫，它直接建立在DSE數據庫之上。DSE圖表通過Apache TinkerPop 項目來支持強大的、且易于表現的Gremlin API。
5.多模型數據庫的優勢和局限性
在考慮是否要使用多模型數據庫的時候（或使用你已有數據庫的多模型功能時），你需要兼顧考慮我們上述所討論的有關混合持久化方法所帶來的開發和運營成本。
使用多模型數據庫可以簡化運營。無論是不同的開發團隊使用不同的API，還是不同的后端數據庫平臺交互模式，我們都會從只需要管理單一的平臺來受益。
在選擇多模型數據庫時，需要考慮的一個方面就是：各種模型如何能夠被支持。一種常用的處理方式是：一個基于單一本地的底層模型與其上面分層的其他模型共同組成一個數據庫引擎。分層的數據模型用于展示其底層主模型的各種特征。
例如，在ThoughtWorks的技術雷達第16卷（Technology Radar Vol. 16）（https://assets.thoughtworks.com/assets/technology-radar-vol-16-en.pdf）中，就討論展示了在Cassandra頂端分層的DSE圖表模型的特性和所涉及的取舍：
我們所長期鐘愛和使用的Neo4j（譯者注：Neo4j是一種高性能的NOSQL類型圖表數據庫，它將結構化數據存儲在網絡中而不是本地表里。）已經在大型的數據集類型中逐漸顯露出了局限性，而建立在Cassandra頂端的DSE圖表則應運而生。
當然，這種模式也有其自己的取舍，例如：您會失去ACID事務和Neo4j的獨立于架構運行（run-time schema-free）特性；但是DSE通過訪問底層的Cassandra各種表格，Spark對分析負載的集成，以及強大的TinkerPop/Gremlin查詢語言，都使得它還是很值得考慮和選擇的。
如果您在自己的Web架構應用中考慮使用不同的數據類型，那么您可能就會發現到：不同的數據類型有著不同的一致性需求，而實際需要立即進行一致化的數據類型并不多。
另一個需要重點考慮的是：多模型的空間問題，即不同數據庫模型和引發的集成與交互，以及訪問數據的各種操作和分析用例。DSE支持通過Spark（DSE分析）來訪問圖表數據以實現其分析的目的，而DSE搜索則提供了用于創建那些存儲在DSE數據庫中數據的各種搜索索引的能力。
二、微服務數據模型的四步驟
既然我們已經了解了混合與多模型方法的各類優點，那么我們應該如何為大規模的微服務應用來選定數據模型呢？請參考下列的步驟：
1. 識別應用程序中的主要數據類型，逐個創建服務，并控制每個服務的持久性。如果可能的話，將多模型的數據庫運用到所有服務上，使服務能根據它們所選擇交互的數據來改變模式。
2. 根據您網頁級的延展性和可用性，鍵-值的分層和文檔的語義，按需使用一種表格的形式（如DSE數據庫）來作為您的主要模型。請務必考慮到各種方式，來保證您的數據能夠被各種操作和分析用例所訪問到。這樣您就可以提前規劃好那些如何使用查找索引，以及向分析數據中心進行復制等方面的功能。
3. 使用高度相關的數據圖表形式（如DSE圖表），特別是在各個實體之間的關系有著比其實體本身更多屬性的時候，或是您需要在同一個實體間獲取多重關系的時候。
4. 當您沒有必要改變的時候，請保留傳統的關系型/SQL技術的架構。例如，當您的用例并不需要大規模、低延遲和高可用性的時候。
我希望上述內容能夠為您在思考如何為自己的應用程序提供多模型支持，以及何時、何處用到多模型數據庫的時候提供一個實用的框架。
原文標題：How to choose a database for your microservices，作者: Jeff Carpenter
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
