所有的服務(wù)都開始了容器化升級(jí)，在一切皆容器的主流思想下，無狀態(tài)的服務(wù)采用容器化已經(jīng)是大勢(shì)所趨，常常困擾架構(gòu)師的一個(gè)問題是，數(shù)據(jù)庫是否需要容器化？

如果我們觀察 2017 年技術(shù)行業(yè)，容器和 Docker 依然將是最熱門的流行語。我們開始在每個(gè)領(lǐng)域的 Docker 容器中打包開發(fā)的軟件。從小型初創(chuàng)公司到巨大的微服務(wù)平臺(tái)都在使用容器技術(shù)。從 CI 平臺(tái)到 Raspberry Pi 。從數(shù)據(jù)庫到……

數(shù)據(jù)庫？您確定要將數(shù)據(jù)庫放在容器中嗎？

[[232155]]

不幸的是，這不是虛構(gòu)的場(chǎng)景。我看到許多快速增長(zhǎng)的項(xiàng)目將數(shù)據(jù)持久化到容器中。并且將計(jì)算服務(wù)和數(shù)據(jù)服務(wù)放在同一臺(tái)機(jī)器上。筆者希望有經(jīng)驗(yàn)的人不會(huì)用這個(gè)解決方案。

下面是我的觀點(diǎn)，數(shù)據(jù)庫容器化從今天來看是非常不合理的。

數(shù)據(jù)庫不適合容器化的7大原因

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

即使你要把 Docker 數(shù)據(jù)放在主機(jī)來存儲(chǔ) ，它依然不能保證不丟數(shù)據(jù)。 Docker volumes 的設(shè)計(jì)圍繞 Union FS 鏡像層提供持久存儲(chǔ)，但它仍然缺乏保證。

使用當(dāng)前的存儲(chǔ)驅(qū)動(dòng)程序，Docker 仍然存在不可靠的風(fēng)險(xiǎn)。 如果容器崩潰并數(shù)據(jù)庫未正確關(guān)閉，則可能會(huì)損壞數(shù)據(jù)。

2. 運(yùn)行數(shù)據(jù)庫的環(huán)境需求

?？吹?DBMS 容器和其他服務(wù)運(yùn)行在同一主機(jī)上。 然而這些服務(wù)對(duì)硬件要求是非常不同的。

數(shù)據(jù)庫（特別是關(guān)系型數(shù)據(jù)庫）對(duì) IO 的要求較高。 一般數(shù)據(jù)庫引擎為了避免并發(fā)資源競(jìng)爭(zhēng)而使用專用環(huán)境。如果將你的數(shù)據(jù)庫放在容器中，那么將浪費(fèi)你的項(xiàng)目的資源。 因?yàn)槟阈枰獮樵搶?shí)例配置大量額外的資源。 在公有云，當(dāng)你需要 34G 內(nèi)存時(shí)，你啟動(dòng)的實(shí)例卻必須開 64G 內(nèi)存。在實(shí)踐中，這些資源并未完全使用。

怎么解決？ 您可以分層設(shè)計(jì)，并使用固定資源來啟動(dòng)不同層次的多個(gè)實(shí)例。 水平伸縮總是比垂直伸縮更好。 

3. 網(wǎng)絡(luò)問題

要理解 Docker 網(wǎng)絡(luò)，您必須對(duì)網(wǎng)絡(luò)虛擬化有深入的了解。也必須準(zhǔn)備應(yīng)付好意外情況。你可能需要在沒有支持或沒有額外工具的情況下，進(jìn)行 bug 修復(fù)。

我們知道：數(shù)據(jù)庫需要專用的和持久的吞吐量，以實(shí)現(xiàn)更高的負(fù)載。我們還知道容器是虛擬機(jī)管理程序和主機(jī)虛擬機(jī)背后的一個(gè)隔離層。然而網(wǎng)絡(luò)對(duì)于數(shù)據(jù)庫復(fù)制是至關(guān)重要的，其中需要主從數(shù)據(jù)庫間 24/7 的穩(wěn)定連接。未解決的 Docker 網(wǎng)絡(luò)問題在1.9版本依然沒有得到解決。

把這些問題放在一起，容器化使數(shù)據(jù)庫容器很難管理。我知道你是一個(gè)頂級(jí)的工程師，什么問題都可以得到解決。但是，你需要花多少時(shí)間解決 Docker 網(wǎng)絡(luò)問題？將數(shù)據(jù)庫放在專用環(huán)境不會(huì)更好嗎？節(jié)省時(shí)間來專注于真正重要的業(yè)務(wù)目標(biāo)。

4. 狀態(tài)

在 Docker 中打包無狀態(tài)服務(wù)是很酷的，可以實(shí)現(xiàn)編排容器并解決單點(diǎn)故障問題。 但是數(shù)據(jù)庫呢？ 將數(shù)據(jù)庫放在同一個(gè)環(huán)境中，它將會(huì)是有狀態(tài)的，并使系統(tǒng)故障的范圍更大。下次您的應(yīng)用程序?qū)嵗驊?yīng)用程序崩潰，可能會(huì)影響數(shù)據(jù)庫。

5. 數(shù)據(jù)庫不適合使用主要的 Docker 功能

考慮容器中的數(shù)據(jù)庫，我們來思考它的價(jià)值。 我們先看看 Docker 官方對(duì)其的定義：

Docker 是為開發(fā)人員和系統(tǒng)管理員構(gòu)建，分發(fā)和運(yùn)行分布式應(yīng)用程序的開放平臺(tái)。 Docker 包括 Docker Engine（便攜式，輕量級(jí)運(yùn)行時(shí)和打包工具）以及 Docker Hub（用于共享應(yīng)用程序和自動(dòng)化工作流的云服務(wù)），Docker 使應(yīng)用程序能夠以組件快速組裝，并消除開發(fā)，QA 和生產(chǎn)環(huán)境之間的不同。 因此，IT 可以更快地分發(fā)程序，并在筆記本電腦，數(shù)據(jù)中心虛擬機(jī)和任何云上運(yùn)行相同的應(yīng)用程序。

根據(jù)該答案，我們可以很容易定義 Docke r的主要特性：

• 易于構(gòu)建新環(huán)境
• 易于重新部署（持續(xù)集成）
• 容易水平伸縮（從實(shí)踐得出）
• 易于維護(hù)環(huán)境一致

讓我們開始思考這些功能如何適應(yīng)數(shù)據(jù)庫世界。

容易設(shè)置數(shù)據(jù)庫？ 讓我們看看，容器化或者在本地運(yùn)行數(shù)據(jù)庫，在運(yùn)行上是否有巨大的差異。

docker run -d mongod:3.4 

對(duì)比：

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6 
echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list 
sudo apt-get update && sudo apt-get install -y mongodb-org 

易于構(gòu)建新環(huán)境？如果我們談?wù)撌?MongoDB集群 - 可能容器化效率更高。但是配置管理系統(tǒng)呢？它們旨在通過運(yùn)行一個(gè)命令來解決配置問題。使用 Ansible 你可以輕松設(shè)置幾十個(gè) Mongo 實(shí)例。正如你所看到的，沒有顯著的價(jià)值增長(zhǎng)。

容易重新部署？您重新部署數(shù)據(jù)庫升級(jí)到下一個(gè)版本的頻率是多少呢？數(shù)據(jù)庫升級(jí)不是可用性問題，而是工程問題（即在群集中的可用性）。想想你的應(yīng)用程序?qū)⑷绾问褂眯碌臄?shù)據(jù)庫引擎版本。引擎更換時(shí)可能導(dǎo)致的問題。

容易水平伸縮？是否要在多個(gè)實(shí)例之間共享數(shù)據(jù)目錄？你不害怕直接數(shù)據(jù)并發(fā)問題和可能的數(shù)據(jù)損壞嗎？使用專用數(shù)據(jù)環(huán)境部署多個(gè)實(shí)例不會(huì)更安全嗎？最后搞一個(gè)主從復(fù)制？

易于維護(hù)環(huán)境一致？數(shù)據(jù)庫實(shí)例環(huán)境的變化頻率如何？每天升級(jí)操作系統(tǒng)嗎？還是數(shù)據(jù)庫版本或依賴軟件變化頻繁？或者是不容易與工程團(tuán)隊(duì)達(dá)成共識(shí)？

最后看來，沒有一個(gè)特性足以讓我考慮數(shù)據(jù)庫容器化。

6. 額外的隔離對(duì)數(shù)據(jù)庫是不利的

其實(shí)我在第二點(diǎn)和第三點(diǎn)原因中提到了這一點(diǎn)。 但我把這個(gè)列為單獨(dú)的原因，因?yàn)槲蚁朐俅螐?qiáng)調(diào)這一事實(shí)。 我們擁有的隔離級(jí)別越多，我們獲得的資源開銷就越多。 相比專用環(huán)境而言，容易水平伸縮可以使我們得到更多的好處。 然而在 Docker 中水平伸縮只能用于無狀態(tài)計(jì)算服務(wù)，而不是數(shù)據(jù)庫。

我們沒有看到任何針對(duì)數(shù)據(jù)庫的隔離功能，那為什么我們應(yīng)該把它放在容器中？

7. 云平臺(tái)的不適用性

大部分人通過共有云開始項(xiàng)目。 云簡(jiǎn)化了虛擬機(jī)操作和替換的復(fù)雜性，因此不需要在夜間或周末沒有人工作時(shí)間來測(cè)試新的硬件環(huán)境。當(dāng)我們可以迅速啟動(dòng)一個(gè)實(shí)例的時(shí)候，為什么我們需要擔(dān)心這個(gè)實(shí)例運(yùn)行的環(huán)境？

這就是為什么我們向云提供商支付很多費(fèi)用的原因。 當(dāng)我們?yōu)閷?shí)例放置數(shù)據(jù)庫容器時(shí)，上面說的這些便利性就不存在了。因?yàn)閿?shù)據(jù)不匹配，新實(shí)例不會(huì)與現(xiàn)有的實(shí)例兼容，如果要限制實(shí)例使用單機(jī)服務(wù)，應(yīng)該讓 DB 使用非容器化環(huán)境，我們僅僅需要為計(jì)算服務(wù)層保留彈性擴(kuò)展的能力。

這 7 點(diǎn)適用于所有數(shù)據(jù)庫嗎？

也許不是全部，但是應(yīng)該是一切需要持久化數(shù)據(jù)的數(shù)據(jù)庫，以及所有具有特殊硬件環(huán)境要求的數(shù)據(jù)庫。

如果我們使用 Redis 作為緩存或用戶會(huì)話存儲(chǔ)- 使用容器就不應(yīng)該有任何問題。因?yàn)椴恍枰ＷC該數(shù)據(jù)落地，那么數(shù)據(jù)沒有丟失的風(fēng)險(xiǎn)。但是如果我們考慮使用 Redis 作為一個(gè)持久的數(shù)據(jù)存儲(chǔ)，那么你最好把數(shù)據(jù)放在容器外面，即使您不斷刷新 RDB 快照，在快速變化的計(jì)算集群中找到這個(gè)快照也會(huì)很復(fù)雜。

我們還可以談?wù)勅萜鲀?nèi)的 Elasticsearch。我們可以存儲(chǔ)在 ES 中的索引，并且可以從持久性數(shù)據(jù)源重建它們。但是看看要求！默認(rèn)情況下，Elasticsearch 需要 2 到 3GB 的內(nèi)存。由于 Java 的 GC，內(nèi)存使用并不一致。您確定Elasticsearch 適合用于資源限制的容器嗎？讓不同的 Elasticsearch 實(shí)例使用不同的硬件配置不是更好嗎？

不要擔(dān)心本地開發(fā)環(huán)境的數(shù)據(jù)庫容器化。將數(shù)據(jù)庫放在本地環(huán)境的容器中，你將節(jié)省大量的時(shí)間和精力。你將能夠復(fù)制生產(chǎn)環(huán)境操作系統(tǒng)。原生Postgres for OS X或Windows不是100％兼容Linux版本。在主機(jī)操作系統(tǒng)上設(shè)置容器而不是軟件包，你會(huì)克服這種問題。

結(jié)論

Docker 的炒作應(yīng)該有一天會(huì)冷下來。 這并不意味著人們將停止使用容器虛擬化技術(shù)，而是說我們?cè)趯⑷萜骰O(shè)計(jì)時(shí)，需要將其帶來的價(jià)值放在首要考量因素。

幾天前我看到了一個(gè)關(guān)于在零亂的 Ruby 世界中框架如何生存的演講。 從這個(gè)演講中我得到的啟發(fā)是技術(shù)炒作周期，借用這個(gè)炒作周期的說法，我們看到 Docker 目前在第二階段（充滿期望的高峰）太長(zhǎng)時(shí)間（高可用架構(gòu)小編：參看資源1），當(dāng)我們?cè)谧詈笠粋€(gè)階段看到 Docker 時(shí)，情況將會(huì)正?；?我認(rèn)為我們需要對(duì)這種過程負(fù)責(zé)，并應(yīng)該加快這一進(jìn)程。