Skip to content

Dubbo

Dubbo工作流程(&原理)

第一步:provider 向注册中心去注册
第二步:consumer 从注册中心订阅服务,注册中心会通知 consumer 注册好的服务
第三步:consumer 调用 provider
第四步:consumer 和 provider 都异步通知监控中心

Dubbo的10层架构

第一层:service 层,接口层,给服务提供者和消费者来实现的
第二层:config 层,配置层,主要是对 Dubbo 进行各种配置的
第三层:proxy 层,服务代理层,无论是 consumer 还是 provider,Dubbo 都会给你生成代理,代理之间进行网络通信
第四层:registry 层,服务注册层,负责服务的注册与发现
第五层:cluster 层,集群层,封装多个服务提供者的路由以及负载均衡,将多个实例组合成一个服务
第六层:monitor 层,监控层,对 rpc 接口的调用次数和调用时间进行监控
第七层:protocal 层,远程调用层,封装 rpc 调用
第八层:exchange 层,信息交换层,封装请求响应模式,同步转异步
第九层:transport 层,网络传输层,抽象 mina 和 netty 为统一接口
第十层:serialize 层,数据序列化层

注册中心挂了可以继续通信吗?

可以,因为刚开始初始化的时候,消费者会将提供者的地址等信息拉取到本地缓存,所以注册中心挂了可以继续通信。

SpringCloud和Dubbo的区别

  1. Dubbo 采用的是传输层 tcp 协议,是二进制传输的,占用带宽较少,序列化采用的是 jdk 自带的序列化协议。
  2. SpringCloud 是应用层 http 协议,占用带宽比较多,同时 springcloud 采用的是 json 报文传输,消耗会比较大。
  3. Dubbo 调用使用的是长链接,适合传输数据量小的包,而对于 springcloud 是短连接,适合传输大数据量的信息,比如图片、文本之类的。
  4. Dubbo 开发需要依赖 jar 包,对依赖的管理比较复杂。springcloud 的接口协议比较松散,约束性不强。
从其他角度的区别
  • 初始定位不同:SpringCloud定位为微服务架构下的一站式解决方案;Dubbo 是 SOA 时代的产物,它的关注点主要在于服务的调用和治理
  • 生态环境不同:SpringCloud依托于Spring平台,具备更加完善的生态体系;而Dubbo一开始只是做RPC远程调用,生态相对匮乏,现在逐渐丰富起来。
  • 调用方式:SpringCloud是采用Http协议做远程调用,接口一般是Rest风格,比较灵活;Dubbo是采用Dubbo协议,接口一般是Java的Service接口,格式固定。但调用时采用Netty的NIO方式,性能较好。
  • 组件差异比较多,例如SpringCloud注册中心一般用Eureka,而Dubbo用的是Zookeeper

开源社区里有许多优秀的 RPC 框架,还有其他的,例如Thrift、gRPC 等

Dubbo支持哪些通信协议?

  • Dubbo协议:默认的通信协议,采用单一长连接和NIO异步通信,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。
  • REST协议:基于标准的Java REST API实现REST调用。
  • Hessian协议:用于集成Hessian的服务,底层采用HTTP通讯,采用Servlet暴露服务。
  • HTTP协议:用于应用程序和浏览器JS使用的服务。
  • jsonrpc WebService协议:用于系统集成,跨语言调用。
  • RMI协议:采用JDK标准的java.rmi.*实现,采用阻塞式短连接和JDK标准序列化方式。

Dubbo支持哪些序列化协议?

  • Hessian协议:默认的序列化协议,基于Hessian进行序列化。
  • Java二进制序列化:RMI协议使用的序列化方式。
  • json序列化:HTTP协议使用的序列化方式。
  • SOAP文本序列化:WebServices协议使用的序列化方式。

为什么你们不使用Spring Cloud来做微服务

  • 直接原因是公司的技术架构是基于Dubbo来做的一整套微服务
  • 另外的原因,是公司的业务特点决定的,使用Dubbo比较快->
  • 像我之前的一家公司,是做的电商ERP系统,这家公司是基于SpringCloud来做的