我有一个整体应用程序，当前使用PostgreSQL数据库，并且已按照大多数关系数据库的期望设置了架构，其中各种表数据通过user_id上的FK链接回用户。
我试图了解有关微服务的更多信息，并试图将python API迁移到微服务架构。我对如何将较大的应用程序分解为较小的部分有一个合理的了解，但是，我对如何处理事物的数据方面尚不完全清楚。
我知道一个大型数据库违反微服务的一般设计原则，但是我不清楚替代方案是什么。
我最大的担忧是在存储微服务数据的各个数据库之间进行级联。在一个简单的rdb中，我可以级联删除，数据库将处理各个表的工作。对于微服务，这将如何工作？我是否需要一个单独的服务来处理其他服务数据库中删除用户数据的操作？
我真的不明白如何将具有关系数据库的传统应用程序迁移到微服务体系结构？
编辑：
要澄清-我面临的特定体系结构/设计问题如下：
我已将我的应用程序拆分为几个微服务。在我看来仍然具有关联性的是：
地理定位-检查几何数据，在PostGIS中记录并返回某些信息的服务。主要目的是记录特定用户的位置以供以后参考
图片-一种简单的上传服务，用于上传图片并将元数据存储在数据库中。
Load-Image-一种简单的服务，可根据位置等参数以及用户个人资料数据（例如Age，Gender等）返回随机的图像集
个人资料-一种仅管理用户数据（例如年龄，性别等）的服务
通常，这三个项目在较大的数据库中都有一个表，而不是各自的数据库。按位置和年龄过滤图片是一种非常简单的JOIN和过滤器。
类似的东西在微服务架构中如何工作？如果数据完全保存在不同的数据库中，我将如何设置逻辑来过滤数据？我可以复制不经常更改的数据（例如，配置文件信息）并将其添加到包含图像数据（包括user_id和配置文件数据）的MongoDB文档中-但是，位置数据可能会定期更改，并且不断进行更新听起来不切实际。
什么是最好的方法？还是我应该仅使用少数几个服务的共享RDBMS？
答案 0 :(得分：1)
这归因于数据的重复，我们为什么想要它以及我们如何管理它。
在我们的职业生涯的早期，我们就复制方面的知识进行了讲授，这些数据是出于冗余的目的，例如在数据库复制或备份中。我们还被教导，可以以关系方式对数据进行建模，而约束条件则强制了模型的完整性。实际上，模型的完整性是神圣不可侵犯的。没有完整性，如何才能保持一致性？答案是你做不到。金田
在使用分布式系统和面向服务的方法时，这样做是因为您希望最大程度地减少交互，从而减少组件之间的耦合。但是，这是有代价的。您的架构越分散，其耦合就越少，那么就需要更多的数据重复。对于微服务而言，这是极端的，在微服务中，相同的数据可能以不同的一致性程度出现在许多不同的地方。
但是，在这种情况下，数据复制不是坏的，而是系统的基本功能。它是具有许多巨大好处的建筑风格的促成因素。换句话说，在没有数据重复的情况下，您将获得更少的分发，您将获得更多的耦合，这将使您的系统构建，拥有和更改的成本更高。
因此，现在我们了解了数据重复以及为什么要重复数据，让我们继续介绍如何管理大量重复数据。让我们尝试一个例子：
在一个关系数据库中，假设我们有一个名为“客户”的表，其中包含一个客户ID和客户详细信息，还有另一个名为“订单”的表，其中包含订单ID，客户ID和订单详细信息。假设我们还有一个订购应用程序，如果为GDPR删除了客户，则需要删除所有客户的订单。
由于我们正在将系统迁移到微服务，因此我们决定创建一个名为“客户”的服务。
因此，我们通过以下操作创建服务：
我们使用以下操作创建另一个名为Orders的服务：
我们构建了一个用于删除客户的UX屏幕。 UX首先调用订单服务以获取客户的所有订单。然后遍历订单列表，调用订单服务以删除订单。然后调用客户服务删除用户。
此示例非常简单，但是如您所见，别无选择，只能从调用者（在本例中是用户界面）协调“删除客户”操作。当然，数据库中的单个原子事务不会转换为多个HTTP / s调用，因此某些调用可能不会成功，从而使整个系统处于不一致状态。在这种情况下，需要通过某种恢复机制解决不一致问题。
答案 1 :(得分：-1)
在微服务体系结构中，我们有两种选择，一种是按服务使用数据库，也可以使用共享数据库。两种模式都有优点和缺点。每个服务架构的数据库是最佳实践，但是当整体应用程序在数据库级别具有很多功能，过程或特定于数据库的功能时，我们可以使用共享数据库方法，如果您有时间和带宽，我知道这不是最佳实践那么您应该为每种服务使用数据库。 由于您关注的是单个数据库的级联，因此您需要从数据库中删除级联，并在应用程序中实现全局事务处理，并执行该事务中所有与级联相关的查询。