8-26接口压力测试-1Dubbo接口测试

1. Dubbo

Dubbo是一个分布式服务框架，提供了高性能和透明化的RPC（Remote Procedure Call Protocol）远程服务调用方案和服务治理方案。
SOA：面向服务的架构
Dubbo协议特点：

• 远程调用：提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。一旦发布这个服务，客户端不需关心内部细节和如何实现，Dubbo已封装好，直接调用接口即可
• 集群管理：内置多种负载均衡策略，提高系统吞吐量，并支持灵活扩展。
• 自动发现：支持多种注册中心服务，服务实力上下线实施感知。对于SOA的系统，其服务都需要自动的去发现，不然会有一个问题：服务提供者很多，服务的地址是没有办法进行管理的，它需要有一个注册中心，去进行管理这些服务。当服务发布之后，自动去注册中心注册；对服务的上下线也能自动的感知。当服务下线，自动从注册中心踢掉。

2. Dubbo基本原理

架构

节点角色说明

节点	角色说明
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行容器

调用关系说明 * 0 服务容器负责启动，加载，运行服务提供者。 * 1 服务提供者在启动时，向注册中心注册自己提供的服务。 * 2 服务消费者在启动时，向注册中心订阅自己所需的服务。 * 3 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 * 4 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。同步的 * 5 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

2.1 Dubbo与整体的服务有什么不同？

假设tomcat有一个服务（包含A、B2部分），通过http去调用。
引发的问题：发布的时候，其实是一整套，各个服务是拆分不开的。假设修改了A，但发布时要把B一起带上去，因为他是一个整体。
而对于SOA来说，改A就是改A

2.2 Dubbo provider管理

Consumer调用的时候先去注册中心，不需要给一个明确的地址。假设有100个服务，就需要100个URL。对于Dubbo来说，只需告诉Consumer服务名字，它自己回去注册中心找可用的provider，不要URL地址。

2.3 Dubbo负载均衡

我们去银行办理业务，大厅工作人员会给我们号码，分散到不同的柜台。

Dubbo也是一样的，不过它是通过注册中心实现的。
我们去消费的时候，一个消费者有非常多的provider提供者。当有大量的请求进来的时候，它会均匀的分配到不同的provider，避免只调一台，否则那台压力会非常大。

2.4 入门知识