dubbo配置注意事项

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.平滑启动：

参见之前。