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