最近看到一篇推文，痛述MySQL不能上容器的各種理由，基本是N年前的陳詞濫調(diào)，東拼西湊出的一篇水帖，文末對(duì)于數(shù)據(jù)庫是否能上容器，也是模糊不清，沒有確切的觀點(diǎn)，標(biāo)題倒是吸引眼球，不明就里的人容易產(chǎn)生一種傾向：數(shù)據(jù)庫不適合容器。

在如今這種信息泛濫的年代，好像否定一種事物，比接納他更容易引起共鳴，小編君也在自問：為什么數(shù)據(jù)庫容器化容易被否定？是他本身的邏輯導(dǎo)致的嗎？做為一名數(shù)據(jù)庫從業(yè)者，小編君舉雙手支持?jǐn)?shù)據(jù)庫容器化！

首先來看看數(shù)據(jù)庫能否容器化受到的各種質(zhì)疑：

▌?1. 如果容器突然崩潰，數(shù)據(jù)庫未正常關(guān)閉，可能會(huì)損壞數(shù)據(jù)

荒謬，按照這個(gè)邏輯，把容器兩字換成物理機(jī)，這句子念的也是通暢的吧？當(dāng)然數(shù)據(jù)持久化姿勢要正確，可以用PV/PVC外掛存儲(chǔ)或目錄的方式，數(shù)據(jù)IO直接透傳出容器，數(shù)據(jù)庫本身是有WAL日志保護(hù)的，只要磁盤不存在損壞，故障重啟后的日志前滾回滾，會(huì)保證commit的你看得見，未commit的你看不見。不管是容器，還是物理機(jī)，都是這套流程。而他們面對(duì)的崩潰導(dǎo)致異常的概率基本是一致的，可能物理機(jī)崩潰事還更大一點(diǎn)吧？

▌?2. 容器里共享數(shù)據(jù)卷組，對(duì)物理機(jī)硬件損傷也比較大

這個(gè)不知從何說起，容器也是一個(gè)OS進(jìn)程，他發(fā)起的IO也和其他原生態(tài)進(jìn)程一樣經(jīng)由內(nèi)核驅(qū)動(dòng)下發(fā)到硬件設(shè)備上，寫5TB的數(shù)據(jù)下去，既不會(huì)使硬盤變重，也不會(huì)破空擊傷了他的。我猜作者是擔(dān)心多個(gè)容器掛載了共享目錄，沒控制寫沖突，導(dǎo)致數(shù)據(jù)的邏輯損壞。這還是個(gè)姿勢問題，與容器無關(guān)了。

▌?3. 容器是無狀態(tài)的，對(duì)于數(shù)據(jù)庫這種IO密集型應(yīng)用，會(huì)拖垮IO性能

從本質(zhì)來講，容器是通過cgroup做的資源限額，通過命名空間做的用戶態(tài)隔離，單純CPU/內(nèi)存的測試，跟物理機(jī)是沒有區(qū)別的，IO層面使用的是aufs內(nèi)部文件系統(tǒng)，這一層的性能確實(shí)是差勁的，所以當(dāng)發(fā)現(xiàn)容器IO跑不起來時(shí)，建議你看看是否把某些密集操作，落到了aufs上，對(duì)于數(shù)據(jù)庫跑容器，都是使用的PV/PVC外掛透傳，瓶頸不在容器，而在外部設(shè)備,無論是吞吐還是IOPS，都可以無損消耗，所以該質(zhì)疑不成立。

▌?4. 容器不安全，擔(dān)心數(shù)據(jù)泄漏

小編君承認(rèn)，容器不如虛擬機(jī)安全，他共享os內(nèi)核，一些關(guān)鍵目錄隔離性不夠，鏡像本身的安全性等，似乎到處都是刺。但大家也要理解一點(diǎn)，容器輸出的是服務(wù)，虛擬機(jī)交付的是os，如果你硬是要把容器當(dāng)成os交付出去，安全肯定是打折扣的。就數(shù)據(jù)庫容器化而言，我最終給出的肯定是端口之類的服務(wù)暴露，所以這個(gè)安全是可控的。也許有人會(huì)問：你就沒有要進(jìn)入容器內(nèi)部去排錯(cuò)的時(shí)候嗎？ok，排錯(cuò)也是這套系統(tǒng)的管理服務(wù)人員，而非終端服務(wù)使用者。另外，既然上了容器化，他也有配套的可觀測系統(tǒng)，就不要再以管os的方式管容器了。

▌?5. 容器網(wǎng)絡(luò)復(fù)雜

所以從技術(shù)層面來看，把數(shù)據(jù)庫塞進(jìn)容器，會(huì)有一些學(xué)習(xí)和開發(fā)成本，但不是什么大的障礙。我們公司的數(shù)據(jù)庫融合平臺(tái)就是基于容器+K8S這條技術(shù)路線，目前支持主流數(shù)據(jù)庫的全生命周期管理，公有云Squids和私有云QFusion，可以滿足用戶線上線下雙軌需求，現(xiàn)已經(jīng)成功上線了多家客戶，在這個(gè)平臺(tái)的建設(shè)上小編君可以說說感受！

不知道是什么時(shí)候開始，數(shù)據(jù)庫這塊也開始聊"CI/CD"了，頻繁創(chuàng)庫成了一個(gè)高頻次操作，而維護(hù)開發(fā)/測試/生產(chǎn)數(shù)據(jù)庫環(huán)境的精準(zhǔn)一致性就顯得特別重要，中國已經(jīng)有240+數(shù)據(jù)庫廠商，琳瑯滿目。?

要在這種多庫多OS的排列組合下做到一次打包，多次使用，我們選了容器化這條路。

我們的squids.cn是直接基于公有云ECS提供RDS服務(wù)的，云主機(jī)種類繁多，還有arm/x86，本來以為適配工作會(huì)非常繁重，是容器化讓這個(gè)路徑大幅縮短。

我們有個(gè)客戶的數(shù)據(jù)庫資源池構(gòu)建也比較有意思，因?yàn)榍捌陬A(yù)算有限，機(jī)器規(guī)模一開始很小，那么就會(huì)有Mongo/Redis/MySQL可能擠到一臺(tái)機(jī)器上的情況，性能是扛得住的，但環(huán)境安裝很麻煩。要是以后再加一款新庫，所有機(jī)器還得更新一次。其實(shí)他就是需要將數(shù)據(jù)庫應(yīng)用和os層做解耦，容器的namespace隔離就非常適合。當(dāng)然虛擬化也可以做，但考慮到資源損耗，還有客戶那邊應(yīng)用研發(fā)正在力推容器化改造，就放棄了。

數(shù)據(jù)庫塞進(jìn)容器，只是第一步，還得有HA保護(hù)，備份恢復(fù)，升級(jí)擴(kuò)容，性能可觀測這些配套設(shè)施，就像火箭和火箭發(fā)射塔一樣，兩者結(jié)合，才能穩(wěn)定高效的運(yùn)行。最近幾年明顯感覺DBA這個(gè)行業(yè)開始快餐化了，都能上去耍一哈子，但精通的不多。不是人不聰明，而是我們的精力很難再聚焦，大家都是快速理解掌握，解決眼前的問題，立馬再下一站。未來可能都不再會(huì)有DBA這一職業(yè)了，所以將DBA的思想，經(jīng)驗(yàn)轉(zhuǎn)化為代碼，并不斷地根據(jù)場景、需求去調(diào)整，是長遠(yuǎn)之策。我們需要用平臺(tái)化、云原生的思路去構(gòu)建數(shù)據(jù)庫運(yùn)行的環(huán)境。

在K8S里面有一種控制器模式，你指定了運(yùn)行兩副本，那就一定是兩副本，不管是殺掉進(jìn)程，還是重啟關(guān)機(jī)，只要K8S的這一套體系還在，他就不斷的調(diào)整資源，達(dá)到你聲明的效果。這種倔強(qiáng)頑強(qiáng)的機(jī)制，就很適合數(shù)據(jù)庫HA檢測保護(hù)，我們只需要將數(shù)據(jù)庫復(fù)制，切換，故障檢測的業(yè)務(wù)邏輯封裝進(jìn)去，一套健壯的HA機(jī)制就可以運(yùn)行起來。K8S的Service服務(wù)暴露，也為數(shù)據(jù)庫集群切換提供了統(tǒng)一訪問入口，避免應(yīng)用修改連接串。再比如他的label標(biāo)簽，親和調(diào)度策略，對(duì)于池化的資源平衡能起到很好的效果。類似的例子還有很多。我們發(fā)現(xiàn)，一旦理解適應(yīng)了k8s這套體系后，你基于他去做數(shù)據(jù)庫平臺(tái)化的改造就會(huì)非常順暢，他幫你解決了很多底層的復(fù)雜邏輯，你專注數(shù)據(jù)庫業(yè)務(wù)就行。

也有人跟小編君探討過，他說你這些說的都對(duì)，但你說的每一個(gè)點(diǎn)，我都可以用非容器化，不借助k8s來實(shí)現(xiàn)掉。以前我一定會(huì)上去跟他爭的面紅脖子粗，現(xiàn)在不會(huì)了。我覺得我們只是在容器化，云原生的潮流下，選了順應(yīng)趨勢的技術(shù)路線，目前，我們受益匪淺！