一、导语
我们应该都有去游乐园玩耍的阅历，其实服务限流与游乐园人流办理很相似。比方每一个游乐园所能承载的规范游客总数是大概确定的，当游乐园承载的游客数量超出了规范数量，游客在玩耍的时分就会出现玩耍道路人潮拥挤（恳求拥堵处理慢）、热门游乐设施排队久（热门API过载）、餐品饮料供给缺货（数据库连接池缺乏）等状况，更有在严重节日时因为人数太多导致的践踏事端（服务宕机导致的雪崩）。
服务限流其实就是一种应对超量流量的保护机制，当事务流量超出体系能够承载的上限时，快速处理超量的恳求（如快速失利），防止超量的恳求继续争抢/占用体系资源。本节将简略介绍服务限流针对的问题域、规划准则及TSF在服务限流方面的才干和运用场景。
二、作者介绍
崔凯
腾讯云 CSIG 微服务产品中心产品架构师
多年分布式、高并发电子商务体系的研制、体系架构规划经历，拿手干流微服务架构技能渠道的落地和施行，现在专注于微服务架构相关中间件的研究推广和最佳实践的沉淀，致力于协助企业完结数字化转型。
三、限流概述
问题域
社会的优势资源总是稀缺的，稀缺的资源又总是让人蜂拥而至。比方在12306抢新年回家的票，就是一场全国返乡公民都会参加的秒杀活动，如此大规模的流量让新年回家难这件事年年上热搜，那么具体是什么技能原因导致的呢？
-
因为回家心切而过于激动的去重复刷新抢票页面（海量并发读）；
-
票放出的时刻和库存都是固定的，一切人会在同一时刻点击购买按钮（海量并发写）；
-
很多人就想抢到好时刻段的票，就去买了抢票机器人（流量扩大）；
-
体系没有做多级缓存、数据精简、消息行列解耦等优化操作（本身架构问题）。
上述原因只是一部分首要影响要素，在遭遇大流量时，假如没有恰当的防御机制，轻则体系呼应缓慢、频频报错，重则体系瘫痪。其实每年的车票就那么多，与其让一切人都花费额定的资源去争抢，不如早早让用户知道卖光了，快速失利。
服务限流就是为了保护后端服务和数据不被大流量击垮而规划，当产生流量浪涌时，让实例能在最大有用负荷运行，而不会超越负载导致溃散。
才干模型
产品的才干再炫酷，也需求落地在问题场景中才干产生价值。那么针对上述问题场景，服务限流能够运用哪些才干模型来解决问题呢？小编以为至少需求具有如下几种首要的才干：大约束流从全体约束服务容量（包含网关和事务服务），标签限流进行精准的细粒度操控，动态调理让服务能够依据本身状况自习惯调整流量。
大约束流
从每个服务的视角全体把控服务容量，并且不区别调用恳求的来历。一切流经被调用服务的恳求都将被计算计数，一旦计算数字超越了大约束流装备的阈值，整个服务会拒绝超越配额的恳求。
标签限流
经过标签化才干，将上游恳求进行分类，针对不同品种的恳求装备不同的限流规矩，一同限流规矩甚至能够精确操控到每个恳求上。最终经过多个限流规矩的组合，完结针对服务中不同API、不同流量来历的组合型防护。
动态调理
针对单个实例依据本身状况和算法，能够动态调整流经恳求数量，确保在不超越每个实例最大吞吐量的状况下，使得资源被有用的充分利用。
限流算法
限流常见的算法包含固定窗口算法、滑动窗口算法、漏斗算法、令牌桶算法等，算法的内容在互联网已有许多描述，小编不再赘述，只简要比照各算法好坏点。
| 算法称号 | 长处 | 缺陷 |
|---|---|---|
| 固定窗口算法 | 代码逻辑简略易完结 | 窗口临界点流量翻倍问题 |
| 滑动窗口算法 | 防止了临界点翻倍问题 | 超越临界值后没有缓冲机制 |
| 漏斗算法 | 固定速率确保安稳性，有必定缓冲 | 瞬时流量不能在短时刻内立即被处理 |
| 令牌桶算法 | 统筹缓冲机制和瞬时流量处理 | 初度启动时令牌数量需优化 |
其实每种算法都有运用的场景，比方滑动窗口算法，完结起来简略易懂，比较合适简略的限流场景；漏斗算法因为其流出速率恒定的特色，更偏重于保护下流服务，削减大流量对下流服务或三方渠道的冲击；令牌桶算法更重视保护运用本身，一同满意了对恳求进行缓冲和瞬时大流量问题的平衡。
别的在微服务体系中，限流更多的落地办法，更多的落地办法是大量微服务共用一套分布式限流结构，方便一致装备、一致运维、一致办理。TSF服务限流经过令牌桶算法，完结了一整套分布式服务限流的管控机制，使得运用在引用TSF-SDK后，开箱即用的获得分布式限流的才干。
上图为TSF服务限流架构示意图，首先支撑端限流中心依据用户的限流装备，计算得出服务中每个实例单位时刻（1S）内应经过的最大的恳求数配额（单位时刻内最大流经恳求数），并将该配额下发到每一个对应的服务实例中（各实例配额并不相同）。其次TSF-SDK会将单位时刻内的计算数据上传到限流中心，供限流中心计算下一个单位时刻应当下发的配额。最终，在当时单位时刻内，当超越配额的恳求抵达实例后，就会被拦截并回来HTTP 429（Too Many Requests）错误。
简略总结下，TSF服务限流经过SDK实时上报的实例计算数据，使得限流中心组件能够动态的调整每个实例当时的配额数值。例如一个服务有4个实例，大约束流装备为100QPS，则每个实例初始时各得25的配额。但当某一个实例产生堵塞，该堵塞实例会经过上报数据被限流中心感知，之后分配给堵塞实例的配额会恰当削减（如5），并恰当增加其它实例的压力。堵塞实例在低流量压力状况下逐步康复后，限流中心能够捕获到实例的压力已经减小，又会重新调整每个实例的配额到底子均分状况。
限流准则
以下图为例是一个通用的WEB体系架构，流量经过APP、PC、第三方渠道等不同的入口经过网关的安全鉴权和攻击防护，经过CLB负载到每一个微服务网关暴露的对外API上，再由微服务网关将恳求分发到不同的后端服务中。
从规划服务限流的视角，咱们不该只是将限流的动作约束在某一些服务上，需尽量从整个架构的视角来分析，中心思维是“分层分级”。
分层是指恳求从网关进入到回来用户，经过了网关、LB、微服务网关、后端服务等多层环节，咱们其实能够在恳求流经的每一层进行缓存，提早削减不安全的（如恶意攻击）、非必要的（如静态资源）的恳求直接透传到后端服务和DB，防止名贵资源被浪费。
分级是指用户恳求会不同程度的分散到网关、前台服务、中台服务中的各个API中，那么依据服务是否中心、API是否热门等不同的特征，能够对各微服务进行分级。例如关于入口型的微服务网关或许BFF聚合服务，更合适装备针对网关/服务的大约束流；中心服务的中心API更合适装备针对API的标签限流；针对单个服务中API数量较多的状况，单独装备API或许不切实践，更合适经过大约束流装备一个该服务QPS合计的预估峰值。
别的，在装备限流之前，对微服务的历史数据（QPS均值和峰值、PV/UV等）、可搜集到的已有事务数据（用户数、库存、商家、预估流量等）、资源耗费状况（服务器装备和数量、CPU内存与流量的对应关系等）提早参照，也是重要的精确评价流量的手法。
压测办法
在进行服务限流装备之前，首先要了解服务所在的层级、服务的预估容量等状况，这就需求一套完好的压测办法来支撑。以下为一些项目中压测的落地经历，供各位读者参阅。
首先，在准备压测前先了解一些压测的“潜规矩”：
-
尽量确保压测环境与生产环境的服务器装备、数量、型号保持一致；
-
影响压测的要素包含不限于：实例数量、服务器装备、运用装备、网络环境等；
-
经过改动上述某一个影响压测的要素，观察压测数据的变化趋势，而不要一同改动多个；
-
当服务中待压测接口较多时，优先压测中心接口，因为时刻总是有限；
-
常见或许的拐点为，在并发压力增大时QPS相等或不升反降、运用报错率飙高、呼应耗时飙高等；
-
长链路压测过程中尽量确保被压服务的下流依靠服务资源相对闲暇，如consumer->provider且consumer为被压服务时，需确保provider并无明显压力；
-
可先经过mock的办法压测本身的服务容量，再进行全链路压测。
其次，关于服务中单个API的压测，意图在于承认每个API在不同场景下的QPS。关于全链路的压测，是以模仿实在事务链路为条件，将服务中单个API进行串联后，承认链路上一切相关API的QPS，两种场景是从不同的视角动身的。全链路压测的问题在于，当上游服务的API成为瓶颈时，下流API的性能再好也无从发挥且不易察觉，而单个API的压测刚好弥补了这一点。一同，依据对上下流API和全体链路的QPS分析比对，能够有用的削减链路中不必要的资源浪费。所以在压测用例中能够尝试如下用例组合：
-
服务单实例：经过单实例压测，了解每一个单独的布置单元的接口/服务容量；
-
服务多实例：单实例前增加一层客户端负载均衡，与单实例的压测数据比照，观察对接口的影响；
-
网关单实例：同服务单实例，了解网关单实例容量；
-
网关多实例：同服务多实例，了解网关多实例容量；
-
网关+服务：经过增加网关，观察网关路由对接口的影响；
-
CLB+网关+服务：经过增加CLB，观察CLB对接口的影响；
-
CLB+网关+服务A+服务B+服务C：经过全链路压测，了解实在事务链路状况下服务运行的状况。
增加实例并不会线性增加容量，当进行服务容量评价时，需求以实践压测结果作为参阅。别的，针对压测数值要留有必定的安全空间作为缓冲，一般限流装备的阈值需依据实例均匀CPU在70-80%左右时的QPS体现来确定。如网关压测时QPS为10000时CPU跑满且呼应耗时开端明显增加（性能拐点），一同在QPS为7500时，各实例CPU均匀数值为70%，则装备限流阈值应为7500（服务API同理）。具体如下表所示：
| 运用类型 | CPU100%压测数值 | 实践装备数值 |
|---|---|---|
| 网关 | 10000 | 7500 |
| 服务 | 200 | 150 |
在压测过程中mock接口或许需求模仿实在调用的随机延时，可从事务分支拉出专门用于压测的压测分支，并对待压测接口进行mock修正，mock代码内容可参阅如下代码的思路编写:
public String mockResponseTime() throws InterruptedException {
int responseTime = 0;
Random randomProportion = new Random();
Random randomOffset = new Random();
int proportion = randomProportion.nextInt(100);
int offset = randomOffset.nextInt(5);
if(proportion < 80){
responseTime = calcTime(50,offset);
} else if(proportion >=80 && proportion < 95){
responseTime = calcTime(200,offset);
}else {
responseTime = calcTime(400,offset);
}
Thread.sleep(responseTime);
return "OK";
}
private int calcTime(int milliSecond,int offset){
Random random = new Random();
if(random.nextInt(100) % 2 == 0){
return milliSecond + offset;
}
return milliSecond - offset;
}
四、TSF限流
装备办法
TSF的服务限流包含两种装备办法：大约束流、标签限流。大约束流针对整个微服务的一切恳求，标签限流能够依据上游流量带着的体系标签或自定义标签进行细粒度管控。限流的装备首要经过装备时刻和恳求数来操控。
一个服务能够有多个一同收效的限流规矩，当一个恳求被多个限流规矩束缚时，则仅当一切效果规矩都判经过时才会放行。且恳求经过后每个效果规矩的通行恳求数+1。若被一个规矩拦截，则针对该规矩的限流恳求数+1。
此外，TSF弹性弹性机制能够经过观测QPS、呼应时刻、CPU运用率、内存运用率的监控数据，对服务实例数量进行动态水平扩缩，安全有用的削减运维本钱。当瞬时大流量来暂时，启用弹性弹性组内的预留资源，尽或许接受用户的事务恳求。合作容器本身快速弹性弹性的特性，能够完结服务的秒级扩缩容。
装备弹性弹性规矩时留意CPU利用率、内存利用率、恳求QPS、呼应时刻的判断取的都是相关布置组内一切实例对应目标的均匀值。冷却时刻是指在完结一次扩缩容之后，会距离一段时刻（即冷却时刻），期间并不会再次判断和触发弹性弹性。
不过，留意弹性弹性与服务限流组合运用的场景。榜首，弹性弹性与限流一同监控QPS时，弹性弹性的规矩收效时刻需求持续至少1分钟以上才会收效，而限流需求在1秒内完结约束，会导致QPS在超限后马上被限流而达不到弹性扩容的条件或许已经超限至少1分钟后才开端限流；第二，弹性弹性的意图在于动态改动实例的数量，而限流规矩是依据固定的实例数量而装备的，当产生弹性扩缩容后，也就意味着原有装备的限流规矩失效并需求更新。
电商大促
每年的双11大促是商家和用户们的狂欢，但细心的读者朋友或许会发现，其实不止11月，每个月电商渠道都会招揽商家们搞促销。即使是为了应对3.15这种每年都会查办商家的晚会，各大渠道仍会乐此不疲。所以，关于有必定规模的电商渠道而言，体系为了应对每月促销所带来的巨大流量，限流几乎是研制团队的一项日常操作。
针对电商大促的场景，TSF能够经过大约束流+标签限流的组合来办理流量。首先，假定现在仅完结了中心服务consumer-demo的服务布置，未进行任何的限流装备。
在日常流量大幅动摇时，中心服务没有自保机制，这是事务不能接受的，所以需求对中心服务增加限流规矩。在经过压测及历史数据分析后，预估当时资源装备可支撑的容量为1500QPS，即大约束流装备每1秒1500个恳求作为上限，如下图所示：
其次，仅装备大约束流不能针对性解决热门API超载的问题，那么能够合作标签限流针对热门API进行约束，如下图所示将某一个热门API约束在1000QPS以内。
额定弥补一点，因为微服务网关/网关是南北流量的入口，一旦网关瘫痪或毛病，影响的是一切的事务。假如不在网关处增加必定的限流规矩，或许会产生恳求还没有流经后端服务，网关已经先搞挂了，这样后端的限流战略底子无从起效。
五、结语
服务限流比较其他管理手法更简单在落地项目中看到，首要是因为其完结办法比较老练，一同各行各业中有丰厚的落地场景。TSF服务限流的首要价值在于，很少的代码改造本钱和学习本钱、能够一致办理不同语言及结构的限流战略、简略的操控台运用办法、免运维的支撑办法，让用户能够快速的获得安稳的服务限流才干。
别的服务限流也需求在未来习惯更多的场景，比方跟降级规矩的联动、如何做到更精准的流量预测和流量自习惯、如何做到毫秒级限流等。跟着微服务管理实战系列已经来到了第三章，也希望能更多的得到我们的反馈，一同探索更多的落地场景和办法。
引用
cloud.tencent.com/document/pr…
cloud.tencent.com/document/pr…
