如何管理微服务架构中的多对多关系？

Question

如果我在两个单独的微服务中有以下实体：

class Employee {
@Id
private Long employeeId;

private String name;
...
}

class Department {
@Id
private Long deptId;

private String name;
...
}

如何在实体之间添加多对多关系？

我想在网关上将两个实体合并为一个实体：

class Empl_Dept{
List<Long> employeeIds;
List<Long> departmentIds;
}

所以联结表将在网关侧。

有没有更好的解决办法？？

Answer 1

假设您的域建模正确，这似乎是集成事件的简单修复。

EmployeeIds向您的部门服务添加一个表，DepartmentIds向您的员工服务添加一个表。当您创建、中断或更改 anEmployee和 a之间的分配时Department，发布EmployeeDepartmentUpdated两个服务都订阅的事件。然后，每个服务都可以处理事件并更新自己的数据以保持同步。

你不想要开始将数据放入您的网关API，这不是它是（这意味着如果你有多个网关相同的后端服务，只有一个会知道的信息）。

拥抱最终一致性，您的微服务之旅将因此变得更好！

编辑：

对于您关于事件对性能和复杂性的影响的问题，答案是“否”和“是”。

首先，不，我不希望事件溯源对系统性能产生负面影响。事实上，它们的异步特性使事件处理成为与 API 响应性不同的关注点。

我确信有一些方法可以在没有消息传递平面的情况下构建面向服务的架构（SOA，其中微服务本质上是一个子集），但根据我的经验，拥有一个是让松散耦合通信发生的绝佳方式。

服务之间的任何直接调用——无论协议（HTTP、gRPC 等）如何，都意味着这些服务之间的紧密耦合。端点名称、参数等都是破坏更改的机会。当您使用消息传递时，每个服务都负责发出向后兼容的事件，每个其他服务都可以选择它关心的事件、订阅它们，并且永远不知道发出的服务是否正在运行、已死、已更改等。

对于你的第二个问题，答案绝对是“是”——事件处理是额外的复杂性。然而，当您选择微服务架构风格时，这是您注册的复杂性的一部分（并且远非最糟糕的）。分布式授权、通过在多个服务之间组织的多个后端调用保持 UI 性能、容错和健康/性能监控都是（至少在我的经验中）更大的挑战。

作为记录，我们使用来自CloudAMQP.com的 RabbitMQ 托管实例，它运行良好。性能很好，他们有很多可扩展的软件包可供选择，而且我们的性能或停机时间问题为零。最新的 RabbitMQ 3.8 版本现在也包括 OAuth，所以我们目前正在努力将我们的 Authz 流与我们的消息代理集成，并将有一个很好的端到端安全解决方案。