1.超时配置:
建议统一在服务提供方配置。可以设置到method级别。
2.启动时检查:
Dubbo缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止Spring初始化完成,以便上线时,能及早发现问题,默认check=true。
3.订阅:
在测试环境时,为方便测试,经常本地运行main方法启动。影响测试消费者调用。
解决方案
以让服务提供者开发方,只订阅服务(开发的服务可能依赖其它服务),而不注册正在开发的服务,通过直连测试正在开发的服务。
禁用注册配置: <dubbo:registry address="****" register="false" />
4.日志输出:
<dubbo:protocol accesslog="true" />输出日志比较大,每天一个节点几百兆。
5.dubbo线程模型:
对应参数流程:
以下转自:http://blog.csdn.net/youaremoon/article/details/51884644
注意表中参数与图中的对应关系:
1、当consumer发起一个请求时,首先经过active limit(参数actives)进行方法级别的限制,其实现方式为CHM中存放计数器(AtomicInteger),请求时加1,请求完成(包括异常)减1,如果超过actives则等待有其他请求完成后重试或者超时后失败;
2、从多个连接(connections)中选择一个连接发送数据,对于默认的netty实现来说,由于可以复用连接,默认一个连接就可以。不过如果你在压测,且只有一个consumer,一个provider,此时适当的加大connections确实能够增强网络传输能力。但线上业务由于有多个consumer多个provider,因此不建议增加connections参数;
3、连接到达provider时(如dubbo的初次连接),首先会判断总连接数是否超限(acceps),超过限制连接将被拒绝;
4、连接成功后,具体的请求交给io thread处理。io threads虽然是处理数据的读写,但io部分为异步,更多的消耗的是cpu,因此iothreads默认cpu个数+1是比较合理的设置,不建议调整此参数;
5、数据读取并反序列化以后,交给业务线程池处理,默认情况下线程池为fixed,且排队队列为0(queues),这种情况下,最大并发等于业务线程池大小(threads),如果希望有请求的堆积能力,可以调整queues参数。如果希望快速失败由其他节点处理(官方推荐方式),则不修改queues,只调整threads;
6、execute limit(参数executes)是方法级别的并发限制,原理与actives类似,只是少了等待的过程,即受限后立即失败;
7、tps,控制指定时间内(默认60s)的请求数。注意目前dubbo默认没有支持该参数,需要加一个META-INF/dubbo/com.alibaba.dubbo.rpc.Filter文件,文件内容为:
tps=com.alibaba.dubbo.rpc.filter.TpsLimitFilter
从上面的分析,可以看出如果consumer数*actives>provider数*threads且queues=0,则会存在部分请求无法申请到资源,重试也有很大几率失败。 当需要对一个接口的不同方法进行不同的并发控制时使用executes,否则调整threads就可以。
关注的两个参数:
- Dispather
- all, direct, message, execution, connection默认all
- ThreadPool
- fixed, cached 默认:fixed
- 具体的要根据实际情况调整,默认大小200.
线程数设置,需要综合考虑,比如查看linux允许用户创建线程数:ulimit -u
这个数据可以调大,但是受限于内存大小,cat /proc/meminfo |grep MemTotal,根据内存/128K大概估算出
6.平滑启动:
参见之前。