运维体系建设(稳定性保障体系22)

运维体系建设(稳定性保障体系22)

（本字共2731字，大约需要阅读7分钟）

负载管理——流量管理

今天我们聊聊流量管理方法的第二部分，请求质量管理。在前面介绍后端负载均衡的章节中，我们已经了解了一些请求质量管理方法，但是仅靠那些标准的优化方法是远远不够的，或者说那些方法只是让系统中各节点的负载分配的更均衡一些，流量管理中的请求质量管理，是需要解决全局过载，DDos攻击等，避免整个系统的所有节点出现全局过载现象。

全局过载（global overload）：在配置了负载均衡的理想情况下，每个前端服务都能和他们所依赖的后端服务之间协调功能发布，从而使后端服务永远有足够容量服务前端服务，这样全局过载情况就永远不会发生，但现实中全局过载的现象出现得非常频繁。

这种现象的原因是一个业务系统通常是多级服务器互联的，并非只有前端和后端两级，这导致了在后端服务的后端服务器上，或者那些被很多其他前端依赖使用的内部服务上，一些在两级系统中偶尔出现的高成本计算变得非常频繁，其负载水平非常的高，而一旦负载水平高到一定程度，就会使整个系统进入全局过载，导致系统不可用。

全局过载可在后端和前端进行分别优化。

后端优化

对后端服务来说，当全局过载情况发生时，应该使过载服务只针对某些“异常”前端应用返回错误，其他前端应用则不应受影响。

具体策略如下：

1. 给每个前端设置限制：运维团队和客户团队协商一个合理的使用约定，同时使用这个约定来配置用户配额，并且配置相应的资源。实际配置中，分配后的资源总量可以超过实际的资源总量，因为每个前端都满负载运转的情况很少见。初始分配后，在后端任务中实时计算每个请求所消耗的资源（尤其是CPU）用量信息，然后进行微调。需要注意有些软件服务不是每个请求一个线程，这种软件用非阻塞API和线程池模式来处理每个请求的不同阶段。

2. 流量超限策略：当某个前端服务超过资源配额时，后端任务应该迅速拒绝该请求，返回用户配额不足的类型错误，该回复的实现资源应该比真正处理该请求所消耗的资源要少得多才算合理。

前端优化

前端请求质量管理功能一方面为了进一步降低后端无效负载（过滤原则），另一方面要避免因为帮助后端降低无效负载造成自身过载（防连锁故障）。

前端优化的原则：请求质量管理的处理一定要比正常业务处理节省资源。如某个服务在收到后端错误时记录调试信息，如果这个记录过程比接收后端正常业务结果成本还要高，则在后端出现服务波动时，该前端服务可能会优先于后端进入过载状态。

1、抗DDos

前端优化要解决的第一个问题（抗DDos）：后端给每个前端设置限制在某些情况下，拒绝请求消耗的资源可能跟实际执行该请求消耗内存差不多（应用层协议解析消耗比实际回复的内容消耗还多），发送这些拒绝回复仍然会消耗一定数据的资源，如果拒绝回复的数量也很多，这些资源消耗可能也十分可观。这种情况下，有可能该后端在忙着不停地发送拒绝回复时一样会进入过载状态。

这种情况在前端进行自行限速比交给后端处理要好的多，当某个前端检测到最近的请求错误中的一大部分都是由于"配置不足"错误导致时，该前端开始自行限制请求速度，限制它自己生成请求的数量。超过这个请求数量限制的请求直接在本地回复失败，而不会真正发到网络层。

这个实现过程如下：

数据结构：每个前端应用记录过去两分钟内的以下信息：

请求数量(requests)：应用层代码发生的所有请求的数量计数。请求接收数量(accepts)：后端任务接受的请求数量。

算法步骤1：在常规情况下，这两个值是相等的。随着后端任务开始拒绝请求，请求接受数量开始比请求数量小了。前端可以继续发送请求，直到请求数量=k*请求接受数量，k一般取2，一旦超过这个限制，前端开始自行节流，新的请求会在前端本地以一定概率被拒绝。即请求数量已大于接收数量的2倍。

算法步骤2：拒绝概率公式为：max{0,[请求数量-(k*请求接收数量)]/请求数量+1}。如请求数量为100，k取2，请求接收数量为20，则每5个请求有3个请求被丢弃，即超出接收比例的均丢弃。

算法步骤3：随着前端发送请求的速度加快，前端在本地丢弃请求的概率也会提高。

算法步骤4：对于那些处理请求消耗的资源和拒绝请求的资源相差无几的系统来说，需要根据实际情况修改k值，k=2意味着保持50%的处理率，k=1.1意味着保持90%的处理率，拒绝请求成本越高k值应越小，直至趋向于1。

不适用情况：该算法不适用于前端请求频率很低的情况，因为前端对后端状态的记录时间非常有限，仅仅是2分钟内的统计。

2、优先级标签

在应用层，我们也可以对各种服务请求在发送给后端之前标记优先级，以便于后端优先处理一些请求，但是需要注意的是，请求的优先级和该请求的延时性（网络设备上配置的Qos，即网络服务质量管理）要求是不相关的，比如当系统在用户在输入框中搜索关键字时会实时显示联想关键字，这些关键字的应用层请求可丢弃性非常强，也就是如果应用系统资源紧张是可以不被处理的，但是这些请求的网络层Qos要求仍然很高，因为很短的时间后用户就不再需要这个联想到的关键字。

优先级的分级参考：

在某个发往后端的请求都会被标记为4类中的一种，说明请求的重要性，对请求进行分级管理。

最重要（CRITICAL_PLUS）：为最重要的请求预留的类型，拒绝这些请求会造成非常严重的用户可见的问题重要（CRITICAL）：生产任务发出的默认请求类型，拒绝这些请求也会造成用户可见的问题，但是可能没有CRITICAL_PLUS那么严重。可丢弃的（SHEDDABLE_PLUS）：这些流量可以容忍某种程度的不可用性。这是批量任务发出的请求的默认值，这些请求通常可以过几分钟，或者几小时之后重试。可丢弃的（SHEDDABLE）：这些流量可能会经常遇到部分不可用的情况，偶尔会完全不可用。

优先级的分级的算法参考：

资源预留：服务必须为所有的CRITICAL_PLUS和CRITICAL流量配置相应的资源

资源配额：当资源配额不够时，后端任务将会按请求优先级顺序分级拒绝请求，这比资源配额基于前端应用的拒绝方式颗粒度要再细一些。

后端过载：当某个后端任务开始进入过载状态时，低优先级的请求会先被拒绝

与抗DDos功能配合：前端自行限速会根据每个优先级分别计数

重要性必须是能传递的：后端A接收到的重要性信息，处理过程中发送给其它后端处理后续或子任务，其它后端会使用与A相同的重要性属性。

标签的添加：通常在离客户端最近的http前端服务器上给任务打上重要性标签。然后在特殊情况下在处理栈的某处可以覆盖优先级设置。

今天的内容有点长，用一篇就聊完了请求质量管理。明天我们聊聊流量管理方法的第三部分——怎样处理后端返回的过载错误。