dubbo是阿里开源的一个远程服务调用（Remote Procedure Call，即RPC）的分布式服务框架，符合典型的生产者消费者模型。
以前，什么都搭在一个服务器上，进行直接调用。但现在随着需求增多，数据量增大，常规的垂直应用架构已经无法满足，服务关系变得缤纷错杂，负载也压力激增，容量问题暴漏的越来越明显。此外，大型的互联网公司往往需要使用自己的私有协议，不具有通用性，因此选用二进制字节码传输的RPC，更加高效也更加安全。
Q1：什么是生产者消费者模型
生产者消费者模型是通过容器解决生产者和消费者之间强耦合（强度依赖关系）问题模型。其过程如下图所示：
生产者和消费者不进行直接通讯，而是通过阻塞队列（途中公共区域，或称缓冲区）进行通讯。生产者将生产完的数据放入公共区域，不必等待消费者消费；而消费者直接从公共区域取回数据。
这种模式有以下三个有点：
①降低了生产者与消费者相互依赖的关系，即解耦。
②支持并发，生产者和消费者作为两个独立的并发主体，互不干扰。
③支持忙闲不均，生产者生产效率时快时慢，数据放入公共区域作为缓存，则消费者不必等待生产者生产完毕，可直接从公共区域取走数据。
Q2：什么是RPC
RPC（Remote Procedure Call）即远程服务调用，客户端通过RPC把调用信息封装起来，序列化后进行网络传输，到达服务器。远程服务器在接收请求之后，反序列化获得调用信息，执行服务并序列化结果，再将数据通过网络传输返给客户端。其具体服务过程如下图：
Q3：什么是dubbo
dubbo是阿里集团开源的分布式服务框架，其提供高性能透明化的RPC调用，能够与Spring框架集成，因此，目前在国内互联网公司及企业应用广泛。
其分布式概念可使用下图表示：
由此可以看出dubbo符合生产者消费者模型，但dubbo在生产者消费者模型基础上进行了改进，添加了注册中心及监控中心，形成了下图的服务架构：
dubbo的发布-订阅过程如下：
- 启动容器，生产者在注册中心发布所提供的服务；
- 消费者在注册中心订阅服务。
服务失败与变更时：
- 注册中心返回生产者提供服务的地址列表给消费者，如果变更，注册中心将基于长连接推送变更数据给消费者（长连接：长时间保持客户端与服务端的连接状态）。
- 消费者从注册中心返回的生产者服务地址列表中选择一台调用，如果失败，再选择另一台。
- 生产者和消费者在内存中累计的调用次数和时间定时发送数据至监控中心。
dubbo测试配置
1. Jar包导入
①生产者和消费者都需要引入dubbo相关的Jar包，如下图：
②根据dubbo的版本引入zk客户端，如下图：
2.生产者xml配置
在xml文件中进行如下生产者相关配置：
3.消费者xml配置
在xml文件中进行如下消费者相关配置：
注：消费者不需要知道生产者的ip地址，只需要知道注册中心的地址（本文即以zookeeper为例的地址）即可。
实施测试
导入上述配置文件中服务的Jar包，进行实例化，即可对服务中的接口进行调用和测试。
测试中注意事项：
①测试前准备：
- 测试之前，确保环境及服务配置正确，不可出现在生产环境测试状况，务必对环境做出区分。
- 查看接口文档，了解功能及业务逻辑，分析需求，选择合适的测试框架/工具/脚本。
- 了解返回码及其对应的描述。
- 了解数据库的配置、查询。
- 确认各项服务运行正常，配置至最新测试版本。
- 确认最新测试数据符合本次测试需求。
②测试失败分析：
- 注册中心进程是否存在：为节约成本，有时测试环境容器配置数量少，并且容器性能大大不如生产环境，当数据量过大时，过于频繁的访问注册中心（zk），易造成服务崩溃，所以当返回错误码时，需要查看zk进程是否存在，如果进程不在需要重启zkClient服务，并将性能问题报告开发人员，提出参考意见。
- 服务进程是否存在：所测试的服务进程是否存在，若服务挂掉，查看日志，查明服务挂掉的原因，分析是否与本次测试有关。
- 接口相关问题：参数正确性（长度/格式）、容错测试。
以上仅为个人测试观点及经验总结，接口测试还需更深入的时间与总结，欢迎大家提出意见与建议~
End
