什么是限频和服务降级 ?
要保证一个大流量对外服务的稳定性, 通常我们很相当注意两个功能控制… 一个是请求的限流,一个是服务降级处理,他的意义在于不会让你的服务全瘫痪了,你可以适当的损失点东西利益,来保证最基础的功能, 这就是过载保护.
每个接口所能提供的单位时间服务能力是有限的。超过服务服务的承载能力,一般会造成整个接口服务停顿,或者应用 Crash毁掉,或者带来一系列未知已知的连锁反应,这样造成整个系统的服务能力丧失,SO 有必要在服务能力超限的情况下实时过载保护。 微信抢红包和小米抢购中,我们会遇到有人OK,有人被友好的deny了,这是因为服务过载保护了 .
为什么要做限流限频和降级?
首先假设几个有意思的场景,从用户访问的角度来看,如果设想有人想暴力碰撞网站的用户密码;或者黑客们尝试各种的sql注入;或者有人cc攻击某个很耗费资源的接口;或者有人想从某个接口大量抓取数据接口等等。 这时候标准的方法是加 应用级的防火墙,也就是咱们说的waf, waf是自带在线行为分析的.
除此之外,我们可以想象促销抢购的需求,当我们已知服务的只能应答约500qps, 但通过促销活动的力度推测可能要超过这个数,请求格外的多….
这时候就要做过载保护了,增加Rate limiting请求限速是个相当直接又易用的好办法。 请求增加限频后,我们后面有时间进一步解决这个问题,比如封堵来源或者特征… 也就是说 限速 是最根本的要求. 那么对于抢购的正常的请求遇到限速后,那么没办法,只能是粗暴的踢人了, 虽然损失了一部分超限的正常请求,但最少还能接客… 不至于请求都来了,后端服务因为处理不过来,直接hang住了,没得玩了…
可以想象成 村里的土鳖电闸安装了保险丝,一旦有人使用超大功率的设备,保险丝就会烧断以保护各个电器不被强电流给烧坏. 同理我们的接口也需要安装上“保险丝”,以防止非预期的请求对系统压力过大而引起的系统瘫痪,当流量过大时,可以采取拒绝或者引流等机制。
再回溯下刚才的电商促销场景,这对于 “服务降级” 的意义又是什么? 为啥又要用服务降级 ?
当服务器压力剧增的情况下,根据当前业务情况及流量对一些服务和页面有策略的降级,以此释放服务器资源以保证核心任务的正常运行。
假定可以分为一级服务,二级服务,三级服务,比如在紧急情况下,务必保证一级服务的稳定性,然后可以牺牲二级和三级服务,这个就是服务降级.
如果还是不懂,那么再举一些例子. 分级保护下 电商里面基本查询和支付可以用,至于评论、买家秀、聊天、收藏、评分等等可以先放放,最少保证买东西到付款这几步的api能正常. 又比如qq当带宽不够时 先砍视频通话,接着砍语音、传文件、群聊天、群图片、各信息推送. 最后最后至少能保留用户的在线状态. 以此类推,各种事例…
服务降级方式:
分级范围拒绝: 也就是我们上面说到的路数,根据uri来区分接处理口, 对于大量的接口适合走nginx lua redis, 当然你在后端做也可以.
增删改查接口拒绝:拒绝所有增删改动作,只允许查询, 错误页面内容可在CDN内获取。 如果是查询,那么直接走cache.
延迟持久化:页面访问照常,但是涉及记录变更,会提示稍晚能看到结果,将数据记录到异步队列或可回溯log,服务恢复后执行。
xxx: 还有几种….
说完服务降级后,再聊下服务请求的限频问题.
在哪里实现接口的限速限频 ? 限速限频的算法有多少?
接入层的限流:
- 基于nginx的limit_conn模块, 用来限制瞬时并发连接数.
- 基于nginx的limit_req模块, 限制每秒的平均速率.
- 基于nginx lua redis定制模块, 可实现多时间区间限速,具体uri限速、用户层限速等, 当然可分布式限速.
后端服务层限速:
- 基于用户级别的限速.
- 基于api的限速.
- 基于用户加api的限速.
- 基于流量限速
- 等等…
后端实现的限速明显更加细致灵活,前端因为是nginx所以性能肯定是最好的. 理论上来说后端能实现的复杂限速体系,我们可以复用在前端接入层. nginx lua可以足够我们构建复杂的接口限频体系了. 如果咱们是集群的场景,量级又不是吓人的. 用后端的限速完全可以支撑一个量级,多了不敢说,我们长期压测十几万的限频速度是没有问题, 注意 压测源和服务处理都是集群 !!!
我们知道分布式限速讲究的是快,那么redis就足够快的了,一个实例完全可以到7w稳定的ops. 那么一致性hash + redis多实例 .
当然共享的计数的nosql是快了,后端的性能又怎么保证? 你的后端如果是那种bio模式,比如php-fpm、uwsgi、早期apache prefork. 那就没得扯了.
为啥bio不行? 你在google去 !!! 当时后端是golang beego… 后来因各种情况变更成渣渣python,web框架是自己用libev撸的轮子, 支持多进程那种, 服务器加到5台左右, 也是可以压到十几万的限频速度.
接入层的限速相对来说粗暴呀. 像limit_conn、limit_req是可以用ip地址或request path限频的. 但如果你想要那种用户层的限速,可以通过cookie来控制,现存的limit_xxx模块有点粗,不能拆分cookie, 这时候只能上nginx lua了.
我见过最复杂的限频是针对用户、uri、用户+uri、多时间区间分别来限速的… 特蛋疼…. 为了解决一次次的redis io时间消耗,我们上了redis内置lua. 但是redis lua又不支持跨多实例及机器. redis cluster也无法使用lua. 那么只能提前定义规则,尽量hash到一个redis.
服务限频限流有这么几种方法:
- 第一是 令牌桶限流算法
- 第二是 漏桶限流算法
- 第三个是 原子计数器的算法.
令牌桶算法:
1. 每秒会有 r 个令牌放入桶中,或者说,每过 1/r 秒桶中增加一个令牌
2. 桶中最多存放 b 个令牌,如果桶满了,新放入的令牌会被丢弃
3. 当一个 n 字节的数据包到达时,消耗 n 个令牌,然后发送该数据包
4. 如果桶中可用令牌小于 n,则该数据包将被缓存或丢弃
漏桶算法:
1. 数据被填充到桶中,并以固定速率注入网络中,而不管数据流的突发性
2. 如果桶是空的,不做任何事情
3. 主机在每一个时间片向网络注入一个数据包,因此产生一致的数据流
这两个算法是有区别的: 漏桶算法能够强行限制数据的传输速率, 而令牌桶算法在能够限制数据的平均传输速率外,还允许某种程度的突发传输.
计数器限频:
简单粗暴的累加计数, 超过就deny,没超过就pass. 我们可以用当前时间的某个单位及方法参数的md5做成key. value是Int数值,然后累加计数就可以了. 我个人还是比较喜欢计数器的限频,可以设置多个时间区间,比如一秒钟可以10个,一分钟只能200个,一小时只能8000个… 计数限频不单单是那种类似常量和length方法对比限频,比如说,数据库的连接数,协程池,秒杀并发. 而且也是可以实现 令牌桶及漏桶的算法的.
其实前两种限速限频算法更多的用于接入层,比如nginx,iptables mark tc, 网络设备qos 等等. . .
针对nginx limit_conn limit_req限速的配置,这里简单阐述下:
添加limit_conn 和limit_req 这个变量可以在http, server, location使用(如果你需要限制部分服务,可在nginx/conf/domains里面选择相应的server或者location添加上便可) 一般都是选择性的添加限频, 比如针对登陆、支付接口可以加 location层限频,针对普通增删改查的逻辑可共用一套限频. 针对翻页递归的查询应该独立一套限频. 类似的还有全文搜索,嵌套评论等等.
参数详解( 数值按具体需要和服务器承载能力设置):
相关推荐
在这个“基于openfeign+sentinel的统一降级服务代码”项目中,我们将会探讨如何结合两者来实现更高效的容错和降级策略。 首先,OpenFeign允许开发者通过简单的接口定义来调用远程服务,它会自动将这些接口转换为...
本项目是一个基于Java开发的简单、易用且高性能的服务降级系统,它提供了限流、熔断和降级等关键功能,对于服务端的稳定性有着至关重要的作用。 首先,我们要理解服务降级的概念。在高并发场景下,如果所有请求都...
ASP在这里可能是“Application Service Provider”的缩写,即应用服务提供商,意味着这个服务器为用户提供固件降级的相关应用或服务。 进行固件降级的过程需要注意以下几点: 1. **备份当前固件**:在执行任何固件...
### Apache Dubbo:Dubbo服务治理:限流与降级策略 #### 1. Dubbo服务治理概述 ##### 1.1 Dubbo服务治理的重要性 在微服务架构中,服务之间的交互频繁且复杂,特别是在高并发场景下,某些服务可能会因为请求量过...
在Dubbo中,服务治理主要依赖于Zookeeper或Eureka等服务注册中心,实现服务提供者和服务消费者的动态连接。服务提供者在启动时会向注册中心注册自己的服务,服务消费者则通过注册中心获取服务提供者的地址,实现服务...
Dubbo服务治理:限流与降级策略 Dubbo服务治理:服务熔断与超时重试 Dubbo服务治理:服务路由与动态配置 Dubbo监控与运维:服务调用监控 Dubbo监控与运维:服务性能分析 Dubbo高级特性:服务版本与分组 Dubbo高级...
在Spring Cloud微服务架构中,Feign和Hystrix是两个重要的组件,它们协同工作以实现服务间的调用和容错处理。Feign是一个声明式的Web服务客户端,它使得编写Web服务客户端变得简单,而Hystrix则是一个用于处理延迟和...
华为E1308降级服务器
它通过隔离并控制对远程系统、服务及第三方库的访问点,有效地阻止级联故障的发生,并增强系统的弹性和可靠性。 #### 二、Hystrix核心概念 ##### 2.1 断路器(Circuit Breaker) 断路器是一种常见的电力保护设备,...
本文将详述中兴B860AV1.1-T2设备的降级过程,以及涉及的一些关键技术点,包括ADB(Android Debug Bridge)、TTL锁死和ADB二维码限制。 中兴B860AV1.1-T2是一款由中兴通讯推出的设备,可能是一款路由器或者智能电视...
本篇将深入探讨如何设计高可用系统架构,以及其中涉及的关键概念——限流、熔断和降级。 首先,我们来理解“限流”。在高并发场景下,系统的处理能力是有限的,如果不加以控制,大量请求可能会导致系统崩溃。限流...
此外,非官方的系统降级可能导致失去保修服务,甚至有可能影响手机的长期稳定性。因此,在使用此类工具前,用户应充分了解可能的风险,并遵循官方的指导说明。 【说明.txt】文件通常包含详细的使用指南、注意事项...
Feign集成Hystrix实现服务熔断和服务降级案例Java代码
请求引流转发和修改负载均衡权重通过真实场景下的流量数据来进行压测,但依赖于系统自身的流量和服务,且需要具备可配置的负载均衡控制器。 容量规划需要理解几个关键名词,如单机能力、单机负荷、集群能力、集群...
### Spring Cloud Hystrix:断路由服务降级 在微服务架构中,系统...通过上述步骤,我们不仅能够在微服务架构中有效利用 Hystrix 实现服务降级,还能够监控并管理服务间的依赖关系,进一步提升系统的稳定性和可用性。
本文主要探讨Sentinel限流、熔断降级的两种核心算法:计数器法和滑动时间窗口算法。 首先,我们来看计数器法。计数器法是最基础的限流策略,适用于简单的场景。例如,若要限制A接口1分钟内的访问次数不超过100次,...
苹果设备降级保姆级教程
为了提高系统的稳定性和可用性,我们需要引入一种机制来处理这种情况,这就是服务降级。Spring Cloud Hystrix 是一个非常重要的工具,它提供了服务降级、断路器、线程隔离等策略,确保了微服务架构中的服务稳定性。 ...