微服务API调用和依赖项设计

Question

在设计有关API依赖的微服务服务（服务调用的API）方面是否有最佳实践？

例如，如果我有一个＆＃34;订单管理＆＃34; （OM）服务，显然它需要调用＆＃34;用户管理＆＃34; （UM）服务，因为它需要多次查询用户信息（送货地址，电子邮件等）。如果我让OM在需要用户信息时始终调用UM，这将对UM服务产生很多依赖。

据我所知，服务应该是自治的并且尽可能地分离 - 但是现在我得到的OM服务每次UM服务都会停止运行。

在Google上搜索时，我找到了3个替代方案：

1. 使用基于事件的编程在UM模块中创建用户数据后立即重新复制用户数据，以便始终将其复制到OM内的表中
2. 使用数据库的重新定位机制将数据从UM复制到OM数据库
3. 将用户数据作为嵌套json复制到订单对象中，以消除订单查询和更新的依赖关系（但我认为初始订单创建仍需要调用UM）

这里是否有关于挑战的最佳实践，或者是否有任何决定采用哪种设计方法的经验法则？

Answer 1

微服务是一种SOA（面向服务的体系结构）。因此，如果存在执行所需工作单元的服务，那么为什么不调用它而不涉及与调用服务没有直接关联的数据模型的后端。如果遇到某种性能或架构问题，我只会沿着避开UM服务呼叫的路线前进。甚至在仍然从OM服务调用UM服务时也可以解决性能问题。

  

据我所知，服务应该是自治的并且尽可能地分离 - 但是现在我得到的OM服务每次UM服务都会停止运行。

此参数可用于说明您使用UM服务的原因，以便OM服务不必涉及（耦合）UM的内部工作。如果OM与UM的后端耦合，并且UM决定完全改变它的工作方式，比如说从关系数据库到无实现的实现，则会导致更多工作，因为它会影响OM。

  

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

我对此的关注是您正在实施UM服务并将其放入OM服务中。如果您遇到性能/存档问题，我只会继续这条路线，您可以处理将UM服务逻辑耦合到OM服务中。

  

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

将UM的后端耦合到OM。

  

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

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

Answer 2

你所说的是有界上下文（BC），它是一种DDD模式。如果服务边界对应于BC，则DDD与SOA非常吻合。 BC是系统的自治部分，彼此之间不共享任何共同的业务逻辑。在设计BC时，您不应该考虑有关数据库或其他跨领域问题的任何想法。您应该记住使代码尽可能具体，然后您不应该试图重用代码。在业务方面，为可重复使用的系统部分保留Web服务。如果可以的话，更喜欢最终的一致性（那么你应该能够处理通知而不是直接的WS调用）。

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