微服务和服务组合中的规范化或非规范化数据
因此，我们的开发团队在过去6-8个月里一直致力于Microservices，并获得了大量的支持。
在这段时间里，我们经历了几个gotcha时刻，并且非常谦卑地知道，随着我们向生产平台的移动，我们将面临更多的挑战。
我无法完全理解的一个领域是我们如何处理我们的服务边界之间的数据。我从成功地实施了Microservices的大公司那里听到了很多陈述，但我似乎从来没有得到过直截了当的建议和推理。
具体来说，给定两个服务域( User 和 Contacts**，)，假设** User 有一个与其关联的 Contact 对象，那么这两个服务域在管理它们自己的数据方面有哪些选项？
User ContactID 应该存储一个ContactID，还是应该存储整个 Contact 对象？
我见过许多可靠的面向服务的开发团队(Netflix、Amazon、Nike等)发表如下声明：
“正常化是万恶之源.”
“破坏所有共享的.”
“什么都不分享”
回答 3
Stack Overflow用户
发布于 2015-06-08 10:29:00
那些说法是错的。模块化就是为你的环境找到低耦合和高内聚力的正确组合。用户可以存储联系人对象的副本，只要它知道它只是某一时刻的快照。对于许多用例来说，这是很好的，有时您只需要确保您使用的是负责域所知道的真正的联系人。
Stack Overflow用户
发布于 2015-07-17 08:27:57
保持主数据规范化。但是--如果你有"ContactID“之类的东西，你就会错误地标准化你的数据！
规范化实体必须不是表，而是业务实体--具有业务意义的文档。你为什么需要ContactID？如果您有有联系人的公司列表，请在公司内保持联系。如果您希望在公司和合同之间共享联系人信息，请提供联系人服务，通过电子邮件或公司名称或任何其他对业务有意义的领域返回联系信息。
完全非正态化数据用于从主数据构建的派生数据。它主要用于建立索引，用于检索和排序。
Stack Overflow用户
发布于 2016-11-07 19:38:00
通过共享标识(ID)跨服务边界关联数据是非常好的。
当您的UI需要显示来自两个服务的相关数据时，您可以使用客户端组合在运行时在客户机上组装数据，而不是在服务之间复制数据(这与您听说过的松散耦合的微服务粒度相反)。从这两个服务中获取数据，构建一个组成它的ViewModel，然后在屏幕上显示它。将其组合在一起的逻辑不需要耦合到这两个服务中。它可以接收服务返回的任何数据，并动态地组合它。执行客户端组合的服务有时被称为"IT/Ops服务“。
下面是一个如何在技术上实现这一目标的例子：
https://stackoverflow.com/questions/30649582
复制相似问题
腾讯云开发者
