当我们提到“平台工程”时，脑海中会浮现什么？
当人们今天谈论平台工程时，一些熟悉的主题会出现：持续集成/持续部署（CI/CD）、可观测性、访问控制、配置管理、编排和安全性。Hashicorp 的“平台工程的六大支柱”很好地捕捉了这些内容，并已成为大多数组织定义其内部开发者平台（IDPs）的参考点。
在这些支柱背后，有一个简单的真理：平台工程为内部开发者构建产品。目标是抽象复杂性，使常见的构建块能够在团队之间重用。任何可以共享以改善开发者体验或运营安全性的东西都属于平台的范畴。
然而，一个很少以同样严谨态度讨论的领域是过载保护。
根据我们在基础设施和数据平台领域的经验，这种差距无处不在。服务在流量激增下崩溃。速率限制和配额的添加不一致。API 开始以不可预测的方式返回 429 或 503 响应。如果没有共享模式，每个团队就会以不同的方式修补问题，客户就会开始围绕这些怪癖编写代码。随着时间的推移，这些变通方法成为生产行为的一部分。
我们见过客户构建依赖错误的错误代码的自动化。在一个案例中，一个节流路径返回了错误的状态码，客户在他们的应用程序中添加了逻辑，将该值视为重试信号，这使得在不破坏实际工作负载的情况下几乎不可能进行纠正。这是一个痛苦的提醒，一旦碎片化渗透到过载控制中，做正确事情的成本就会急剧上升，未来的客户就会继承一种破碎的体验。
这突出了为什么过载保护不应该是一个事后的想法。它应该被视为平台工程的一级特性。
为什么过载保护比以往任何时候都更重要
现代 SaaS 系统运行在一个有限制的共享世界中。每个客户层、API 和后端系统都有必须遵守的边界。这些限制通常以多种形式出现：
控制平面限制：客户可以创建多少集群、帐户或管道。
数据平面限制：可以并行或在一个时间窗口内运行多少读或写查询。
基础设施限制：GPU 或虚拟机配额、API 调用频率或内存分配。
特定于服务的配额：超大规模帐户中的每个托管服务或构建块都有配额，这些限制可能对开发者不可见，执行不一致，甚至在没有协调的情况下可以修改。
存在一些保护系统的限制。其他的则是加强客户之间的公平，或者与合同层级保持一致。无论出于何种原因，这些限制都必须以可预见和透明的方式执行。
通过我们在大型数据和基础设施平台上的工作，我们已经看到过载保护如何随着系统的扩展而变得至关重要。在数据密集型环境中，瓶颈通常出现在存储层、计算层或排队层。一个没有边界的查询或失控的作业可能会剥夺其他人的资源，从而影响整个区域或租户。如果没有统一的过载保护层，每个团队都会成为潜在的故障域。
领先的公司已经认识到了这一点。
在奈飞，自适应并发限制会根据观察到的延迟和错误率自动调整服务并发性。当服务显示出过载的迹象时，框架会减少并发直到稳定。
在谷歌，过载保护被深度集成到Borg和 Stubby 中；他们的系统使用反馈控制回路来动态调整请求率，并在流量激增期间保持低尾部延迟。
在 Databricks，在 Gaurav Nanda 撰写的一篇博客文章中描述了速率限制框架，该框架在控制平面和数据平面上应用一致的策略。它强制执行每个租户和每个端点的限制，同时为开发者提供遥测和自助服务配置。这种一致性帮助我们在客户流量增长了几个数量级时仍能安全地扩展。
在 Meta 中，异步计算框架（FOQS）会根据延迟和错误遥测自动调整排队速率，以防止级联故障。它的分片管理器在集群之间动态地重新平衡负载，优先级感知调度器和速率限制 API 确保关键服务在流量激增时保持稳定。
这些例子显示了一个清晰的模式。过载保护不仅仅是一个可靠性问题。它是一个平台的责任，保护客户和开发者免受彼此成功的侵害。
一流的过载保护平台是什么样的
将过载保护视为头等关注点意味着提供清晰、可重用的原语，每个服务都可以轻松采用它们。其中三种能力脱颖而出。
a.速率限制
在简单的配置中，每个服务都应该能够声明它可以安全处理多少流量。平台使用Envoy或 service-mesh 过滤器等代理将这些规则转换为边缘执行。这可以防止在到达核心逻辑之前过载，并允许在不更改代码的情况下进行全局配置更新。
在 Databricks，速率限制框架允许产品团队以声明式定义限制，平台自动处理执行、指标和退避头。例如，服务可以在一个简单的 YAML 配置文件中指定每个租户的请求限制，框架将跨控制平面和数据平面一致地执行这些限制。这消除了自定义实现，并在 API 之间提供了可预测的行为。
b. 配额服务
当配额系统有机发展时，企业客户经常面临挑战。配额的发布不一致，计数错误，或者对正确的团队不可见。外部客户和内部服务都需要可预测的限制。
集中的配额服务解决了这个问题。它定义了清晰的 API，用于跟踪和执行跨租户、资源和时间间隔的使用情况。它可以与计费、遥测和开发者门户集成，以显示客户接近其限制的程度。这避免了隐藏上限或静默节流的混乱。
没有无限套餐这回事。每个系统都有瓶颈，甚至所谓的无限制层也有限制，这些限制必须被定义、监控和可预测地执行。
c. 负载卸载和自适应并发
速率限制和配额决定谁可以获得访问权限以及多少。当系统本身变得不健康时，负载卸载决定会发生什么。
最好的实现是不断观察延迟、队列深度或错误率，并相应地调整并发目标。Netflix 的自适应并发和谷歌的反馈控制器就是很好的例子。
如果没有共享框架，这是很难实现的。逻辑必须深入运行时库和通信层，而不是在临时服务代码中。如果操作得当，开发人员可以自动获得过载保护，平台在变化的条件下保持服务健康。
可见性是保护的一部分
客户一再要求更多地了解他们接近系统限制的程度。这并不是一件好事；这是必不可少的。
当客户收到 429（“请求过多”）时，响应应该清楚地传达发生了什么，哪个限制被触发了，何时重置，以及剩余多少配额。这些细节应该在响应头中，以便客户端可以优雅地退避，而不是盲目重试。
然而，仅头信息是不够的。大多数实际工作负载需要的上下文比单个响应所能提供的更多：使用趋势、即将到来的重置，以及每个租户或令牌距离其限制有多远。如果没有这种可见性，客户经常会猜测、反复重试或打开支持单。
提供开箱即用的遥测、使用 API 和仪表板，将过载保护从执法机制转变为合作伙伴关系。当开发人员可以实时观察和对他们的速率限制或配额消费采取行动时，他们可以更快地自我纠正，并以更多的信任进行操作。
忽视它的代价
当平台不拥有过载保护时，团队会反复地重新设计它。每个实现都有不同的行为，这通常都会有压力。
结果是产生脆弱的生态系统，其中：
限制执行不一致，例如，一些端点应用资源限制，而其他端点在不执行任何限制的情况下运行请求，导致不可预测的行为和下游问题。
故障不可预测地级联，例如，失控的数据管道作业可能使共享数据库饱和，延迟或失败不相关的作业，并触发跨团队的重试和警报。
当客户为错误报告的节流或配额错误构建解决方案时，错误代码变成了民间传说，而不是标准。
一旦这些不一致泄露给客户，就几乎不可能修复。多年来，我们已经看到集成依赖于我们错误配置的限制或不正确的错误代码，这使得以后很难发展系统。从长远来看，消除碎片化的成本远高于预先投资共享基础设施。
当平台拥有过载保护时，默认情况下每个服务都继承了安全性和可预测性。工程师可以专注于构建产品功能，而不是重新实现防御性管道。
结论
近年来，平台工程发展迅速。我们已经为 CI/CD、可观测性、安全性和开发者体验建立了模式。但可靠性不仅仅是关于检测故障的。它还应是关于预防的。
过载保护应该与平台工程的其他支柱站在一起。它使系统在现实世界的压力下保持弹性，并确保服务之间的一致行为。
过载保护应该被视为一等的平台特性，而不是留给团队维护的防御性代码的拼凑。
最好的组织已经通过速率限制框架、配额服务和自适应负载管理悄悄地实践了这一点。现在是时候让它成为我们平台词汇表中可见且有意的一部分了。
原文链接：
https://www.infoq.com/articles/overload-protection-platform-engineering/
