14、微服务弹性与Istio客户端负载均衡实践

微服务弹性与Istio客户端负载均衡实践

1. 微服务弹性的重要性

在构建微服务时，弹性应该是首要考虑的因素。“构建一个永不失败的系统”是不现实的，一旦出现故障，可能会导致所有服务崩溃。当构建通过网络通信的分布式系统时，会增加更多的故障点和灾难性故障的可能性。因此，服务所有者应该在其应用程序和服务中始终采用一些弹性模式。

例如，当服务A调用服务B时，如果向服务B的特定端点发送请求出现延迟，服务A应该主动发现并将请求路由到其他端点、可用区甚至其他区域。如果服务B出现间歇性错误，可以重试失败的请求。若调用服务B的端点出现问题，可暂停调用，直到服务B恢复。若持续给服务B施加负载（有时重试请求还会增加负载），可能会使服务B过载，进而导致服务A及依赖这些服务的其他服务出现严重甚至级联错误。

解决方案是构建能够预期故障的应用程序，并在处理请求时自动尝试修复或回退到替代路径。例如，服务A调用服务B出现问题时，可以重试请求、设置请求超时或使用熔断模式取消进一步的出站请求。

2. 应用程序弹性的发展历程

在服务网格技术广泛应用之前，服务开发者需要在应用程序代码中编写大量基本的弹性模式。开源社区出现了一些有助于解决这些问题的框架。2011年，Twitter开源了其弹性框架Finagle，这是一个Scala/Java/JVM应用程序库，可用于实现各种RPC弹性模式，如超时、重试和熔断。不久后，Netflix开源了其弹性框架的组件，包括Hystrix和Ribbon，分别提供熔断和客户端负载均衡功能。这些库在Java社区非常受欢迎，Spring Framework在其Spring Cloud框架中采用了Netflix OSS栈。

然而，这些框