微服务中的关系数据库 [英] Relational DB in microservices

问题描述

我有一个当前使用 PostgreSQL 数据库的单体应用程序，并且架构的设置正如您对大多数关系数据库所期望的那样，各种表数据通过 user_id 上的 FK 链接回用户.

I have a monolithic application that currently uses a PostgreSQL DB and the schemas are set up as you would expect for most relational databases with various table data being linked back to the user via FKs on the user_id.

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

I'm trying to learn more about microservices am trying to migrate my python API to a microservice architecture. I have a reasonable understanding of how I'm going to break up the larger app into smaller parts, however, I'm not entirely clear on how I'm supposed to deal with the data side of things.

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

I understand that one single large DB is against general design principles of microservices but I'm not clear on what the alternative would be.

我最担心的是在保存微服务数据的各个数据库之间进行级联.在一个简单的 rdb 中，我可以级联删除，而数据库将处理跨各种表的工作.在微服务的情况下，这将如何工作?我是否需要一个单独的服务来处理跨其他服务数据库删除用户数据?

My biggest concern is cascading across individual databases that would hold microservice data. In a simple rdb, I can just cascade on delete and the DB will handle the work across the various tables. In the case of microservices, how would that work? Would I need to have a separate service that handles deleting user data across the other service DBs?

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

I don't really understand how I would migrate a traditional application with a relational DB to a microservice architecture?

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

To clarify - a specific architectural/design problem I'm facing is as follows:

我已将我的应用程序拆分为几个微服务.那些在我脑海中仍然相关的是:

I have split up my application into a few microservices. The ones that are in my mind still relational are:

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

Geolocation - A service that checks geometry data, records in PostGIS, and returns certain information. A primary purpose is to record the location of a particular user for referencing later

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

Image - A simple upload service to upload images and store meta data in the db.

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

Load-Image - A simple service that returns a random set of images based on parameters such as location, and user profile data such as Age, Gender, etc

个人资料 - 一种简单管理用户数据(例如年龄、性别等)的服务

Profile - A service that simply manages user data such as Age, Gender, etc

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

Normally, these three items would have a table each in a larger db rather than their own individual dbs. Filtering images by say location and age is a very simple JOIN and filter.

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

How would something like that work in a microservice architecture? If the data is held in different dbs entirely how would I setup the logic to filter the data? I could duplicate data that doesn't change often like profile info and add it to a MongoDB document that would contain image data including user_id and profile data - however, location data can change regularly and constant updates doesn't sound practical.

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

What would be the best approach? Or should I stick with a shared RDBMS for just those few services?

推荐答案

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

It comes down to the duplication of data, why we want it, and how we manage it.

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

Early in our careers we were taught about the the duplicating data in the context of duplication for the purpose of redundancy, for example, in database replication, or backups. We were also taught that data can be modelled in a relational manner, with constraints enforcing the integrity of the model. In fact, the integrity of the model is sacrosanct. Without integrity, how can you have consistency? The answer is that you can't. Kinda.

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

When you work with distributed systems and service orientation, you do so because you want to minimise interactions thereby reducing coupling between components. However, there is a cost to this. The more distributed your architecture, the less coupling it has, and the more duplication of data will be necessary. This is taken to an extreme with microservices, where effectively the same data may be present in many different places, in varying degrees of consistency.

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

Instead of being bad, however, in this context data duplication is an essential feature of your system. It is an enabler of an architectural style with many great benefits. Put another way, without duplication of data, you get less distribution, you get more coupling, which makes your system more expensive to build, own, and change.

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

So, now we understand duplication of data and why we want it, let's move onto how we manage having lots of duplication. Let's try an example:

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

In a relational database, let's say we have a table called Customers, which contains a customer ID, and customer details, and another table called Orders which contains the order ID, customer ID, and the order details. Let's say we also have an ordering application, which needs to delete all the customer's orders if the customer is deleted for GDPR.

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

Because we are migrating our system to microservices, we decide to create a service called Customers.

所以我们创建了一个具有以下操作的服务:

So we create a service with the following operation:

• DELETE/customers/{customerId} - 删除客户

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

We create another service called Orders with the following operations:

• GET/orders/customers/{customerId} - 获取客户的所有订单
• DELETE/orders/{orderId} - 删除订单

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

We build a UX screen for deleting a customer. The UX first calls the orders service to get all the orders for the customer. Then it iterates over the list of orders, calling the orders service to delete the order. Then it calls the customers service to delete the user.

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

This example is very simplistic, but as you can see, there is no option but to orchestrate the "Delete Customer" operation from the caller, which in this case is the user interface. Of course, what would be a single atomic transaction in a database does not translate to multiple HTTP/s calls, so it is possible that some of the calls may not succeed, leaving the system as a whole in an inconsistent state. In this instance the inconsistency would need to be resolved via some recovery mechanism.

这篇关于微服务中的关系数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！