经过从基础架构层到应用程序的前端，您的系统都有限制。当您将其推到其阈值之上时，您的系统会以意想不到的方式行事。服务退化。发生中断。尽管我们经常在发现和纠正问题的根本原因方面考虑事件响应，但在许多情况下，没有一个原因。对服务的需求突然提高会导致在消息队列中建立大量请求，这通常不是问题。但是，将其与错误配置的参数结合在一起，该参数阻止了消息队列群集扩展资源，并且您将获得降级且可能破坏的服务。
尽管可能难以预测特定的行为，但SRE和DEVOPS团队可以计划宏观问题，例如饱和，长期延迟和工作量过多。该计划的一部分应包括设计以优雅的服务降级，这允许在避免灾难性失败的同时提供更多的功能。网络工程师，例如，如果不再可用路径，则设计网络以重新路由流量。这可能会导致其他路线和更长的潜伏期上的饱和度更高，但交通最终到达目的地。大规模的企业应用程序可以从设计优美的退化中受益。
在设计系统以进行弹性和优雅的降解时，请考虑这四种既定实践中的哪种最适合您的服务，从对用户产生影响最大的开始：
- 减少工作量
- 时间转移工作量
- 降低服务质量
- 增加容量
让我们仔细看看每个人：
1.摆脱工作量
当对发电设施的需求超过容量并冒着损害整个系统的风险时，工程师会关闭电网部分的电源。这被称为负载脱落，是解决分布式系统过多负载的恰当类比。例如，当请求API调用，数据库连接或持久存储超过当前容量时，其中一些请求将被删除。
负载脱落的关键设计考虑因素是决定要删除哪些请求。简单的方法是在超过阈值时将所有请求放在服务上。尽管相对易于实施，但这种方法并没有区分不同的服务级别或特定请求的优先级。例如，应将健康检查优先于服务的其他请求。
2.时间移动工作量
对于某些服务而言，减轻负载可能不是一个选择。如果您开展了一项巨大成功的营销活动，而新客户淹没了您的电子商务网站，则不想丢弃订单交易。一个更好的选择是时间转移过多工作量的处理。该技术将请求的生成从该请求的处理中分离出来。
消息队列，例如Apache Kafka和Google Cloud Pub/sub，广泛用于缓冲此类异步处理的数据。但是，在使用此技术时，您应该考虑交易的范围。每个解耦服务都可以实现交易，但是如果一系列服务调用必须成功或失败，则可能需要其他逻辑来确保正确回滚的跨越多个服务的交易。
3.降低服务质量
当您不想脱落或分时工作量，但仍需要减少系统的负载，您可能会降低服务质量。例如，如果您的系统受到压力，则可以暂时降低哪些功能可用或切换到近似数据库查询而不是确定性查询。这种方法的一个优点是您仍然可以服务所有请求，而不是删除一些请求。此策略还可以帮助您避免与时间转移相关的时间延迟。
4.增加更多容量
理想情况下，从客户体验POV来看，最好不要省下工作量，时移工作量或退化服务。另一方面，增加容量通常是处理工作负载尖峰的最佳选择。云提供商允许您自动自动VM和其他基础架构组件，以及Kubernetes可以自动缩放POD，以应对工作负载的变化。除非可用资源量耗尽，否则这些操作很少需要人类干预；例如，公共云中的一个区域发生故障会导致该地区剩余区域中对资源的突然需求。
最后，一些高级容量规划和主动监视可以帮助您的团队创建更多的弹性服务。
期待预期
现代软件的最终承诺是100％正常运行时间，但是SRE和DEVOPS团队必须为无法避免的系统中的工作量模式和复杂的故障模式做好准备。如果您在设计应用程序时考虑了这些因素，那么您将为建立具有弹性且能够优雅降解的系统做好准备。希望不会影响您的正常运行时间。
除了优雅的退化之外，还可以学习如何监视您的电子书中的完整云体验，采用，实验和规模：云原生成功的核心能力
经过
经过
经过