dubbo的使用背景
作为分布式微服务之间的调用框架，今天把dubbo的使用配合其高级特性做一个叙述，以及代码实现。
整体代码结构
web包 是请求接口的入口，其依赖了interface包的UserService类
service包 是实现了 interfce包的UserService类
以下高级特性，都是在这个代码结构上面实现的。
一、序列化
分布式微服务和单体服务不同，尤其是在传输对象的过程中，需要把Java对象通过网络进行传输的时候。因为数据只能够以二进制的形式在网络中进行传输，因此当把对象通过网络发送出去之前需要先序列化成二进制数据，在接收端读到二进制数据之后反序列化成Java对象。
dubbo 内部已经将序列化和反序列化的过程内部封装了
我们只需要在定义pojo类时实现Serializable接口即可
一般会定义一个公共的pojo模块，让生产者和消费者都依赖该模块。
二、地址缓存
三、超时与重试
服务消费者在调用服务提供者的时候发生了阻塞、网络抖动、等待的情形，这个时候，服务消费者会一直等待下去。
在某个峰值时刻，大量的请求都在同时请求服务消费者，会造成线程的大量堆积，势必会造成雪崩。
这时候，超时与重试机制就有了必要性。消费端不需要改动。
服务端：
1、首先 timeout = 3000,retries = 2 这个部分也可以放在消费端，但是通常服务端才是决定业务时长的部分。
2、这里模拟了一个超时重试的调用过程，超时时间是3秒，而服务调用需要5秒多，此时因为重试为2次，所以一共调用了3次，才返回给消费端错误信息。
3、默认重试就是2次。每次重试的时候，依然和第一次调用相同，会在超时时间的限制下，对服务是否调用成功做判断，所以上图的代码示例，就会执行3+3+3=9秒的服务调用，才会返回服务端错误信息。
四、多版本
消费端代码：
服务端代码
多版本主要是针对服务端，对接口有多个实现，消费端可以根据需求选择相应的版本实现。
五、负载均衡
负载均衡的应用，是在微服务集群的场景下，消费端选择集群当中的哪个服务来调用的一种策略。
其中按权重随机和按权重轮询，都需要在集群的服务端设置服务的权重。
最少活跃调用数，是指在进行负载均衡时，会根据调用服务的时长来做判断，哪个服务响应的越快，就去访问哪个服务。
一致性hash，保留。
下面以随机策略为例，展示代码消费端：
服务端：
六、集群容错
这里容易和 上面的 超时重试机制混淆，
超时重试，是在消费端针对单个服务调用的时候，采取的策略。
集群容错，是在消费端针对服务集群情况下采取的策略。
下面以失败重试为例，给出代码示例：
消费端：
上图的策略等价于下图的策略，重试两次是默认的。
服务端不需要代码改动。
七、服务降级
这里有两种场景的服务降级
1、服务端因为执行错误或者超时等原因，会根据服务降级策略，给出返回。
消费端：
服务端代码不变。
这里会去做远程的调用，并且也会默认重试两次，retries =2，也就是调用了三次服务端之后，会返回null。
2、消费端不发起对远程的调用直接根据降级策略，给出返回。
消费端：
服务端代码不变。
