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

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 表添加到您的 Departments 服务，并将 DepartmentIds 表添加到您的Employees 服务。当您在 Employee 和 Department 之间进行、中断或更改分配时，请发布两个服务都订阅的 EmployeeDepartmentUpdated 事件。然后，每个服务都可以处理该事件并更新自己的数据以保持同步。

您不想想要开始将数据放入网关 API 中，这不是它的用途(这意味着如果您有多个通往同一后端服务的网关，则只有一个网关知道该信息)。

拥抱Eventual Consistency您的微服务之旅将会因此变得更加美好!

编辑:

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

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

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

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

对于第二个问题，答案绝对是"is"——事件处理会增加复杂性。然而，当您选择微服务架构风格时，这是您所面临的复杂性的一部分(而且远不是最糟糕的)。分布式授权、通过在多个服务之间组织多个后端调用来保持 UI 性能、容错和运行状况/性能监控都是(至少根据我的经验)更大的挑战。

郑重声明，我们使用 CloudAMQP.com 中的 RabbitMQ 托管实例而且效果很好。性能很好，他们有很多可扩展的软件包可供选择，而且我们在性能或停机方面的问题为零。最新的 RabbitMQ 3.8 版本现在也包含 OAuth，因此我们目前正在努力将 Authz 流与消息代理集成，并将拥有一个很好的端到端安全解决方案。