戳藍(lán)字“CSDN云計(jì)算”關(guān)注我們哦！

Docker 在企業(yè)環(huán)境的應(yīng)用端具有很大的潛力，在這一點(diǎn)上我想大家是有目共睹的，無(wú)狀態(tài)的服務(wù)采用容器化已經(jīng)是一種大趨勢(shì)，那么問(wèn)題來(lái)了，作為系統(tǒng)核心的數(shù)據(jù)庫(kù)是否需要容器化？

針對(duì)數(shù)據(jù)庫(kù)是否適合容器化這個(gè)問(wèn)題，不同的人可能會(huì)給出不同的答案，在回答此問(wèn)題之前我們先看下容器化部署數(shù)據(jù)庫(kù)和常規(guī)數(shù)據(jù)庫(kù)部署上的一些比較。

容器化VS非容器化

  數(shù)據(jù)庫(kù)不適合容器化，筆者相信持這種觀點(diǎn)的技術(shù)人員不在少數(shù)，為此筆者專門梳理了此種觀點(diǎn)常見(jiàn)的一些依據(jù)，我們一起看一下：

1. 數(shù)據(jù)安全性

數(shù)據(jù)安全這個(gè)話題較大，可以細(xì)分很多的小方向，在此我們只從數(shù)據(jù)丟失這個(gè)角度分下數(shù)據(jù)庫(kù)容器化后引入的問(wèn)題。

和數(shù)據(jù)庫(kù)打過(guò)交道的同學(xué)應(yīng)該都知道，公司線上的數(shù)據(jù)庫(kù)一般都需要進(jìn)行定期的數(shù)據(jù)備份，區(qū)別的話無(wú)非就是根據(jù)業(yè)務(wù)的輕重緩急設(shè)置不同的數(shù)據(jù)備份方式、備份頻率和備份數(shù)量。常見(jiàn)的數(shù)據(jù)庫(kù)的數(shù)據(jù)備份方式有全量備份和增量備份。

顧名思義，全量備份即每次都進(jìn)行一次完整的數(shù)據(jù)備份，即便是相較前一次的全量備份數(shù)據(jù)沒(méi)有絲毫的增加也要再進(jìn)行一次完整的數(shù)據(jù)備份，此種方式的特點(diǎn)是可靠性較好，每一個(gè)數(shù)據(jù)備份都是備份所在時(shí)間點(diǎn)的完整數(shù)據(jù)，當(dāng)然此種方式的缺點(diǎn)也是顯而易見(jiàn)的，即備份周期較長(zhǎng)(相比增量備份的數(shù)據(jù)量大)，且備份數(shù)據(jù)占用的磁盤存儲(chǔ)也較大；增量備份即在第一次備份時(shí)進(jìn)行一次全量的備份，后續(xù)在進(jìn)行備份時(shí)只備份相較前一次備份時(shí)變化的數(shù)據(jù)，增量備份的優(yōu)點(diǎn)是備份周期短，且備份數(shù)據(jù)占用的磁盤空間較少。

備份周期并非越小越好，需要結(jié)合業(yè)務(wù)的屬性進(jìn)行選擇，如公司OA系統(tǒng)使用的數(shù)據(jù)庫(kù)可以一周備份一次，畢竟OA 這種系統(tǒng)并會(huì)經(jīng)常進(jìn)行大量數(shù)據(jù)的寫(xiě)入。再一種情況，比如公司的重要的線上業(yè)務(wù)一般需要較高的備份頻率，一般以天或者小時(shí)作為備份周期的時(shí)間單位，比如一天備份一次、或者1小時(shí)備份一次。有些更重要的業(yè)務(wù)系統(tǒng)，出現(xiàn)數(shù)據(jù)丟失時(shí)會(huì)帶來(lái)比較大的損失，此種情況一般會(huì)采用更高的數(shù)據(jù)備份頻率，比如銀行的數(shù)據(jù)庫(kù)備份多以分鐘或者秒作為數(shù)據(jù)庫(kù)的備份周期單位。

和備份周期的設(shè)置類似，備份數(shù)據(jù)保留的數(shù)量也并非越多越好，也需要根據(jù)具體的業(yè)務(wù)場(chǎng)景來(lái)設(shè)置備份數(shù)據(jù)的保留數(shù)量。比如一般的線上業(yè)務(wù)可以每天備份一次，最多保留7份備份數(shù)據(jù)。

以上我們說(shuō)的是我們?cè)趯?shù)據(jù)庫(kù)容器化之前為防止數(shù)據(jù)庫(kù)數(shù)據(jù)丟失通常進(jìn)行的配置，從現(xiàn)實(shí)角度來(lái)看即使我們?cè)O(shè)置了上面提到的各種配置也仍然不能保證不丟失數(shù)據(jù)。

從上面的經(jīng)驗(yàn)來(lái)看，容器化后即使我們通過(guò)容器的volume 將數(shù)據(jù)存儲(chǔ)在容器所在宿主機(jī)上也不能保證數(shù)據(jù)不丟失。況且Docker 的volume 是圍繞聯(lián)合文件系統(tǒng)的鏡像層來(lái)進(jìn)行的持久化存儲(chǔ)設(shè)計(jì)，這種設(shè)計(jì)目前在數(shù)據(jù)庫(kù)存儲(chǔ)方面仍缺乏保證。

除了上面的問(wèn)題，還有一種情況也會(huì)為數(shù)據(jù)庫(kù)的數(shù)據(jù)安全性帶來(lái)問(wèn)題，眾所周知在容器的世界里某個(gè)容器的崩潰、重建是常態(tài)，這種情況對(duì)于業(yè)務(wù)實(shí)例來(lái)說(shuō)也許不會(huì)有多大的影響，但同樣的場(chǎng)景換為數(shù)據(jù)庫(kù)可能會(huì)出現(xiàn)問(wèn)題，比如運(yùn)行著數(shù)據(jù)庫(kù)的容器崩潰可能會(huì)導(dǎo)致容器內(nèi)的數(shù)據(jù)庫(kù)不能正確關(guān)閉，從而可能造成數(shù)據(jù)的損壞。

2. 環(huán)境需求

在非容器化的場(chǎng)景中，為了避免避免和其他組件的資源競(jìng)爭(zhēng)，數(shù)據(jù)庫(kù)這種核心組件我們一般都是單獨(dú)部署的，要么單獨(dú)部署到一臺(tái)或者幾臺(tái)的虛擬機(jī)上，要么單獨(dú)部署到一臺(tái)或者幾臺(tái)的物理機(jī)上，一般需要和其它的線上組件分開(kāi)部署，比如后端的一些業(yè)務(wù)實(shí)例等，防止其它異常組件拖垮數(shù)據(jù)庫(kù)，畢竟數(shù)據(jù)庫(kù)掛了線上業(yè)務(wù)一般也就歇菜了，這種情況下企業(yè)一般也是寧愿多花點(diǎn)錢來(lái)保證線上業(yè)務(wù)的正常運(yùn)行。

數(shù)據(jù)庫(kù)的單獨(dú)部署只是第一步，實(shí)際環(huán)境中一般還需要給數(shù)據(jù)庫(kù)組件配置好一些的硬件資源，具體需要在哪些方面進(jìn)行升配也需要結(jié)合具體額業(yè)務(wù)場(chǎng)景和數(shù)據(jù)庫(kù)的類型來(lái)看。比如關(guān)系型數(shù)據(jù)庫(kù)，一般對(duì)I/O要求較高，這個(gè)時(shí)候一般需要為數(shù)據(jù)庫(kù)配置較好的存儲(chǔ)設(shè)備，比如磁盤選用優(yōu)質(zhì)的全固態(tài)盤。在一種比如緩存數(shù)據(jù)庫(kù)，為提高查詢效率緩存數(shù)據(jù)庫(kù)一般會(huì)將數(shù)據(jù)存儲(chǔ)在內(nèi)存中，如果存在較多的高頻訪問(wèn)數(shù)據(jù)，此時(shí)一般需要為數(shù)據(jù)庫(kù)配置較高的內(nèi)存。

考慮到上面的兩種情況，我們?cè)谶M(jìn)行數(shù)據(jù)庫(kù)的容器化過(guò)程中為了避免數(shù)據(jù)庫(kù)實(shí)例和其他的業(yè)務(wù)實(shí)例產(chǎn)生資源競(jìng)爭(zhēng)，我們需要為數(shù)據(jù)庫(kù)容器配置大量額外的資源，一般可能需要設(shè)置超過(guò)實(shí)際用量一倍的資源，比如我們實(shí)際需要8GB內(nèi)存，可能需要為實(shí)例分配16GB內(nèi)存，多出的這8GB的內(nèi)存資源一般并不會(huì)被完全使用。

3. 網(wǎng)絡(luò)需求

  Docker 的引入一定程度上增加了網(wǎng)絡(luò)的復(fù)雜性，想要理解Docker 的網(wǎng)絡(luò)需要對(duì)網(wǎng)絡(luò)虛擬化有比較深入的了解。另外，雖然Docker 的使用已經(jīng)逐步落地，但Docker 本身的技術(shù)仍在發(fā)展之中，Docker 本身還存在或多或少的bug，這些bug可能會(huì)為我們帶來(lái)一些意外的情況。為應(yīng)對(duì)這些意外，我們可能需要花費(fèi)較多的時(shí)間排查和修復(fù)Docker 的bug，從筆者實(shí)際體驗(yàn)來(lái)看這種情況一般會(huì)花費(fèi)企業(yè)較多的人力。

  上文中我們提到數(shù)據(jù)庫(kù)一般會(huì)有較高的吞吐量，因此通常情況下我們需要為數(shù)據(jù)庫(kù)配置較好的配置，以此來(lái)應(yīng)對(duì)更高的負(fù)載。除了磁盤、內(nèi)存、CPU會(huì)較大的影響數(shù)據(jù)庫(kù)的性能之外，網(wǎng)絡(luò)對(duì)數(shù)據(jù)庫(kù)的性能也是非常只要的一環(huán)，尤其是在涉及到數(shù)據(jù)復(fù)制的場(chǎng)景，網(wǎng)絡(luò)性能差的情況下可能會(huì)影響到數(shù)據(jù)庫(kù)的數(shù)據(jù)復(fù)制效率，在異步復(fù)制的場(chǎng)景下網(wǎng)絡(luò)性能差可能會(huì)導(dǎo)致業(yè)務(wù)實(shí)例讀不到最新的數(shù)據(jù)。我們知道容器是虛擬機(jī)管理程序和主機(jī)虛擬機(jī)背后的一個(gè)隔離層，Docker 容器引入的額外的網(wǎng)絡(luò)邏輯一定程度上會(huì)降低網(wǎng)絡(luò)的傳輸效率，進(jìn)而可能會(huì)影響到數(shù)據(jù)庫(kù)容器之間的數(shù)據(jù)復(fù)制，進(jìn)而導(dǎo)致業(yè)務(wù)實(shí)例從數(shù)據(jù)庫(kù)讀取到錯(cuò)誤的數(shù)據(jù)。

  數(shù)據(jù)庫(kù)本身就是一個(gè)比較復(fù)雜的系統(tǒng)，數(shù)據(jù)庫(kù)的容器化會(huì)導(dǎo)致數(shù)據(jù)庫(kù)更加難以管理，相比引入Docker復(fù)雜的網(wǎng)絡(luò)環(huán)境，將數(shù)據(jù)庫(kù)實(shí)例放在專用的環(huán)境中，節(jié)省下時(shí)間專注于業(yè)務(wù)的改進(jìn)對(duì)項(xiàng)目、對(duì)企業(yè)來(lái)說(shuō)可能會(huì)是更好的選擇。

4. 狀態(tài)抉擇

  Docker 容器出現(xiàn)之初主要是用來(lái)運(yùn)行無(wú)狀態(tài)的應(yīng)用實(shí)例，對(duì)于數(shù)據(jù)庫(kù)這種情況并未專門的支持。數(shù)據(jù)庫(kù)的特性決定了它是有狀態(tài)的，和無(wú)狀態(tài)的應(yīng)用實(shí)例混布在一起，會(huì)加大系統(tǒng)的故障范圍，業(yè)務(wù)系統(tǒng)中的應(yīng)用程序?qū)嵗惓？赡軙?huì)直接影響到運(yùn)行在有狀態(tài)容器中的數(shù)據(jù)庫(kù)實(shí)例。

5. Docker的支持

簡(jiǎn)單說(shuō)來(lái)就是Docker并未對(duì)容器中運(yùn)行數(shù)據(jù)庫(kù)這種場(chǎng)景做專門的優(yōu)化。我們先看下Docker 官方對(duì)Docker的定義：

Docker Containerization Unlocks the Potential for Dev and Ops，Freedom of choice, agile operations and integrated container security for legacy and cloud-native applications。

具體說(shuō)來(lái)就是：

(1) Docker 是為程序開(kāi)發(fā)者和系統(tǒng)運(yùn)維人員提供的一個(gè)開(kāi)放平臺(tái)，這個(gè)平臺(tái)提供了包含應(yīng)用構(gòu)建、應(yīng)用分發(fā)和運(yùn)行分布式應(yīng)用在內(nèi)的一些功能。

(2) Docker 為程序開(kāi)發(fā)者和系統(tǒng)管理人員提供了Docker 引擎和眾多的配套組件，如Docker Hub，Docker 引擎是一個(gè)C/S架構(gòu)的應(yīng)用程序，開(kāi)發(fā)者可以借助Docker 引擎對(duì)Docker 對(duì)象進(jìn)行管理，常見(jiàn)的Docker 對(duì)象包括：Dcoker鏡像、Docker容器、Docker網(wǎng)絡(luò)、Docker 數(shù)據(jù)庫(kù)卷等。Docker Hub 為開(kāi)發(fā)者提供鏡像的托管服務(wù)。開(kāi)發(fā)者借助Docker 可以將應(yīng)用程序以組件的形式進(jìn)行快速的部署，同時(shí)借助Docker 可以消除各種環(huán)境的差異性，比如開(kāi)發(fā)環(huán)境、測(cè)試環(huán)境、生產(chǎn)環(huán)境。因此借助Docker 開(kāi)發(fā)者可以更快的對(duì)應(yīng)用進(jìn)行分發(fā)，可以實(shí)現(xiàn)一份應(yīng)用在個(gè)人電腦、數(shù)據(jù)中心的虛擬機(jī)和任何云上運(yùn)行上快速運(yùn)行。

  從上面的介紹我們可以明顯的看出Docker的一些特性，比如易于構(gòu)建新環(huán)境、適合持續(xù)集成、靈活的水平伸縮和不同環(huán)境的易維護(hù)性等。那么問(wèn)題來(lái)了，這些特性會(huì)為數(shù)據(jù)庫(kù)帶來(lái)什么？

  為了回答這個(gè)問(wèn)題我們先看下數(shù)據(jù)庫(kù)的容器化和本地化運(yùn)行數(shù)據(jù)庫(kù)，二者是否有較大的差異，我們以mongodb數(shù)據(jù)庫(kù)為例來(lái)具體看下：

  本地化的批量部署軟件大家一般都會(huì)借助一些現(xiàn)成的批量部署工具，比如我們最常使用的Ansible，借助Ansible 我們可以很輕松的部署并設(shè)置幾十個(gè)mongodb實(shí)例，比對(duì)下容器化部署幾十個(gè)mongodb實(shí)例，可能容器化的方式并未為我們節(jié)省多少時(shí)間。

  有些同學(xué)可能會(huì)問(wèn)如果批量重新部署多個(gè)mongodb實(shí)例的話容器化的部署方案應(yīng)該會(huì)更加高效一些，但問(wèn)題來(lái)了，實(shí)際工作中數(shù)據(jù)庫(kù)實(shí)例需要批量升級(jí)的頻率有多高，這種情況可能大部分人在自己目前的職業(yè)生涯中都還沒(méi)有遇到過(guò)一次。且數(shù)據(jù)庫(kù)實(shí)例的升級(jí)一般不是可用性問(wèn)題，而是一個(gè)比較系統(tǒng)的工程問(wèn)題，需要考慮到數(shù)據(jù)庫(kù)實(shí)例在升級(jí)后在整個(gè)系統(tǒng)中的可用性。比如更新數(shù)據(jù)庫(kù)的版本之后已有的應(yīng)用中的邏輯可以無(wú)縫的對(duì)接嗎，這個(gè)可能不見(jiàn)得，從實(shí)際情況來(lái)看，數(shù)據(jù)庫(kù)實(shí)例更換了引擎版本之后可能會(huì)引入很多的新特性，這些特性中一般也會(huì)有一些不兼容的情況，為解決更新數(shù)據(jù)庫(kù)版本帶來(lái)的不兼容的問(wèn)題，我們需要花費(fèi)很多額外的人力來(lái)對(duì)應(yīng)用進(jìn)行對(duì)應(yīng)的版本升級(jí)，整個(gè)過(guò)程耗時(shí)、耗力，因此實(shí)際生產(chǎn)環(huán)境中一般不會(huì)對(duì)數(shù)據(jù)庫(kù)實(shí)例進(jìn)行頻繁的升級(jí)，所以在此點(diǎn)上數(shù)據(jù)庫(kù)的容器化并不能帶來(lái)明顯的效率提升。

  再一個(gè)方面，比如動(dòng)態(tài)伸縮。容器化的實(shí)例在動(dòng)態(tài)伸縮方面確實(shí)存在優(yōu)勢(shì)，尤其是一般的后端應(yīng)用上，但放在數(shù)據(jù)庫(kù)的容器化實(shí)例上卻不能這么樂(lè)觀。比如我們?cè)谌萜髟浦羞\(yùn)行了一個(gè)db server的多個(gè)實(shí)例，那么我們需要考慮下多個(gè)實(shí)例之間的數(shù)據(jù)一致性問(wèn)題，如何解決這個(gè)數(shù)據(jù)一致性？有些同學(xué)可能會(huì)說(shuō)多個(gè)容器實(shí)例共享數(shù)據(jù)目錄或者加入復(fù)制的從節(jié)點(diǎn)不就可以解決嗎，這些方式當(dāng)然是合適的，但是都會(huì)引入額外的問(wèn)題，比如數(shù)據(jù)并發(fā)問(wèn)題和可能出現(xiàn)的數(shù)據(jù)損壞問(wèn)題改如何應(yīng)對(duì)，這些都是問(wèn)題。反觀非容器化部署數(shù)據(jù)庫(kù)實(shí)例，將多個(gè)數(shù)據(jù)庫(kù)實(shí)例部署到專用的環(huán)境中相對(duì)來(lái)說(shuō)更簡(jiǎn)單，更容易維護(hù)，數(shù)據(jù)更安全，且不會(huì)引入額外的問(wèn)題，另外對(duì)于技術(shù)人員來(lái)說(shuō)學(xué)習(xí)成本也相對(duì)較低。

  通過(guò)上面幾個(gè)特性的對(duì)比，相比專用環(huán)境部署數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)的容器化似乎并未為我們帶來(lái)明顯的改進(jìn)。

6. 隔離問(wèn)題

了解Docker 的同學(xué)應(yīng)該都知道，Docker 通過(guò)namespace(命名空間)對(duì)各種資源進(jìn)行了隔離，這些隔離包括：主機(jī)和域名隔離、進(jìn)程編號(hào)隔離、用戶和用戶組隔離、文件系統(tǒng)隔離、網(wǎng)絡(luò)設(shè)備隔離、網(wǎng)絡(luò)棧隔離、端口號(hào)隔離、信號(hào)量消息隊(duì)列和共享內(nèi)存的隔離等。

默認(rèn)情況下只有同一個(gè)namespace下的進(jìn)程之間是可以相互聯(lián)系的，無(wú)法感受到外部進(jìn)程的存在，Docker通過(guò)這種方式營(yíng)造出一種獨(dú)立的系統(tǒng)環(huán)境，從而實(shí)現(xiàn)隔離。

這種隔離性雖然保證了不同容器中進(jìn)程的沖突等問(wèn)題，但是這些額外引入的隔離級(jí)別也會(huì)增加資源的開(kāi)銷。并且這種隔離性只是為業(yè)務(wù)的應(yīng)用量身打造的，并未專門針對(duì)數(shù)據(jù)庫(kù)做做額外的優(yōu)化。

7. 云平臺(tái)問(wèn)題

當(dāng)前環(huán)境下借助云平臺(tái)已經(jīng)成為常態(tài)，我們知道云計(jì)算簡(jiǎn)化了虛擬機(jī)管理、替換上的復(fù)雜性，因此在需要添加新的虛擬機(jī)計(jì)算節(jié)點(diǎn)時(shí)直接登錄上云平臺(tái)，控制臺(tái)界面上鼠標(biāo)操作幾個(gè)步驟即可準(zhǔn)備完畢幾臺(tái)新的計(jì)算節(jié)點(diǎn)，為我們節(jié)省了很多的購(gòu)買已經(jīng)設(shè)備和測(cè)試硬件設(shè)備的時(shí)間和精力，可謂方便至極。當(dāng)然這個(gè)也是我們需要向云廠商付費(fèi)的原因之一。

我們?cè)僬f(shuō)回容器云，用過(guò)云廠商容器云產(chǎn)品的同學(xué)應(yīng)該會(huì)知道，云廠商提供的容器產(chǎn)品相比原生的容器往往會(huì)有一些限制，這個(gè)時(shí)候如果我們不想直接使用云廠商提供的容器云產(chǎn)品，轉(zhuǎn)而使用云廠商提供的其他的計(jì)算產(chǎn)品自己部署容器環(huán)境，比如使用虛擬機(jī)或者使用物理機(jī)，這種情況下上文中我們講到的云廠商為我們提供的便利性就不存在了，當(dāng)然我們可以在容器所在宿主上對(duì)數(shù)據(jù)庫(kù)容器實(shí)例的資源使用進(jìn)行限制，這種方式的確可以，但相比直接使用虛擬機(jī)或者物理機(jī)部署數(shù)據(jù)庫(kù)實(shí)例這種容器化部署的方式更加復(fù)雜。

以上我們?cè)?/span>7個(gè)方面列舉了下數(shù)據(jù)庫(kù)不適合進(jìn)行容器化的原因，很多方面僅僅只是進(jìn)行了粗略的描述，尤其是在關(guān)鍵的有狀態(tài)部署和無(wú)狀態(tài)部署方面，由于此部分涉及對(duì)比的方面較多，在此下面我們專門單獨(dú)拿出來(lái)看下。

有狀態(tài) VS 無(wú)狀態(tài)

  Docker 及其編排技術(shù)的興起和逐步成熟讓大家由最初的要不要上容器轉(zhuǎn)為什么不用容器，但在業(yè)務(wù)容器化的過(guò)程中大家一般都會(huì)遇到這樣一個(gè)問(wèn)題：我們應(yīng)該將自己的數(shù)據(jù)庫(kù)實(shí)例跑在容器中嗎？                     

  要想回答這個(gè)問(wèn)題，我們不妨先回顧下容器技術(shù)出現(xiàn)的背景，即這門技術(shù)的出現(xiàn)是為了解決什么問(wèn)題。接觸容器比較早的話大家應(yīng)該記得容器技術(shù)主要是用在有臨時(shí)數(shù)據(jù)的無(wú)狀態(tài)服務(wù)上，也就是說(shuō)可以隨時(shí)起、隨時(shí)用、隨時(shí)銷毀(銷毀的組件包括容器中的緩存和數(shù)據(jù))，容器基本就是用來(lái)處理請(qǐng)求，可能還會(huì)保存一部分的臨時(shí)數(shù)據(jù)，且這部分?jǐn)?shù)據(jù)是允許丟失的。由于這種特性的存在，用戶不能將不允許丟失的數(shù)據(jù)存放在容器中，這類數(shù)據(jù)比如用戶上傳的文件、應(yīng)用的關(guān)鍵日志信息等，也是由于此特性的存在為數(shù)據(jù)庫(kù)的容器化帶來(lái)了障礙。

  有些同學(xué)可能會(huì)問(wèn)，通過(guò)給容器掛載volume不能解決嗎？ 的確，容器是有掛載volume的機(jī)制，volume 可將docker 容器所在的宿主機(jī)上的某個(gè)路徑掛載到容器中，這樣容器中的應(yīng)用可以將需要持久化的數(shù)據(jù)寫(xiě)入到volume掛載的路徑中，寫(xiě)入到volume 掛載路徑的數(shù)據(jù)實(shí)際會(huì)被寫(xiě)入到Docker 容器所在的宿主機(jī)上，這樣docker 容器銷毀之后我們需要的數(shù)據(jù)仍然存于容器所在的宿主機(jī)之上，不會(huì)丟失。這種方案看似比較合理，但是也存在一個(gè)很大的漏洞。使用容器的時(shí)我們一般通過(guò)保存鏡像的方式將容器中新增的數(shù)據(jù)保存到鏡像中，但是docker 容器的鏡像保存機(jī)制不能將容器中掛載的volume里的數(shù)據(jù)保存到鏡像中，如果容器中運(yùn)行的為我們的數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)的data路徑為docker容器的volume掛載路徑，當(dāng)我們保存容器鏡像時(shí)，由于剛剛講到的docker的特性，容器運(yùn)行后數(shù)據(jù)庫(kù)中新增的數(shù)據(jù)并不能被保存到鏡像中，不是很方便。由于數(shù)據(jù)庫(kù)有狀態(tài)特性的存在一定程度上限制了我們對(duì)數(shù)據(jù)庫(kù)實(shí)例的容器化。

  上面我們談到的volume 可以解決數(shù)據(jù)庫(kù)實(shí)例數(shù)據(jù)庫(kù)持久化的問(wèn)題只是在為引入容器編排的情況下的情況。實(shí)際使用中項(xiàng)目在使用容器部署應(yīng)用時(shí)一般都會(huì)引入容器的編排功能，最常見(jiàn)的容器編排工具，比如kubernetes。加入容器編排之后，假設(shè)我們將數(shù)據(jù)庫(kù)容器實(shí)例以有狀態(tài)服務(wù)的方式進(jìn)行運(yùn)行，那么問(wèn)題來(lái)了，如果數(shù)據(jù)庫(kù)容器實(shí)例漂移到了另一臺(tái)的宿主機(jī)上怎么辦，畢竟數(shù)據(jù)庫(kù)的數(shù)據(jù)還在漂移前的宿主機(jī)上。這個(gè)時(shí)候我們可能就需要將計(jì)算和存儲(chǔ)進(jìn)行分離，最常見(jiàn)的比如加入分布式存儲(chǔ)來(lái)解決這個(gè)問(wèn)題，如Ceph分布式存儲(chǔ)，這種方式的確是可以的，很多實(shí)用容器云的企業(yè)也是這樣操作的，但是引入Ceph會(huì)引入很多的復(fù)雜性，且企業(yè)內(nèi)的運(yùn)維人員不一定對(duì)Ceph存儲(chǔ)了如指掌，這種情況下我們?yōu)榱藢?shí)現(xiàn)數(shù)據(jù)庫(kù)容器化而額外引入的問(wèn)題可能比數(shù)據(jù)庫(kù)容器化帶來(lái)的便利性還要多。

總結(jié)

  上文中關(guān)于數(shù)據(jù)庫(kù)是否適合容器化的描述中我們更多的對(duì)比的是數(shù)據(jù)需要持久化的數(shù)據(jù)庫(kù)，以及需要特殊硬件環(huán)境才能運(yùn)行的數(shù)據(jù)庫(kù)。但大家都知道數(shù)據(jù)庫(kù)中眾多，并不是每一種都需要進(jìn)行數(shù)據(jù)的持久化，比如當(dāng)做緩存使用的數(shù)據(jù)庫(kù)，拿redis來(lái)說(shuō)，如果我們使用redis作為緩存或者用來(lái)存儲(chǔ)用戶會(huì)話這一類的數(shù)據(jù)，這種場(chǎng)景下數(shù)據(jù)庫(kù)的容器化不會(huì)涉及前文中提到的7個(gè)方面的限制，因此數(shù)據(jù)庫(kù)實(shí)例作為緩存這種場(chǎng)景時(shí)，數(shù)據(jù)庫(kù)實(shí)例的容器化也是合適的。

  從實(shí)際的使用來(lái)看，數(shù)據(jù)庫(kù)要不要容器化這個(gè)問(wèn)題并不是絕對(duì)的，需要結(jié)合具體的業(yè)務(wù)場(chǎng)景才能得出結(jié)論。比如，微服務(wù)的場(chǎng)景，如果我們的系統(tǒng)已經(jīng)實(shí)現(xiàn)了微服務(wù)化，數(shù)據(jù)庫(kù)實(shí)例的規(guī)?？梢愿鶕?jù)業(yè)務(wù)負(fù)載的實(shí)際情況進(jìn)行動(dòng)態(tài)的調(diào)整，這種場(chǎng)景下數(shù)據(jù)庫(kù)實(shí)例的微服務(wù)化是比較有意義的，一般也是比較推薦的，且很多業(yè)務(wù)做了微服務(wù)化改造的企業(yè)確實(shí)也是這樣做的。當(dāng)然微服務(wù)化的過(guò)程中數(shù)據(jù)庫(kù)的容器化也不是絕對(duì)的，筆者自己接觸的一些業(yè)務(wù)已經(jīng)微服務(wù)化落地的企業(yè)中就存在一些未對(duì)數(shù)據(jù)庫(kù)做微服務(wù)化改造的情況。

  筆者個(gè)人認(rèn)為數(shù)據(jù)庫(kù)的容器化像一般應(yīng)用的容器化那樣普及只是時(shí)間問(wèn)題，隨著Docker 及其周邊的配套技術(shù)的逐步成熟，相信在不久的將來(lái)大家會(huì)像使用Docker 容器部署應(yīng)用一樣來(lái)部署自己的各種數(shù)據(jù)庫(kù)實(shí)例，會(huì)像使用kubernetes 編排應(yīng)用的實(shí)例一樣來(lái)自由的編排自己的數(shù)據(jù)庫(kù)實(shí)例。

福利