写点什么

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

发布于: 2021 年 05 月 19 日
分布式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 配置


@Configurationpublic 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 方法抛出异常

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 隔离模式也生效)

发布于: 2021 年 05 月 19 日阅读数: 10
用户头像

一位攻城狮的自我修养 2021.04.06 加入

分享技术干货,面试题和攻城狮故事。 你的关注支持是我持续进步的最大动力! https://github.com/ChovaVea

评论

发布
暂无评论
分布式RPC框架Dubbo实现服务治理:集成Kryo实现高速序列化,集成Hystrix实现熔断器