微服务和服务组合中的规范化或非规范化数据答案

【问题标题】：Normalized or Denormalized Data in Microservices and Service Composition微服务和服务组合中的规范化或非规范化数据
【发布时间】：2016-11-08 03:38:00
【问题描述】：

因此，我们的开发团队在过去 6 到 8 个月内一直致力于微服务，并且取得了很大进展。

在那段时间里，我们经历了几次gotcha 时刻，并且谦虚地知道，随着我们越来越接近将我们的平台投入生产，我们还会经历更多。

我不能完全说明的一个领域是我们如何处理我们的服务边界之间的数据。我听到很多大公司已经成功实施微服务的说法，但我似乎永远无法得到直接的建议和推理。

具体来说，给定两个服务域User 和Contacts，并假设User 有一个与之关联的Contact 对象，这两个服务域各自的选项是什么？管理自己的数据？

User 应该存储一个 ContactID，还是应该存储整个 Contact 对象？

我见过许多可靠的面向服务的开发团队（Netflix、亚马逊、耐克等）发表如下声明：

“规范化是万恶之源……”

“破坏所有共享...”

“什么都不分享...”

【问题讨论】：

如果有更好的地方问这个，请推荐。
能否分享一些联系方式

标签： domain-driven-design soa composition microservices

【解决方案1】：

嗯，这些说法是错误的。模块化是关于为您的上下文找到低耦合和高内聚的正确组合。用户可以存储联系人对象的副本，只要它知道它只是某个时刻的快照。对于许多用例来说这很好，有时您只需要确保您与负责域已知的真实联系人合作。

【讨论】：

这些说法没有错，只是被误解了。 Share nothing 表示不通过您的数据库进行集成。共享身份并不是真正的共享。
这没有用，他们仍然错了。对于有效和高效的系统，需要仔细考虑共享什么以及如何共享。

【解决方案2】：

保持主数据规范化。但是 - 如果你有“ContactID”之类的东西，你就错误地规范了你的数据！

规范化的实体不能是表格，而是业务实体——具有业务意义的文档。为什么需要 ContactID？如果您有联系人的公司列表，请在公司内部保留联系人。如果您希望联系人在公司和合同之间共享信息 - 请使用联系人服务，通过电子邮件或公司名称或任何其他对业务有意义的字段返回联系人信息。

完全非规范化的数据适用于从主数据构建的派生数据。它主要用于在其上建立索引以进行搜索和排序。

【讨论】：

【解决方案3】：

通过共享身份 (ID) 跨服务边界关联数据是非常好的。

当您的 UI 需要显示来自两个服务的相关数据，而不是在服务之间复制数据（这与您听说的松散耦合的微服务粒度相悖）时，您可以使用客户端组合来组合数据运行时的客户端。从两个服务中获取数据，构建一个 ViewModel 组合它，然后将其显示在屏幕上。将其组合在一起的逻辑无需耦合到任一服务。它可以获取服务返回的任何数据并动态组合它。执行客户端组合的服务有时称为“IT/Ops 服务”。

这是一个如何在技术上实现的示例：

https://particular.net/blog/secret-of-better-ui-composition

【讨论】：