架构思考（八）

微服务设计服务间通信

微服务之间的通信必须高效且健壮。由于许多小型服务交互以完成单个业务活动，这可能是一个挑战。在本文中，我们将研究异步消息传递与同步 API 之间的权衡。然后我们看看设计弹性服务间通信的一些挑战。

挑战

以下是服务到服务通信带来的一些主要挑战。本文稍后将介绍的服务网格旨在应对许多此类挑战。

弹性。任何给定的微服务可能有几十个甚至几百个实例。实例可能由于多种原因而失败。可能存在节点级故障，例如硬件故障或 VM 重新启动。实例可能会崩溃，或者被请求淹没而无法处理任何新请求。这些事件中的任何一个都可能导致网络调用失败。有两种设计模式可以帮助提高服务到服务网络调用的弹性：

重试。网络调用可能会因为会自行消失的瞬态故障而失败。调用者通常应该重试操作一定次数，或者直到配置的超时期限过去，而不是彻底失败。但是，如果操作不是幂等的，重试可能会导致意外的副作用。最初的调用可能会成功，但调用者永远不会得到响应。如果调用者重试，该操作可能会被调用两次。通常，重试 POST 或 PATCH 方法是不安全的，因为这些方法不能保证是幂等的。

断路器。太多失败的请求会导致瓶颈，因为挂起的请求会在队列中累积。这些被阻塞的请求可能持有关键的系统资源，例如内存、线程、数据库连接等，这可能会导致级联故障。断路器模式可以防止服务重复尝试可能失败的操作。

负载均衡。当服务“A”调用服务“B”时，请求必须到达服务“B”的运行实例。在 Kubernetes 中，Service资源类型为一组 pod 提供了一个稳定的 IP 地址。到服务 IP 地址的网络流量通过 iptable 规则转发到 Pod。默认情况下，随机选择一个 pod。服务网格（见下文）可以根据观察到的延迟或其他指标提供更智能的负载平衡算法。

分