postgresql - 微服务中的关系数据库

我有一个当前使用 PostgreSQL 数据库的单体应用程序，并且按照您对大多数关系数据库的期望设置了模式，其中各种表数据通过user_id.

我正在尝试了解有关微服务的更多信息，我正在尝试将我的 python API 迁移到微服务架构。我对如何将较大的应用程序分解为较小的部分有一个合理的理解，但是，我并不完全清楚我应该如何处理事物的数据方面。

我知道一个大型数据库违反了微服务的一般设计原则，但我不清楚替代方案是什么。

我最大的担忧是跨存储微服务数据的单个数据库级联。在一个简单的 rdb 中，我可以级联删除，数据库将处理各种表的工作。在微服务的情况下，这将如何工作？我是否需要有一个单独的服务来处理删除其他服务数据库中的用户数据？

我真的不明白如何将具有关系数据库的传统应用程序迁移到微服务架构？

编辑：

澄清一下 - 我面临的一个特定的架构/设计问题如下：

我已将我的应用程序拆分为几个微服务。在我看来仍然相关的是：

地理位置 - 检查几何数据、PostGIS 中的记录并返回某些信息的服务。主要目的是记录特定用户的位置以供以后参考

Image - 一个简单的上传服务，用于上传图像并将元数据存储在数据库中。

Load-Image - 一个简单的服务，它根据位置等参数和年龄、性别等用户资料数据返回一组随机图像

Profile - 一种简单地管理用户数据的服务，例如年龄、性别等

通常，这三个项目在一个更大的数据库中都有一个表，而不是它们各自的数据库。按位置和年龄过滤图像是一个非常简单的 JOIN 和过滤器。

这样的东西在微服务架构中如何工作？如果数据完全保存在不同的数据库中，我将如何设置逻辑来过滤数据？我可以复制不经常更改的数据（例如配置文件信息）并将其添加到包含图像数据（包括 user_id 和配置文件数据）的 MongoDB 文档中 - 但是，位置数据可以定期更改，并且不断更新听起来不切实际。

最好的方法是什么？或者我应该为这几个服务坚持使用共享 RDBMS？

标签： postgresqlrelational-databasemicroservices

它归结为数据的重复、我们为什么需要它以及我们如何管理它。

在我们职业生涯的早期，我们被教导在复制上下文中复制数据以实现冗余，例如，在数据库复制或备份中。我们还被告知可以以关系方式对数据进行建模，并通过约束来强制执行模型的完整性。事实上，模型的完整性是神圣不可侵犯的。没有诚信，怎么可能有一致性？答案是你不能。有点。

当您使用分布式系统和面向服务时，您这样做是因为您希望最大限度地减少交互，从而减少组件之间的耦合。然而，这是有代价的。你的架构越分散，它的耦合就越少，数据的重复就越多。这在微服务中发挥到了极致，实际上相同的数据可能以不同程度的一致性存在于许多不同的地方。

然而，在这种情况下，数据复制不是坏事，而是系统的一个基本特征。它是一种建筑风格的推动者，具有许多巨大的好处。换句话说，如果没有数据重复，你会得到更少的分布，你会得到更多的耦合，这使得你的系统构建、拥有和更改的成本更高。

所以，现在我们了解了数据重复以及我们想要它的原因，让我们继续讨论如何管理大量重复。让我们尝试一个例子：

在关系数据库中，假设我们有一个名为 Customers 的表，其中包含客户 ID 和客户详细信息，还有另一个名为 Orders 的表，其中包含订单 ID、客户 ID 和订单详细信息。假设我们还有一个订购应用程序，如果根据 GDPR 删除客户，则需要删除所有客户的订单。

因为我们正在将系统迁移到微服务，所以我们决定创建一个名为“客户”的服务。

因此，我们使用以下操作创建服务：

我们使用以下操作创建另一个名为 Orders 的服务：

我们构建了一个用于删除客户的 UX 屏幕。UX 首先调用订单服务来获取客户的所有订单。然后它遍历订单列表，调用订单服务删除订单。然后它调用客户服务删除用户。

此示例非常简单，但正如您所见，除了从调用者（在本例中为用户界面）编排“删除客户”操作之外别无选择。当然，数据库中的单个原子事务不会转换为多个 HTTP/s 调用，因此可能某些调用可能不会成功，从而使整个系统处于不一致的状态。在这种情况下，需要通过某种恢复机制来解决不一致问题。