假设我的整个域都有类似的实体
[
{
id: 1,
name: "Joe",
age: 16,
hometown: "Los Angeles",
friends: [2]
},
{
id: 2,
name: "Jack",
age: 83,
hometown: "Phily",
friends: [1, 3]
},
{
id: 3,
name: "Susy",
age: 50,
hometown: "Dayton",
friends: [2]
}
]
我决定有两个独立的服务
- 人员信息经理
- 好友经理
来处理这些实体。我对"什么都不共享"的字面解释是，每个服务都有类似的存储
[
{
id: 1,
name: "Joe",
age: 16,
hometown: "Los Angeles"
},
{
id: 2,
name: "Jack",
age: 83,
hometown: "Phily"
},
{
id: 3,
name: "Susy",
age: 50,
hometown: "Dayton"
}
]
对于1。和
{
1: [2],
2: [1, 3],
3: [2]
}
对于2。因此，基本上，整个信息被划分为存储在两个位置(除了ids，我想它们是共享的(。
以下是我看到的一些潜在问题：
- 在Friend Manager服务的情况下，由于您所拥有的只是
ids，如果不将来自该服务的信息与来自Person Info Manager服务的信息相结合，在整个系统中可能没有什么有用的事情可做 - 按照前面的观点，假设我们想要一个用户界面，用户可以在其中管理朋友船。然后，我们需要查询Friend Manager服务来获得这些信息，并通过
id执行"加入"。这意味着Friend Manager服务依赖于Person Info Manager服务，或者有一些第三方服务同时依赖于两者
为了解决这些潜在的问题(我不确定它们是否是真正的问题；这就是我问s.O.的原因(，我们可以让他们共享更多的数据。比方说，为了管理友谊，你至少需要了解一个人的name。然后我们可以有
{
info: {
1: {
name: "Joe"
},
2: {
name: "Jack"
},
3: {
name: "Susy"
}
},
friendships: {
1: [2],
2: [1, 3],
3: [2]
}
}
以便现在Friend Manager服务可以独立工作。有一些潜在的缺点
- 重复数据带来的额外存储成本
- 由于从个人信息管理器服务接收更新的延迟或错误，Friend Manager服务中的名称可能已过时。然而，如果Friend Manager服务在需要时向Person Info Manager服务查询姓名，那么它将始终具有最新信息(该查询还可以说明已删除的人员(
我的2美分：
-
person-info和friend-manager听起来都太小了，不适合作为单独的微服务，根据经验，这应该映射到有边界的上下文。想象一下，有界上下文是发生在你的领域中的主要过程，而不是实体组。
-
重复存储的额外成本在大多数情况下都不是问题，我们不是在谈论Twitter规模，甚至他们也通过数据重复来解决问题https://www.infoq.com/presentations/Twitter-Timeline-Scalability
-
为了像您的示例中那样保持数据一致性，您需要在不同的有界上下文中定义可接受的一致性级别(根据业务规则/域逻辑(。这里经常出现的一个原则是最终一致性。结合领域驱动设计进行搜索，你一定会在那里发现很多东西：(
-
微服务直接调用其他微服务在某些情况下也可以工作，我的意思是看看Netflix；(