简介:
Dubbox 前身是阿里的dubbo
Dubbox致力于提高性能和透明化RPC远程服务调用的方案,以及SOA(分布式)服务治理的方案,简单的说就是,dubbox就是个服务的架构,如果没有分布式的需求,其实是不需要的,说白了,分布式在调用不同系统之间的服务的时候,是通过Dubbox来进行指定的服务的调用
上图节点的说明:
Service Provider:暴露服务的服务提供方
Service Consumer:调用远程服务的服务消费方
Dubbo Redistry:服务发现的注册中心
Dubbo Monitor :统计服务的调用的次数和调用时间的监控中心
Container:服务运行的容器
执行流程:
1,服务容器负责启动,加载运行服务提供方
2,服务提供者在启动的时候,向注册中心注册自己的服务
3,服务消费方在启动的时候,向注册中心获取自己所需要的服务
4,注册中心返回提供者地址列表给消费者,如果服务提供者有变更,此时注册中心将基于长连接推送编更新的数据给消费者
5,服务消费者和提供者,在内存中累计的次数和调用时间,每隔一分钟发送一次数据到监控中心(监控中心可以不存在)
注册中心:
简介:
官方提供的zookeeper注册中心,注册中心负责服务地址和注册于查找,相当于目录服务,服务提供者和消费者只在启动的时候于注册中心交互,注册中心不转发请求,压力较小
Zookeeper在Apache的子项目,是一个树型的目录服务,支持变更推送,适合作为Dubbox服务的注册中心,工业强度较高,可用于生产环境
总结:
Dubbox:在使用的时候,服务提供者会每隔一定的时间向注册中心报告一下自己的状态,是下线还是存活,如果指定时间内服务没有向注册中心报告自己的状态,注册中心就会将该服务从注册中心中移除掉,在使用Dubbox的时候,会出现当Zookeeper宕机之后,消费方还可以继续使用服务,是因为当消费方和提供方连接的时候,消费方是直接跟服务方进行连接,所以服务方的地址消费方是知道的,所以当注册中心宕机之后,有些服务还是可以继续工作的,但是服务方提供新的服务的时候,消费方是无法获取到的
小Demo: 采用的是注解+配置的方式
定义接口:
实现类:
在提供服务的时候,需要使用Dubbo提供的@Service的注解,是因为此时的服务不是由spring去管理而是由Douubx去管理。
Service的配置 --- 服务方
注解:
1,因为需要发布到Zookeeper注册中心,所以需要在调用的时候调用指定的服务,所以需要在发布的时候,提供名称
2,需要将服务发布到Zookeeper中心,需要指定Zookeeper的地址和端口号
3,在进行访问的时候,是以怎样的协议访问那个端口
4,需要将那个服务发布到Douubx,需要指定接口所在的包,因为对应的接口的实现类上使用了Dubbox的@Service
实现类;
Service的配置 --- 消费方
注解:
1,应用的名称
2,连接的注册中心IP和地址
3,表示要访问的服务(订阅的服务,获取的服务是发布的时候发布的接口 )
实现类在进行类引入的时候需要使用@Reference的注解来进行类的注入
协议的说明:
dubbo:缺省协议采用单一的长连接和NIO的异步通信,适用于小数据量大并发的服务调用,以及服务消费者机器数大于服务提供者机器数的情况,反之,Dubbo缺省不适合传输大数据的服务,比如穿文件、视频等,除非请求量低,适用的场景和适用的范围:传入传出的数据包大小在100K之间,尽量不要适用dubbo去传输大文件或者超大的字符串,适用的场景于常规的远程服务方法的调用
Rmi:
rmi 协议采用JDK标准的java.rmi.*实现,采用阻塞式短连接和JDK标准序列化方式
适用的范围和场景:
传入传输参数数据包代销混合,消费者与提供者的个数差不多,可穿文件
用于常规的远程服务方法的调用,与原生的RMI服务互操作
注意:
参数以及返回值需要实现Serializable接口,
dubbo 配置中的超时时间对RMI无效,需使用java启动参数设置