初识RPC

RPC VS REST HTTP

Dubbo

Dubbo 特性：

1. 基于接口+动态代理的远程方法调用

	Dubbo对开发者屏蔽了底层的调用细节，在实际代码中调用远程服务就像调用一个本地接口类一样方便。这
	个功能和Fegin很类似，但是Dubbo用起来比Fegin还要简单很多，Fegin优势还需要独立声明一个接口，
	而Dubbo真的就是拿到公共接口类后直接就能用。

2. 负载均衡

Dubbo内置多种负载均衡策略，只能感知下游节点健康状况，提高系统吞吐量，这部分功能和Ribbon十分接近，
但是Dubbo的负载均衡策略不如Ribbon的多，而且Dubbo的负载均衡能力只能供自己享用，而Ribbon可以赋能
给Spring Cloud里的各个组件。

3. 集群容错

Dubbo提供了一个Cluster组件专门用来做集群容错，它其实并不是Hystrix这类降级组件，而是一种 “异常重
试”

4. 服务治理

支持多种注册中心服务，服务实力上下线实时感知。就是服务注册、服务发现、服务下线之类的流程，这些功能
和Eureka里面的概念是一模一样的，只是实现方式却大有不同。比如Dubbo在服务下线后会主动将可用服务列表
下发到各个服务节点，送货上门服务周到，而Eureka每次都等着服务节点自己上注册中心来拿数据。

Dubbo 的技能点比较专一，全点在了服务治理体系，但就服务治理来看确实比Eureka细致一些。

Dubbo架构

Dubbo和Eureka中服务发现的不同

1. Dubbo里的注册中心、Provider和Counsumer三者之间都是长连接，借助于Zookeeper的高吞吐量，实现基于服务端的服务发现机制。因此Dubbo利用Zookeeper+发布订阅模型可以很快将服务节点的上线下线同步到Consumer集群。如果服务提供者宕机，那么注册中心的长连接会立马感知到这个事件，并且立即推送通知到消费者。
2. 在服务发现的做法上Dubbo和Eureka有很大的不同，Eureka使用客户端的服务发现机制，因此对于服务列表的变动响应会稍慢，比如某台机器下线以后，在一段时间内可能还会陆续有服务请求发过来，当然这些请求会收到Service Unavailable的异常，需要借助Ribbon活Hystrix实现重试或者降级措施。
3. 对于注册中心宕机的情况，Dubbo和Eureka的处理方式相同，这两个框架的服务节点都在本地缓存了服务提供者的列表，因此仍然可以发起调用，但服务提供者列表无法被更新，因此可能导致本地缓存的服务状态与实际情况有别。

Dubbo有哪些底层协议

1. Dubbo本尊，官方推荐；
2. RMI ， JDK中“java.rmi”包下的实现，底层采用阻塞的短连接 + JDK中标准的二进制序列化。
   适用场景：参数数据报大小不一，发i为i提供者和服务消费者个数相近
3. Hessian ， 基于HTTP短连接，采用Service向外暴露服务
   适用场景：参数数据报较大，服务提供者的数量远多于消费者数量
4. HTTP，基于http表单的协议
   适用场景：可以使用浏览器查看，适用于需要同时给后台应用程序以及浏览器提供服务的场景
5. WebService，基于大名鼎鼎的Apache CFX，使用基于SOAP的序列化技术
   适用场景：系统由多种不同语言构成的，那么这个场景就比较适合采用WebService协议，WebService通常使用在系统集成和跨语言调用场景中。
6. REST，基于标准的Java REST API 实现的REST风格调用， Dubbo花了大力气在这部分的实现上面， 他的使用风格和原生Spring MVC类似。

Dubbo协议的特性和性能

• 连接个数 -> 单连接
• 连接方式 -> 长连接
• 传输协议 -> TCP
• 底层通信框架 -> Netty异步NIO
• 序列化方式 -> Hessian2或Dubbo序列化

Dispatcher线程派发模型

Dispatcher用来创建具有线程派发能力的ChannelHandler，将来访Request派发到线程池或者当前IO线程。我们可以给Dispatcher配置5种派发策略：

1. all：所有消息都派发到线程池，包括请求，响应，连接事件，断开事件
2. direct：所有消息都不派发到线程池，全部在IO线程上直接执行
3. message：只有请求和响应消息派发到线程池，其它消息均在IO线程上执行
4. execution：只有请求消息派发到线程池，不含响应。其它消息均在IO线程上执行
5. connection：在IO线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池

Dubbo的Cluster和Clister Invoker组件：

1. 集群模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以专心处理远程调用相关事宜。比如发请求，接受服务提供者返回的数据等。
2. Cluser Invoker大集合
   a. FailoverClusterInvoker - 指定重试次数 (默认)
   b.FailbackClusterInvoker - 后台定时重试
   c.FailfastClusterInvoker - 早死早超生
   d.FailsafeClusterInvoker - 睁一只眼闭一只眼
   e.ForkingClusterInvoker - 百万雄师过大江

Dubbo中的负载均衡

1. RandomLoadBalance 基于权重算法的负载均衡策略
2. LeastActiveLoadBalance 基于最少活跃调用数算法
3. ConsistentLoadBalance 基于Hash一致性
4. RoundRobinLoadBalance 基于加权轮询算法