微服务架构集群内通信

Question

通常团队使用 rest api 从微服务 A 到 B 进行通信，但这意味着紧密耦合，如果可能的话应该避免这种情况。此外，如果存在从 A 到 B 的依赖关系，并且 B 已关闭，则不仅希望不对 A 的原始请求失败，而且请求信息也不应该丢失。 另一种方法是排队。但是：

• 如果 B 下线，那么 A 无论如何都无法回答；
• 即使请求信息在队列中，当 B 上来时也无法处理请求，将响应返回给 A 并返回给客户端；
• 当只有 2 个节点时，最多只需要 2 个队列（每路一个），但是当我们处理 12 个微服务时，为所有这些节点之间的每个通信需求创建一个队列很容易变得不切实际。

最后一个问题：我错过了什么？您能否指出一些可以清楚地回答这个问题的阅读材料，可能还有一个例子？

附：我正在寻找 spring boot atm 来开发我的微服务，在这种情况下的一些指针将不胜感激，但不是必需的。

Answer 1

您提到的方面是基于微服务架构的一般问题/缺点。如果您有与这些方面正交的需求，那么您应该选择不同的方法，也许是基于服务的架构。

AFAIK，对于涉及关键用户交互（例如身份验证）的业务流程，理想情况下，您应该有一个处理该流程的微服务。通过这种方式，您可以最大限度地减少其他微服务的依赖开销，这些微服务涉及与弹性相关的方面（如上面提到的方面），当出现问题时可能会出现问题：

• 有超时
• 重试策略
• 如您所述，排队（以避免数据丢失）
• 断路

这并不意味着您不能在该关键路径上拥有多个微服务，但是您增加该路径的长度越多，处理实时流的难度就越大。

Here 是一个很棒的微服务架构网站。