Dubbo简介
Apache Dubbo是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的、轻量级的开源Java RPC 框架,可以和Spring框架无缝集成。
什么是RPC?
RPC全称为remote procedure call,即远程过程调用。比如两台服务器A和B,A服务器上部署一个应用,B服务器上部署一个应用,A服务器上的应用想调用B服务器上的应用提供的方法,由于两个应用不在一个内存空间,不能直接调用,所以需要通过网络来表达调用的语义和传达调用的数据。 需要注意的是RPC并不是一个具体的技术,而是指整个网络远程调用过程。
RPC是一个泛化的概念,严格来说一切远程过程调用手段都属于RPC范畴。各种开发语言都有自己的 RPC框架。Java中的RPC框架比较多,广泛使用的有RMI、Hessian、Dubbo等。
Dubbo提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
Dubbo架构图如下:
虚线都是异步访问,实线都是同步访问 蓝色虚线:在启动时完成的功能 红色虚线(实线)都是程序运行过程中执行的功能
调用关系说明:
0. 服务容器负责启动,加载,运行服务提供者。
1. 服务提供者在启动时,向注册中心注册自己提供的服务。
2. 服务消费者在启动时,向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失
败,再选另一台调用。
5. 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。
在项目中配置使用Duboo
XML配置
服务端xml配置(调用端的配置大致相同)
<dubbo:application name="dubbodemo_provider"/>
<!-- 连接服务注册中心zookeeper ip为zookeeper所在服务器的ip地址-->
<dubbo:registry register="true" address="zookeeper://192.168.142.128:2181" check="false" protocol="dubbo"/>
<dubbo:service cluster="failover" retries="2" loadbalance="random" interface="com.lsh.service.HelloService" ref="helloService" />
<!-- 注册 协议和port -->
<dubbo:protocol name="dubbo" port="20881"></dubbo:protocol>
属性说明
1.<dubbo:application>:当前应用名称,用于注册中心计算应用间依赖关系,注意:消费者和提供者应用名不要一样。
2.<dubbo:registry>:连接服务注册中心zookeeper,中间包括许多标签
2.1 check:启动检查,Dubbo
缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止 Spring
初始化完成,以便上线时,能及早发现问题,默认check="true",开发过程中如有需要快速启动,可设置check="false"关闭检测
。
2.2 address:连接服务注册中心zookeeper,ip为zookeeper所在服务器的ip地址
,如 address="zookeeper://192.168.142.128:2181",如果注册中心为集群,用逗号隔开即可,如
address="zookeeper://192.168.142.128:2181,zookeeper://192.168.142.128:2182"。
2.3 register:是否注册到注册中心。默认为true
2.4 protocol:协议配置
3.<dubbo:service>:具体注册的服务和属性
3.1 cluster:集群容错(推荐在服务提供端设置)
dubbo
也是支持集群容错的,同时也有很多可选的方案,其中,默认的方案是 failover
,也就是重试机制。
容错机制:
Failover Cluster:失败自动切换,当出现失败,重试其它服务器。通常用于读操作,但重试会带来更长延迟。可通过retries="2"
来设置重试次数(不含第一次)。
Failfast Cluster:快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
Failsafe Cluster:失败安全,出现异常时,直接忽略。
Failback Cluster:失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
Forking Cluster:并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过forks="2"
来设置最大并行数。
Broadcast Cluster:广播调用所有提供者,逐个调用,任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
3.2 loadbalance:负载均衡(推荐在服务提供端设置)
dubbo
支持的负载均衡的一些方案及使用方法:
Random LoadBalance:随机 按权重设置随机概率。
RoundRobin LoadBalance:轮询 按公约后的权重设置轮询比率。
LeastActive LoadBalance:最少活跃调用数 相同活跃数的随机,活跃数指调用前后计数差。
ConsistentHash LoadBalance:一致性 Hash
相同参数的请求总是发到同一提供者。 当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
3.3 interface:需要注册的服务接口
3.4 ref:需要注册的服务接口的实现类
4.<dubbo:protocol>协议配置(不同的传输协议,可以提高Dubbo对服务的高效调用,可定义多个)
支持的协议有:
2.4.1dubbo: 默认协议:单一 TCP 长连接,Hessian 二进制序列化和 NIO 异步通讯,适合于小数据包大并发的服务调用和服务消费者数远大于服务提供者数的情况,不适合传送大数据包的服务。
2.4.2rmi 协议:采用 JDK 标准的 java.rmi.* 实现,采用阻塞式短连接和 JDK 标准序列化方式,如果服务接口继承了 java.rmi.Remote 接口,可以和原生 RMI 互操作,因反序列化漏洞,需升commons-collections3 到 3.2.2版本或 commons-collections4 到 4.1 版本。对传输数据包不限,消费者和传输者个数相当。
2.4.3hessian 协议:底层 Http 通讯,Servlet 暴露服务,Dubbo 缺省内嵌 Jetty 作为服务器实现可与原生 Hessian 服务互操作通讯效率高于 WebService 和 Java 自带的序列化,参数及返回值需实现 Serializable 接口,自定义实现 List、Map、Number、Date、Calendar 等接口,适用于传输数据包较大,提供者比消费者个数多,提供者压力较大。
2.4.4http 协议:基于 http 表单的远程调用协议,短连接,json 序列化,对传输数据包不限,不支持传文件,适用于同时给应用程序和浏览器 JS 使用的服务。
2.4.5webservice 协议:基于 Apache CXF 的 frontend-simple 和 transports-http 实现,短连接,SOAP文本序列化,可与原生 WebService 服务互操作,适用于系统集成、跨语言调用。
thrift 协议:对 thrift 原生协议 [2] 的扩展添加了额外的头信息,使用较少,不支持传 null 值。
2.4.6基于 Redis实现的 RPC 协议。
2.4.7基于 Memcached 实现的 RPC 协议。