[[203397]]

一、什么是數(shù)據(jù)庫即服務(wù)(DBaaS) 

首先介紹一下『數(shù)據(jù)庫即服務(wù)』。『數(shù)據(jù)庫即服務(wù)』其實是『Database-as-a-service』的中文翻譯，我們看看它在維基百科中的定義：

我們知道，現(xiàn)在有很多的as-a-service，比如Infrastructure as a Service(IaaS)、Platform as a Service(Paas)還有Software as a Service(Saas)。他們到底都是什么呢?有什么區(qū)別?

這張圖應(yīng)該可以很好地解釋這些X-aaS。最左邊是傳統(tǒng)企業(yè)的IT，所有的活都要自己干，從數(shù)據(jù)中心服務(wù)器到操作系統(tǒng)數(shù)據(jù)庫再到上層業(yè)務(wù)系統(tǒng)。IaaS開始就進入云計算的范疇了，最基礎(chǔ)的是云服務(wù)器，不需要再關(guān)心機房啊硬件拉，直接就可以用。然后再往右客戶需要關(guān)注的越來越少，臟活累活都交給服務(wù)提供商來干。

那么『數(shù)據(jù)庫即服務(wù)』的情況是怎么樣呢?

數(shù)據(jù)庫即服務(wù)的優(yōu)勢

『數(shù)據(jù)庫即服務(wù)』其實可以認為是PaaS的一種變種，主要關(guān)注點在數(shù)據(jù)庫上，客戶不再需要去自己部署數(shù)據(jù)庫，而是只需要按需使用由服務(wù)提供商提供的數(shù)據(jù)庫即可，數(shù)據(jù)庫的維護都交給服務(wù)提供商來完成，這樣客戶只需關(guān)注應(yīng)用本身即可。

我們來具體看一下使用『數(shù)據(jù)庫即服務(wù)』和原來有什么不同，這里除了列舉傳統(tǒng)全部DIY的方式之外，還對比了一種利用IaaS來自建數(shù)據(jù)庫的方式，這也是現(xiàn)在比較常見的一種做法。我們看到傳統(tǒng)方式，需要做很多事情，這當(dāng)中還需要涉及多個團隊來協(xié)作，非常不容易。然后看看第二種方式，利用IaaS來自建，這里以阿里云的云服務(wù)器ECS為例，這種方式和剛剛相比，省了不少事，但是仍然是比較麻煩的，也可能還需要涉及跨團隊協(xié)作。

我們再來看看如果是使用『數(shù)據(jù)庫即服務(wù)』呢?只需要點下頁面上的部署按鈕，就可以等著用了，已經(jīng)進化為完全自助服務(wù)了。從時間上來看，第一種方式可能需要花費數(shù)月，第二種可能需要花費數(shù)天，第三種則只需要數(shù)小時即可?？梢姟簲?shù)據(jù)庫即服務(wù)』的優(yōu)勢還是很明顯的。

所以說為什么要『即服務(wù)』，其實是一個進化的趨勢。我們經(jīng)常說人不能太懶，但是懶這個字用在程序猿身上可能并不是不好的東西，因為懶，促使我們會去自動化。最早我們通過人肉操作，下載軟件，編譯部署，然后配置。有一天我們發(fā)現(xiàn)經(jīng)常需要這么干很累很浪費時間，就開始寫腳本來完成這些操作，生產(chǎn)力開始提高。等到規(guī)模更大的時候，比如要同時管理數(shù)十臺數(shù)百臺機器，這時候可能分發(fā)腳本也嫌麻煩了，開始寫一些自動化的工具來做這個事情。到最高級階段，就是完全實現(xiàn)自助服務(wù)，這是懶的最高境界。

二、MongoDB簡介

說完了『即服務(wù)』以及其重要性，接下來我們看一下今天的另一個主角：MongoDB，因為有些同學(xué)可能對這個不了解，所以還是簡單介紹一下。

首先，MongoDB是什么呢，它是一個Document Store，文檔型數(shù)據(jù)庫，也是我們經(jīng)常說的NoSQL。根據(jù)DB-Engines的數(shù)據(jù)庫排名，MongoDB長期霸占著NoSQL老大的地位，現(xiàn)在是數(shù)據(jù)庫界一位重量級選手。

事實上，MongoDB可以稱為是一種NewSQL，它融合了傳統(tǒng)關(guān)系型數(shù)據(jù)庫和NoSQL的一些優(yōu)點。

最左邊的3個能力是來自于關(guān)系型數(shù)據(jù)庫：

1. 首先，它具備豐富的查詢語句和二級索引。通過這點，用戶可以以足夠復(fù)雜的方式來訪問和組織數(shù)據(jù)。
2. 第二點，強一致性。MongoDB支持一個靈活的一致性模型。你可以選擇使用強一致性，或最終一致性，取決于你的業(yè)務(wù)場景。
3. 第三點，MongoDB能很好的集成到多企業(yè)現(xiàn)有技術(shù)架構(gòu)中。

右邊3個能力來自NoSQL：

• 首先是靈活的數(shù)據(jù)模型，MongoDB的文檔模型允許動態(tài)修改schema，不用擔(dān)心有任何的性能影響。
• 其次是高性能和高可擴展性，MongoDB可以輕松進行水平擴展，從而帶來更高的吞吐和更低的延遲。
• 最后，是全球部署，也就是高可用。接下來我們就來具體講下MongoDB的幾個關(guān)鍵特性。

MongoDB的關(guān)鍵特性

MongoDB的關(guān)鍵特性主要是3個，第一個就是靈活動態(tài)的文檔模型，第二個是高可用副本集，第三個是MongoDB的水平擴展，也就是sharding。

1、靈活動態(tài)的文檔模型

MongoDB以一種叫做BSON(二進制JSON)的存儲形式將數(shù)據(jù)作為文檔存儲。具有相似結(jié)構(gòu)的文檔通常被組織成集合?？梢园鸭峡闯深愃朴陉P(guān)系數(shù)據(jù)庫中的的表：文檔對應(yīng)的是行，字段對應(yīng)的是列。

MongoDB將一條記錄的所有數(shù)據(jù)聚合在一個文檔中，而在關(guān)系數(shù)據(jù)庫中則傾向于將數(shù)據(jù)分布在多個表中。這樣做有幾個好處，一是由于數(shù)據(jù)聚集，減少了多表JOIN的需求，這樣只需要讀一次就可以讀到所有數(shù)據(jù)，在性能上會有很大優(yōu)勢。

另外，這種模型更加接近我們平時編程語言中的對象結(jié)構(gòu)，可以方便開發(fā)者進行數(shù)據(jù)映射。

最后就是這種模型是schema-less的，也就是在MongoDB中不需要像關(guān)系數(shù)據(jù)庫一樣去事先定義每個表的schema。MongoDB一個集合內(nèi)的文檔之間可以擁有不同的結(jié)構(gòu)，可以輕松為一個新的文檔添加和減少字段，不會有任何的性能影響。這個特性非常適合開發(fā)一些新產(chǎn)品，可以快速迭代。

當(dāng)然，過于靈活就可能導(dǎo)致混亂。有時候我們想要求文檔必須要有某些字段，某些字段必須要有固定的類型。為此，MongoDB提供了一個文檔驗證功能來對文檔的格式進行約束。

2、高可用副本集

接下來說MongoDB的第二個關(guān)鍵特性，高可用副本集(也可以翻譯成復(fù)制集)。

MongoDB副本集由一組Mongo實例(進程)組成，包含一個Primary節(jié)點和多個Secondary節(jié)點，Mongodb Driver(客戶端)的所有數(shù)據(jù)都寫入Primary，Secondary從Primary同步寫入的數(shù)據(jù)，以保持副本集內(nèi)所有成員存儲相同的數(shù)據(jù)集，提供數(shù)據(jù)的高可用。

上圖是一個典型的MongDB副本集，包含一個Primary節(jié)點和2個Secondary節(jié)點。

副本集通過replSetInitiate命令(或mongo shell的rs.initiate())進行初始化，初始化后各個成員間開始發(fā)送心跳消息，并發(fā)起Primary選舉操作，獲得『大多數(shù)』成員投票支持的節(jié)點，會成為Primary，其余節(jié)點成為Secondary。

這里『大多數(shù)』的定義是副本集內(nèi)可投票成員的一半以上，當(dāng)副本集內(nèi)存活成員數(shù)量不足大多數(shù)時，整個副本集將無法選舉出Primary，此時副本集將無法提供寫服務(wù)，處于只讀狀態(tài)。通常建議將副本集成員數(shù)量設(shè)置為奇數(shù)，因為偶數(shù)個節(jié)點能容忍的節(jié)點失效和比它少1個節(jié)點的奇數(shù)個節(jié)點是一樣的，但是可以節(jié)省一個節(jié)點的數(shù)據(jù)存儲成本。

除了初始化的時候會進行選舉，MongoDB副本集的高可用服務(wù)體現(xiàn)在，當(dāng)副本集中沒有Primary節(jié)點時，選舉都會進行。比如當(dāng)Primary節(jié)點宕機時，剩下的Secondary節(jié)點中會選舉出新的Primary(只需要滿足大多數(shù)成員存活的條件)。選舉使用的算法是基于Raft協(xié)議，但是可以通過為節(jié)點配置選舉優(yōu)先級對選舉結(jié)果進行控制。

此外需要提一下，有一些比較常見的特殊的Secondary。一個是Hidden，Hidden節(jié)點和普通的Secondary的區(qū)別是它是對Driver隱藏的節(jié)點，也就是客戶端無法訪問到Hidden，另外就是它的選舉優(yōu)先級是0，也就是它不能被選舉為Primary。Hidden節(jié)點上擁有數(shù)據(jù)，因此通常會用來作一些運維任務(wù)，如數(shù)據(jù)備份、計算分析等。

另外還有一個是Arbiter，Arbiter是只參與投票，但是不存儲數(shù)據(jù)的節(jié)點，這可以用在對可用性有要求，又要嚴(yán)格控制成本的場景。

此外還有如Priority0節(jié)點、Delayed節(jié)點等。

3、MongoDB的水平擴展

MongoDB提供了一種水平擴展的方式，叫做sharding，通過這種方式對數(shù)據(jù)庫進行擴容，對應(yīng)用是透明的。通過sharding，可以將一個集合的數(shù)據(jù)散到多個shard節(jié)點上。這里每個shard都可以是一組副本集。應(yīng)用程序通過一個路由節(jié)點(mongos)來訪問sharding集群的數(shù)據(jù)。有了sharding，MongoDB就可以突破單機的限制，比如磁盤、內(nèi)存和IOPS等，從而提供更強大的服務(wù)能力。

Sharded cluster由Shard、Mongos和Config server 3個組件構(gòu)成。Mongos本身并不持久化數(shù)據(jù)，Sharded cluster所有的元數(shù)據(jù)都會存儲到Config Server，而用戶的數(shù)據(jù)則會分散存儲到各個shard。Mongos啟動后，會從config server加載元數(shù)據(jù)，開始提供服務(wù)，將用戶的請求正確路由到對應(yīng)的Shard。

Sharded cluster支持將單個集合的數(shù)據(jù)分散存儲在多個shard上，用戶可以指定根據(jù)集合內(nèi)文檔的某個字段即shard key來分布數(shù)據(jù)，目前主要支持2種數(shù)據(jù)分布的策略，范圍分片(Range based sharding)或hash分片(Hash based sharding)。

范圍分片下，文檔是根據(jù)其shard key的值進行分片。shard key的值相鄰近的文檔比較有可能會被放在同一個shard上，這種方式適用于需要使用范圍查詢的業(yè)務(wù)。

哈希分片下，文檔根據(jù)其shard key的hash值進行分片。這會保證數(shù)據(jù)分布比較均勻，但是不利于范圍查詢。

隨著數(shù)據(jù)量的增多，MongoDB也會自動在后臺對數(shù)據(jù)以chunk為單位進行負載均衡。

三、如何搭建MongoDB數(shù)據(jù)庫即服務(wù)

接下來介紹一下今天的重點內(nèi)容，如何搭建一個MongoDB數(shù)據(jù)庫即服務(wù)。

首先，在我看來，數(shù)據(jù)庫即服務(wù)，應(yīng)該具備這些特性：自動化、按需服務(wù)、彈性、安全、高可用和可量化：

• 第一個，自動化，這是非常關(guān)鍵的，是實現(xiàn)自助服務(wù)的基礎(chǔ)，所有可以被自動化操作的流程都應(yīng)該被自動化，不需要人工干預(yù)。
• 第二個，按需服務(wù)，數(shù)據(jù)庫即服務(wù)應(yīng)該是由用戶驅(qū)動的，后臺應(yīng)該要有一個工作流的機制來對需求進行響應(yīng)。
• 第三個，彈性，可以按需動態(tài)擴縮容。
• 第四個，安全，這是毋庸置疑的。
• 第五個，高可用，宕機自動切換。
• 第六個，可量化，服務(wù)的使用量可以被衡量、報告并且是可控的。

此圖為數(shù)據(jù)庫即服務(wù)應(yīng)具備的功能大圖。主要包括生命周期管理、容災(zāi)體系、監(jiān)控報警、數(shù)據(jù)管理和增值服務(wù)：

• 生命周期管理包括數(shù)據(jù)庫實例的新建、釋放、擴縮容等，這是數(shù)據(jù)庫即服務(wù)最基礎(chǔ)的功能。
• 容災(zāi)體系包括高可用、備份恢復(fù)，甚至更高級的如異地容災(zāi)/多活等等。
• 監(jiān)控報警一方面就是服務(wù)使用量的監(jiān)控，另一方面則是報警，包括服務(wù)不可用的報警，以及一些監(jiān)控數(shù)據(jù)異常的報警。
• 數(shù)據(jù)管理指的就是可以方便的對數(shù)據(jù)進行管理，如可以提供一些圖形化界面等。
• 增值服務(wù)包括審計、診斷服務(wù)等。其中審計是數(shù)據(jù)庫的一個非常重要的功能，一方面可以幫助查證問題，另一方面可以為一些數(shù)據(jù)分析或診斷提供數(shù)據(jù)源。診斷服務(wù)一方面跟蹤服務(wù)的資源使用量，為是否需要擴縮容提供決策依據(jù)，另一方面主要為慢查詢提供優(yōu)化建議。

數(shù)據(jù)庫即服務(wù)的核心架構(gòu)就是工作流引擎，這是實現(xiàn)自動化及按需服務(wù)的基礎(chǔ)。

1、生命周期管理

生命周期管理功能包括數(shù)據(jù)庫實例的新建、釋放、擴縮容以及遷移。新建一個數(shù)據(jù)庫實例包括分配資源(主要是主機資源)、安裝數(shù)據(jù)庫、初始化配置。對MongoDB來說，副本集涉及多個節(jié)點，涉及到資源的分配策略，Sharding更多。另外副本集還需要一些初始化工作，sharding需要有一個各組件的組合。釋放實例比較簡單，主要是資源的回收。擴縮容可以分為本地和跨機的擴縮容，其實跨機的擴縮容就是遷移。對于MongoDB來說，遷移可以直接利用MongoDB的添加節(jié)點自動同步的特性，還是比較方便的。

生命周期管理功能主要涉及這幾個組件，包括資源管理、規(guī)格及配置管理、軟件棧管理和負載均衡：

資源管理主要是指主機資源的管理，這里主機可以是物理機，也可以是虛擬機，如云主機等。資源管理主要負責(zé)資源的分配和回收，此外還包括如何實施資源隔離。

規(guī)格及配置管理一個是需要為數(shù)據(jù)庫實例制定一些規(guī)格，以方便擴容和縮容，另一方面是負責(zé)數(shù)據(jù)庫相關(guān)配置的維護。

軟件棧管理則包括數(shù)據(jù)庫軟件以及其依賴的軟件的安裝維護等，包括操作系統(tǒng)。

除了這些，還需要一個負載均衡組件來保證數(shù)據(jù)庫實例在資源上的分布的均衡，當(dāng)有主機資源需要下線的時候，能夠做到自動對其上的數(shù)據(jù)庫實例進行遷移。 

對于MongoDB來說，在實施資源分配策略時需要注意的一點是需要保證不要破壞副本集原本的高可用特性。雖然MongoDB副本集自帶了高可用，但是如果你把副本集的所有節(jié)點都分布在一臺物理機上，那如果這個物理機掛了，整個副本集都沒用了。所以一個起碼的原則是要保證MongoDB多副本的主機安全性，盡可能夠做到機架安全。

現(xiàn)在我們的MongoDB數(shù)據(jù)庫即服務(wù)的架構(gòu)可以稍微擴充一下了，多了資源服務(wù)、規(guī)格及配置服務(wù)、軟件棧服務(wù)以及負載均衡服務(wù)這幾個組件。

2、容災(zāi)體系

接下來看一下容災(zāi)體系，這包括高可用、備份/恢復(fù)、異地容災(zāi)/多活。高可用需要有一個負責(zé)健康檢查的巡檢服務(wù)，另外還需要有一個容災(zāi)切換的組件。備份/恢復(fù)也是容災(zāi)體系非常重要的一環(huán)，這里有一個很容易被忽視的事情是需要做備份的有效性驗證。如果備份不是有效的，那等于沒有備份。異地容災(zāi)/多活是比較高級的容災(zāi)能力，實施起來比較復(fù)雜，有興趣的同學(xué)可以參考我之前做過的一個分享《MongoDB異地容災(zāi)多活實踐》。

(鏈接：https://yq.aliyun.com/articles/96598) 

MongoDB副本集自帶了高可用，我們還需要做什么工作呢?主要是需要保證容災(zāi)切換的一個可控。以一個經(jīng)典的3節(jié)點P/S/H副本集為例，一方面我們可以通過配置選舉優(yōu)先級的方式來保持Primary和Secondary的角色穩(wěn)定性。另一方面，我們希望在任意時刻，用戶都可以有兩個節(jié)點是可訪問的，因此我們需要對節(jié)點宕機后的副本集做一些reconfig操作，保證宕機節(jié)點最終都會變成Hidden，然后統(tǒng)一對Hidden進行處理，比如重搭等。

容災(zāi)體系第二個比較重要的點就是備份恢復(fù)。備份主要需要做的是需要提供自動/手動的備份方式以及支持一些靈活的備份策略制定，如備份周期/備份保留時間等?；謴?fù)主要是看對恢復(fù)的形態(tài)做成什么樣，是覆蓋原來的實例還是克隆出一個新的實例來，還有就是恢復(fù)的粒度，這取決于備份能力，是只能恢復(fù)到某個全量備份，還是可以恢復(fù)到任意時間點。關(guān)于備份存儲，我們要求的最要 能力是高可靠性。另外就是剛剛提過的備份有效性驗證，不能等到火燒眉毛了才發(fā)現(xiàn)備份不可用，需要防范于未然。

關(guān)于MongoDB的備份方法，相關(guān)的文檔和分享已經(jīng)有很多了，這里再簡單提一下。全量備份從實施方式上可以分為兩種，邏輯備份和物理備份。其中邏輯備份主要使用官方提供的mongodump/mongorestore工具。物理備份則可以在文件系統(tǒng)或是更底層的邏輯卷、塊設(shè)備這層去做。

從各個指標(biāo)上對比邏輯備份和物理備份，在備份和恢復(fù)效率上，物理備份的優(yōu)勢比較明顯，不過邏輯備份在兼容性上會比較好。

MongoDB的增量備份主要通過持續(xù)的抓取oplog來實現(xiàn)。有了全量備份加增量備份，就可以實現(xiàn)恢復(fù)到任意時間點。

至此，我們的MongoDB數(shù)據(jù)庫即服務(wù)的架構(gòu)又可以得到一個比較大的擴充，主要增加了高可用以及備份相關(guān)的一些服務(wù)。

3、監(jiān)控報警

接下來看下數(shù)據(jù)庫的監(jiān)控報警，性能監(jiān)控主要涉及性能數(shù)據(jù)的采集、存儲和展示。采集粒度越細越好，最好能做到秒級。報警則可以分為可用性的報警和性能數(shù)據(jù)的報警。

具備監(jiān)控報警能力后的架構(gòu)圖已經(jīng)有點滿了，這里報警服務(wù)可以通過巡檢服務(wù)和性能數(shù)據(jù)存儲收集相關(guān)數(shù)據(jù)。

4、增值服務(wù)

來看最后一個增值服務(wù)，一個是審計，主要涉及審計日志的采集、存儲和分析。另一個是診斷服務(wù)，一個是資源使用量上的診斷，另外一個是慢查詢的診斷，可以做一些索引推薦等。

這就是我們的MongoDB數(shù)據(jù)庫即服務(wù)的完整架構(gòu)，可以看到組件還是比較多的，做一個數(shù)據(jù)庫即服務(wù)還不是那么容易的。

總結(jié)

最后做一下總結(jié)，我認為數(shù)據(jù)庫即服務(wù)的核心特性有兩點，一個是資源池化，另外一個是服務(wù)可量化。

資源池化后才可以進行資源的自動管理，而我們需要的服務(wù)是要能夠被量化的，并且是可控的?，F(xiàn)在回顧一下之前的一鍵安裝數(shù)據(jù)庫，其實背后有許多工作要做。當(dāng)然，如果覺得自己搭建一個數(shù)據(jù)庫即服務(wù)太麻煩，可以考慮使用現(xiàn)成的云服務(wù)，比如阿里云MongoDB數(shù)據(jù)庫服務(wù)：)