服务限流降级

最新推荐文章于 2024-08-28 23:44:36 发布
最新推荐文章于 2024-08-28 23:44:36 发布
阅读量294 收藏
点赞数
分类专栏： 其他 文章标签： 算法
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/lucyxu107/article/details/128304210
版权

https://segmentfault.com/a/1190000015967922

高并发的线上服务， 有时候面对突发流量， 比如流量突然激增，服务扛不住了，类似这种场景，需要有一个防御措施， 常用的有降级和限流

降级：比如一些热点事件， 当前服务器压力很大， 可以置顶一些降级策略，最简单的比如，随机丢弃一定的用户不走推荐逻辑； 或者用一些低资源消耗的计算逻辑替换线上的逻辑等等， 主要是策略导向的； 被降级的用户请求，可能推荐结果不是那么的最优， 但可尽量的保证正常的访问。 同等的资源下， 服务更多的用户， 以适当的牺牲用户体验为代价

限流： 服务的抗压能力是一定的，在请求量突然增大， 可通过限流策略，来丢弃部分请求，保证服务的稳定。比如服务扛压是1w,  当前有4个上游在同时调用我们的服务，其中有一个服务优先级特别高，需要优先保证正常访问，此时，需要根据一定的策略来限制当前的流量不超过1w，常用的限流策略有令牌桶和漏桶

令牌桶：按照固定的速度， 给令牌桶里面放令牌， 每个服务发请求过来的时候， 需要去桶里面拿对应的令牌，如果没有令牌了，则丢弃本次请求； 有点像混合型共厂，即生产电话，也生产电脑。给的原料多了就快一些，少了就慢一些，都能跑起来，但是再优秀的机器，也有一个上限， 还是不能太多了，如果真的太多了，就要限制速度，到底是生产电脑还是手机呢？就早一个桶，两边分别去拿对应的速率生产就好了

漏桶：按照固定的速度从桶里释放请求，新来的请求放进桶里，如果桶满了，就直接丢弃；有点像工厂里面的生产机器，按照固定的速度生产螺丝钉， 如果前面堆的原料太多，已经溢出了，新原料就放不进来了，而流水线的产出速度稳定不变，慢悠悠的吐出就可以了，没什么压力

dubbo服务降级与限流
congge
11-19 1万+
前言 作为RPC框架，dubbo在调用过程中不可避免的会出现各种异常问题，在使用springcloud进行微服务治理时，会接触到hystrix，sentinel等服务限流降级框架，同样对于dubbo来说，使用过程中也需要考虑这方面的问题 1、集群容错 集群容错指的是，当消费者调用提供者集群时发生异常的处理方案，以上一篇的小demo为例，当consumer端调用hello这个服务时，如果正好调到了其中的的一台机器上的服务挂掉了怎么办？ 在实际部署中，为了保证服务的高可用通常服务会部署多份，当某台机器的服务挂掉
golang 熔断限流降级
weixin_44575660的博客
12-24 922
限流 - 2k 但是我的服务能力只有1k，所以这个时候多出来的流量怎么办： 1. 拒绝 2. 排队等待。用户体验不太好： 当前访问用户过多，请稍后重试和你的服务直接挂了 用户体验降级了 - 原本是访问流畅，下单流畅 -> 当前访问用户过多，请稍后重试 熔断 - 比如A服务访问B服务，这个时候B服务很慢 - B服务压力过大，导致了出现了不少请求错误，调用方很容易出现一个问题： 每次调用都超时 2k，结果这个时候数据库出现了问题， 超时重试 - 网络 2k的流量突然变成了3k。这让原本就满负荷的b服务雪上
Sentinel限流降级的使用
qq_57558631的博客
04-20 2789
通过限流和降级保证在系统流量大的时候保证部分用户的正常使用，保证系统稳定，提升可用性。（前提找到系统和单机的最高能支撑的流量水平） 限流 如商品调用营销，营销仅仅能支撑最多10qps流量，超出后营销系统会性能大幅下降，营销可以对商品进行限流，超过流量就报错 降级/熔断/快速错误 如商品调用营销，发现营销接口异常或者响应时间很长，则商品可以对营销接口进行降级，快速返回错误，防止商品自己被拖死。 处置方式 抛出异常 返回默认值 规则配置方式 代码写死 平台配置 applicati
【微服务】限流、熔断和降级
z036548的博客
08-28 3935
限流、降级和熔断的定义、常见场景、策略和实现方式。包含阿里实现Sentinel的使用的案例，以及对限流算法的学习实践
降级限流
行而不辍，未来可期 - King
11-23 1394
对于高可用的服务，除了尽量保证自身的服务的可靠性外，还的防止不被上游压垮，控制上游的访问一般使用限流策略，避免被下游服务不可用拖垮，一般采取降级策略，只有更好的了解和控制上下游才能使自身的服务的稳定性增强。
『互联网架构』软件架构-服务限流降级熔断机制详解
IT架构圈博客
02-21 736
大部分老铁都没用过hystrix，一般来说能用到hystrix的公司都是比较大型的互联网公司， 服务的限流，降级，熔断，超时这些东西很多老铁经常听说，在一些技术演讲技术大会上，听一些大牛演讲常说服务限流，熔断，降级这些东西，很多公司的流量，性能，并发达不到那么大，对于高可用没有高的要求，用到这些技术机会很少，所以老铁对今天的内容很陌生，非常的感兴趣，确实这是技术BAT用到最多的技术。所以今天一起探秘，看起来很牛逼的技术让他技术的落地，能彻底的了解掌握这门技术。 分布式系统中，会出现哪些问题？（一） .
10分钟带你彻底搞懂服务限流和服务降级
Apple_Boy的博客
07-26 4052
文章目录服务限流计数器法滑动窗口法漏桶算法令牌桶算法服务降级 我们知道，在分布式系统中，当面对高并发、大流量的应用场景时，系统就会面临崩溃的风险。这时候，为了提高系统可用性，我们就需要对外部流量进行限制，以减少对现有系统的影响。目前，业界主流的两种最佳实践是服务限流和服务降级，这节课我们就来深入了解这两种解决方案。 假如你正在设计和开发一个分布式服务系统，各个服务为了满足特定业务需求，通常都会相互依赖形成一种复杂的调用链路。那么，在这样的调用链路中，服务可能因为自身无法承受大量的请求而发生调用失败，或者可能
分布式服务限流降级熔断解决方案Nacos之Dashboard界面配置含义记录
Firstlucky77的博客
05-23 639
Sentinel 流控规则 配置流量控制规则 阈值种类 QPS：每秒钟请求数（request per second） 线程数：每秒钟线程数 流控模式 直接：就是直接触发流控效果 关联：就是关联资源达到了流控阈值，我本身进行流控（订单服务限流，那么我也进行限流） 链路：更加细粒度的（如限制了service中的一个方法，在controller中有两个方法都可以调用它，我们针对于controller其中一个进行限制，而另一个则不限制）【service中方法为abc，controller中方法为
sentinel 限流 熔断降级 组件
weixin_43820780的博客
03-15 211
sentinel 限流 熔断降级 组件
sentinel限流降级
WRSR52的博客
12-27 1015
1.降级是指:服务在访问的过程中发生了阻塞,那么这个时候就选择抛出异常结束这个服务,这就叫降级. 2.慢调用比例是指:请求数超过所设置的数量后,平均响应时间超过设定的毫秒数的30%,则对请求进行熔断,熔断时长为你所设置的值, 所设置的秒后恢正常 3.Sentinel异常处理:系统提供了默认的异常处理机制,当默认处理机制不满足用户的需求时那么就可自定义,定义方式上可以直接或间接实现BlockEceptionHandler接口,并将对象交给Spring容器管理 面试分析 4. 为何降级熔断:让外部应用停
熔断、限流、降级
weixin_43452287的博客
05-24 231
熔断、限流、降级 1 写在前面   1.1 名词解释 consumer表示服务调用方  provider标示服务提供方，dubbo里面一般就这么讲。 下面的A调用B服务，一般是泛指调用B服务里面的一个接口。   1.2 拓扑图 大写字母表示不同的服务，后面的序号表示同一个服务部署在不同机器的实例。   2 从微观角度思考 &
读书笔记-限流与降级
anLA_的专栏
03-09 835
限流 限流目的是通过对并发访问/请求进行限速或者一个事件窗口内的请求进行限速，来保护系统。 一般高并发系统常见限流有： 限制总并发数（如数据库连接池、线程池） 瞬时并发数（如Nginx的limit_conn模块） 限制时间窗口内平均速率（如Guava的RateLimiter、Nginx的limit_req模块，用来限制每秒的平均速率） 限制远程接口调用速率 限制MQ消费 限流算法 主要有令牌桶...
重试，限流与服务降级
布谷2015
07-15 271
spring-cloud架构的几个概念理解 ribbon的重试功能 当A服务部署在N台服务器上，ribbon路由到A(n1)…的过程中，如果A(n1)实例异常关闭，则通过配置重试机制可以向后搜索可用的实例，配置项如下： zuul.retryable=true ribbon.eager-load.enabled=true ribbon.restclient.enabled=true ribbon....
微服务架构-限流、降级篇
qq_29653373的博客
02-03 687
一、涉及的技术：sentinel、nacos、微服务 二、原理：利用sentinel-datasource-nacos实施与nacos通信，将sentinel配置实时持久化到nacos配置中心，用户可以操作nacos配置或者sentinel平台直接对微服务进行管控。 三、实现： 1.升级聚合项目依赖(基础项目搭建参考：微服务架构-权限篇_Morik的博客-优快云博客)，目前最新支持sentinel 1.8.1 2、配置common模块依赖，目前这个模块只是用来测试sentinel的持久化.
稳定性实践:限流降级
阅读之后，对你有帮助，那就点个赞再走吧
11-14 967
首先，我们先梳理清楚限流和降级的概念，明白它们会发挥怎样的作用，这样才便于我们理解后续的解决方案。限流，它的作用是根据某个应用或基础部件的某些核心指标，如QPS或并发线程数，来决定是否将后续的请求进行拦截。比如我们设定1秒QPS阈值为200，如果某一秒 的QPS为210，那超出的10个请求就会被拦截掉，直接返回约定的错误码或提示页面。降级，它的作用是通过判断某个应用或组件的服务状态是否正常，来决定是否继续提供服务。
云时代架构阅读笔记十六——Hystrix理解
weixin_30468137的博客
06-19 128
背景 分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。如下图，对于同步调用，当库存服务不可用时，商品服务请求线程被阻塞，当有大批量请求调用库存服务时，最终可能导致整个商品服务资源耗尽，无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递，这种现象被称为雪崩效应。 雪崩效应应对策略 针对造成雪崩效应的不同场景，可以使用不同的应对策略，没有一种通用所...
聊聊限流、熔断和降级
曹建涛的博客
02-19 1006
背景 分布式系统中的调用关系错综复杂，如何保障整个系统平稳运行则显得尤为重要。 限流、熔断和降级应运而生… 限流 为了保障下游服务稳定性，通常会提前预估调用QPS，一旦超过预估QPS则可以进行限流，拒绝超出预估的请求。 常见的限流算法有固定窗口、滑动窗口、漏桶和令牌桶，后续会专门出一篇文章。 熔断 当下游服务不可用或者响应过慢，可以切断调用链路直接返回结果，保证自身服务的可用性。 降级 当服务器压力剧增，可以考虑对非核心业务流程进行降级，保证核心功能可用。 逻辑上讲，限流和熔断都可以算降级的一种。
降级、熔断、限流
标准都是留给不爱的人，爱的本质是自由意志的沉沦
07-17 992
降级、熔断和限流都是为了保护系统在高并发场景下的稳定性和可用性。它们可以通过使用断路器模式、配置负载均衡器、使用限流算法等方式实现。同时，合理的设置降级策略、熔断条件和限流阈值也是保证系统高可用运行的重要因素。降级、熔断和限流是在高并发环境中保护系统稳定性的重要手段。它们通过对服务的调用进行控制和限制，防止系统因突发负载而崩溃或出现性能下降。
【微服务稳定性之限流降级】【一】限流概念和算法
懂幸福，爱生活
07-13 994
微服务稳定性稳定性三大杀器，缓存，队列，限流降级。这一部分讲一下限流降级。每个系统都有自己的最大服务能力，即在达到某个临界点之前，系统都可以正常提供服务。为了保证系统在面临瞬间的流量时仍然可以对外提供服务，我们就需要使用限流技术。下面就讲一讲笔者认为的降级和熔断的概念。 限流：1)服务的入口的限流，在流量激增的情况下对流量进行控制；2)当然还有一个情况就是，服务A在调用B，下游服务...
gateway的限流降级操作案例
最新发布
03-27
<think>好的，用户之前询问了Redis中并发执行Lua脚本的问题，现在转向了gateway的限流降级操作案例。我需要先理解用户的需求。可能用户正在设计或维护一个分布式系统，需要处理高并发下的流量控制和故障处理。限流和降级是微服务架构中的常见策略，用于保证系统稳定性。 用户可能想知道具体的实现案例，比如使用哪些工具，如何配置，以及实际应用中的注意事项。他们可能对不同的限流算法（如令牌桶、漏桶）和降级策略（如熔断、服务降级）感兴趣。同时，用户可能希望了解在实际项目中如何集成这些功能，比如使用Spring Cloud Gateway、Sentinel或者Nginx等。 需要确定用户的技术栈，但用户没有明确说明，所以需要涵盖常见的解决方案。比如，Spring Cloud Gateway适合Java生态，Sentinel是阿里开流的，Nginx作为反向代理也很常用。此外，还要提到云服务提供商的方案，如AWS的API Gateway，这对使用云服务的用户可能有帮助。 另外，用户可能关心如何配置限流规则，比如每秒请求数，如何根据IP或用户进行限流，降级后的处理策略，比如返回默认值或错误信息。案例部分需要具体，最好有代码示例或配置示例，这样用户更容易理解。 还需要注意潜在的问题，比如限流导致的用户体验下降，如何监控和调整限流阈值，降级后如何恢复服务等。此外，分布式系统中的一致性问题，比如在集群环境下如何同步限流状态，可能需要使用Redis等中间件。 最后，总结部分需要强调限流降级的重要性，以及如何根据具体场景选择合适的工具和策略。确保回答结构清晰，分点说明，覆盖不同工具和实际案例，帮助用户全面理解并应用这些技术。</think>以下是网关限流与降级操作的典型实现方案及实践案例解析，分层说明核心原理与实施方法： --- ### 一、**基础限流模型** #### 1. **令牌桶算法（Token Bucket）** $$ \text{令牌生成速率} = \frac{\text{桶容量}}{\text{时间窗口}} $$ ```yaml # Spring Cloud Gateway 配置示例 spring: cloud: gateway: routes: - id: user_service uri: lb://user-service predicates: - Path=/api/users/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 100 # 每秒100令牌 redis-rate-limiter.burstCapacity: 200 # 突发容量200 key-resolver: "#{@ipKeyResolver}" # 按IP限流 ``` #### 2. **滑动窗口计数** $$ \text{允许请求数} = \sum_{i=1}^{n} \text{子窗口计数} \leq \text{阈值} $$ ```java // Sentinel 滑动窗口实现核心逻辑 public class SlidingWindow { private AtomicReferenceArray<WindowWrap> array; // 时间窗口数组 private int windowLength; // 子窗口时长（毫秒） } ``` --- ### 二、**降级策略分类** #### 1. **熔断降级（Circuit Breaker）** 状态转换逻辑： ``` CLOSED → (失败率超阈值) → OPEN → (冷却时间后) → HALF-OPEN ``` | 指标 | 阈值示例 | 监控周期 | |--------------------|------------|-----------| | 慢调用比例 | > 50% | 10秒 | | 异常比例 | > 60% | 5秒 | | 最小请求数 | 10次 | - | #### 2. **返回预设值降级** ```xml <!-- Sentinel 降级规则配置 --> <flowRule> <resource>getUserInfo</resource> <grade>1</grade> <!-- 异常数模式 --> <count>5</count> <!-- 触发阈值 --> <timeWindow>30</timeWindow> <fallbackClass>com.example.UserFallback</fallbackClass> </flowRule> ``` --- ### 三、**分布式场景实践** #### 1. **Redis集群限流同步** ```lua -- 分布式令牌桶Lua脚本 local tokens_key = KEYS[1] -- 令牌桶key local timestamp_key = KEYS[2] -- 最后更新时间key local rate = tonumber(ARGV[1]) -- 令牌生成速率 local capacity = tonumber(ARGV[2])-- 桶容量 local now = tonumber(ARGV[3]) -- 当前时间戳 local requested = tonumber(ARGV[4])-- 请求令牌数 local last_tokens = tonumber(redis.call("get", tokens_key)) or capacity local last_refreshed = tonumber(redis.call("get", timestamp_key)) or now local delta = math.max(0, now - last_refreshed) local new_tokens = math.min(capacity, last_tokens + delta * rate) local allowed = new_tokens >= requested local result = { allowed, new_tokens } if allowed then new_tokens = new_tokens - requested end redis.call("setex", tokens_key, math.ceil(capacity/rate), new_tokens) redis.call("setex", timestamp_key, math.ceil(capacity/rate), now) return result ``` #### 2. **Nginx限流配置** ```nginx http { limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s; server { location /api/ { limit_req zone=api_limit burst=50 nodelay; proxy_pass http://backend; # 超时降级处理 error_page 504 = @fallback; } location @fallback { return 503 '{"code":503,"msg":"服务暂时不可用"}'; } } } ``` --- ### 四、**云原生方案示例** #### 1. **AWS API Gateway 阶梯限流** ```json { "throttling": { "burstLimit": 1000, // 突发请求上限 "rateLimit": 500 // 持续请求速率（次/秒） }, "quota": { "limit": 10000, // 日请求总量限制 "offset": 0, // 配额周期偏移量 "period": "DAY" // 配额周期类型 } } ``` #### 2. **Envoy 动态限流** ```yaml # envoy限流过滤器配置 http_filters: - name: envoy.filters.http.ratelimit typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.ratelimit.v3.RateLimit domain: apigateway failure_mode_deny: true rate_limit_service: grpc_service: envoy_grpc: cluster_name: rate_limit_cluster ``` --- ### 五、**监控与调优** #### 1. 关键监控指标 | 指标类型 | PromQL示例 | 告警阈值 | |------------------|-------------------------------------|---------------| | 限流触发次数 | rate(gateway_requests_limited[5m]) | > 10次/分钟 | | 平均响应时间 | histogram_quantile(0.95, rate(...)) | > 500ms | | 熔断器状态 | sum(circuit_breaker_state) | OPEN状态持续>30s | #### 2. 动态规则调整 ```java // Sentinel 动态规则更新示例 List<FlowRule> rules = new ArrayList<>(); FlowRule rule = new FlowRule("resA") .setGrade(RuleConstant.FLOW_GRADE_QPS) .setCount(100); // 动态调整QPS阈值 FlowRuleManager.loadRules(rules); ``` --- ### 六、**典型故障案例** **案例背景**：电商大促期间订单服务超载 **应对措施**： 1. **分级降级**： - 一级降级：关闭商品推荐服务 - 二级降级：简化订单确认页数据 - 三级降级：启用静态兜底页面 2. **流量调度**： ```bash # 使用HAProxy动态调整权重 echo "set weight order_service/backend1 30" | socat stdio /var/run/haproxy.stat ``` 3. **效果验证**： - API成功率从65%提升至92% - 系统负载下降40% --- **最佳实践总结**： 1. **分层防御**：边缘节点（CDN）→ 网关层 → 服务层逐级限流 2. **动态生效**：结合配置中心实现规则热更新 3. **灰度发布**：新规则先作用于5%流量验证 4. **熔断恢复**：采用指数退避策略尝试恢复 5. **压测验证**：定期通过Chaos Engineering测试系统极限 通过合理组合这些技术手段，可使网关系统在1ms内完成限流判断，支持百万级QPS场景，将服务不可用时间减少至传统架构的1/10。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值