API网关的一个重要功能就是进行流量的控制，当然这里主要是沿用大众的概念，毕竟限流这个词是很容易普及的，其实更加贴切的说法我更愿意把这个Control使用Adjust，至于原因我这里先不直表，等我文章写完了，答案应该自然就出来了。那么我们先来说说流量控制的几个策略，这里还是主要以控制为主，常见的有熔断、限流，所以我先不使用调整。
熔断
熔断其实字面意思很好理解，但是仔细推敲下来有两个层面的意思：
1、服务端熔断：后端服务的upstream的一个成员或者微服务的一个服务实例响应超时，这时候API网关根据http响应自动对这一个成员或者实例进行限流，使后来的流量打到其他的成员或者实例。
2、客户端熔断：根据某一客户端或者某一组客户端的行为特征，当流量激增并且与业务行为的典型特征不同，这时候API网关根据客户端IP、用户分布等特征进行熔断。笔者曾经遇到过一个案例，某App做新用户注册的运营活动，注册后就给积分，再加上几个线上活动：签到、玩游戏+积分、发帖+积分等一系列操作，基本可以达到1000积分，这1000积分在疫情期间可以兑换口罩、平时可以是JD卡密等，这样的信息被羊毛党盯上了，就会快速跟进，第一次试点了薅了几次羊毛之后，第二次成批的注册用户，然后使用爬虫去签到、玩游戏直接兑换JD卡。这时候就是要用最快的速度反爬、客户端熔断。客户端熔断实际上还有一个更加明显的事件，前几年的双十一实际上支付宝都是对淘系以外的商家进行直接熔断来的，实际就是保障自己的支付服务的正常进行，同时打压一下小电商的双11分流。
限流
限流的字面意思更好理解，也不存在服务端限流，主要是对客户端限流，但是限流的算法很多，这里有同学可能要问，都是提供降级服务，为什么限流的算法很复杂，但是熔断却很少呢，至少上述章节就没有提到，这里稍作补充，熔断一般都是大事件，自动熔断是比较少的，常见的还是人工触发熔断，也就是由后台监控之后综合业务表现来发出熔断的指令，而限流一般不需要业务参与，会根据各种指标进行技术限流，你比如：API相应报文大小、单位时间内的最大/平均请求次数，后台服务根据监控主动请求限流，针对特定时间段限流、针对特定IP限流，根据用户分组（VIP/非VIP）限流等等
对于这么多的限流场景，其实更多的场景是上述限流条件的组合，所以对于API网关而言，除了要提供基本的插件式方式允许用户自定义限流条件，还要能对限流条件进行组合，排列优先级，判断互斥等。除了技术上的储备，还要对业务熟练，你比如用户分组就是一个与业务场景结合比较紧密的条件，很难从技术上进行直接定义。
整流
熔断和限流都是常用的服务降级手段，相对而言熔断比较硬一些，限流稍微软一些，但是跟我们这里提到的整流比起来，还是不够软。那么我们来说说什么是整流，就是流量整形，或者换一个更加容易理解的流量缓冲。流量整形的源出处应该是网络概念里面的术语，有流量监管和流量整形，其实这个概念在我们生活中有更形象的例子：
实际上API网关的整流思路与高速公路的收费口一致，就是无论你进来的流量多少，我都可以把入口流量按照一定的热度调整成后端服务可以承受的速度，这样就不会像熔断和限流那样给到用户非常硬的响应回复，而是一种排队等待。流量整形经常发生在一些特定的业务场景，你不如秒杀。
写在最后
API流控常规的操作手段都是在控制，因此被称为流控也很正常，而实际上我们更应该有一些服务思维，可以通过流量整形这样的思路，来调整流量的密度、频次等，从而能给业务带来更丰富的场景实践。
