流量治理开篇

本篇文章是笔者流量治理的第一篇文章，笔者希望在这里系统的讲解下这些年以来对流量和流量治理的理解，希望对读者有所帮助，也希望读者能够及时指正文章中笔者理解不对的地方。

本篇文章笔者会从下面几点来介绍流量治理。

问题一:流量治理是什么？

问题二:为什么需要流量治理？

问题三:如何进行流量治理？

一、流量治理是什么

流量治理:顾名思义流量治理就是针对流量就行治理，这里面有两个关键字，流量和治理。

流量从位置来看通常分为南北向流量和东西向流量，这两个概念都是来自于我们平时的画图，一般服务整个入口的流量也就是网关流量，因为我们画图通常都是上下结构，对应方位的话也就是上北下南，所以我们称从网关入口的流量叫做南北向流量。

同样的道理，东西向流量指的是服务和服务之间通讯的Rpc流量，这也根我们平时画图把这部分流量画成左右结构有很大关系，左西右东嘛，所以我们一般称这部分流量叫做东西向流量。

除了上面的划分方法，流量还可以按照同步和异步的方式进行划分成同步流量和异步流量。

其中同步流量指的是流量交互是直接交互的方式，不需要依赖第三方服务特别是MQ等，往往流量的处理是串行的。

异步流量指的是需要依赖第三方服务作为中转的流量，例如消息队列等，它把流量的生产者和消费者解耦开来，这一类流量通常是并行的，不需要等待消费结束在进行下一步操作。

治理，指的是采用人为参与的方式或者设计好的策略让流量按照我们希望的方式进行流动。对于治理而言，往往是堵和疏两种动作，基于这两种动作，可以对流量进行管控、引导，让流量从无序变得有序，从不可控变得可控，尽量让流量在能够管控的前提下留下它应该流向的地方。比如，我们通过削峰去把瞬时的大流量请求拉的平滑，让它能够在系统可接受的范围内慢慢消费掉。我们通过限流和熔断来将过多的流量丢弃来保护服务能够正常工作。同样我们也可以通过一致性Hash算法，来将指定的流量导流到指定的服务上面，进而进行专项整治。

二、流量需要治理的原因

对于流量来说，它具有下面几个特性:

1.不可预期性，特别是南北向流量，因为它承接的是用户的流量，而我们是没有办法提前预知流量什么时候来，来多少，来那些流量的。

2.不均衡性，流量的到来往往呈现出不均衡的特点，一个不均衡是时间不均衡，流量不会均匀到来，它会随着时间的迁移而呈现波动性，时高时低。

3.不可控制性，流量的到来有时候就是一瞬间就会来非常多，例如流量风暴，一旦到来之后，流量就不可控制，它不会因为你当前的资源承担不了，就不进行冲击。

而对于承担流量的服务来说，它们却有下面几个特性:

1.不变性，这里主要指的时候服务的资源往往是不变的，不会随着流量变大或者变小就会随之变化，除非我们实现了这个功能逻辑。

2.有限性，有限性分两方面，一方面是代码逻辑场景的有限性，它不会穷举所有的场景并加以实现，因为如此一来实现成本太高；一方面是资源的有限性，包括cpu、mem、网络io等等，对于一个服务来说，我们不可能无限制的去扩充它的资源，往往一个服务的资源都是在一个规定的范围内。

正式因为服务的特性和流量的特性存在矛盾和冲突，我们才需要流量治理。我们希望用尽量少的资源去承担更大的流量，希望流量在突增的时候我们的服务就算扛不住也不要挂掉，同时也希望能够根据流量的时间特性和业务特性来反馈给用户，进而能够挖掘出流量的产品价值。

三、如何流量治理

笔者根据对流量治理的程度将流量治理划分成了三个层级去治理:

层级一:提供稳定和准确的流量转发功能。

这一层级的治理比较低级，基本没做管控，算是草创阶段，目前市面上的网关和代理产品基本都具备这一个功能。主要特点包括:

1.产品能够提供一个很稳定性的功能，在流量没被放大的情况下，能够正常转发流量。

2.产品能够将正常的流量，准确的转发到它所归属的下游服务。

我们只要开发一个网关服务或者流量代理服务，在启动的时候把流量转发规则配置好即可，在流量到来的时候，便会实时转发流量。

这里的流量顶多也就支持2倍大小的流量变化，再大的话，服务会因为消费不过来，变慢甚至会崩掉。

对于流量转发功能也是比较死板的，不够灵活，路由转发配置不支持随时变动，必须重启服务才能生效。

层级二:提供有效的流量管控能力。

这一层级的治理能力相对第一层级高了一个纬度，属于流量治理层面的中级阶段，主要特点包括:

1.可以有效支持流量的持续增长，具备支持流量十倍到一百倍增长的能力。

当然这里的支持不是指的资源不变，而是在资源扩展到2到3倍的情况下，这就要求服务要具备水平扩展的能力，最好是无状态的。

2.可以有效应对流量瞬间徒增的流量变化，具备支持流量上一秒和下一秒就有流量峰值的场景，例如典型的秒杀系统。

这里的应对可以采用长用的削峰玩法，限流机制，熔断机制，优先级调度机制。

3.可以稳定的保护服务在大流量的冲击下，不被拖垮。

这里的拖垮主要指的是服务的水位，包括cpu和mem，我们需要建立负载保护机制，在水位到达一定量级的时候，我们需要有逻辑保证流量被直接或者选择性的丢弃。

除此之外，我们还需要支持便捷的服务降级能力，例如:旁路流量的降级，非关键功能的降级等等。

4.具备准确实时的监控能力。

这里的监控针对的是服务资源类的指标，例如:服务的整体水位(主要是cpu和mem）、网络io数据、内存的申请和释放频率，磁盘io的表现，业务核心队列的使用状态，流量层面的指标包括但不限于:流量的处理耗时、99线，流量的消息大小，rtt响应时间，响应错误率等等。

5.具备灵活调配流量转发的能力。

对于流量的转发需要通过配置修改就可以立马生效，当中不需要重启服务。这里的路由转发调配功能可以按照下面几个纬度进行划分，服务粒度，节点的实例粒度，接口粒度，甚至可以支持到消息头里面的标签这个粒度。

层级三:提供自适应的流量调度能力并能挖掘流量的数据价值。

这一层级的治理能力属于高级阶段，管控的主要侧重点在于第二层级的基础上进行自适应能力的支撑；除此之外，需要在数据上面做些文章，希望能够提供有价值的数据特性出去，一个目的是为了更好的进行运维，一个目的是为了提供更有价值的运营面数据价值出去。主要特点包括:

1.自适应的流量管控能力，包括:根据流量大小进行自动扩缩容，根据资源水位自动触发负载保护，根据流量特性进行自动降级、触发熔断等等。

2.尽量提供力所能及的数据价值，对于流量来说，它们本身就存在很多价值，例如运行时经过的轨迹、业务处理的快慢、99线、分布的时间曲线，消息本身的数据大小，消息的类型等等。

针对流量的这些特质，我们需要进行挖掘，把流量的这些特性进行聚合分析，展示出来，并能提供出去给对应的用户让流量变得更有价值，例如:可以让整个产品进行链路调优，让业务方可以知道热点并去优化系统，让运营人员能够二次分析用户行为，去优化产品，等等。

总结:

在有了前面的流量治理层级划分之后，我们首先，要做的就是对我们当前的产品进行评估，看下它们当前所属的级别。

其次，我们确定自己的业务所处的产品环境，是不是具备了升级流量治理能力的阶段，如果确定的话，就按部就班的开发和构建就好了。

作者:灰子

日期:2022年6月21日