Dependencies 微服务API调用和依赖关系设计

关于API依赖关系（服务调用的API），在设计microservices服务时是否有任何最佳实践

例如，如果我有一个“订单管理”（OM）服务，显然它需要调用“用户管理”（UM）服务，因为它需要多次查询用户信息（发货地址、电子邮件等）。如果我让我的OM在需要用户信息的时候一直呼叫UM，这将对UM服务产生很大的依赖性

据我所知，服务应该是自治的，并且尽可能地解耦——但现在我得到了一个OM服务，它将在每次UM服务宕机时宕机

在谷歌上搜索时，我发现了3个备选方案：

在UM模块中创建用户数据后，使用基于事件的编程立即复制用户数据，以便始终将其复制到OM中的表中

使用数据库的复制机制将数据从UM复制到OM数据库

将用户数据作为嵌套json复制到order对象中，以消除对订单查询和更新的依赖（但我认为初始订单创建仍需要调用UM）

---

在这一挑战中是否有最佳实践，或者是否有经验法则来决定采用哪种设计方法？

微服务是一种SOA（面向服务的体系结构）。因此，如果有一个服务执行所需的工作单元，那么为什么不调用它，而不是直接涉及到调用服务的数据模型的后端呢。如果遇到性能或体系结构问题，我只会选择避免UM服务调用。即使性能问题也可能在仍然从OM服务调用UM服务时得到解决

据我所知，服务应该是自治的，并且尽可能地解耦——但现在我得到了一个OM服务，它将在每次UM服务宕机时宕机

这个参数可以用来说明为什么要使用UM服务，这样OM服务就不必参与（耦合）UM的内部工作。如果OM连接到UM的后端，并且UM决定完全改变它的工作方式，比如说从关系数据库到无sql实现，那么这将导致更多的工作，因为它将影响OM

1.使用基于事件的编程在UM模块中创建用户数据后立即复制用户数据，以便始终将其复制到OM内的表中

我关心的是，您正在实现UM服务，并将其放入OM服务中。同样，我只会在遇到性能/arch问题并且可以处理将UM服务逻辑耦合到OM服务中的情况下走这条路线

2.使用数据库的复制机制将数据从UM复制到OM数据库

将UM的后端连接到OM

3.将用户数据作为嵌套json复制到order对象中，以消除对订单查询和更新的依赖（但我认为初始订单创建仍需要调用UM）

---

如果它减少了对UM的调用数量，那么这将非常有用。请记住这样做的成本，这可能是承载这些额外信息的性能损失，这可能是一个问题，也可能不是一个问题。传递的OM JSON越少，调用的UM服务越多，则此解决方案越理想。但是，如果只调用一次UM服务（比如在订单流程结束时），但OM JSON传递了很多，那么这个解决方案可能比它的价值更昂贵。

您所说的是一个有界上下文（BC），这是一种DDD模式。如果服务边界对应于BCs，DDD很适合SOA。BC是系统的自治部分，彼此之间不共享任何公共业务逻辑。当设计你的BC时，你不应该考虑任何关于数据库或其他横切关注点的想法。您应该记住使您的代码尽可能具体，这样您就不应该试图重用代码。在业务方面，为系统中可重用的部分保留Web服务。如果可以的话，您更喜欢最终的一致性（那么您应该能够使用通知而不是直接的WS调用）

关于最终的一致性（如果可能的话），我会选择第一个选项