不知何故，歷史上，IT產業出於某種原因被分成兩個有條件的陣營：「支持」和「反對」。 此外，爭議的主題可以是完全任意的。 哪個作業系統比較好：Win 還是 Linux？ 在 Android 或 iOS 智慧型手機上？ 您應該將所有內容儲存在雲端還是將其放在冷 RAID 儲存上並將螺絲放入保險箱中？ PHP人有資格被稱為程式設計師嗎？ 有時，這些爭議本質上完全是存在性的，除了體育利益之外沒有任何基礎。
碰巧的是，隨著容器的出現以及所有這些受人喜愛的 docker 和條件 k8s 的出現，「支持」和「反對」在後端各個領域使用新功能的爭論開始了。 (讓我們提前預約一下，雖然 Kubernetes 在本次討論中最常被稱為協調器，但這個特定工具的選擇並不重要。相反，您可以替換任何您認為最方便和熟悉的其他工具.)
而且，這似乎是同一枚硬幣的兩面之間的簡單爭議。 就像 Win 與 Linux 之間永恆的對抗一樣毫無意義和無情，在這種對抗中，有足夠的人存在於中間的某個地方。 但就容器化而言，並非一切都那麼簡單。 通常，在此類爭議中，沒有正確的一方，但在「使用」或「不使用」容器儲存資料庫的情況下，一切都顛倒了。 因為從某種意義上來說，這種做法的支持者和反對者都是對的。
美好的一面
光明面的論點可以用一句話來概括：“你好，2k19就在窗外！” 當然，這聽起來像是民粹主義，但如果你仔細研究一下情況，你會發現它有其優點。 現在讓我們來整理一下吧。
假設您有一個大型網路專案。 它最初可能是建立在微服務方法的基礎上的，或者在某個時候它是透過演進路徑實現的——事實上，這並不是很重要。 您將我們的專案分散到單獨的微服務中，設定編排、負載平衡和擴充。 現在，你問心無愧，在哈布拉效應期間在吊床上喝一杯莫吉托，而不是扶起倒下的服務器。 但在所有行動中你必須保持一致。 通常，只有應用程式本身（程式碼）被容器化。 除了代碼我們還有什麼？
沒錯，就是數據。 任何專案的核心都是它的資料：這可以是典型的DBMS - MySQL、Postgre、MongoDB，也可以是用於搜尋的儲存（ElasticSearch）、用於快取的鍵值儲存- 例如，redis 等。目前我們還沒有當資料庫因查詢編寫不當而崩潰時，我們將討論彎曲的後端實現選項，相反，我們將討論確保該資料庫在客戶端負載下的容錯能力。 畢竟，當我們對應用程式進行容器化並允許其自由擴展以處理任意數量的傳入請求時，這自然會增加資料庫的負載。
事實上，存取資料庫及其運行的伺服器的通道成為我們美麗的容器化後端的針眼。 同時，容器虛擬化的主要動機是結構的移動性和靈活性，這使我們能夠盡可能有效地在我們可用的整個基礎架構上組織尖峰負載的分配。 也就是說，如果我們不將系統的所有現有元素容器化並跨叢集推出，我們就會犯下一個非常嚴重的錯誤。
不僅對應用程式本身進行集群，而且對負責存儲資料的服務進行集群，這更符合邏輯。 透過在 k8s 中叢集和部署獨立工作的 Web 伺服器並在它們之間分配負載，我們已經解決了資料同步的問題 - 如果我們以某些媒體或部落格平台為例，貼文上的評論也是如此。 無論如何，我們都有一個叢集內的、甚至是虛擬的資料庫表示作為外部服務。 問題是資料庫本身還沒有集群化——部署在多維資料集中的 Web 伺服器從我們的靜態戰鬥資料庫中獲取有關更改的信息，該資料庫單獨輪換。
你感覺到有陷阱嗎？ 我們使用 k8s 或 Swarm 來分配負載並避免主 Web 伺服器崩潰，但我們不會對資料庫這樣做。 但如果資料庫崩潰，那麼我們的整個叢集基礎設施就沒有意義了——返回資料庫存取錯誤的空網頁有什麼用呢？
這就是為什麼不僅需要像通常那樣對 Web 伺服器進行集群，而且還需要對資料庫基礎架構進行集群。 只有這樣，我們才能確保一種結構在一個團隊中充分運作，但同時又相互獨立。 此外，即使我們的一半後端在負載下“崩潰”，其餘的也將倖存下來，集群內數據庫相互同步的系統以及無限擴展和部署新集群的能力將有助於快速達到所需的容量 -要是資料中心有機架就好了。
此外，分佈在叢集中的資料庫模型允許您將這個資料庫帶到需要的地方； 如果我們談論的是全球服務，那麼在舊金山地區的某個地方啟動網路集群，同時在訪問莫斯科地區的資料庫並返回時發送資料包是非常不合邏輯的。
此外，資料庫的容器化允許您在相同抽象層級建置系統的所有元素。 反過來，這使得開發人員可以直接從程式碼管理這個系統，而無需管理員的積極參與。 開發人員認為新的子專案需要一個單獨的 DBMS - 很簡單！ 寫一個yaml文件，上傳到叢集就完成了。
當然，內部操作也大大簡化了。 告訴我，你有多少次在新隊員把手伸進戰鬥資料庫工作時閉上眼睛？ 事實上，哪一個是您目前擁有且正在旋轉的唯一一個？ 當然，我們都是成年人，在某個地方我們有一個新的備份，甚至在更遠的地方——放著奶奶的黃瓜和舊滑雪板的架子後面——另一個備份，甚至可能在冷藏庫裡，因為你的辦公室曾經著火。 但儘管如此，每引入一個能夠訪問戰鬥基礎設施，當然還有戰鬥數據庫的新團隊成員，對周圍的每個人來說都是一桶有效的東西。 好吧，誰認識他，一個新手，也許他是交叉手？ 這很可怕，你會同意的。
容器化以及專案資料庫的分散式實體拓撲有助於避免此類驗證時刻。 不相信新手？ 好的！ 讓我們給他自己的叢集來使用，並將資料庫與其他叢集斷開連接 - 僅通過手動推送和同步輪換兩個密鑰（一個用於團隊領導，另一個用於管理員）進行同步。 每個人都很高興。
現在是時候轉變為資料庫叢集的反對者了。
暗面
在爭論為什麼不值得將資料庫容器化並繼續在一台中央伺服器上運行它時，我們不會屈從於正統的言辭和諸如“祖父在硬體上運行資料庫，我們也會！”之類的說法。 相反，讓我們試著設想一種情況，在這種情況下，容器化實際上會帶來切實的紅利。
同意，真正需要容器底座的項目即使不是最好的銑床操作員也可以用一隻手的手指來數出來。 在大多數情況下，甚至使用 k8s 或 Docker Swarm 本身也是多餘的 - 通常，由於技術的普遍炒作以及性別中“全能”的態度，而使用這些工具將一切都推向了現實。雲和容器。 嗯，因為現在它很時尚，每個人都這樣做。
至少在一半的情況下，在專案中使用 Kubernetes 或僅使用 Docker 是多餘的。 問題在於，並非所有受僱維護客戶基礎設施的團隊或外包公司都意識到這一點。 當容器被強加時情況會更糟，因為它會給客戶帶來一定數量的硬幣。
總的來說，有一種觀點認為 docker/cube 黑手黨愚蠢地壓垮了外包這些基礎設施問題的客戶。 畢竟，為了使用集群，我們需要有能力並且整體了解所實施解決方案的架構的工程師。 我們曾經在 Republic 出版物上描述過我們的案例 - 在那裡我們培訓了客戶的團隊在 Kubernetes 的現實中工作，每個人都感到滿意。 這很不錯。 通常，k8s「實施者」會劫持客戶的基礎設施 - 因為現在只有他們了解那裡的一切是如何運作的；客戶端方面沒有專家。
現在想像一下，透過這種方式，我們不僅外包 Web 伺服器部分，還外包資料庫維護。 我們說BD就是心臟，失去心臟對任何生物體來說都是致命的。 總之，前景並不是最好的。 因此，許多項目不應該大肆宣傳 Kubernetis，而應該不必理會 AWS 的正常費率，這將解決其網站/項目上的所有負載問題。 但 AWS 不再時尚，炫耀比金錢更有價值 - 不幸的是，在 IT 環境中也是如此。
好的。 也許該專案確實需要集群，但如果無狀態應用程式的一切都清楚了，那麼我們如何為集群資料庫組織良好的網路連接呢？
如果我們談論的是無縫工程解決方案，也就是向 k8s 的過渡，那麼我們主要頭痛的是群集資料庫中的資料複製。 一些 DBMS 最初非常忠實於其各個實例之間的資料分佈。 許多其他人則不那麼歡迎。 通常，為我們的專案選擇 DBMS 的主要論點不是能夠以最少的資源和工程成本進行複製。 特別是如果該項目最初並未計劃為微服務，而是簡單地朝這個方向發展。
我們認為沒有必要談論網路驅動器的速度——它們很慢。 那些。 如果發生任何情況，我們仍然沒有真正的機會在有更多資源（例如處理器能力或可用 RAM）的地方重新啟動 DBMS 實例。 我們很快就會遇到虛擬化磁碟子系統的效能問題。 因此，DBMS 必須固定在靠近的自己的個人機器上。 或者有必要以某種方式單獨冷卻足夠快的資料同步以用於假定的儲備。
繼續虛擬檔案系統的主題：不幸的是，Docker Volume 並非沒有問題。 一般來說，在長期可靠的資料儲存這樣的事情上，我想湊合使用技術上最簡單的方案。 而從容器的FS新增一個新的抽象層到父主機的FS本身就是一個風險。 但當容器化支撐系統的運作也遇到了這些層之間資料傳輸的困難時，那就真的是一場災難了。 目前，進步人類已知的大多數問題似乎都已被根除。 但你明白，機制越複雜，就越容易壞掉。
鑑於所有這些“冒險”，將資料庫保留在一個地方會更有利可圖，也更容易，即使您需要對應用程式進行容器化，也可以讓它自行運行，並透過分發網關接收與應用程式的同步通訊。資料庫，只能在一個地方讀取和寫入一次。 這種方法將錯誤和不同步的可能性降至最低。
我們要走向什麼？ 此外，資料庫容器化適用於真正需要的地方。 你不能填充一個完整的應用程式資料庫並像擁有兩打微服務一樣旋轉它 - 它不會那樣工作。 必須清楚地了解這一點。
而不是輸出
如果您正在等待「是否虛擬化資料庫」的明確結論，那麼我們會讓您失望：它不會在這裡。 因為在創建任何基礎設施解決方案時，我們不能以時尚和進步為指導，而首先必須以常識為指導。
有些專案與 Kubernetes 附帶的原理和工具完美契合，並且在這些專案中至少在後端領域是和平的。 還有一些項目不需要容器化，而是需要普通的伺服器基礎設施，因為它們從根本上無法重新擴展到微服務叢集模型，因為它們會崩潰。
來源： www.habr.com