Dubbo服务治理（一）：限流策略
一、前言
高并发环境下，服务端不能及时处理请求，造成大量请求线程挤压，最终会造成大面积的服务崩溃现象（服务雪崩），根据服务特点设定合理的请求拒绝策略。
Dubbo中能够实现服务限流的方式较多，可以划分为两类：直接限流与间接限流
- 直接限流：通过对连接数量直接进行限制来达到限流的目的。（官方方案汇总）
- 间接限流：通过一些非连接数量设置来达到限制流量的目的。（我的偶像总结-Reythor雷）
注意:负载均衡只能分配流量而不能限制流量。限流和熔断是处理并发的两大利器，客户端熔断，服务端限流
1.1 dubbo限流策略
- 客户端限流
信号量限流 （通过统计的方式）
连接数限流 (socket->tcp) - 服务端限流
线程池限流 (隔离手段)
信号量限流 (非隔离手段)
接收数限流 (socket->tcp)
二、 消费端actives
仅针对消费者端生效，只能在<dubbo:reference>亦或是其子标签<dubbo:method>或者是<dubbo:consumer>中配置
2.1 配置示例
- dubbo:consumer中配置针对所有服务所有方法生效
- dubbo:consumer中配置针对该服务所有方法生效
- dubbo:method中配置针对该方法生效
2.2 参数详解
| 描述 | 备注 |
|---|---|
| 作用 | 消费者最大并发数量限制，超过限制将会抛出异常 |
| 实现 | 过滤器Filter，具体实现子类为ActiveLimitFilter |
| 默认值 | 0表示没有限制 |
| 配置地点 | <dubbo:consumer>、<dubbo:reference> 、<dubbo:method> |
2.3 源码导读
- 处理请求参数：URL为Dubbo封装的一个请求对象类，包含Map<String, String>类型属性numbers，该属性中含有actives配置
- 请求过滤判断：RpcStatus类封装生产者调用状态，AtomicInteger原子类型active属性存储当前调用数量。通过其与URL中获取到的对应参数属性值比较判断
- 请求返回结果：如果允许则进行下一步RPC调用，不允许则会暂停等待线程timeout参数时长，若唤醒还未有空余线程则抛出异常
三：消费端connections
大家熟悉的HTTP协议就属于短连接，每次请求的时候都会多次验证握手建立连接。默认的Dubbo协议属于长连接，采用NIO异步传输，每消费者与生产者之间默认采用单一长连接方式通信。换个简单说法就是每个消费者与生产者之间长连接默认就创建一个，所有请求共用。
connections参数针对上述长连接与短连接具备不同作用效果：
- 短连接因为是多连接所以限制其个数
- 长连接因为是单一连接所以是指定其创建数量
3.1 配置示例
connections参数生效的位置在消费端，图一表示消费端的配置，图二表示在生产者的配置。根据自身测试以及github验证，生产端的配置确实会通过注册中心传递给消费端生效
3.2 参数详解
| 描述 | 备注 |
|---|---|
| 作用 | 限制消费者短连接数量，长连接创建数量 |
| 实现 | 初始化连接时根据参数控制 |
| 默认值 | 长连接默认表示使用JVM共享长连接，线上一般都是多生产多消费，这个参数不建议更改 |
| 配置地点 | <dubbo:consumer>、<dubbo:reference> 、<dubbo:provider>、<dubbo:service> |
3.3 源码导读
首先项目初始化的时候会根据connections参数初始化连接，过程在DubboProtocol类的getClients()方法中，下图是debug跟进的初始化结果。可以看到用于储存连接的数组最后返回的是两个连接实例
连接使用发生在类DubboInvoker中，该类的方法doInvoke()用于执行调用逻辑。使用的连接就是在DubboProtocol类中getClients()初始化出来并在方法refer()中放入DubboInvoker对象的连接。如下图所示是DubboInvoker中doIncoke()使用连接的关键代码
四：生产端accepts
消费者可以通过connections参数设置连接的数量，但是如果生产者不进行自我保护，采用默认的无限制连接策略。高并发情况下生产者可能就会因为连接数量巨大崩溃，这时可以通过参数accepts限制生产者可接受最大连接数量
4.1 配置示例
accepts用于生产者限制最大连接数量保护自身服务可用性，可以在标签<dubbo:protocol>中进行配置。这时候在<dubbo:reference>中设置connections超过accepts值，用于方便后续的源码跟进
4.2 参数详解
| 描述 | 备注 |
|---|---|
| 作用 | 限制生产者最大可接受连接数量，用于保护生产者自身 |
| 实现 | 消费者初始化创建连接时会打开创建链接，这时候就会根据限制参数判断 |
| 默认值 | 0表示没有限制，比较危险的配置 |
| 配置地点 | <dubbo:protocol> |
4.3 源码导读
生产者启动初始化过程中可以看到开启连接的时候获取了参数accepts的设置，过程在AbstractServer类构造函数中可以看到
消费端初始化的时候当超过生产者限制连接数量后，在AbstractClient类中可以看到，构造函数中调用方法connect()创建连接。这时候会抛出异常，因为异常原因是等待创建连接超时3000ms。验证参数accepts效果
五：生产端线程池
多线程并发操作一定离不开线程池，Dubbo自身提供了支持了四种线程池类型支持。生产者<dubbo:protocol>标签中可配置线程池关键参数，线程池类型、阻塞队列大小、核心线程数量等
5.1 iothreads、threads
- iothreads：限制的是io线程池大小，该线程池线程用于处理Dubbo框架自身业务逻辑。默认值为
CPU+1，不建议更改设置 - threads：用于指定下面讲到的业务线程池线程数量，这个才是业务需要关心的线程数量。默认大小
200
5.2 threadpool
参数threadpool指定使用线程池类型，Dubbo中自身实现提供了如下表所示四种线程池。默认使用固定大小线程池FixedThreadPool
| 类型名称 | 队列类型 | 特性备注 |
|---|---|---|
| FixedThreadPool |
queues属性为0创建无容量阻塞队列SynchronousQueue，若 queues小于0则创建Integer.MAX_VALUE容量LinkedBlockingQueue阻塞队列，大于0则创建 queues参数限定容量LinkedBlockingQueue阻塞队列
|
核心线程数量与最大线程数量一致采用参数threads值、线程空闲存活时间0
|
| CachedThreadPool |
队列创建类型规则与FixedThreadPool一致
|
相对于固定容量大小FixedThreadPool线程池多了参数corethreads设置核心线程数量支持默认0，线程空闲存活时间暂时未提供参数设置，默认1分钟
|
| LimitedThreadPool |
队列创建类型规则与FixedThreadPool一致
|
相对于CachedThradPool而言最大的变化在于线程存活时间修改为Long.MAX_VALUE |
| EagerThreadPool |
队列为Dubbo设计实现的TaskQueue队列，该队列继承自LinkedBlockingQueue。当queues参数小于等于0则其容量为1，若大于0则容量为queues参数值
|
后面会有专门文章研究这个线程池实现 |
5.3 注意
Dubbo官网文档只描述了fixed/cached，四种线程池默认支持的是fixed
六：生产端executes
一个只能在生产者即dubbo:service亦或是其子标签dubbo:method中配置的属性，消费者中配置不会生效。这个参数主要目的是在生产者端限制应用线程使用数量
6.1 配置示例
限制该服务每个方法并发不超过10，其中dubboProtocolGetMethod方法并发不超过2。方法级别的配置优先级高于服务配置
6.2 参数详解
| 配置地点 | 生产者dubbo:service标签或其子标签dubbo:method中 |
|---|---|
| 默认值 | 0表示没有限制 |
| 作用 | 服务提供者每个方法只能占用线程池中配置数量线程，超出则抛出异常 |
| 实现 | 过滤器Filter |
6.3 源码导读
- 主要涉及类：ExecuteLimitFilter，关注相关类RpcStatus、URL
- 主要方法：getMethodParameter()、beginCount()、getStatus()
- 处理请求参数，URL为Dubbo封装的一个请求对象类，包含Map<String, String>类型属性numbers，该属性中含有executes配置
- 提取executes参数值，numbers – paramters – 默认值顺序返回
- 比较executes值数量，RpcStatus类封装生产者调用状态，AtomicInteger原子类型active属性存储当前调用数量
Dubbo服务治理（一）：限流策略相关推荐
- dubbo服务降级与限流
前言 作为RPC框架,dubbo在调用过程中不可避免的会出现各种异常问题,在使用springcloud进行微服务治理时,会接触到hystrix,sentinel等服务限流降级框架,同样对于dubbo来 ...
- 秒杀限制人群，如何设计秒杀服务的限流策略？
对于秒杀业务,大家应该比较熟悉了.比如,"某商品原价 1299 元, 双十一整点秒杀价仅 500 元,限量 100 件,先到先得" 等等.通过这段文案我们能够发现,参与秒杀活动商品 ...
- 服务容错、限流、资源隔离、熔断、监控…3天，撸完了！
随着业务规模增大,服务拆分往往成为必然选择,团队开发效率.部署灵活度.扩展性会得到大幅度提升. 但整个应用分散成多个服务后,定位故障点变得更加困难:一个服务故障可能导致整个系统挂掉,稳定性下降,对系统 ...
- gateway sentinel 熔断 不起作用_Spring Cloud Alibaba集训营第五天（服务熔断和限流）
前言:为什么需要流控降级 我们的生产环境经常会出现一些不稳定的情况,如: 大促时瞬间洪峰流量导致系统超出最大负载,load 飙高,系统崩溃导致用户无法下单 "黑马"热点商品击穿缓存 ...
- Service Mesh微服务熔断、限流的骚操作
在微服务架构中,随着服务调用链路变长,为了防止出现级联雪崩,在微服务治理体系中,熔断.限流作为服务自我保护的重要机制,是确保微服务架构稳定运行的关键手段之一. 那么什么是熔断.限流?在传统Spring ...
- 分布式高并发服务三种常用限流方案简介
以下文章来源于技术岁月 ,作者贺鹏Kavin 在高并发大流量系统中,由于并发大造成服务资源不足,负载过高,进而引发致一系列问题,这里的流量一般都是突发性的,由于系统准备不足,很难短期扩容来应对 ,进行 ...
- Java限流策略与算法
概要 在大数据量高并发访问时,经常会出现服务或接口面对暴涨的请求而不可用的情况,甚至引发连锁反映导致整个系统崩溃.此时你需要使用的技术手段之一就是限流,当请求达到一定的并发数或速率,就进行等待.排队. ...
- 玩转Service Mesh微服务熔断、限流骚操作
在微服务架构中,随着服务调用链路变长,为了防止出现级联雪崩,在微服务治理体系中,熔断.限流作为服务自我保护的重要机制,是确保微服务架构稳定运行的关键手段之一. 那么什么是熔断.限流?在传统Spring ...
- 如何设计秒杀服务器的限流策略
如果平时系统的访问量只有一万,而最大承受限制为五万,在秒杀时刻的瞬间,访问量突然增加到100W,此事系统一定会因访问量过大而宕机,此时就应该设计一个限流策略,使服务器能接收和处理的请求减少. 秒杀限流 ...
- java 限流熔断_SpringCloud-Alibaba-Sentinel服务降级,热点限流,服务熔断
前言:除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一.一个服务常常会调用别的模块,可能是另外的一个远程服务.数据库,或者第三方 api 等.例如,支付的时候,可能需 ...
最新文章
- 数字双胞胎技术和物联网如何帮助企业取得成功
- 每日一皮：产品经理的黑化，你听过几个？
- Leetcode 141. 环形链表 解题思路及C++实现
- 应用市场高速下载以及网页端调起APP页面研究与实现
- 使用 Hyper-v 虚拟化域控制器
- php 保護連接字符串,PHP字符串操作
- python 超高精度除法_Python十进制-除法，舍入，精度
- 常用Git客户端：Tower for Mac
- 将Ubuntu从Win7的魔爪中拯救出来
- 基于双生视界的live2d提取与查看方法
- 计算机学的是苹果系统,苹果电脑装windows7教程 苹果电脑装windows7方法
- sap 双计量单位_采购订单单位与基本计量单位不一致问题案例
- 用C写邮箱密码暴力破解器
- java 读取文件inputstream_使用FileInputStream读取本地文件
- 汇编指令及其英文全称
- Scala+Hadoop+Spark开发
- 一文讲透，分布式系统的数据分片难题
- 共话行业新趋势，神州信息亮相毕马威中国金融科技高峰论坛
- 2022前端笔试面试题
- php 发微博实例,基于PHP实现发微博动态代码实例