dubbo

目录 

Dubbo的模块

invocation

一：什么是RPC

二：dubbo的配置

三：@Reference

 四： @DubboService

五：protocal  http请求

五（1）protocol接口

根据用户的配置来决定使用什么协议（）

六： proxy服务代理层​

七： 注册中心registry

八：Dubbo容错机制

九：负载均衡策略

Random LoadBalance

RoundRobin LoadBalance

LeastActive LoadBalance

ConsistentHash LoadBalance

十：服务超时

十一：使用zk/redis作为注册中心的原因

十二：SpringCloud和Dubbo的区别

十三：HTTP协议和TCP协议的区别

十四：Dubbo的SPI机制

---

Dubbo的模块

生产者，消费者，还有一个存放接口的common模块

protocol 层，远程调用层，封装 rpc 调用；这里可以使用http连接，也可以使用netty连接

.

proyx：服务代理层

.

registry 层，服务注册层，负责服务的注册与发现；

.                   

service 层，接口层，给服务提供者和消费者来实现的（留给开发人员来实现）；

.

invocation

Invocation，一次具体的调用，包含方法名、参数类型、参数，版本号

---

一：什么是RPC

维基百科是这么定义RPC的：

在分布式计算，远程过程调用（英语：Remote Procedure Call，缩写为 RPC）是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一个地址空间（通常为一个开放网络的一台计算机）的子程序，而程序员就像调用本地程序一样，无需额外地为这个交互作用编程（无需关注细节）。RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。

如果涉及的软件采用面向对象编程

那么远程过程调用亦可称作远程调用或远程方法调用，例：Java RMI

所以，对于Java程序员而言，RPC就是远程方法调用。

远程方法调用和本地方法调用是相对的两个概念，本地方法调用指的是进程内部的方法调用，而远程方法调用指的是两个进程内的方法相互调用。

如果实现远程方法调用，基本的就是通过网络，通过传输数据来进行调用。

所以就有了：

1. RPC over Http：基于Http协议来传输数据
2. PRC over Tcp：基于Tcp协议来传输数据

对于所传输的数据，可以交由RPC的双方来协商定义，但基本都会包括：

1. 调用的是哪个类或接口
2. 调用的是哪个方法，方法名和方法参数类型（考虑方法重载）
3. 调用方法的入参

所以，我们其实可以看到RPC的自定义性是很高的，各个公司内部都可以实现自己的一套RPC框架，而Dubbo就是阿里所开源出来的一套RPC框架。

二：dubbo的配置

使用dubbo的话，就不需要通过restTemplate来调用http请求，可以直接通过方法请求

生产者的配置

dubbo.scan.base-packages=com.tuling.provider.service  扫描这个路径下的这些类，看有无dubbo注解，然后会去解析这些类和注解

dubbo.registry.address=zookeeper://127.0.0.1:2181  定义你应用下的这些服务，要注册到哪个地方去

#dubbo.protocol.name=dubbo
#dubbo.protocol.port=20880  
protocol代表的是协议，这里用的是dubbo协议，dubbo默认用的是netty

 

 如果这样定义，那就默认支持三个协议，如果想确定哪个协议，加上protocol即可

消费者的配置

这里连接到zookeeper，去注册中心获取数据 

三：@Reference

@Reference是dubbo的注解，也是注入，他一般注入的是分布式的远程服务的对象，需要dubbo配置使用。

 简单来说他们的区别：
@Reference注入的是分布式中的远程服务对象，@Resource和@Autowired注入的是本地spring容器中的对象。

@DubboReference会引用服务，具体会引用那些服务，我们都不管，因为dubbo会从配置文件的zookeeper://127.0.0.1:2181  注册中心里面去获取 

当然，userService如有多个版本，那么我们从@DubboReference(version = "2.0")这样去指定版本

@Service
public class OrderService {
    @Resource
    private RestTemplate restTemplate;

    @DubboReference
    private UserService userService;

    /**
     * 使用dubbo的话，就不需要通过restTemplate来调用http请求，可以直接通过方法请求
     * @return
     */
    public String getOrder(){
        

        //String result = restTemplate.getForObject("http://localhost:8080/user",String.class);
        return userService.getUser();;
    }
}

 四： @DubboService

@DubboService这里可以存放版本

UserServiceImpl2的版本是2.0，UserServiceImpl1的版本是1.0，

@DubboService(version = "2.0")
public class UserServiceImpl2 implements UserService {
    public String getUser(){
        return "yangBX";
    }
}

---

我们的接口放在common模块，我们的生产者模块需要用到接口，所以在生产者模块里面我们需要导入接口的模块common 

五：protocal  http请求

 消费者调用代理对象

代理对象执行sayHello方法，进入invoke

invoke里面初始化Invocation，调用client，send请求发送给locolhost：8080

请求会被我的provider的tomcat接收到

 tomcat的dispatcher会接收所有请求        

然后进入到dispathcerServlet的service方法里面去，调用HttpServletHandle方法

请求会发送到我们的HttpServletHandle里面去

HttpServletHandle拿到我们的invocation，会通过接口名，拿到实现类impl

然后通过反射的形式，拿到invocation里面所需要执行的方法

http里面通过生产者的locolRegister，拿到对应的服务！

 

五（1）protocol接口

 

然后你用什么协议，就new什么protocol

 代理类改成这样

 但是这样改来改去也很麻烦

根据用户的配置来决定使用什么协议（）

  

 代理类改成这样

六： proxy服务代理层

在消费者端，通过JDK动态代理方法，获得接口HelloService

helloService.sayHello方法，就是执行JDK动态代理的invoke方法

七： 注册中心registry

注册中心步骤

1. 我们需要获得url，就需要去注册中心获取（redis/zk）
2. 服务启动后，拿到本机的IP地址，不仅要存到本地，还要存到注册中心里面去
3. 本机IP地址的获取，一般需要借助JDK的util工具类，这里就自己定义了
4. 然后在consumer的代理的invoke方法里面去获取地址，发送请求
5. 集合里面有多个部署的ip地址，我们怎么知道是哪个？负载均衡
6. 看看用户设置的负载均衡的策略是什么，根据策略来决定发送的请求去哪个IP地址

注册中心的get方法为什么返回的是集合？因为服务一般都是部署在多台服务器的

 

八：Dubbo容错机制

一般我们都在invoke方法里面通过try，catch的方式来抛出错误

但是不可以单纯的try，catch

因为protocol.send方法会先提前捕捉到异常（send里面也有try，catch）

所以我们需要自定义异常RPCException

然后在我们觉得应该需要抛出异常的地方 throw new RPCException 

九：负载均衡策略

Random LoadBalance

• 随机，按权重设置随机概率。
• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

• 轮询，按公约后的权重设置轮询比率。
• 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

• 一致性 Hash，相同参数的请求总是发到同一提供者。
• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
• 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
• 缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

这其中比较难理解的就是最少活跃调用数是如何进行统计的？

讲道理，最少活跃数应该是在服务提供者端进行统计的，服务提供者统计有多少个请求正在执行中。

但在Dubbo中，就是不讲道理，它是在消费端进行统计的，为什么能在消费端进行统计？

逻辑是这样的：

1. 消费者会缓存所调用服务的所有提供者，比如记为p1、p2、p3三个服务提供者，每个提供者内都有一个属性记为active，默认位0
2. 消费者在调用次服务时，如果负载均衡策略是leastactive
3. 消费者端会判断缓存的所有服务提供者的active，选择最小的，如果都相同，则随机
4. 选出某一个服务提供者后，假设位p2，Dubbo就会对p2.active+1
5. 然后真正发出请求调用该服务
6. 消费端收到响应结果后，对p2.active-1
7. 这样就完成了对某个服务提供者当前活跃调用数进行了统计，并且并不影响服务调用的性能

十：服务超时

在服务提供者和服务消费者上都可以配置服务超时时间，这两者是不一样的。

消费者调用一个服务，分为三步：

1. 消费者发送请求（网络传输）
2. 服务端执行服务
3. 服务端返回响应（网络传输）

如果在服务端和消费端只在其中一方配置了timeout，那么没有歧义，表示消费端调用服务的超时时间，消费端如果超过时间还没有收到响应结果，则消费端会抛超时异常，但，服务端不会抛异常，服务端在执行服务后，会检查执行该服务的时间，如果超过timeout，则会打印一个超时日志。服务会正常的执行完。

如果在服务端和消费端各配了一个timeout，那就比较复杂了，假设

1. 服务执行为5s
2. 消费端timeout=3s
3. 服务端timeout=6s

那么消费端调用服务时，消费端会收到超时异常（因为消费端超时了），服务端一切正常（服务端没有超时）。

十一：使用zk/redis作为注册中心的原因

1. 他们都可以在内存里面存数据，作为共享数据给服务者和消费者使用
2. 可以在本地注册中心里面存放缓存
3. 缓存需要保持缓存和真实数据保持一致，zk可以使用监听watch，redis的消费订阅机制
4. 心跳机制，用在服务端；服务器挂了，需要在注册中心删除数据---临时节点

十二：SpringCloud和Dubbo的区别

十三：HTTP协议和TCP协议的区别

• http协议是应用层协议，主要是解决如何包装数据。而tcp协议是传输层协议，主要解决数据如何在网络中传输。
• 通俗点说，http的任务是与服务器交换信息，它不管怎么连到服务器和保证数据正确的事情。而tcp的任务是保证连接的可靠，它只管连接，它不管连接后要传什么数据。
• http协议是建立在tcp之上的，http是无状态的短链接，而tcp是有状态的长链接。
   

十四：Dubbo的SPI机制