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、消费端不发起对远程的调用直接根据降级策略,给出返回。
消费端:
服务端代码不变。