Question

比方说，我的整个域都有类似的实体

[
   {
      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]
   }
]

我决定提供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。因此，基本上，整个信息已被划分为存储在2个位置中（我猜是共享的id除外）。

这是我看到的一些潜在问题：

在使用Friend Manager服务的情况下，由于您所拥有的只是id，因此如果不将该服务中的信息与Person Info Manager服务中的信息进行合并，那么在整个系统中可能没有任何有用的东西。
要遵循上一点，假设我们需要一个用户可以用来管理好友飞船的UI。然后，我们将需要查询Friend Manager Service来获取此信息并通过id执行“加入”。这意味着Friend Manager Service依赖于Person Info Manager服务，或者某些第三项服务依赖于两者。

要纠正这些潜在问题（我不确定它们是否是真正的问题；这就是为什么我要提出问题），我们可以让它们共享更多数据。假设您至少需要了解一个人的name才能管理友谊。那我们可以有

{
    info: {
        1: {
          name: "Joe"
        },
        2: {
          name: "Jack"
        },
        3: {
          name: "Susy"
        }
    },
    friendships: {
        1: [2],
        2: [1, 3],
        3: [2]
    }
}

，以便现在的Friend Manager服务可以独立运行。与此相关的一些潜在缺点是

重复数据产生的额外存储费用
由于从“个人信息管理器”服务接收更新的延迟或错误，“朋友管理器”服务中的名称可能会过时。而如果Friend Manager服务将在需要时查询Person Info Manager服务的名称，那么它将始终具有最新信息（该查询还可以说明已被删除的人员）。

Answer 1

我的2美分：

个人信息和朋友管理器听起来太小，无法用作单独的微服务，这通常应映射到Bounded Context。想象一下，有界上下文是您域中发生的主要过程，而不是实体组。
大多数情况下，重复存储的额外成本不是问题，我们不是在谈论Twitter规模，甚至他们通过数据复制https://www.infoq.com/presentations/Twitter-Timeline-Scalability
要像示例中那样保持数据一致性，您需要在不同的有界上下文中定义可接受的一致性级别（根据业务规则/域逻辑）。 Eventual Consistency是经常出现的一项原则。结合域驱动设计进行搜索，您一定会在这里发现很多东西：）
直接调用其他微服务的微服务在某些情况下也可以使用，我的意思是看看Netflix;）

如何调和微服务“不共享”原则与“独立性”

1 个答案: