Dubbo Kryo实现高速序列化
- Dubbo RPC是Dubbo体系中最核心的一种高性能,高吞吐量的远程调用方式,是一种多路复用的TCP长连接调用:序列化:
1.序列化（serialization）在计算机科学的资料处理中，是指将数据结构或物件状态转换成可取用格式（例如存成档案，存于缓冲，或经由网络中传送），
以留待后续在相同或另一台计算机环境中，能恢复原先状态的过程。依照序列化格式重新获取字节的结果时，
可以利用它来产生与原始物件相同语义的副本。
2.简单的来讲就是将某种数据结构或者对象转换成一种数据格式，数据格式可以通过网络传送或者存入数据库中，
同时可以根据数据格式还原出原来的数据结构（反序列化）。在 Java 中，对象只有在 JVM 运行时才会存在，如果想要把对象存储到本地或者发送到远程的服务器，
则必须通过序列化将对象转换成相应的字节然后进行存储或者传送，之后再将字节组装成对象。
3.在以下场景中都会遇到序列化：
3.1将对象状态保存到文件或者数据库中
3.2通过 socket 在网络中传送对象
3.3通过RMI(远程方法调用)传输对象1.为什么需要手动注册,不在配置文件中注册?
因为要注册的类往往数量较多,导致配置文件冗长
在没有好的IDE支持下,配置文件的编写和重构都比Java类复杂得多
这些注册的类一般是不需要在项目编译打包后还需要动态修改的
2.为什么不用@annotation标注然后系统发现并注册?
因为annotation只能用来标注你可以修改的类,很多序列化的类是无法修改的(第三方库,JDK系统和其它项目的类)
3.除了annotation,可以用其它方式来自动注册被序列化的类,如扫描路径,自动发现实现
Serializable接口(甚至包括Externalizable)的类并注册,类路径上找到Serializable类可能非常多,
可以用package前缀来一定程度限定扫描范围
在自动注册机制中,要保证服务提供端和消费端以同样的顺序(或者ID)来注册类,避免错位.因为可
被发现然后注册的类的数量可能都是不一样的可以在@HystrixCommand中的@HystrixProperty中配置阈值Dubbo Consumer中使用熔断器Dubbo Hystrix熔断器仪表盘在Provider和Consumer中都需要配置Hystrix仪表盘,配置方式一致Dubbo Hystrix配置熔断器仪表盘@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)
- 长连接: 避免每次调用新建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
- 在面向生产的环境中,使用Dubbo Kryo实现序列化: <dependency>
<groupId>de.javakaffee</groupId>
<artifactId>kryo-serializers</artifactId>
<version>0.42</version>
</dependency> dubbo.protocol. serialization=kryo
- 引入Kryo依赖kryo-serializers
- 配置文件中增加配置
- 注册被序列化类
- 要让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
- 注册这些类后,序列化的性能大大提升,特别是针对小数量的嵌套对象
- 注意:(无参构造函数和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代理
- 在Consumer(服务消费者)中增加依赖spring-cloud-starter-netflix-hystrix
- 在主类上标注@EnableHystrix注解
- 在调用类controller中的调用方法上标注 @HystrixCommand(fallback="熔断返回页面的方法名")
- 增加Hystrix仪表盘依赖spring-cloud-starter-netflix-hystrix-dashboard
- 在主类上标注@EnableHystrixDashboard注解开启Hystrix仪表盘功能
- 创建hystrix.stream(监控路径)的Servlet配置
- 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�llback
- hystrix.command.default.fallback.isloation.semaphore.maxConcurrentRequests: 调用线程(Consumer)允许请求HystrixCommand.GetFallback()最大数量,默认为10.(==注意:== 该项配置对于THREAD隔离模式也生效)
