干货概览

对于容量管理，在之前的文章《聊聊时序数据存储系统的容量管理》中，我们已经对容量建模和容量规划做了探讨。本文将继续跟大家介绍容量管理中最为重要的一环——过载保护部分的内容。

在高并发、海量数据存储场景下，系统过载的案例并不少见。一旦系统过载，通常无法使用常用的双集群主备切换预案立即止损，同时，集群过载很有可能产生流量雪崩现象，造成实例、机器批量假死或宕机，恢复成本巨大。所以我们需要通过一定的过载保护手段，保证系统在容量承载能力下最大限度的为用户提供服务。下面将给出系统过载保护的通用方案，以及在Noah平台智能监控系统的流式计算－时序数据存储（下文以Astream-TSDB指代）中的应用实践。

过载保护的通用解决方案

1 识别过载流量来源

过载流量来源通常意义上可以分为自然流量上涨和人为触发的流量上涨。自然流量上涨指的是由于业务量增长带来的可预期的系统流量。这类流量过载可以通过系统的弹性扩缩容解决，并且可以通过更科学的、更合理的容量规划得以规避。人为触发的流量来源可以细分为攻击性流量（比如DDOS攻击）和用户行为导致的非预期流量。无论哪一种流量来源，在后台都应该可以通过运维数据找到来源IP。在实际生产场景下，不同的业务都应该有自己定义好的业务数据模型，比如在Noah监控中，每个请求都必须带有自己的产品线（Product）、集群（Cluster）、服务单元（Namespace）等信息。这些数据为识别流量来源提供重要依据，同时也是做多租户配额管理的基础。

2 设置流量阈值

根据上一篇文章中的容量建模方法，可以合理的根据容量数据给出实例/系统的流量阈值。容量阈值的管理可以放在配置中心以方便随时调整。

3 采取合理的过载保护措施

过载保护的手段通常有限流和降级两种。限流指系统只允许阈值之下的流量通过，而对于超出阈值的流量不额外消耗资源处理，直接丢弃。降级指系统通过“业务剪枝”的手段，丢弃非重要功能或非重要流量来源的处理，保证核心功能不受影响、核心流量稳定处理。

从过载保护策略生效层级上来说，又可分为单实例级别和全局级别。单实例级别的过载保护策略只在单机单实例上做过载保护，其流量数据统计通常受负载均衡和流量局部波动的影响较大，不利于微小异常的过滤；相比之下，全局策略对此类情况处理起来更有优势，但全局策略势必会带来额外的开销和系统设计难度，具体使用哪一种，需要结合业务的实际情况具体问题具体分析。

Astream-TSDB场景下过载保护实践

1 过载场景描述

在Noah平台的智能监控系统中，用户可以以自定义监控配置的方式驱动客户端做监控采集。自定义监控配置的方式比较灵活，甚至支持以正则匹配的方式采集多维度数据，这时如果用户对正则匹配不够熟悉，或者滥用例如*这样的通配符，很容易匹配远超预期的维度数值，从而导致客户端发送下游的数据量翻倍,直接造成后端Astream-TSDB压力突增，影响后端服务的可用性。在这种场景下，由于无法提前预知用户提交的配置会产生多少数据点，直接在采集端做流量控制也具有一定难度。

2 过载保护机制实现

客户端限流

客户端的主要功能是根据用户配置的监控配置做本地采集，再将数据发送到下游计算存储。在客户端我们实现了远程限流配置控制开关。采集客户端会根据远程配置中的周期和阈值，在本地周期性的统计数据维度信息，统计的粒度从大到小，可以是集群级别(Cluster)、服务单元级别(Namespace)，甚至可以精确到单个监控指标（Metric）。若统计到的维度组合数目超过了配置中的阈值数目，则这些“超额”的数据拒绝发往下游模块，并在采集监控项中吐出超限的监控提示用户。客户端限流可以从源头最大程度切断下游模块过载的流量来源。由于在分布式系统中，各个采集任务落在不同的客户端上，每一个客户端都只能统计本机上的数据，各个客户端不过载并不能保证全局的不过载，所以单纯的用单机单实例限流的方式无法解决所有过载问题。

服务端限流

客户端的数据按服务单元名做一致性哈希计算发往服务端，在服务端表现为相同服务单元的数据落在某几个实例上。我们在存储服务端的单机层级也针对服务单元维度做了限流策略。虽然存储端能将入口流量限制住，但对于计算集群来说这部分流量还在重试范围内，在计算端还是有打垮计算集群模块的风险。所以，存储端在发现维度超限的情况后，会返回给计算集群一个特殊的返回码，上游计算集群收到返回码后将这部分流量不再重试，直接丢弃。这样就防止了上游计算集群的重试机制造成自身发送队列堵塞，同时避免流量翻倍打垮下游存储。同客户端一样，这也无法解决全局的流量过载问题。

云堤全局限流

为了避免单机限流的方案的不足带来的过载风险，我们针对Astream-TSDB的过载保护开发了云堤全局限流系统，整个监控的计算存储后端整体作为一个APP 接入云堤，实现全局计数和配额限流。它的主要思想是在计算存储后端模块的入口进行流量全局统计，在模块级别根据统计结果进行限流，达到模块级过载保护的效果。同时，将统计结果定期反馈到采集客户端，使得流量可以从最前端的入口进行限制，达到入口限流的效果。

云堤的运行流程如下:

a. 在计算端入口 Astream-adaptor以及存储端入口 Saver上集成云堤SDK，入口模块每次收到数据时，调用云堤SDK上报该数据在Namespace和User维度的原始数据点数增量

b. 云堤 SDK 返回上一个轮询周期统计到的Namespace和User维度的全局配额余量

c. 入口模块根据云堤 SDK 返回的余量判断该Namespace和User的原始数据点是否超限，并决策是否拒绝当前流量

d. 在客户端上，云堤提供当前统计结果中超限对象和超限指标的列表查询接口。由Checker模块负责轮询超限列表，并根据列表生成采集端限流配置，并同步到配置分发模块。

总结

以上是我在容量过载保护方面的一些粗浅经验和落地实践，如有不足之处，还请大家多提意见。

作者介绍：

姜泽，百度高级运维工程师。

负责百度智能运维产品（Noah）的运维工作，在可用性建设，容量管理方面有着丰富的实践经验。

本文转载自公众号AIOps智能运维（ID：AI_Ops）。

原文链接：

https://mp.weixin.qq.com/s/1d1u8Hc031IwICZMX00TMQ

创作场景

百度智能监控系统的过载保护实践