云服务过载控制的前世今生

来源：《华为云SRE确定性运维专刊》第三期

作者：郑磊

      1.    为什么会有过载？
      过载，是服务或应用处理的请求超过了自身所能承载的能力，造成服务或应用自身处理请求时延变慢、错误率增加，或者请求失败，乃至服务中断。

      如上图，客户端与服务器通信的分布式系统中，客户端在等待一段时间后常常会变得不耐烦，并会停止等待服务器响应。这段时间称为超时时间。如果服务器因过载而导致其延迟超过客户端的超时值，请求会开始失败。图1显示服务器响应时间如何随着提交的吞吐量（以每秒事务数为单位）增加而延长，最终到达情况迅速恶化的转折点。

      如上图，当响应时间超过客户端超时值，可清楚看到情况很糟糕，但并未显示到底有多糟糕。可在延迟旁边画出客户端感知到的可用性，不使用常规的响应时间测量值，而是改用中值响应时间。中值响应时间表示50%的请求比中值快。如果服务的中值延迟时间等于客户端超时值，则表示一半的请求超时，因此可用性为50%，进而将延迟增加问题转化为可用性问题。
      2.    过载的典型表现？
      2.1 典型过载环介绍
      ● 客户端发起一个会造成系统瘫痪的恶意/规模性请求。
      ●  LB节点将这个请求转发给一个后端服务管理节点处理。
      ●  后端服务管理节点尝试处理这个恶意/规模性请求。
      ●  LB节点自动识别到这个请求后端管理节点无法正常处理，并将处理这个请求的管理节点剔除。
      ●  客户端再次尝试，且LB将这个恶意请求再次下发给另外一个后端管理节点。
      ●  LB再次将处理这个恶意请求的后端管理节点剔除。
      ● 恶意/规模请求一直持续下去，直到所有的后端管理节点故障，乃至重大隐患/事件发生。

      2.2 过载表现说明

      ● 缺少基于优先级的过载控制（按照租户/请求类型QoS），导致请求处理通道堵塞或异常，任何请求均失败。                          

       ● 缺少过载感知与溯源能力，海量蚂蚁流类请求无序抢占，导致正常请求出现了性能损失，但无法在短时间内感知过载现象，无法获取过载源。

      ● 缺少依赖组件过载感知与控制，服务自身请求没有过载，但依赖组件出现过载，导致服务整个链路的请求发生过载。

      3.    如何应对服务/应用过载？
      应对业务随机突增，扩展服务或应用处理能力，但无法控制客户的请求按照优先级处理。当客户端请求速率超过规格时，相应请求可被拒绝、或可被限制（包括速限制单个客户端对该服务继续施加负载），实现服务或应用已承接业务的持续高可用（已经接入用户，在过载期间SLA满足业务目标）。
      过载处理模型：通用可伸缩定律(Universal Scalability Law)，阿姆达尔定律Amdahl’s Law的一个衍生理论，定义了系统中的串行化，例如数据库的性能瓶颈，包括关系数据库和非关系数据库，很难做到在线实时扩缩容。重负载时，请求排队等待处理，这时线程争用，上下文切换和垃圾回收等会加重系统负载。请求排队的时间越来越长直到超时，如此形成一个恶性循环。

      服务过载控制是一个循序渐进的过程，在大象流/蚂蚁流的冲击下，服务一般具备三步走的过载控制：
      Step1：服务过载自治，包括Scale-out，Scale-up，基于系统自身的基础能力进行扩容。
      Step2：感知过载现象，哪个服务/集群出现了过载异常，影响了哪些业务。
      Step3: 启动过载控制
      3.1基础过载控制：重试保护，小服务主动消费，超时保护，幂等保等基础能力。
      3.2中阶过载控制：过载溯源，基于QoS、黑白名单的过载控制。
      3.3高阶过载控制：基于AIOPS自动学习，主动进行过载反压，过载拉黑，及精细化QoS、黑白名单控制等。
      本文重点介绍服务或应用应对过载的基础能力：
      ● 重试保护：重试服务调用链中，存在逐级放大的风险。可以每个主调用最多重试1次；为每个依赖项保留少数重试次数（最多10次），如每1000次请求重试次数最多10次。
      ● 消费者向生产者发起请求：拥有小规格的服务向大规格服务请求，而不是大规格服务请求小规格服务，减少内部冲击！

      ● 超时保护：服务依赖项响应慢要有超时保护（如TP99.9出现异常，主动超时），减少服务请求因尝试/多次超时对系统造成持续消耗，最终导致服务过载。
      ● 幂等设计&过时请求释放：每个请求包含唯一ID，如果与请求ID关联的请求已经成功，在再次获得相同请求时，直接忽略，并确认成功即可（公网不稳定/不可靠是一个长期存在的现实）。且排队过期请求（long live），如50%客户在10秒后放弃请求，系统在5min后处理该请求的意义就不存在了。
      ● 服务降级：服务在降级/亚健康前，主动拒绝不能处理的请求，减少过度请求对系统造成过载冲击。
      ● 统一错误码：过载类的API请求或过载类的页面请求定义唯一的标识符，支撑客户端快速感知过载现象，进而在客户端主动规避过载异常。
      结束语：
      服务过载在云时代是必然存在的，上层应用（比如某购物App，或者某翻译App）客户端少量重负载的大象流或海量的蚂蚁流请求下会造成服务过载，服务端偶发的高负载会造成服务过载，网络的抖动或时延会造成服务过载，互联网各种攻击/恶意行为也会造成服务过载。如何解决与应对成为了云服务开发、运营与运维的关键能力。
      如何高效&及时感知过载、有效的处置过载就成为了关键能力，本期我们谈到基础过载控制能力，下期会围绕过载控制与感知的中高阶能力进行介绍，包括过载溯源，精细化与分布式的过载控制等。