微服务架构集群内通信

Question

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

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

最后一个问题：我错过了什么？你能指出我清楚地回答这个问题的一些阅读，可能是一个例子吗？

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

Answer 1

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

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

• 超时
• 重试政策
• 排队，正如您提到的（以避免数据丢失）
• 电路中断

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

Here 是一个关于微服务架构的优秀网站。