腾云忆想技术干货|TSF微服务治理实战系列（三）——服务限流

导语

大家应该都有去游乐园游玩的经历，其实服务限流与游乐园人流管理很相似。比如每一个游乐园所能承载的标准游客总数是大概确定的，当游乐园承载的游客数量超出了标准数量，游客在游玩的时候就会出现游玩路线人潮拥挤（请求拥堵处理慢）、热点游乐设施排队久（热点API过载）、餐品饮料供应缺货（数据库连接池不足）等情况，更有在重大节日时由于人数太多导致的踩踏事故（服务宕机导致的雪崩）。

服务限流其实就是一种应对超额流量的保护机制，当业务流量超出系统能够承载的上限时，快速处理超额的请求（如快速失败），防止超额的请求继续争抢/占用系统资源。本节将简单介绍服务限流针对的问题域、设计原则及TSF在服务限流方面的能力和使用场景。

 

作者简介

崔凯                                                                        

腾云忆想产品架构师

多年分布式、高并发电子商务系统的研发、系统架构设计经验，擅长主流微服务架构技术平台的落地和实施，目前专注于微服务架构相关中间件的研究推广和最佳实践的沉淀，致力于帮助企业完成数字化转。

限流概述

问题域

社会的优势资源总是稀缺的，稀缺的资源又总是让人蜂拥而至。比如在12306抢春节回家的票，就是一场全国返乡人民都会参与的秒杀活动，如此大规模的流量让春节回家难这件事年年上热搜，那么具体是什么技术原因导致的呢？

• 由于回家心切而过于激动的去重复刷新抢票页面（海量并发读）；

• 票放出的时间和库存都是固定的，所有人会在同一时间点击购买按钮（海量并发写）；

• 很多人就想抢到好时间段的票，就去买了抢票机器人（流量放大）；

• 系统没有做多级缓存、数据精简、消息队列解耦等（自身架构问题）。

上述原因只是一部分主要影响因素，在遭遇大流量时，如果没有适当的防御机制，轻则系统响应缓慢、频繁报错，重则系统瘫痪。其实每年的车票就那么多，与其让所有人都花费额外的资源去争抢，不如早早让用户知道卖光了，快速失败。

服务限流就是为了保护后端服务和数据不被大流量击垮而设计，当发生流量浪涌时，让实例能在最大有效负荷运行，而不会超过负载导致崩溃。

能力模型

产品的能力再炫酷，也需要落地在问题场景中才能产生价值。那么针对上述问题场景，服务限流可以使用哪些能力模型来解决问题呢？小编认为至少需要具备如下几种主要的能力：全局限流从整体限定服务容量（包括网关和业务服务），标签限流进行精准的细粒度控制，动态调节让服务可以根据自身状态自适应调整流量。

• 全局限流

从每个服务的视角整体把控服务容量，并且不区分调用请求的来源。所有流经被调用服务的请求都将被统计计数，一旦统计数字超过了全局限流配置的阈值，整个服务会拒绝超过配额的请求。

• 标签限流

通过标签化能力，将上游请求进行分类，针对不同种类的请求配置不同的限流规则，同时限流规则甚至可以精确控制到每个请求上。最终通过多个限流规则的组合，实现针对服务中不同API、不同流量来源的组合型防护。

• 动态调节

每个单个实例基于自身情况，通过算法动态调整流经服务的请求数量，保证在不超过每个