级联故障是高吞吐量分布式系统中不可用的主要原因之一。在过去的四年中，Lyft已从单片架构转变为数百种微服务。随着微服务数量的增加，由于级联故障或意外内部拒绝服务导致的中断次数也在增加。
今天，这些故障情况在Lyft基础设施中基本上是一个已解决的问题。Lyft部署的每项服务都会自动获得吞吐量和并发保护。通过对我们最关键的服务进行一些有针对性的配置更改，基于负载的事件减少了95％，从而提高了用户体验。
速率限制和并发
并发和速率限制是同一枚硬币的两面。在考虑限制系统负载时，运营商传统上会考虑每秒的请求数。限制发送到系统的请求的速率的行为是速率限制。通常进行压力测试以确定服务什么时候将变为过载的请求率，然后将请求率限制配置在低于该点数值的某处。在某些情况下，业务逻辑决定了速率限制。
在硬币的另一面，我们还需要并发性，即同时使用多少个单元。这些单位可以是请求，连接等。例如，我们可以考虑某个时间点的并发飞行请求数，而不是考虑请求率。当我们考虑并发请求时，我们可以应用排队理论来确定一个服务最大能处理多少请求数，超过这个数值将导致请求延迟增加，以及服务因资源耗尽而失败。
速率限制
lyft / ratelimit 是一种开源Go / gRPC服务，旨在为各种应用程序启用通用速率限制方案，可以是每IP速率限制，或每秒对数据库的连接数。
Ratelimit在Lyft投入了生产，每秒处理数十万个速率限制请求。我们在边缘代理和内部服务网格中使用Ratelimit。
Envoy提供以下与这个速率限制的集成：
- 网络级别速率限制过滤器：Envoy可以为安装过滤器的侦听器上的每个新连接调用速率限制服务。配置指定特定域和描述符设置为速率限制。这具有限制每秒通过收听者的连接的速率的最终效果。
- HTTP级别速率限制过滤器：Envoy可以为安装过滤器的侦听器上的每个新请求调用速率限制服务。
在Lyft，我们主要使用速率限制来抵御基础设施边缘的负载。例如，每个用户ID允许的请求率。这样可以保护Lyft的服务 免受外部客户端意外或恶意负载造成的资源匮乏 。
并发处理
Envoy的主要优点之一是它通过网络级别的断路系统强制执行并发限制，而不必独立地在每个应用程序中配置和实现模式。特使支持各种类型的全分布式断路器：
- 最大连接数：Envoy将为上游群集中的所有主机建立的最大连接数。实际上，这通常用于保护HTTP / 1集群，因为HTTP / 2可以通过单个连接复用请求，因此限制了减速期间的连接增长。
- 最大挂起请求数：等待池中可用连接时将排队的最大请求数。实际上，这仅适用于HTTP / 1群集，因为HTTP / 2连接池从不对请求进行排队。HTTP / 2请求立即被多路复用。
- 最大请求数：在任何给定时间，群集中所有主机可能未完成的最大请求数。实际上，这主要用于HTTP / 2，因为HTTP / 1通常每个连接有一个请求。
- 最大活动重试次数：在任何给定时间，群集中所有主机可以执行的最大重试次数。通常，我们建议积极地进行断路重试，以便允许重试故障，但整体重试量不会爆炸并导致大规模级联故障。此设置可防止 重试放大。
在Lyft，我们专注于两种管理服务网格中并发性的机制：
- 限制入口层的并发连接数。鉴于Lyft的每项服务都运行一个特使边车来管理进入服务的入口请求（入口），我们可以配置边车对应用程序的并发连接数，从而限制入口并发进入应用程序。我们提供合理的值作为默认值，但鼓励服务所有者分析其并发模式并收紧设置。
- 限制出口层的并发请求数。运行边车来管理来自服务的出口流量的另一个好处是，我们可以管理从服务（出口）到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还需要吗？