dubbo调优

http://alibaba.github.io/dubbo-doc-static/Dubbo+Protocol-zh.htm

http://dubbo.io/user-guide/demos/%E5%B9%B6%E5%8F%91%E6%8E%A7%E5%88%B6.html

1.dubbo一个提供方和一个消费方，默认使用单一长连接

如果消费方调用提供方其中一个服务比较慢，则会造成其它服务缓慢，解决办法是设置多个连接。

但连接数过多也会造成服务端连接暴满的问题，需要根据实际情况设置。

全局设置：

单个服务设置：

或表示该服务使用独立两条长连接。

2.事件分发模式

Dispatcher 

all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。 

direct 所有消息都不派发到线程池，全部在IO线程上直接执行。 

message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在IO线程上执行。

3.服务提供方，尽量与服务消费方在同一局域网

spring cloud提供调用优先级。优先调用同机房服务，没有则调用同一个城市服务。

4.超时时间设置

根据不同业务设置超时时间，有些后台任务，需要设置长点。默认超时时间为6秒。

面向用户的服务，超时时间不能过长，如果这个服务出现问题，会导致雪崩。

5.读服务可以重试，写服务一般不建议重试

6.设置处理线程池的大小和类型

iothreads=“9” />

默认线程池核心线程数为：200,最大线程数为200,queue为SyncronouseQueue。

考虑下，如果出现请求200个处理线程都不够，再来一个请求会发生什么情况？

底层会抛一个RejectedExecutionException，使用的是dubbo自己的拒绝策略：AbortPolicyWithReport。

这里最好不要设置queues。

如果设置了，因为在请求比较多时，如果服务提供方处理不过来，会将请求存储在queue，但因为是先进先出，所以之前早点的请求会被先处理，处理完后由于有dubbo超时时间这批请求实际是无效的。

接着导致之后新的请求就算服务已经恢复正常速度，由于还要先处理之前旧的请求导致这批请求都无效。

初始化代码：

 public Executor getExecutor(URL url) {

        String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);

        int threads = url.getParameter(Constants.THREADS_KEY, Constants.DEFAULT_THREADS);

        int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);

        return new ThreadPoolExecutor(threads, threads, 0, TimeUnit.MILLISECONDS, 

        queues == 0 ? new SynchronousQueue() : 

        (queues < 0 ? new LinkedBlockingQueue() 

        : new LinkedBlockingQueue(queues)),

        new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));

    }

7.dubbo调用链监控

使用开源的cat，pinpoint或自研。

8.现在dubbo用的是netty3，nett4之后做了很多优化，其中包括缓存池的利用可以提升不少性能。

期望dubbo之后能有升级。

9.dubbo限流

针对某个接口做限流

服务消费方：

connections

防止服务提供方接收过多连接：

< dubbo:protocol name = "dubbo" accepts = "1000" />

10.请求响应数据大小限制

payload

默认8M

不要传送大包

11.业务的熔断降级

dubbo默认不提供，可以使用hystrix去做

12.服务提供方及消费者限制调用某个服务的并发数

//限制服务端，这个服务可以同时并发的线程数

//限制服务端，这个服务可以同时存在的连接数

13.dubbo本身上层有心跳，底层还设置了tcp的keepAlive

这样做的原因可能是担心dubbo线程池无可用线程用于心跳检测，导致服务端连接不释放。

14.服务不能拆的太细

原因：

1.在组装某个业务结果时，涉及远程调用太多

2.服务方过多，消费方建立的socket也会比较多。