點選「 IT碼徒 」， 關註，置頂 公眾號
每日技術幹貨，第一時間送達！
每當有鐵子問到一些環境的搭建和部署問題時，總是會習慣性的問一句： 學習還是線上 ？學習的話，能 Docker 就無腦 Docker 部署，省時省力，比如安裝個MySQL，一條命令就搞定了，用完容器一刪，幹幹凈凈；如果在物理機上面安裝MySQL，不僅會浸入電腦，而且還可能面臨各種問題，結果是還沒開始學，卻被環境給難住了。
但我的建議僅限於個人學習，如果部署線上環境，那就得綜合考試當前的服務是否適合容器化；
容器
的定義：容器是為了解決「在切換執行環境時，如何保證軟體能夠正常執行」這一問題。
目前，容器和 Docker 依舊是技術領域最熱門的詞語，無狀態的服務容器化已經是大勢所趨，同時也帶來了一個熱點問題被大家所爭論不以： 資料庫 MySQL 是否需要容器化？
認真分析大家的各種觀點，發現贊同者僅僅是從容器優勢的角度來闡述 MySQL 需要容器化，幾乎沒有什麽業務場景進行驗證自己的觀點；反過來再看反對者，他們從效能、數據安全等多個因素進行闡述 MySQL不需要容器化，也舉證了一些不適合的業務場景。下面，我們就聊一下 Docker 不適合跑 MySQL 的 N 個原因！
數據安全問題
不要將數據儲存在容器中，這也是 Docker 官方容器使用技巧中的一條。容器隨時可以停止、或者刪除。當容器被rm掉，容器裏的數據將會遺失。為了避免數據遺失，使用者可以使用數據卷掛載來儲存數據。但是容器的 Volumes 設計是圍繞 Union FS 映像層提供持久儲存，數據安全缺乏保證。如果容器突然崩潰，資料庫未正常關閉，可能會損壞數據。另外，容器裏共享數據卷組，對物理機硬體損傷也比較大。
效能問題
大家都知道，MySQL 屬於關系型資料庫，對IO要求較高。當一台物理機跑多個時，IO就會累加，導致IO瓶頸，大大降低 MySQL 的讀寫效能。
在一次Docker套用的十大難點專場上，某國有銀行的一位架構師也曾提出過：「資料庫的效能瓶頸一般出現在IO上面，如果按 Docker 的思路，那麽多個docker最終IO請求又會出現在儲存上面。現在互聯網的資料庫多是share nothing的架構，可能這也是不考慮遷移到 Docker 的一個因素吧」。
其實也有相對應的一些策略來解決這個問題，比如：
1）資料庫程式與數據分離
如果使用Docker 跑 MySQL，資料庫程式與數據需要進行分離，將數據存放到共享儲存，程式放到容器裏。如果容器有異常或 MySQL 服務異常，自動啟動一個全新的容器。另外，建議不要把數據存放到宿主機裏，宿主機和容器共享卷組，對宿主機損壞的影響比較大。
2）跑輕量級或分布式資料庫
Docker 裏部署輕量級或分布式資料庫，Docker 本身就推薦服務掛掉，自動啟動新容器，而不是繼續重新開機容器服務。
3）合理布局套用
對於IO要求比較高的套用或者服務，將資料庫部署在物理機或者KVM中比較合適。目前騰訊雲的TDSQL和阿裏的Oceanbase都是直接部署在物理機器，而非Docker 。
狀態問題
在 Docker 中水平伸縮只能用於無狀態計算服務，而不是資料庫。
Docker 快速擴充套件的一個重要特征就是無狀態，具有數據狀態的都不適合直接放在 Docker 裏面，如果 Docker 中安裝資料庫，儲存服務需要單獨提供。
目前，騰訊雲的TDSQL（金融分布式資料庫）和阿裏雲的Oceanbase（分布式資料庫系統）都直接執行中在物理機器上，並非使用便於管理的 Docker 上。
資源隔離方面
資源隔離方面，Docker 確實不如虛擬機器 KVM，Docker是利用 Cgroup 實作資源限制的，只能限制資源消耗的最大值，而不能隔絕其他程式占用自己的資源。如果其他套用過渡占用物理機資源，將會影響容器裏 MySQL 的讀寫效率。
需要的隔離級別越多，獲得的資源開銷就越多。相比專用環境而言，容易水平伸縮是Docker的一大優勢。然而在 Docker 中水平伸縮只能用於無狀態計算服務，資料庫並不適用。
難道 MySQL 不能跑在容器裏嗎？
MySQL 也不是全然不能容器化。
1）對數據遺失不敏感的業務（例如使用者搜尋商品）就可以數據化，利用資料庫分片來來增加例項數，從而增加吞吐量。
2）docker適合跑輕量級或分布式資料庫，當docker服務掛掉，會自動啟動新容器，而不是繼續重新開機容器服務。
3）資料庫利用中介軟體和容器化系統能夠自動伸縮、容災、切換、內建多個節點，也是可以進行容器化的。
典型案例：同程旅遊、京東、阿裏的資料庫容器化都是不錯的案例，大家可以自行去檢視。
來源：toutiao.com/article/6675622107390411276
— END —
PS：防止找不到本篇文章，可以收藏點贊，方便翻閱尋找哦。
往期推薦
