分布式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方法

fallback方法抛出异常

参数	描述
FALLBACK_FAILURE	Fallback执行抛出出错
FALLBACK_REJECTED	Fallback信号量拒绝,不尝试执行
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隔离模式也生效)