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

假设您对域进行了正确建模，这似乎是使用Integration Events轻松解决的问题。

将EmployeeIds表添加到“部门服务”中，并将DepartmentIds表添加到“员工”服务中。在Employee和Department之间进行分配，中断或更改分配时，请发布两个服务都订阅的EmployeeDepartmentUpdated事件。然后，每个服务都可以处理事件并更新自己的数据以保持同步。

您确实不要开始将数据放入网关API，这不是它的用途（这意味着，如果您有多个通往同一后端服务的网关，那么只有一个人会知道该信息）。

拥抱Eventual Consistency，您的微服务之旅将会更好！

编辑：

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

首先，不，我不希望事件源对系统性能产生负面影响。实际上，它们的异步特性使事件处理与API响应能力成为一个单独的问题。

我确信有多种方法可以构建没有消息传递平面的面向服务的体系结构（SOA，微服务本质上是其中的一个子集），但是以我的经验，有一种方法可以使松散耦合的通信发生。

服务之间的任何直接调用-与协议（HTTP，gRPC等）无关，都意味着这些服务之间的紧密耦合。端点名称，参数等都是打破变化的机会。使用消息传递时，每个服务都负责发出向后兼容的事件，而每个其他服务都可以选择它关心的事件，订阅它们，而对发出的服务是否正在运行，无效，已更改等则一无所知。

对于第二个问题，答案是绝对“是”-事件处理会带来额外的复杂性。但是，这是您选择微服务体系结构样式时所申请的复杂性的一部分（并且远不及最坏的部分）。分布式授权，使UI性能与在多个服务之间组织的多个后端调用，容错和运行状况/性能监视保持一致（至少以我的经验）是更大的挑战。

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

Answer 2

每个微服务都拥有自己的数据库，因此联结表毫无意义，因为它是一种关系解决方案。

您可以考虑这两种方法中的一种，如果Empl_Dept是Domain对象，则应将其放在第三个微服务中，如果不是将雇员关系放入部门中，反之亦然。

希望对您有帮助。

Answer 3

如果只有这两个微服务，则必须在一个服务中添加employee_department_map，在第二个服务中添加department_employee_map。

在设计微服务时，始终认为您无法更改其他服务中的任何内容（例如，如果它是第三方api）

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

3 个答案: