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

.

proyx：服务代理层

.

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

.? ? ? ? ? ? ? ? ? ?

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

.

invocation

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

一：什么是RPC

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

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

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

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

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

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

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

所以就有了：

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

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

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

所以，我们其实可以看到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

注册中心步骤

我们需要获得url，就需要去注册中心获取（redis/zk）
服务启动后，拿到本机的IP地址，不仅要存到本地，还要存到注册中心里面去
本机IP地址的获取，一般需要借助JDK的util工具类，这里就自己定义了
然后在consumer的代理的invoke方法里面去获取地址，发送请求
集合里面有多个部署的ip地址，我们怎么知道是哪个？负载均衡
看看用户设置的负载均衡的策略是什么，根据策略来决定发送的请求去哪个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中，就是不讲道理，它是在消费端进行统计的，为什么能在消费端进行统计？

逻辑是这样的：

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

十：服务超时

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

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

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

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

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