分布式RPC框架Dubbo实现服务治理：集成Kryo实现高速序列化，集成Hystrix实现熔断器

Posted 攻城狮Chova

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分布式RPC框架Dubbo实现服务治理：集成Kryo实现高速序列化，集成Hystrix实现熔断器相关的知识，希望对你有一定的参考价值。

Dubbo+Kryo实现高速序列化

  • Dubbo RPC是Dubbo体系中最核心的一种高性能,高吞吐量的远程调用方式,是一种多路复用的TCP长连接调用:

    • 长连接: 避免每次调用新建TCP连接,提高调用的响应速度
    • 多路复用: 单个TCP连接可交替传输多个请求和响应的消息,降低了连接的等待时间,从而减少了同样并发数的情况下网络连接数,提高了系统的云吞吐量
  • Dubbo RPC主要用于两个Dubbo之间的远程调用,适合高并发,小数据的互联网场景.序列化对于远程调用的响应速度,吞吐量,网络带宽消耗等同样也起着至关重要的作用,是提升分布式系统性能的最关键因素之一

  • Dubbo中支持的序列化方式:

    • dubbo序列化: 阿里的高效java序列化实现
    • hessian2序列化: hessian是一种高效跨语言的二进制序列化方式.这里不是原生的hessian2序列化,而是阿里修改过的hessian lite,是Dubbo RPC默认启动的序列化方式

    • json序列化: 目前有两种实现-

      • 采用阿里的fastjson库
      • 采用dubbo中实现的简单json库
      • json这种文本序列化性能不如dubbo序列化,hessian2序列化这两种二进制序列化
    • java序列化: 主要采用JDK自带的Java序列化实现,性能差

  • 序列化方式:

    • 针对Java语言的序列化方式:Kryo,FST

    • 跨语言的序列化方式:Protostuff,ProtoBuf,Thrift,Avro,MsgPack

      序列化:
1.序列化（serialization）在计算机科学的资料处理中，是指将数据结构或物件状态转换成可取用格式（例如存成档案，存于缓冲，或经由网络中传送），
以留待后续在相同或另一台计算机环境中，能恢复原先状态的过程。依照序列化格式重新获取字节的结果时，
可以利用它来产生与原始物件相同语义的副本。
2.简单的来讲就是将某种数据结构或者对象转换成一种数据格式，数据格式可以通过网络传送或者存入数据库中，
同时可以根据数据格式还原出原来的数据结构（反序列化）。在 Java 中，对象只有在 JVM 运行时才会存在，如果想要把对象存储到本地或者发送到远程的服务器，
则必须通过序列化将对象转换成相应的字节然后进行存储或者传送，之后再将字节组装成对象。
3.在以下场景中都会遇到序列化：
    3.1将对象状态保存到文件或者数据库中
    3.2通过 socket 在网络中传送对象
    3.3通过RMI(远程方法调用)传输对象

  • 在面向生产的环境中,使用Dubbo+Kryo实现序列化:

    • 引入Kryo依赖kryo-serializers

      <dependency>
  <groupId>de.javakaffee</groupId>
  <artifactId>kryo-serializers</artifactId>
  <version>0.42</version>
</dependency>

    • 配置文件中增加配置

      dubbo.protocol. serialization=kryo

    • 注册被序列化类

      • 要让Kryo发挥高性能,需要将需要被序列化的实体类注册到Dubbo系统中,实现如下回调接口:

        public class SerializationOptimizerImpl implements SerializationOptimizerImpl{
public Collection<class> getSerializableClasses(){
      List<Class> classes=new LinkedList<class>();
      classes.add(provider.class);
      classes.add(consumer.class);
      return classes;
}
}

      • 配置文件中增加配置

        dubbo.protocol.optimizer=com.oxford.SerializationOptimizerImpl
      • 注册这些类后,序列化的性能大大提升,特别是针对小数量的嵌套对象
      1.为什么需要手动注册,不在配置文件中注册?
因为要注册的类往往数量较多,导致配置文件冗长
在没有好的IDE支持下,配置文件的编写和重构都比Java类复杂得多
这些注册的类一般是不需要在项目编译打包后还需要动态修改的
2.为什么不用@annotation标注然后系统发现并注册?
因为annotation只能用来标注你可以修改的类,很多序列化的类是无法修改的(第三方库,JDK系统和其它项目的类)
3.除了annotation,可以用其它方式来自动注册被序列化的类,如扫描路径,自动发现实现
Serializable接口(甚至包括Externalizable)的类并注册,类路径上找到Serializable类可能非常多,
可以用package前缀来一定程度限定扫描范围

在自动注册机制中,要保证服务提供端和消费端以同样的顺序(或者ID)来注册类,避免错位.因为可
被发现然后注册的类的数量可能都是不一样的
  • ==注意:==(无参构造函数和Serializable接口)
  • 如果被序列化的类,不包含无参构造函数,则会导致Kryo序列化性能降低.因为底层将会使用Java的序列化来透明取代Kryo序列化.尽可能为每一个被序列化的类添加无参构造函数(Java类如果不自定义构造函数,默认就有无参构造函数)

  • Kryo和FST都不需要被序列化类实现Serializable接口,但还是需要每个序列化类都去实现Serializable接口,保持和Java序列化以及dubbo序列化兼容性

    Dubbo+Hystrix实现服务熔断

  • 熔断器:

    • 在微服务架构中,根据业务拆分成一个个的服务,服务服务之间通过RPC相互调用
    • 为了保证高可用,单个服务采用集群部署,由于网络或者自身的原因,服务不能保证100%可用
    • 如果单个服务出现问题,调用这个服务就会出现出现线程阻塞,此时若大量的请求涌入,servlet容器的线程就会被消耗完毕,导致服务瘫痪,服务与服务之间的依赖性会导致故障传播,进而导致整个微服务瘫痪,这就是"服务雪崩效应"
    • 为了解决服务雪崩效应,提出熔断器的模型

  • 熔断器模型:

    • 底层的服务出现故障,会导致连锁故障
    • 当对特定服务调用的不可用到达一个阈值(Hystrix默认5秒20次),熔断器就会被打开

    • 熔断器打开后,为了避免连锁故障,通过fallback方法直接返回一个固定值

      Dubbo Provider中使用熔断器

  • 在Provider(服务提供者)中增加依赖spring-cloud-starter-netflix-hystrix
  • 在主类中标注@EnableHystrix注解

  • 在接口实现类的服务调用方法上标注@HystrixCommand注解,调用Hystrix代理

    可以在@HystrixCommand中的@HystrixProperty中配置阈值

    Dubbo Consumer中使用熔断器

  • 在Consumer(服务消费者)中增加依赖spring-cloud-starter-netflix-hystrix
  • 在主类上标注@EnableHystrix注解
  • 在调用类controller中的调用方法上标注 @HystrixCommand(fallback="熔断返回页面的方法名")

  • Dubbo+Hystrix熔断器仪表盘

    在Provider和Consumer中都需要配置Hystrix仪表盘,配置方式一致

    Dubbo+Hystrix配置熔断器仪表盘

  • 增加Hystrix仪表盘依赖spring-cloud-starter-netflix-hystrix-dashboard
  • 在主类上标注@EnableHystrixDashboard注解开启Hystrix仪表盘功能

  • 创建hystrix.stream(监控路径)的Servlet配置

    @Configuration
public class HystrixDashBoardConfiguration{
  @Bean
  public ServletRegistrationBean getServlet(){
      HystrixMetricsStreamServlet streamServlet=new HystrixMetricsStreamServlet();
      ServletRegistrationBean registrationBean=new ServletRegistrationBean(streamServlet);
      registrationBean.setLoadOnStartup(1);
      registrationBean.addUrlMappings("/hystrix.stream");
      registrationBea.setName("HystrixMetricsStreamServlet");
      return registrationBean;
  }
}

    Hystrix说明

    触发fallback方法

    参数描述
    FAILURE执行抛出异常
    TIMEOUT执行开始,但没有在指定的时间内完成
    SHORT_CIRCUITED断路器打开,不尝试执行
    THREAD_POOL_REJECTED线程池拒绝,不尝试执行
    SEMAPHORE_REJECTED信号量拒绝,不尝试执行

    fallback方法抛出异常

    参数描述
    FALLBACK_FAILUREFallback执行抛出出错
    FALLBACK_REJECTEDFallback信号量拒绝,不尝试执行
    FallBack_MISSING没有Fallback实例

    Hystrix常用配置信息

    超时时间(默认1000ms)
    • hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 在Consumer中配置,Provider的所有方法的超时时间都是该值,优先级低于下面的指定配置

    • hystrix.command.HystrixCommandKey.execution.isolation.thread.timeoutInMilliseconds: 在Consumer中配置,Provider的指定方法(HystrixCommandKey方法名)的超时时间都是该值

      线程池核心线程数
    • hystrix.threadpool.default.coreSize: 默认为10,Consumer中配置

  • Queue:

    • hystrix.threadpool.default.maxQueueSize: 最大排队长度,默认-1,使用 SynchronousQueue, 其他值使用LinkedBlockingQueue. 如果要从-1换成其他值重启,即该值不能动态调整,需要使用下边这个配置

    • hystrix.threadpool.default.queueSizeRejectionThreshold: 排队线程数量阈值,默认为5,达到时拒绝,如果配置了该选项,队列的大小是该队列(==注意:== 如果maxQueueSize=-1的话,则该选项不起作用)

      断路器
    • hystrix.command.default.circuitBreaker.requestVolume.Threshold: 当在配置时间窗口内达到此数量的失败后,进行短路,默认20个
    • hystrix.command.default.circuitBreaker.sleepWindowinMilliseconds: 短路一定的时间开始尝试是否恢复,默认5s

    • hystrix.command.default.circuitBreaker.errorThresholdPercentage: 出错百分比阈值,当达到此阈值后,开始短路,默认50%

      fallback
  • hystrix.command.default.fallback.isloation.semaphore.maxConcurrentRequests: 调用线程(Consumer)允许请求HystrixCommand.GetFallback()最大数量,默认为10.(==注意:== 该项配置对于THREAD隔离模式也生效)

以上是关于分布式RPC框架Dubbo实现服务治理：集成Kryo实现高速序列化，集成Hystrix实现熔断器的主要内容，如果未能解决你的问题，请参考以下文章

架构实战篇：Spring Boot 集成 Dubbo

Rpc基于开源Dubbo分布式RPC服务框架的部署整合

如何使用Dubbo服务和集成Spring

集成Dubbo服务(Spring)

分布式RPC服务调用框架选型：使用Dubbo实现分布式服务调用

史上最强Dubbo面试28题答案详解：核心功能+服务治理+架构设计等