微服务之间的通信必须高效且健壮。由于许多小型服务交互以完成单个业务活动，这可能是一个挑战。在本文中，我们将研究异步消息传递与同步 API 之间的权衡。然后我们看看设计弹性服务间通信的一些挑战。
以下是服务到服务通信带来的一些主要挑战。本文稍后将介绍的服务网格旨在应对许多此类挑战。
弹性。任何给定的微服务可能有几十个甚至几百个实例。实例可能由于多种原因而失败。可能存在节点级故障，例如硬件故障或 VM 重新启动。实例可能会崩溃，或者被请求淹没而无法处理任何新请求。这些事件中的任何一个都可能导致网络调用失败。有两种设计模式可以帮助提高服务到服务网络调用的弹性：
重试。网络调用可能会因为会自行消失的瞬态故障而失败。调用者通常应该重试操作一定次数，或者直到配置的超时期限过去，而不是彻底失败。但是，如果操作不是幂等的，重试可能会导致意外的副作用。最初的调用可能会成功，但调用者永远不会得到响应。如果调用者重试，该操作可能会被调用两次。通常，重试 POST 或 PATCH 方法是不安全的，因为这些方法不能保证是幂等的。
断路器。太多失败的请求会导致瓶颈，因为挂起的请求会在队列中累积。这些被阻塞的请求可能持有关键的系统资源，例如内存、线程、数据库连接等，这可能会导致级联故障。断路器模式可以防止服务重复尝试可能失败的操作。
负载均衡。当服务“A”调用服务“B”时&