微服务架构设计答案

【问题标题】：Microservice Architecture design微服务架构设计
【发布时间】：2018-04-28 12:45:36
【问题描述】：

我对微服务架构没有什么疑问。

假设有微服务 A、B 和 C。 A 将工作的上下文与其所做的其他事情分开，而 B、C 则通过为该工作完成各自的任务来完成该工作。

我有问题。

1.数据库设计

我在这里谈论的是 SQL。外键的使用简化了很多事情。但据我了解微服务架构，每个微服务都维护自己的数据，如果需要，必须从该服务中查询数据。

这是否意味着没有外键引用另一个微服务中的表？

2。数据流

我在这里看到有两种方法。

所有查询都使用 jobId 在所有微服务中为作业进行唯一维护。

以上两个必须遵循哪一个，为什么？

【问题讨论】：

【解决方案1】：

您认为微服务理想情况下应该有自己的数据结构，以便它们可以独立部署，这是正确的。然而，有几种设计模式可以帮助您，这并不一定意味着“无 FK”。请参考：

上面列出的模式回答了你的两个问题。

【讨论】：

【解决方案2】：

这是否意味着没有外键引用另一个微服务中的表？

不是数据库意义上的。一个微服务可能持有IDs 的远程实体，但不应假设任何关于远程微服务持久性的内容（即数据库类型，它可以是从 SQL 到 NoSQL 的任何东西）。

以上两个必须遵循哪一个，为什么？

这真的取决于。架构有两种类型：编排和编排。他们俩都很好。使用哪一个？只有你可以决定。以下是一些关于它们的博客文章：

另外，SO question 的解决方案可能有用。

【讨论】：

感谢您的回复。对于第一个答案，在我们的案例中，所有微服务都使用 MySQL。在这种情况下，如果我们使用外键，主表中的 delete 会触发所有其他表中的 delete 将其作为外键引用。但它是微服务的反模式吗？感谢您的链接。我会通过并回来。
@Kiran 这绝对是一种反模式。微服务不共享表或数据库。