确保微服务中外键/所有权的一致性答案

【问题标题】：Ensure consistence for foreignkeys/ownerships in microservices确保微服务中外键/所有权的一致性
【发布时间】：2018-11-20 15:33:06
【问题描述】：

我有两个有界上下文，它们导致两个微服务

个人管理
文档存储

我在这里保持实体模型简单。

个人管理：

Entity/Table Person:
@id - int
tenantId - int
name - string
...

文档存储

Entity/Table Document:
@id - int
tenantId - int
personId - int
dateIssued - string
...

您需要知道，在启动应用程序之前 - 选择了一家公司（租户）来定义公司上下文。

我想使用 REST/JSON 存储一个新文档。

这是到 /tenants/1/persons/5/documents 的 POST

with the body
{
    "dateIssued" : "2018-06-11"
}

在后端 - 我验证输入正文。

一个验证可能是“如果指定的人存在并且真的属于给定的租户”。

由于此信息存储在 PersonalManagement-MicroService 中，我需要提供如下操作：

"Does exists (personId=5,tenantId=1)"

在 PersonalManagement 中确保一致性，因为调用者可能是邪恶的。

一般来说：

在微服务中跨数据库检查实体“所有权”的最佳做法是什么

如果创建了一个新人 (tenantId,personId) 也可以选择将此信息另外存储（！）在 DocumentStorage 中，但希望避免这种冗余。

【问题讨论】：

标签： rest reference foreign-keys microservices

【解决方案1】：

我不会将此答案扩展到您的有界上下文和服务端点是否定义明确，因为您的问题似乎是简化问题以保持明确定义的范围，但关于您的具体问题：

在微服务中跨数据库检查实体“所有权”的最佳做法是什么

微服务架构使用“无共享”原则。这通常从代码库扩展到数据库。所以你假设你在你的场景中检查这个约束“跨数据库”是正确的。

在这种特殊情况下，您有几个选项，每个选项都有其缺点：

1) 您提议的 "Does exists (personId=5,tenantId=1)" 调用从 DocumentContext 到 PersonContext 不本身是错误的，但是您将在这两个微服务之间生成直接依赖关系，因此您必须问自己，如果 PersonManagement 微服务离线，您是否可以不接受新文档。

在特定情况下，这样的依赖关系可能是可以接受的，但你拥有的这些依赖关系越多，你的微服务架构就越不像一个“分布式单体”，而它本身几乎就是一种反模式。

2) 您拥有的另一个主要选项是您应该认识到 DocumentContext 对与 People 相关的某些信息/行为非常感兴趣，因此它应该是可以在其边界内对 Person Entity 进行建模。

这意味着，您可以让 DocumentContext 订阅 PersonContext 中的更改，以了解当前存在哪些 People 以及他们的特征并且因此能够保留此类信息的本地副本。

这样，您的验证将完全保存在 DocumentContext 中，其操作不会受到 PersonContext 最终问题的阻碍，您会发现您对文档相关实体将比以前更干净。

但最后，您也会发现“不共享任何内容” 原则通常会让您付出看似冗余的代价，但实际上它是上下文的独立性。

【讨论】：

【解决方案2】：

仅用于租赁检查，这可以使用 JWT 令牌（可以存储租赁信息和其他元数据的令牌）来完成。

让我提供另一个使用 JWT 无法解决的相同场景的示例。

假设一位客户想要创建订单，而我们的系统想要在创建订单时检查客户是否存在。

由于订单和客户服务是分开的，我们希望它们之间的依赖最小，所以有多个 sol.针对以上问题：

在“验证状态”中创建订单，并在 OrderCreated 事件中检查客户有效性并将客户状态更新为“有效”
在为客户创建订单检查之前再进行一次检查（这不是正确的方法，因为它会产生依赖性，除非非常关键，否则不要这样做）
最后一种方式是创建订单，最终检查订单是否交付的人员将验证客户是否会删除

【讨论】：