最近看到一篇推文，痛述MySQL不能上容器的各種理由，基本是N年前的陳詞濫調，東拼西湊出的一篇水帖，文末對于數據庫是否能上容器，也是模糊不清，沒有確切的觀點，標題倒是吸引眼球，不明就里的人容易產生一種傾向：數據庫不適合容器。
在如今這種信息泛濫的年代，好像否定一種事物，比接納他更容易引起共鳴，小編君也在自問：為什么數據庫容器化容易被否定？是他本身的邏輯導致的嗎？做為一名數據庫從業者，小編君舉雙手支持數據庫容器化！
首先來看看數據庫容器化受到的各種質疑：
▌ 1. 如果容器突然崩潰，數據庫未正常關閉，可能會損壞數據
荒謬，按照這個邏輯，把容器兩字換成物理機，這句子念的也是通暢的吧？當然數據持久化姿勢要正確，可以用PV/PVC外掛存儲或目錄的方式，數據IO直接透傳出容器，數據庫本身是有WAL日志保護的，只要磁盤不存在損壞，故障重啟后的日志前滾回滾，會保證commit的你看得見，未commit的你看不見。不管是容器，還是物理機，都是這套流程，兩者面對的崩潰導致異常的概率基本是一致的，可能物理機崩潰事還更大一點吧？
▌ 2. 容器里共享數據卷組，對物理機硬件損傷也比較大
這個不知從何說起，容器也是一個OS進程，他發起的IO也和其他原生態進程一樣經由內核驅動下發到硬件設備上，寫5TB的數據下去，既不會使硬盤變重，也不會破空擊傷了他，我猜作者是擔心多個容器掛載了共享目錄，沒控制寫沖突，導致數據的邏輯損壞。這還是個姿勢問題，與容器無關了。
▌ 3. 容器是無狀態的，對于數據庫這種IO密集型應用，會拖垮IO性能
從本質來講，容器是通過cgroup做的資源限額，通過命名空間做的用戶態隔離，單純CPU/內存的使用，跟物理機是沒有區別的，IO層面使用的是aufs內部文件系統，這一層的性能確實差勁，當發現容器IO跑不起來時，建議你看看是否把某些密集操作，落到了aufs上。對于數據庫跑容器，都是使用的PV/PVC外掛透傳，瓶頸不會是容器，無論是吞吐還是IOPS，都可以無損消耗，所以該質疑不成立。
▌ 4. 容器不安全，擔心數據泄漏
小編君承認，容器不如虛擬機安全，他共享os內核，一些關鍵目錄隔離性不夠，鏡像本身的安全性等，似乎到處都是刺。但大家也要理解一點，容器輸出的是服務，虛擬機交付的是os，如果你硬是要把容器當成os交付出去，安全肯定是打折扣的。就數據庫容器化而言，最終給出的肯定是端口之類的服務暴露，所以這個安全是可控的。也許有人會問：你就沒有要進入容器內部去排錯的時候嗎？ok，排錯也是這套系統的管理服務人員，而非終端服務使用者。另外，既然上了容器化，他也有配套的可觀測系統，就不要再以管os的方式管容器了。
所以從技術層面來看，把數據庫塞進容器，會有一些學習和開發成本，但不是什么大的障礙。我們公司的數據庫融合平臺就是基于容器+K8S這條技術路線，目前支持主流數據庫的全生命周期管理，公有云Squids和私有云QFusion，滿足用戶線上線下雙軌需求，現已經成功上線了多家客戶，在這個平臺的建設上小編君可以說點感受！
不知什么時候開始，數據庫這塊也開始聊"CI/CD"了，頻繁創庫居然成了一個高頻次操作，維護開發/測試/生產數據庫環境的精準一致性就顯得特別重要，中國已經有240+數據庫廠商，要在這種多庫多OS的排列組合下做到一次打包，多次使用是不容易的，例如squids.cn是直接基于公有云ECS提供RDS服務的，6大云廠商，各種os，CPU還有arm/x86，機型達1700種，本來以為適配工作會非常繁重，是容器化讓這個路徑大幅縮短，我們將每款數據庫的環境依賴，最優配置固化到了一個小盒子里，送到了全球各地。我們有個客戶的數據庫資源池構建也比較有意思，因為前期預算有限，機器規模一開始很小，那么就會有Mongo/Redis/MySQL可能擠到一臺機器上的情況，性能是扛得住的，但環境安裝很麻煩。要是以后再加一款新庫，所有機器還得更新一次。其實他就是需要將數據庫和os層解耦，容器鏡像隔離就非常適合，當時也調研過虛擬化方案，資源損耗比較大，而客戶的研發部也在力推應用容器化改造，虛擬化就放棄了。
數據庫塞進容器，只是第一步，還得有HA保護，備份恢復，升級擴容，性能可觀測這些配套設施，就像火箭和火箭發射塔一樣，兩者結合，才能穩定高效的運行，而很多時候，這些配套設施都留在DBA的腦子里，或者某些shell腳本里，最近幾年小編君明顯感覺DBA這個行業開始快餐化了，誰都能上去耍一哈子，但精通的不多。不是人不聰明，而是我們的精力很難再聚焦，大家都是快速理解掌握，解決眼前的問題，立馬下一站。未來可能都不再會有DBA這一職業了，所以將DBA的思想，經驗轉化為代碼，并不斷地根據場景、需求去調整，是長遠之策。我們需要用平臺化、云原生的思路去構建數據庫運行的環境。
在選擇容器化方向后，自然就會引入K8S，最初團隊是非常不適應的，特別是他的網絡策略，而數據持久性，高可用，故障切換，備份恢復都需要迎合K8S的特點去實現，這個過程很痛苦，否定一個工具有兩種可能，這個工具不行，或者你這個人不行，經過艱難的摸索后，我們也逐漸找到了感覺，例如在K8S里面有一種控制器模式，你指定了運行兩副本，那就一定是兩副本，不管是殺掉進程，還是重啟關機，只要K8S的這一套體系還在，他就不斷的調整資源，達到你聲明的效果，這種倔強的脾氣，就很適合數據庫HA檢測和故障保護，我們只需要將數據庫復制，切換，故障檢測的業務邏輯封裝進去，一套健壯的HA機制就可以運行起來，K8S的Service服務暴露，可以為業務訪問提供統一入口，即使數據庫飄了，也不用應用修改連接串。再比如K8S的label標簽，親和調度策略，對于池化資源平衡能起到很好的效果，類似的例子還有很多，在資源調度，自動化，故障自愈，健壯性上，K8S似乎給了我們很多可能。我們發現，一旦理解適應了K8S這套體系，你基于他去做數據庫平臺化建設是非常順暢的，他解決了很多底層的復雜邏輯，你專注數據庫業務就行。所以當我們基于K8S完成了MySQL這貨的全生命周期管理后，后面的什么SQLServer,Oracle,Redis,Mongo.....全都不是事。
也有人跟我探討過，他說你這些說的都對，但你說的每一個點，我都可以用非容器化，非K8S的方式來實現，換以前小編君會跟他battle的，現在年紀大沒力氣了。我覺得我們只是在容器化，云原生的潮流下，選了順應趨勢的技術路線，目前，受益匪淺！！！
▌ 本文作者：羅春，沃趣科技聯合創始人&產品總架構師
Squids 官網：www.squids.cn
Squids是多云時代的數據庫云服務提供商，基于公有云基礎資源，提供云上RDS，云備份，云遷移，SQL窗口等企業級數據庫服務功能，幫助企業快速構建云上數據庫融合生態。
服務電話： 400-678-1800 （周??周五 09:00-18:00）
商務合作： 0571-87770835
市場反饋： marketing@woqutech.com
地址： 杭州市濱江區濱安路1190號智匯中?A座1101室
0571-87770835