从零开始学习Dubbo7——Dubbo的高级特性

序列化

序列化 (Serialization)是将对象的状态信息转换为可以存储或传输的形式的过程。在序列化期间，对象将其当前状态写入到临时或持久性存储区。以后，可以通过从存储区中读取或反序列化对象的状态，重新创建该对象。

例：消费者和生产者传输java对象

序列化前提：对象要实现序列化接口implements serializable

1.生产者通过序列化使对象转化为数据流

2.数据流传递到消费者

3.消费者通过反序列化将数据流转化为对象

序列化测试

首先在项目中添加一个模块dubbo-pojo，在其中新建实例类User并实现Serializable接口，类中包含三个属性：id，username，password

package com.itheima.pojo;

import java.io.Serializable;

public class User implements Serializable {
    private int id;
    private String username;
    private String password;

    public User() {
    }

    public User(int id, String username, String password) {
        this.id = id;
        this.username = username;
        this.password = password;
    }

    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }
}

在interface中创建根据id一个查询User的方法，创建之后我们发现User爆红，因为interface中还没有导入关于dubbo-pojo的依赖

导入依赖：

在interface中定义一个方法，接下来我们就要在service中实现这个方法，由于目前还没有连接数据库所以我们先用一个假数据传递

在web中的controller层声明该方法对应的路径

启动项目

目前四个项目依赖顺序如下：所以在启动项目之前要先install一下pojo再是interface，再启动service和web

启动后访问

localhost:8000/user/findUserById.do?id=1

可以看到我们要输出的数据

地址缓存

面试点：注册中心挂了，服务是否可以正常访问?

答：可以，因为dubbo服务消费者在第一次调用时，会将服务提供方地址缓存到本地，以后在调用则不会访问注册中心。

当服务提供者地址发生变化时，注册中心会通知服务消费者。

所以就算我们将服务器端的zookeeper服务停止web项目仍然可以访问

超时与重试

首先我们先了解一下正常情况下消费者调用服务提供者的过程

用户访问消费者时，消费者会创建一个线程调用提供者并说明自己想调用的方法，服务提供者处理结束后将数据返回给消费者，消费者将数据封装再归还给用户，流程结束后消费者销毁线程

异常情况

服务消费者在调用服务提供者的时候发生了阻塞、等待的情形，这个时候，服务消费者会一直等待下去。

如果有许多用户调用消费者时导致消费者会积攒大量的线程无法释放，导致计算机崩溃

解决办法：超时机制

设置一个超时时间，在这个时间段内，无法完成服务访问，则自动断开连接。

使用timeout属性配置超时时间，默认值1000，单位毫秒。

1.在服务提供方设置

timeout是超时时间，retires是重试机制

错误设置：在service项目设置等待5s

在controller层设置每隔1s输出1

可以看到在输出三个数字后程序中断

2.在消费者方设置

如果提供者和消费者都设置了，那么消费者的超时设置会覆盖提供者的，也就是1s

重试机制

现实用户使用中很可能会因为网络原因导致超时，如果每次超时都是中断服务那么会让用户的使用好感大幅下降，因此我们可以设置重试机制，如果多次重试还是连接失败，那么就真正判定为连接失败，重试次数默认是2次

在服务提供方设置

多版本

灰度发布:当出现新功能时，会让一部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能。

dubbo中使用version属性来设置和调田同—个接口的不同版本

代码测试

service中创建两个userServiceImpl类来模拟两个不同的版本

旧版本：

新版本：

在消费者端controller类中声明使用的版本，我们先声明为旧版本

访问findById后service端输出

修改消费者端为新版本

service端：

负载均衡

负载均衡是对于集群中服务器处理任务数量的分配，dubbo中负载均衡策略分为4种

1.Random

按权重随机，默认值。按权重设置随机概率，权重越大越可能被选中

代码设置

服务提供者service设置权重

消费者层设置负载均衡策略为random

2.RoundRobin

按权重轮询，并不是随机，如果权重按下图设置的话，那么相当于比例为1:2:1，如果消费者调用4次那么便会先轮询输出1,2,3，最后一次再输出2

3.LeastActive

最少活跃调用数，相同活跃数随机，如下图中三个服务器活跃度目前是1号机最少优先调用1号机

4.ConsistentHash

一致性hash，相同参数的请求总是发送到同一提供者

集群容错

对于某一个服务，通常会使用多台服务器组成集群，当消费者调用一个服务中某一台服务器发生错误时，此时就要通过集群容错机制来解决

1.Failover Cluster:

失败重试。默认值。当出现失败，重试其它服务器，默认重试2次，使用retries配置。一般用于读操作

消费者设置集群容错机制为failover，这也是默认的容错机制

2.Failfast Cluster :

快速失败，只发起一次调用，失败立即报错。通常用于写操作。

3.Failsafe Cluster :

失败安全，出现异常时，直接忽略。返回一个空结果。

4.FailbackCluster:

失败自动恢复，后台记录失败请求，定时重发。

5.Forking Cluster :

并行调用多个服务器，只要一个成功即返回。

6.Broadcast Cluster :

广播调用所有提供者，逐个调用，任意一台报错则报错。

服务降级

如果在一个服务提供者的服务器中有多个服务正在运行，当CPU效率受到影响时，将那些不重要的服务停止来保证核心服务的运行

在消费者端通过mock修改 服务降级机制：

1.mock=force:return null

表示消费方对该服务的方法调用都直接返回null值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。

2.mock=fail:return null

表示消费方对该服务的方法调用在失败后，再返回null值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
上一篇：(20条消息) 从零开始学习Dubbo6——控制端dubbo-admin_崔泡泡—猫的博客-优快云博客