Dubbo（3）Dubbo常用高级配置1：序列化、地址缓存、超时、重试、多版本

序列化

实现步骤：

（1）新增一个模块，用来存放实体类，需要实现Serializable接口，因为它需要在两台服务器之间进行传输

（2）在专门存放接口的模块添加pojo的依赖

（3）在接口中添加方法：

（4）在service(服务提供者)中实现这个方法

（5）在web(消费者)这个地方实现访问这个方法

（6）最后可以通过浏览器输入这个web的地址，就可以实现

地址缓存

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

• 可以， 因为dubbo服务消费者在第一次调用时，会将服务提供方地址缓存到本地，以后在调用则不会访问注册中心。
• 当服务提供者地址发生变化时，注册中心会通服务消费者。
• 老的访服务还是可以用的，只是新的访问是还需要注册的

超时

出现场景：设置了超时时间，在这个时间段内，无法完成服务访问，则自动断开连接。

• 正常情况：

  1. 服务的消费者和访问的提供者分别部署在A和B两台机器上
  2. 有一个用户，访问服务的消费者，消费者A内部会创建一个线程，单独的而且访问服务的提供者B，调用服务（Dubbo的过程）
  3. 服务提供者B处理好数据过后，将数据返回给服务的消费者A，
  4. 消费者收到数据后，把数据封装一下给用户，
  5. 截止到4，整个过程就结束了 ，过程结束过后，线程也就会归还到线程池里面去

  

• 异常情况：

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

     A调用B，这个调用一直不成功，调用不成功后，服务消费者里面线程就会一直在等，即该线程一直不会被释放

     • 在请求比较少的时候是不会有什么问题的
     • 当有很多用户同时来访问访问的消费者的时候，会产生多线程同时来访问服务的提供者，如果都不成功，这时候，服务的消费者里面就积压了很多线程，这些线程也得不到释放，导致A机器的资源用完了
       • 在某个峰值时刻，大量的请求都在同时请求服务消费者，会造成线程的大量堆积,势必会造成雪崩。
     • dubbo利用超时机制来解决这个问题，设置一个超时时间, 在这个时间段内，无法完成服务访问，则自动断开连接。
       • 使用timeout属性配置超时时间，默认值1000,单位毫秒。

有两个地方配置超时时间：

服务消费者定义的超时时间会覆盖掉服务的提供方的超时时间，

建议将超时时间定义到服务的提供方上面

1. 服务的提供方

   

2. 服务的消费者

重试

如果出现网络抖动(网络突然断开)，则这一次请求就会失败。

• 第一次请求失败了，然后服务消费者会再发一次请求重试一下
• 一共会发送设置的次数，全部都失败就是真的失败
• 通过retries属性来设置重试次数。默认为2次。

多版本

灰度发布：

• 当出现新功能时，会让一部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能。
• dubbo中使用version属性来设置和调用同一个接口的不同版本

测试：

• 旧版本：

  

• 新版本：

  

• 使用版本：图中是新版本的接口