用自己的数据库部署微服务：如何保证复制和可靠性？答案

【问题标题】：Deploying a microservice with its own database: how to guarantee replication and reliability?用自己的数据库部署微服务：如何保证复制和可靠性？
【发布时间】：2020-11-19 08:31:15
【问题描述】：

我正在构建一个要部署在云环境中的应用程序。我正在使用 Kubernetes 和 Docker。

我的映像包含两个容器：一个用于应用程序，另一个用于 Postgres DBMS（包括它自己的数据库，通过持久卷声明存储）。

我这样做是因为这样我可以线性扩展我的应用程序，因为我的主要要求是能够像那样扩展它。

所以当我扩展我的部署时，它看起来或多或少像下面的图（我的应用程序有 N 个 pod）：

我已经对该架构进行了性能测试，它非常适合我的需求，并且可以根据我的需要进行扩展。

但是，我担心数据复制及其可靠性。

所以这是我的问题：

如何使用这种类型的架构进行复制？ Kubernetes 有没有办法通过特定的存储类来处理它？最好的方法是什么？
一般而言，在研究此架构时，DBA 的期望是什么？是否可以接受，因为我最终可能会使用太多数据库？

【问题讨论】：

为什么将 DB 部署在同一个 pod 中，而不是将 DB pod 与应用程序 pod 分开？
因为他们有自己的数据库以使其更好地扩展。如果我只扩展应用程序，那么我的数据库就会成为瓶颈。
如果您通过引入服务的新实例来扩大规模或通过减少实例数量来缩小规模，它是如何工作的。您已经保存的数据会怎样？实例消失后谁为他们服务？

标签： docker kubernetes cloud microservices database-administration

【解决方案1】：

无法按照您的建议执行 Postgres 缩放，并且无法在多个 pod 中以读/写模式挂载持久卷 (with a few exceptions)

要扩展 Postgres，您可以考虑 CrunchyData

此外，将应用程序层与数据库分离有很多好处，包括对每一层的扩展策略进行精细控制。

PS：漂亮的图表。它使问题非常容易理解。

【讨论】：

我已经测试过了，效果很好。但为简单起见，我使用 HostPath 对其进行了测试。
两个独立的 Postgres 实例，愉快地写入它们的 /var/lib/postgresql/data，却不知道在幕后，另一个实例正在写入同一个卷 / HostPath？
我们可以将它们映射到不同的挂载点。例如：/data/app-001 /data/app-002 依此类推...
我不明白。 DB如何同步？假设一位用户访问您的应用程序，他在 PodA 上唱歌。后来他回来了，但这次应用程序是从 PodB 提供的。如果他的用户名/通行证存储在 PostgresA://data/app-001 中，而 PostgresB://data/app-002 中不存在，PodB 将如何知道他是注册用户
它是按id分片的，所以我知道东西在哪里。当然，我前面有一些足够聪明的东西可以找到它需要的东西。但这不是问题的范围。