局部故障的解决办法

在内部微服务间使用异步通讯（如基于消息的通讯）。最好不要在内部微服务间创建同步 HTTP 调用的 长链，因为错误的设计终将成为导致故障停机的主要原因。相反，除了客户端应用程序和第一级微服务 或细粒度的 API 网关间的前端通信外，在初始的请求/响应周期后，建议仅使用异步（基于消息）通 信。最终一致性和事件驱动架构将有助于最大限度地减少涟漪效应。这些方法强制执行较高级别的微服 务自治，防止此处提到的问题。 使用指数补偿重试 。当服务仅在短期内不可用时，通过一定次数的重试调用，有助于避免短时间和间歇 性故障。这可能是在间歇性网络故障的情况下，或在微服务/容器迁移到集群中其它节点时发生。但是 如果这些重试没有用断路器模式恰当设计，还会加剧连锁反应，最终导致拒绝服务（DoS）。 260 实现弹性应用 解决网络超时 。通常，客户端应设计为非无限期阻塞，并在等待响应时始终使用超时。使用超时可确保 资源不会无限期地被占用。 使用断路器模式。 在这种方式中，客户端进程会跟踪失败请求的数量。如果错误率超过配置的限制，则 触发“断路器”跳闸，从而使进一步的尝试立即失败。（如果大量请求失败，则表明该服务不可用，继 续发送请求毫无意义）在超时之后，客户端应再次尝试，如果新请求成功，则关闭断路器。 提供回退。在这种方式中，客户端进程在请求失败时执行回退逻辑，例如返回缓存的数据或默认值。这 是适合查询的方式，对于更新或者命令则更为复杂。 限制排队请求的数量