数据非规范化如何与微服务模式一起工作？

Question

我刚刚在Microservices and PaaS Architecture 上阅读了一篇文章。在那篇文章中，大约下降了三分之一，作者指出（在 Denormalize like Crazy 下）：

重构数据库模式，并对所有内容进行反规范化，以实现数据的完全分离和分区。也就是说，不要使用服务于多个微服务的底层表。不应该共享跨多个微服务的基础表，也不应该共享数据。相反，如果多个服务需要访问相同的数据，则应通过服务 API（例如已发布的 REST 或消息服务接口）共享这些数据。

虽然这在理论上听起来很棒，但在实践中它有一些严重的障碍需要克服。其中最大的原因是，数据库通常是紧密耦合的，每个表都与至少一个其他表有一些外键关系。因此，不可能将数据库划分为 n 个由 n 个微服务控制的子数据库。

所以我问：给定一个完全由相关表组成的数据库，如何将其非规范化为更小的片段（表组），以便这些片段可以由单独的微服务控制？

例如，给定以下（相当小但示例性的）数据库：

[users] table
=============
user_id
user_first_name
user_last_name
user_email

[products] table
================
product_id
product_name
product_description
product_unit_price

[orders] table
==============
order_id
order_datetime
user_id

[products_x_orders] table (for line items in the order)
=======================================================
products_x_orders_id
product_id
order_id
quantity_ordered

不要花太多时间来批评我的设计，我是即时完成的。关键是，对我来说，将这个数据库分成 3 个微服务是合乎逻辑的：

1. UserService - 用于系统中的 CRUDding 用户；应该最终管理[users] 表；和
2. ProductService - 用于系统中的 CRUDding 产品；应该最终管理[products] 表；和
3. OrderService - 用于系统中的 CRUDding 订单；最终应该管理[orders] 和[products_x_orders] 表

但是，所有这些表之间都有外键关系。如果我们对它们进行非规范化并将它们视为单体，它们就会失去所有的语义意义：

[users] table
=============
user_id
user_first_name
user_last_name
user_email

[products] table
================
product_id
product_name
product_description
product_unit_price

[orders] table
==============
order_id
order_datetime

[products_x_orders] table (for line items in the order)
=======================================================
products_x_orders_id
quantity_ordered

现在无法知道谁订购了什么、数量多少或何时订购。

那么这篇文章是典型的学术喧嚣，还是这种非规范化方法在现实世界中有实用性，如果有，它是什么样子（在答案中使用我的示例的奖励积分）？

Answer 1

这确实是微服务中的关键问题之一，在大多数文章中都非常方便地省略了。幸运的是，有解决方案。作为讨论的基础，让我们有您在问题中提供的表格。 上图显示了表在单体应用中的外观。只有几个带有连接的表。

---

要将其重构为微服务，我们可以使用一些策略：

API 加入

在这个策略中，微服务之间的外键被破坏，微服务暴露了一个模仿这个键的端点。例如：产品微服务将暴露findProductById端点。订单微服务可以使用这个端点代替join。

它有一个明显的缺点。比较慢。

只读视图

在第二个解决方案中，您可以在第二个数据库中创建表的副本。副本是只读的。每个微服务都可以在其读/写表上使用可变操作。当涉及从其他数据库复制的只读表时，他们可以（显然）使用只读表

高性能读取

在read only view解决方案之上引入redis/memcached等解决方案，可以实现高性能读取。应将连接的两侧复制到优化阅读的平面结构。您可以引入全新的无状态微服务，可用于从该存储中读取数据。虽然看起来很麻烦，但值得注意的是，它比基于关系数据库的单体解决方案具有更高的性能。

---

可能的解决方案很少。实现最简单的那些性能最低。高性能解决方案需要几周时间才能实施。

Answer 2

我意识到这可能不是一个好的答案，但到底是什么。你的问题是：

给定一个完全由相关表组成的数据库，如何 将其非规范化为更小的片段（表组）

WRT 数据库设计我会说“你不能不删除外键”。

也就是说，使用严格的不共享数据库规则推动微服务的人们要求数据库设计者放弃外键（他们隐式或显式地这样做）。当他们没有明确说明 FK 的丢失时，您会怀疑他们是否真的知道并识别外键的值（因为它经常根本没有被提及）。

我已经看到大型系统被分成几组表。在这些情况下，可能存在 A) 组之间不允许 FK 或 B) 一个特殊组包含“核心”表，这些表可以被 FK 引用到其他组中的表。

...但在这些系统中，“表组”通常是 50 多个表，因此不足以严格遵守微服务。

对我来说，使用微服务方法拆分数据库的另一个相关问题是它对报告的影响，即如何将所有数据汇总在一起以进行报告和/或加载到数据仓库中的问题。

有些相关的还有忽略内置 DB 复制功能而倾向于消息传递（以及核心表/DDD 共享内核的基于 DB 的复制如何）影响设计的趋势。

编辑：（通过 REST 调用加入的成本）

当我们按照微服务的建议拆分数据库并删除 FK 时，我们不仅失去了（FK 的）强制声明性业务规则，而且我们也失去了数据库跨这些边界执行连接的能力。

在 OLTP 中，FK 值通常不是“UX 友好”的，我们经常希望加入它们。

在示例中，如果我们获取最后 100 个订单，我们可能不想在 UX 中显示客户 ID 值。相反，我们需要再次致电客户以获取他们的姓名。但是，如果我们还想要订单行，我们还需要再次调用产品服务以显示产品名称、sku 等而不是产品 ID。

通常我们会发现，当我们以这种方式分解数据库设计时，我们需要执行大量“通过 REST 连接”调用。那么这样做的相对成本是多少？

实际案例：“通过 REST 连接”与数据库连接的示例成本

有 4 个微服务，它们涉及很多“通过 REST 连接”。这 4 项服务的基准负载为 ~15 分钟。这 4 个微服务转换为具有 4 个模块的 1 个服务，针对共享数据库（允许连接）在 ~20 秒内执行相同的负载。

不幸的是，这并不是数据库连接与“通过 REST 连接”的直接比较，因为在这种情况下，我们也从 NoSQL DB 更改为 Postgres。

与具有基于成本的优化器等的数据库相比，“通过 REST 加入”的性能相对较差，这是否令人惊讶？

在某种程度上，当我们像这样分解数据库时，我们也在远离“基于成本的优化器”以及与查询执行计划相关的所有事情，转而编写我们自己的连接逻辑（我们有点写我们自己相对简单的查询执行计划）。

Answer 3

这是主观的，但以下解决方案对我、我的团队和我们的数据库团队都有效。

• 在应用层，微服务被分解为语义功能。
  • 例如Contact 服务可能会 CRUD 联系人（有关联系人的元数据：姓名、电话号码、联系信息等）
  • 例如User 服务可能会使用登录凭据、授权角色等对用户进行 CRUD。
  • 例如Payment 服务可能会使用 CRUD 付款并在后台与第三方 PCI 兼容服务（如 Stripe 等）一起工作。
• 在 DB 层，可以按照 devs/DBs/devops 人员的要求组织表格

问题在于级联和服务边界：付款可能需要用户知道谁在付款。而不是像这样对您的服务进行建模：

interface PaymentService {
    PaymentInfo makePayment(User user, Payment payment);
}

像这样建模：

interface PaymentService {
    PaymentInfo makePayment(Long userId, Payment payment);
}

这样，属于其他微服务的实体仅通过 ID 在特定服务内引用，而不是通过对象引用。这允许数据库表在所有地方都有外键，但在应用层，“外来”实体（即生活在其他服务中的实体）可通过 ID 获得。这可以防止对象级联失控并清晰地描绘服务边界。

它确实引起的问题是它需要更多的网络调用。例如，如果我给每个Payment 实体一个User 引用，我可以通过一次调用让用户获得特定的付款：

User user = paymentService.getUserForPayment(payment);

但是使用我在这里的建议，您需要两个调用：

Long userId = paymentService.getPayment(payment).getUserId();
User user = userService.getUserById(userId);

这可能会破坏交易。但是，如果您很聪明并实施了缓存，并实施了精心设计的微服务，每次调用的响应时间为 50 到 100 毫秒，那么我毫不怀疑这些额外的网络调用可以精心设计，以不会对应用。

Answer 4

我会将每个微服务视为一个对象，并且与任何 ORM 一样，您使用这些对象来提取数据，然后在您的代码和查询集合中创建连接，微服务应该以类似的方式处理。唯一的区别在于每个微服务一次代表一个对象，而不是一个完整的对象树。 API 层应该使用这些服务并以必须呈现或存储的方式对数据进行建模。

为每个事务多次调用服务不会产生影响，因为每个服务都在单独的容器中运行，并且所有这些调用都可以并行执行。

@ccit-spence，我喜欢交集服务的方法，但是如何设计和使用其他服务呢？我相信它会为其他服务创建一种依赖关系。

请问有cmets吗？