不知何故，历史上，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 附带的原理和工具完美契合，并且在这些项目中至少在后端领域是和平的。 还有一些项目不需要容器化，而是需要普通的服务器基础设施，因为它们从根本上无法重新扩展到微服务集群模型，因为它们会崩溃。
来源： habr.com