上一篇我们聊过了架构设计中的“服务隔离“模式,今天我们继续来探索一下在分布式系统架构中的另一个常用的设计:服务限流。
那么,什么是“服务限流”呢?在解释“服务限流”之前,我们来看一下前些时间网上很火的一个段子,说的是新浪微博的一名工程师正在家里办婚礼,突然接到公司的电话要紧急处理线上流量激增的问题,那天应该是某当红明星突然在微博上公布恋情,微博流量突增好几倍,导致系统功能出现不稳定,用户访问不畅。然后这名工程师就只好晾开新娘,在婚礼现场穿着西装打开笔记本调试代码了。
当时这名工程师内心肯定是崩溃的,肯定在想:为啥要在今天公布恋情!等我把系统的扩容和服务限流机制做好先啊。
哈哈,看完了段子,基本上服务限流的作用也就明白:“服务限流”其实是指当系统资源不够,不足以应对大量请求,即系统资源与访问量出现矛盾的时候,我们为了保证有限的资源能够正常服务,因此对系统按照预设的规则进行流量限制或功能限制的一种方法。
<强> 一,为什么要做服务限流设计?
再举一个我们生活中的例子:一些热门的旅游景点,往往会对每日的旅游参观人数有严格的限制,比如厦门的鼓浪屿,北京的故宫等,每天只会卖出固定数目的门票,如果你去的晚了,可能当天的票就已经卖完了,当天就无法进去游玩了。
为什么旅游景点要做这样的限制呢?多卖一些门票多赚一些钱岂不是更好吗?
其实对于旅游景点而言,她们也很无奈,因为景点的服务资源有限嘛,每日能服务的人数是有限的,一旦放开限制了,景点的工作人员就会不够用,卫生情况也得不到保障,安全也有隐患,超密集的人群也会严重的影响游客的体验。但由于景区名气大,来游玩的旅客络绎不绝,远超出了景区的承载能力,因此景区只好做出限制每日人员流量的举措。
同理,在软件行业中,系统服务也是这样的。
如果你的系统理论是时间单位内可服务100 w用户,但是今天却突然来了300 w用户,由于用户流量的随机性,如果不加以限流,很有可能这300 w用户一下子就压垮了系统,导致所有人都得不到服务。
因此为了保证系统至少还能为100 w用户提供正常服务,我们需要对系统进行限流设计。
有的人可能会想,既然会有300 w用户来访问,那为啥系统不干脆设计成能足以支撑这么大量用户的集群呢?
这是个好问题。如果系统是长期有300 w的用户来访问,肯定是要做上述升级的,但是常常面临的情况是,系统的日常访问量就是100 w,只不过偶尔有一些不可预知的特定原因导致的短时间的流量激增,这个时候,公司往往出于节约成本的考虑,不会为了一个不常见的尖峰来把我们的系统扩容到最大的尺寸。
<强> 二,服务限流应该怎么做?
对系统服务进行限流,一般有如下几个模式:
熔断:这个模式是需要系统在设计之初,就要把熔断措施考虑进去。当系统出现问题时,如果短时间内无法修复,系统要自动做出判断,开启熔断开关,拒绝流量访问,避免大流量对后端的过载请求。系统也应该能够动态监测后端程序的修复情况,当程序已恢复稳定时,可以关闭熔断开关,恢复正常服务。
服务降级:将系统的所有功能服务进行一个分级,当系统出现问题,需要紧急限流时,可将不是那么重要的功能进行降级处理,停止服务,这样可以释放出更多的资源供给核心功能的去用例。如在电商平台中,如果突发流量激增,可临时将商品评论,积分等非核心功能进行降级,停止这些服务,释放出机器和CPU等资源来保障用户正常下的单,而这些降级的功能服务可以等整个系统恢复正常后,再来启动,进行补单/补偿处理。除了功能降级以外,还可以采用不直接操作数据库,而全部读缓存,写缓存的方式作为临时降级方案。
延迟处理:这个模式需要在系统的前端设置一个流量缓冲池,将所有的请求全部缓冲进这个池子,不立即处理,然后后端真正的业务处理程序从这个池子中取出请求依次处理,常见的可以用队列模式来实现。这就相当于用异步的方式去减少了后端的处理压力,但是当流量较大时,后端的处理能力有限,缓冲池里的请求可能处理不及时,会有一定程度延迟。
