Envoy服务网格如何减轻级联故障?

18-10-23 banq
                   

级联故障是高吞吐量分布式系统中不可用的主要原因之一。在过去的四年中,Lyft已从单片架构转变为数百种微服务。随着微服务数量的增加,由于级联故障或意外内部拒绝服务导致的中断次数也在增加。

今天,这些故障情况在Lyft基础设施中基本上是一个已解决的问题。Lyft部署的每项服务都会自动获得吞吐量和并发保护。通过对我们最关键的服务进行一些有针对性的配置更改,基于负载的事件减少了95%,从而提高了用户体验。 

速率限制和并发

并发和速率限制是同一枚硬币的两面。在考虑限制系统负载时,运营商传统上会考虑每秒的请求数。限制发送到系统的请求的速率的行为是速率限制。通常进行压力测试以确定服务什么时候将变为过载的请求率,然后将请求率限制配置在低于该点数值的某处。在某些情况下,业务逻辑决定了速率限制。

在硬币的另一面,我们还需要并发性,即同时使用多少个单元。这些单位可以是请求,连接等。例如,我们可以考虑某个时间点的并发飞行请求数,而不是考虑请求率。当我们考虑并发请求时,我们可以应用排队理论来确定一个服务最大能处理多少请求数,超过这个数值将导致请求延迟增加,以及服务因资源耗尽而失败。

速率限制

lyft / ratelimit  是一种开源Go / gRPC服务,旨在为各种应用程序启用通用速率限制方案,可以是每IP速率限制,或每秒对数据库的连接数。

Ratelimit在Lyft投入了生产,每秒处理数十万个速率限制请求。我们在边缘代理和内部服务网格中使用Ratelimit。

Envoy提供以下与这个速率限制的集成:

  1. 网络级别速率限制过滤器:Envoy可以为安装过滤器的侦听器上的每个新连接调用速率限制服务。配置指定特定域和描述符设置为速率限制。这具有限制每秒通过收听者的连接的速率的最终效果。
  2. HTTP级别速率限制过滤器:Envoy可以为安装过滤器的侦听器上的每个新请求调用速率限制服务。

在Lyft,我们主要使用速率限制来抵御基础设施边缘的负载。例如,每个用户ID允许的请求率。这样可以保护Lyft的服务  免受外部客户端意外或恶意负载造成的资源匮乏 。

并发处理

 Envoy的主要优点之一是它通过网络级别的断路系统强制执行并发限制,而不必独立地在每个应用程序中配置和实现模式。特使支持各种类型的全分布式断路器:

  • 最大连接数:Envoy将为上游群集中的所有主机建立的最大连接数。实际上,这通常用于保护HTTP / 1集群,因为HTTP / 2可以通过单个连接复用请求,因此限制了减速期间的连接增长。
  • 最大挂起请求数:等待池中可用连接时将排队的最大请求数。实际上,这仅适用于HTTP / 1群集,因为HTTP / 2连接池从不对请求进行排队。HTTP / 2请求立即被多路复用。
  • 最大请求数:在任何给定时间,群集中所有主机可能未完成的最大请求数。实际上,这主要用于HTTP / 2,因为HTTP / 1通常每个连接有一个请求。
  • 最大活动重试次数:在任何给定时间,群集中所有主机可以执行的最大重试次数。通常,我们建议积极地进行断路重试,以便允许重试故障,但整体重试量不会爆炸并导致大规模级联故障。此设置可防止  重试放大。

在Lyft,我们专注于两种管理服务网格中并发性的机制:

  1. 限制入口层的并发连接数。鉴于Lyft的每项服务都运行一个特使边车来管理进入服务的入口请求(入口),我们可以配置边车对应用程序的并发连接数,从而限制入口并发进入应用程序。我们提供合理的值作为默认值,但鼓励服务所有者分析其并发模式并收紧设置。
  2. 限制出口层的并发请求数。运行边车来管理来自服务的出口流量的另一个好处是,我们可以管理从服务(出口)到Lyft的任何其他服务的传出并发请求。这意味着“位置”服务的所有者可以有选择地配置他们想要支持Lyft的每个其他服务的并发级别,例如,他们可以决定并配置“游乐设施”服务可以向“位置”发出100个并发请求“,但”用户“服务只能向”位置“发出50个并发请求。

对Lyft的每个服务的出口和入口运行并发限制的一个有趣结果是,更容易跟踪不需要的行为。如上所述,所见的常见故障情形是突发性,出口和入口的并发限制使得通过查看请求路径中并发溢出的位置,可以轻松查明整个系统的突发行为。

缺陷

具体参数值很难选择;整个服务网络中每天有数百个部署。对服务及其依赖项的任何更改都可以更改资源和负载配置文件。一旦选择了某个参数值,由于这些变化又将过时。

并发限制很容易实施,因为Envoy存在于网络的每一次调用中,通过Envoy可以容易控制并发调用;但是速率限制很难确定,因为它需要服务所有者完全理解系统的所有约束。此外,由于网络拓扑结构的不断发展和弹性,当今的互联网规模公司,尤其是那些处于成长阶段的公司迅速增长。 

Netflix在这个问题上投入了大量资金,最近  开源了一个库,  用于衡量或估算网络中每个点的并发限制。更重要的是,随着系统规模和命中而限制每个节点,[系统中]每个节点将调整并强制执行其局部极限值视图。他们通过将系统的并发约束等同于TCP拥塞窗口,借用了常见的TCP拥塞控制算法。 

Envoy的设计原则之一包括丰富且功能强大的过滤器堆栈,以提供可扩展性。Envoy具有L3 / L4(TCP级别)和L7(HTTP级别)过滤器堆栈。可以编写HTTP过滤器以对HTTP级别消息进行操作。HTTP过滤器可以停止并继续迭代到后续过滤器。这种丰富的过滤器架构允许复杂的场景,例如运行状况检查处理,调用速率限制服务,缓冲,路由,生成应用程序流量统计数据,如DynamoDB等。  

在接下来的几个月里,Lyft将与Netflix的并发限制库背后的团队合作,将基于其库的系统带入特使L7过滤器。这意味着在Lyft - 以及使用Envoy的任何其他公司 - 我们将迁移到自动化系统,我们的服务工程师不必静态配置并发限制。这意味着,例如,如果由于意外情况导致服务减速,则自适应限制系统可以自动抑制检测到的限制,从而防止由于不可预见的减速而导致的故障  。一般而言,自适应系统消除了我们过去遇到的两个问题:确定适当的限制是非直观的,并且静态限制无法面对弹性分布式系统的快速增长。

banq: Netflix将重点放在了Envoy集成,这些都足以替代Zuul,因此Zuul 2.0还需要吗?

 

                   

1