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

de.javakaffee kryo-serializers 0.42

配置文件中增加配置

dubbo.protocol. serialization=kryo

注册被序列化类

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

public class SerializationOptimizerImpl implements SerializationOptimizerImpl{ public Collection getSerializableClasses(){ List classes=new LinkedList(); 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方法抛出异常

Hystrix常用配置信息

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%

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

Dubbo RPC 分布式

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。