吵了6年的資料庫話題，會在馮若航這裏終結嗎？

2024-07-04碼農

談及在 k8s/Docker 上部署資料庫服務時，業界意見分歧顯著，形成了一場圍繞「資料庫容器化」的持久辯論。

一方面，支持者強調 k8s 在提供環境無關性、自動化運維及資源最佳化方面的潛力；另一方面，反對者則擔憂資料庫的特殊需求與 k8s 的設計理念存在沖突，可能導致安全、效能及成本效率上的挑戰。

本文跟蹤了一下這場持續六七年的辯論，從 Mikhail Chinkov 與王淵命的早期論戰，到王竹鋒、姜承堯對於在 k8s 上部署資料庫的必要性思考，以及馮若航提到的可能面臨的「雙輸」情況，來看看資料庫容器化在 k8s 生態中的爭議與前景。

第一回合：Mikhail Chinkov VS. 王淵命：資料庫容器化合理嗎？

2017 年，Docker 宣布完成 7500 萬美元融資，其總市值達到了 13 億美元，這標誌著容器技術在 IT 領領域的巨大潛力和影響力。

當時 Docker 的發展如日中天，幾乎成了容器的代名詞。

與此同時，一篇 【為什麽資料庫不適合容器】 （中文版：）引發了一場技術圈內的激烈辯論。

作者 Mikhail Chinkov 提出了資料庫容器化並不合理的觀點，並列舉了七大理由，包括數據安全、執行環境匹配、網路挑戰、狀態問題、與 Docker 核心功能的協調性、過度隔離的負擔以及雲平台套用的局限性。

數據不安全：Docker 數據儲存在主機上仍面臨遺失風險，Docker volumes 基於 Union FS 設計，但缺乏數據保護的絕對保障。容器崩潰可能導致資料庫損壞，尤其是未正確關閉時。

執行環境不匹配：資料庫管理系統（DBMS）與其它服務共用主機時，因硬體需求差異大，可能導致資源浪費。資料庫對 I/O 要求高，通常需專用環境。水平擴充套件優於垂直擴充套件，但容器化資料庫可能需要過多資源調整。

網路挑戰：Docker 網路復雜，需深入理解網路虛擬化且常遇未解決的 bug。資料庫復制需主從間穩定連線，而 Docker 網路問題可能影響這點，增加管理難度。

狀態問題：容器化適合無狀態服務，資料庫作為有狀態服務加入容器環境會增加系統故障範圍，套用崩潰可能波及資料庫。

與 Docker 核心功能不協調：資料庫套用並不直接獲益於 Docker 的便捷構建、快速部署、水平擴充套件和環境一致性等優點，這些特性對資料庫管理來說價值有限。

過度隔離的負擔：容器化的額外隔離層導致資源開銷增加，對資料庫而言，這種隔離並未帶來顯著好處，反而可能不如專用環境高效。

雲平台套用局限：在雲環境中，容器化資料庫並未利用雲平台的便捷性，如快速啟動例項和環境一致性。資料庫容器化可能與雲服務的彈性擴充套件和管理便利性不相容，限制了雲服務的優勢。

毫不意外，文章的觀點遭到了諸多反對。

技術極客王淵命認為資料庫容器化具有重要的價值，撰寫了一文進行反駁。

王淵命曾任新浪微博架構師、微米技術總監，2014 年作為聯合創始人創立團隊協作 IM 服務 Grouk，2016 年加入青雲從事容器方面開發。

對於 Mikhail Chinkov 的質疑，王淵命逐一分析並指出：

安全方面，容器實際上增加了隔離層，提升了安全性。

IO 效能方面，容器通常不對 IO 進行限制，與宿主機差異不大。

網路問題，容器網路方案成熟且多樣化，使用者可根據需要選擇。

成本方面，容器技術的接納成本相對較低，且長期收益顯著。

他認為，資料庫部署和運維之間存在巨大鴻溝，傳統方法難以滿足高可用、易維護等需求。而容器技術，特別是 Docker 和 k8s，透過提供環境無關的封裝、基礎架構的可編程性、動態排程與編排能力，能夠幫助構建自動化高可用資料庫服務，減少人為錯誤，促進運維經驗的沈澱和復用。

引入容器固然會帶來的技術成本和風險，如安全性、IO 效能、網路效能等方面，但這些成本和風險相對於收益來說是可以接受的。「即便是它現在存在著許多問題，但絕對是一個潛力股，值得投入。」

遺憾的是，Mikhail Chinkov 和王淵命這場爭論沒有來回交鋒，對於很多問題的討論還不夠深入。

但這恰恰激發了更多人的思考：資料庫容器化，是否就是一場雙刃劍的遊戲呢？

這場技術論戰，當然不會就這樣草草結束。

圖片來源於 Mikhail Chinkov 個人部落格

第二回合：王竹鋒 VS. 姜承堯：資料庫上 k8s 有必要嗎？

四年之後，又開始了新一輪的討論，只不過，一些新情況的出現了。

在容器編排領域，相較於 Docker，Kubernetes 在企業采用率、社群活躍度和技術發展趨勢上明顯占據了優勢，討論的物件從 docker 變成了 k8s。

關於是否應該在 k8s 上部署資料庫，爭論的焦點已經發生了變化。

在 k8s 的早期版本中，可能更適合無狀態服務，不適用於部署有狀態服務，而資料庫就是典型的有狀態服務。

因為 k8s 的初衷是提供一個能夠自動化部署、可延伸、套用容器可營運的平台。無狀態服務通常更符合這些設計目標，因為它們沒有持久化狀態，可以輕松地進行擴充套件和故障恢復。

但從 1.5 版本開始，k8s 引入了 StatefulSet 控制器來支持有狀態服務，並且這一功能自引入後就持續前進演化，對有狀態服務的支持不斷成熟，包括對數據持久化、儲存卷管理、網路策略等特性的增強，使得資料庫已經可以很好地執行在 k8s 上。

不支持有狀態服務，已經不是 k8s 明顯的弱點。因此，爭論的焦點變成了，在 k8s 上部署資料庫，是業務所需嗎？

去哪兒網資料庫總監的王竹鋒在【】中認為，在 docker/k8s 部署 MySQL 是隔靴搔癢，作繭自縛。言辭頗為犀利。

你想上 k8s，是為了解決什麽問題？編排部署安裝找資源的問題？

MySQL 是一個有狀態的大型通用資料庫，這麽重儲存的服務，找資源安裝，問題很大嗎？

又說是資源隔離的問題，資源隔離的需求很緊迫嗎？單機單例項就不說了，即使在單機多例項的情況下，也沒幾個例項，並且 MySQL 本身內部就是多執行緒的，均衡問題也比較好，同一台機器上一個例項影響其它例項的案例少之又少，所以這需求有那麽緊迫嗎？

而且對於使用 MySQL 沒有上到一定量級的情況下，非 k8s 的自動化平台就可以很好的解決資源部署安裝編排的問題，為了解決這個問題，創造一個上 k8s 的大問題，這樣就有點和初衷背道而馳了。

同時 k8s 是一個新的技術棧，支撐它上線，是需要另一個專業團隊來做的，投入產出比非常低。

我反過來再問一下， MySQL 本身的問題你解決完了嗎？慢查詢有沒有好的工具去最佳化？主從切換能不能不影響業務？機器掛了能不能不丟數據？資料庫服務能不能做到不同機房的多活？自動化 SQL 稽核可以自助服務了嗎？如果哪個沒做到，那就先放棄 k8s 吧。

再者，我們專業的 MySQL 運維技術人員，非要作繭自縛，給 MySQL 套一個殼，出了問題，是殼的問題？還是 MySQL 本身的問題？

當引入一個變量的時候，可服務率肯定就會有一定程度的下降，因為 99.99%*99.99% 的結果是 99.98%。

總結來說就是，對於資源不足的公司來說，沒必要將 MySQL 部署到 k8s，而且收益並不大，還可能引入新的問題，應該先確保現有的 MySQL 問題得到妥善解決。

姜承堯在一文中對王竹鋒的觀點進行了肯定，認為其正確之處在於資料庫需要先滿足業務的需求。但顯然他不滿意僅僅只有這一個說法。

姜承堯擁有近 15 年的 MySQL 內核研發、運維和管理經驗，曾任騰訊雲資料庫技術負責人，在 MySQL 技術和開源社群領域有很高的知名度和影響力。

他提到，不是資料庫需要跑在 k8s 上，而是業務需要資料庫提供這樣的服務能力。" 在 k8s 上跑資料庫的意義在於，可以提供資料庫服務，也就是 DBaaS，能夠解決開發過程中面臨的業務多環境部署的問題，這是 Paas 辦不到的。"

所謂多環境部署，不是指一個業務部署在騰訊雲、阿裏雲等多個雲環境，因為這種情況機率不大，而是指研發過程中會面臨的開發環境、自測環境、聯調環境、UAT 環境、生產環境等多環境。不僅要保證這些環境和最終的生產環境是一致，還要保證各個環境資料庫的表結構、索引一致。

「這款資料庫服務不僅提供資料庫存取，還提供資料庫例項的自愈、故障轉移、負載均衡、備份、監控、日常操作等一系列的資料庫配套工具。同時，這個資料庫服務可以透過映像、編排、容器等技術快速復制到不同研發和生產環境，對業務使用者提供極致的 CI、CD、CO 體驗。」

姜承堯認為，雖然將資料庫部署在 k8s 上還存在這樣或者那樣的問題，但 Cloud Native Database，DBaaS 的趨勢不可逆轉。

馮若航：將資料庫放入 k8s 中會導致「雙輸」

「k8s 為資料庫帶來的收益相比其引入的問題與麻煩，實在是微不足道。」開源計畫 Pigsty 的作者馮若航在 【】 中表示，在分布式網路儲存的可靠性與效能超過本地儲存前，將資料庫放入 k8s 是一種不明智的選擇。

盡管 k8s 提供了諸如 StatefulSet、PV、PVC、LocalhostPV 等抽象原語用於支持有狀態服務（i.e. 資料庫），但這些東西對於執行有著更高可靠性要求的生產級資料庫服務來說仍然遠遠不夠。

資料庫是「寵物」而非「家畜」，需要細心地照料呵護。將資料庫放入 k8s 作為「牲畜」對待，本質上是將外部的磁盤 / 檔案系統 / 儲存服務變為了新的「資料庫寵物」。

使用 EBS / 網路儲存 / 雲盤執行資料庫，在可靠性與效能上有巨大劣勢；然而如果使用高效能本地 NVMe 磁盤，與節點繫結無法排程的資料庫又失去了放入 k8s 的主要意義。

將資料庫放入 k8s 中會導致「雙輸」 —— k8s 失去了無狀態的簡單性，不能像純無狀態使用方式那樣靈活搬遷排程銷毀重建；而資料庫也犧牲了一系列重要的內容：可靠性，安全性，效能，以及復雜度成本，卻只能換來有限的「彈性」與資源利用率 —— 但虛擬機器也可以做到這些！對於公有雲廠商之外的使用者來說，幾乎都是弊遠大於利的。

以 k8s 為代表的「雲原生」狂熱已經成為了一種畸形的現象：為了 k8s 而上 k8s。

工程師想提高不可替代性堆砌額外復雜度，管理者怕踩空被業界淘汰互相卷著上線。

騎自由車就能搞定的事情非要開坦克來刷經驗值 / 證明自己，卻不考慮要解決的問題是否真的需要這些屠龍術 —— 這種架構雜耍行為終將招致惡果。

馮若航

作為 PostgreSQL 專家和全棧開發者，馮若航對資料庫管理、開發以及最佳化有著深厚的理解和經驗，經常在其主理的公眾號「非法加馮」公開發表觀點。同時他是一名活躍的開源貢獻者，其開源的 Pigsty 是一個旨在替代 Amazon RDS PostgreSQL 服務的開源解決方案。

8 月 16 日，馮若航將以特邀嘉賓的身份出席 GOTC 2024 「開源資料庫與 AI 協同創新」論壇，並行表主題演講。

「開源資料庫與 AI 協同創新」論壇還將邀請 Byzer 社群 PMC / 資深數據架構師、Kyligence 技術合夥人祝海林，愛可生 AI 創新事業部負責人蘇鵬，與馮若航一起探討智慧索引最佳化、資料壓縮革新、自動化運維進階、業務決策智慧化、AI 與資料庫的融合未來、實戰案例剖析等方面，探索 AI 與資料庫領域的結合能夠為行業帶來怎樣革命性的變革。

報名通道現已開啟，
誠邀全球各技術領域開源愛好者共襄盛舉！

掃碼或長按辨識二維碼

8 月 15 日至 16 日，GOTC 2024 將在上海張江科學會堂盛大開啟。

GOTC 2024 將與上海浦東軟體園聯合舉辦，並結合「 GOTC（全球開源技術峰會）」與「 GOGC（全球開源極客嘉年華）」，旨在打造一場全新開源盛會。2024 全球開源極客嘉年華（GOGC 2024）由浦東軟體園攜手 S 創共建，與開放原子開源基金會、開源中國、Linux 基金會等品牌聯合呈現。

此次大會將集結全球範圍內對開源技術充滿熱情的開發者、社群成員、創業者、企業領袖、媒體人，以及各開源計畫套用場景的產業精英、跨界才俊與年輕力量。透過主題演講、圓桌討論、創新集市、人才集市、黑客松、技術展示和互動工作坊等形式，與會者將有機會交流實踐經驗、探索前沿技術，讓我們一起激發創新活力、展示開源魅力、促進跨領域合作。

更多資訊，存取官網檢視：
https://gotc.oschina.net

參考連結：

為什麽資料庫不適合容器

https://myopsblog.wordpress.com/2017/02/06/why-databases-is-not-for-containers/

資料庫不適合 Docker 及容器化的 7 大原因

https://mp.weixin.qq.com/s/bx_zgJs88GljYH0zdvDCTQ

資料庫容器化的價值 —— 反駁資料庫不適合容器化的錯誤觀點

https://mp.weixin.qq.com/s/9OzNAALcy2OLdl3blOHMRg

一個資料庫十年老兵的思考與總結

https://mp.weixin.qq.com/s/un84g7fUMrn5Yp8Vcfj8-Q

在 Kubernetes 上跑資料庫，真的沒有意義麽？

https://mp.weixin.qq.com/s/vEg8Y65JDmw3JTkOxNzZ1g