爱测未来性能-性能测试之dubbo
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000多个服务提供30多亿次访问量支持，最大单机支撑每天近1亿访问量，并被广泛应用于阿里巴巴集团的各成员站点。核心部分包含:
远程通讯:提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
集群容错:提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
自动发现:基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
为了更好的认识dubbo，下面从产生背景、现实需求、架构、主要配置、参数优化、常见问题等方面对dubbo进行介绍：
一、产生背景
随着互联网的发展，网站应用规模的不断扩大，常规的垂直应用架构无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
垂直应用架构
分布式服务架构
流动计算架构
二、现实需求
在规模大服务化之前应用可能只是通过RMI或等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。
（1）当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和，降低对F5硬件负载均衡器的依赖，也能减少部分成本。
（2）当进一步发展，服务间依赖关系变得错综复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。这时，需要自动画出应用间的依赖关系图，以帮助架构师清理关系。（3）接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到相应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
三、架构
节点角色说明：
调用关系说明：
(1) 连通性：
(2) 健状性：
(3) 伸缩性：
(4) 升级性：
四、主要配置
.xml：
.xml：
五、参数调优
Dubbo涉及的参数比较多，以下介绍几个比较重要参数：
注意表中参数与图中的对应关系
1、当发起一个请求时，首先经过 limit(参数）进行方法级别的限制，其实现方式为CHM中存放计数器()，请求时加1，请求完成（包括异常）减1,如果超过则等待有其他请求完成后重试或者超时后失败。
2、从多个连接(）中选择一个连接发送数据，对于默认的netty实现来说，由于可以复用连接，默认一个连接就可以。不过如果在压测，且只有一个,一个，此时适当的加大确实能够增强网络传输能力。但线上业务由于有多个多个，因此不建议增加参数。
3、连接到达时（如dubbo的初次连接），首先会判断总连接数是否超限（），超过限制连接将被拒绝。
4、连接成功后，具体的请求交给io 处理。io 虽然是处理数据的读写，但io部分为异步，更多的消耗的是cpu，因此默认cpu个数+1是比较合理的设置，不建议调整此参数。
5、数据读取并反序列化以后，交给业务线程池处理，默认情况下线程池为fixed，且排队队列为0()，这种情况下，最大并发等于业务线程池大小()，如果希望有请求的堆积能力，可以调整参数。如果希望快速失败由其他节点处理（官方推荐方式），则不修改，只调整。
6、 limit（参数）是方法级别的并发限制，原理与类似，只是少了等待的过程，即受限后立即失败。
7、tps，控制指定时间内（默认60s）的请求数。注意目前dubbo默认没有支持该参数，需要加一个META-INF/dubbo/com..dubbo.rpc.文件，文件内容为：tps=com..dubbo.rpc..。
从上面的分析，可以看出如果数*>数*且=0，则会存在部分请求无法申请到资源，重试也有很大几率失败。 当需要对一个接口的不同方法进行不同的并发控制时使用，否则调整就可以。
六、常见问题
1. 出现: No for 异常怎么办？
表示没有可用的服务提供者：1.检查连接的注册中心是否正确；2.到注册中心查看相应的服务提供者是否存在；3.检查服务提供者是否正常运行。
2. 出现调用超时com..dubbo..异常怎么办？
通常是业务处理太慢，可在服务提供方执行： PID > .log分析线程都卡在哪个方法调用上，这里就是慢的原因。如果不能调优性能，请将设大。
3. 出现java.util..或者 pool 怎么办？
表示线程池已经达到最大值，并且没有空闲连，拒绝执行了一些任务。 pool 通常是min和max不一样大时，表示当前已创建的连接用完，进行了一次扩充，创建了新线程，但不影响运行。原因可能是连接池不够用，请调整dubbo.中的：
//设成一样大，减少线程池收缩开销：
dubbo..min..pool.size=200
dubbo..max..pool.size=200
如果线程池已经有200，还不够，通常是业务处理占用线程时间过长，需优化业务，可通过运行：进程号> .txt，分析当前大多数线程都在干什么，从而分析出哪个地方是瓶颈，比如，如果大部分线程都在处理SQL，可能是数据库连接不够，或数据源配置错误，或SQL没走索引等。
4. 服务提供者没挂，但在注册中心里看不到怎么办？
首先，确认服务提供者是否连接了正确的注册中心，不只是检查配置中的注册中心地址，而且要检查实际的网络连接。其次，看服务提供者是否非常繁忙，如压力测试，以至于没有CPU片段向注册中心发送心跳，这种情况，减小压力，将自动恢复。
5. 如果服务注册不上怎么办？
(1)检查dubbo的jar包有没有在中，以及有没有重复的jar包；
(2)检查有没有重复的dubbo.配置文件；
(3)检查暴露服务的配置有没有加载；
(4)检查或有没有重复；
(5)查看有没有错误日志；
(6)在服务提供者机器上测试与注册中心的网络是否通；
(7)检查与注册中心的连接是否存在： -anp | grep XXX；
(8)如果是预发布机，检查hosts文件有没有正确绑定：cat /etc/hosts；
以上若仍不行，开启远程调试：
(a)在服务器JVM参数中加入：
- - piler=NONE-:=
=7001,=y,=y，
注意线上只有7001和8080可以被线下访问，调试端口需用这两个之一，因注册是启动时行为，启动时必需挂起=y；
(b)在dubbo源码的ce的()方法中设置断点；
(c)在的Debug按钮下拉菜单Debug 中的 Java 中新增远程调试，并设置IP和端口，以及增加dubbo的源码，进行远程Debug调试。
关于我们：
