REL01-BP03 通过架构适应固定服务限额和限制
了解不可更改的服务限额、服务限制和物理资源限制。为应用程序和服务设计架构，以防止这些限制影响可靠性。
其中的示例包括网络带宽、无服务器功能调用有效负载大小、API Gateway 的节流突发速率，以及并发用户连接至数据库。
期望结果：应用程序或服务在正常条件下和高流量条件下按预期执行。它们设计为在该资源的固定约束或服务限额的限制范围内工作。
常见反模式：
-
选择使用一项服务资源的设计时，没有意识到设计存在限制，这些限制将导致扩展时设计失败。
-
执行不现实的基准测试，并且在测试期间将达到服务固定限额。例如，以突发限制运行测试，但运行时间较长。
-
选择在超过固定服务限额时无法扩展或修改的设计。例如，SQS 有效负载大小为 256KB。
-
没有设计和实施可观测性，以便监控在高流量事件期间可能面临风险的服务限额阈值并发出警报。
建立此最佳实践的好处：确认应用程序将在所有预计的服务负载水平下运行，而不会中断或降级。
在未建立这种最佳实践的情况下暴露的风险等级：中等
实施指导
与软服务限额或替换为更高容量单位的资源不同，无法更改 AWS 服务的固定限额。这意味着，在应用程序设计中使用所有这些类型的 AWS 服务时，必须评估是否存在潜在的硬容量限制。
Service Quotas 控制台中显示了硬限制。如果列中显示 ADJUSTABLE = No，则服务具有硬限制。一些资源配置页中也显示了硬限制。例如，Lambda 具有无法调整的特定硬限制。
例如，在设计 Python 应用程序以在 Lambda 函数中运行时，应评估应用程序，以确定 Lambda 是否有可能运行超过 15 分钟。如果代码可能运行超过此服务限额限制，则必须考虑替代技术或设计。如果在生产部署后达到此限制，则应用程序将遭受降级和中断，直到可以补救为止。与软限额不同，即使在紧急的严重性 1 事件下，也无法更改这些限制。
应用程序部署到测试环境之后，应使用策略来查明是否会达到任何硬限制。引入测试计划中应包括压力测试、负载测试和混沌测试。
实施步骤
-
查看可在应用程序设计阶段使用的 AWS 服务的完整列表。
-
查看所有这些服务的软限额限制和硬限额限制。Service Quotas 控制台中并没有显示所有限制。有些服务描述了备用位置的这些限制。
-
在设计应用程序时，检查工作负载的业务和技术驱动因素，例如业务成果、使用案例、相依系统、可用性目标和灾难恢复对象。让业务和技术驱动因素指导流程，以确定适合工作负载的分布式系统。
-
分析各个区域和账户的服务负载。服务的许多硬限制基于区域。但有些限制基于账户。
-
分析弹性架构在可用区故障和区域故障期间的资源使用情况。在使用“主动/主动”、“主动/被动 – 热”、“主动/被动 - 冷”和“主动/被动 - 指示灯”方法的多区域设计过程中，这些故障情况会导致使用率更高。这会形成达到硬限制的潜在使用案例。
资源
相关最佳实践：
相关文档：
相关视频：
相关工具：
