技术栈 | 传送门 |
JAVA 基础 | 手撸架构,Java基础面试100问_vincent-CSDN博客 |
JAVA 集合 | 手撸架构,JAVA集合面试60问_vincent-CSDN博客 |
JVM 虚拟机 | 手撸架构,JVM面试30问_vincent-CSDN博客 |
并发编程 | 手撸架构,并发编程面试123问_vincent-CSDN博客 |
Spring | 手撸架构,Spring面试63问_vincent-CSDN博客 |
Spring cloud | 手撸架构,Spring cloud面试45问_vincent-CSDN博客 |
SpringBoot | 手撸面试,Spring Boot面试41问_vincent-CSDN博客 |
Netty 与 RPC | 手撸架构,Netty 与 RPC面试48问_vincent-CSDN博客 |
Doubo | 手撸架构,Dubbo面试49问_vincent-CSDN博客 |
Redis | 手撸架构,Redis面试41问_vincent-CSDN博客 |
Zookeeper | 手撸架构,Zookeeper面试27问_vincent-CSDN博客 |
Mysql | 手撸架构,Mysql 面试126问_vincent-CSDN博客 |
MyBatis | 手撸架构,MyBatis面试42问_vincent-CSDN博客 |
MongoDB | 手撸架构,MongDB 面试50问_vincent-CSDN博客 |
Elasticsearch | 手撸架构,Elasticsearch 面试25问_vincent-CSDN博客 |
RabbitMQ | 手撸架构,RabbitMQ 面试49问_vincent-CSDN博客 |
Kafka | 手撸架构,Kafka 面试42问_vincent-CSDN博客 |
Docker | 手撸架构,Docker 面试25问_vincent-CSDN博客 |
Nginx | 手撸架构,Nginx 面试40问_vincent-CSDN博客 |
算法 | 常用排序算法总结(1)-- 比较排序_vincent-CSDN博客_比较排序 常用排序算法总结(2)-- 非比较排序算法_vincent-CSDN博客_非比较排序的算法有 |
分布式事务 | 分布式事务解决方案(总览)_vincent-CSDN博客 |
HTTP | 太厉害了,终于有人能把TCP/IP 协议讲的明明白白了_vincent-CSDN博客_tcp和ip |
Dubo是阿里巴巴开源的基于Java的高性能RPC分布式服务框架,现已成为 Apache基金会孵
化项目。官网:http://dubbo.apacheorg
因为是阿里开源项目,国内很多互联网公司都在用,已经经过很多线上考验。内部使用了 Netty、
Zookeeper,保证了高性能高可用性。
使用 Dubbo可以将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,可用于提高业务复用灵活扩展,使前端应用能更快速的响应多变的市场需求
下面这张图可以很清楚的诠释,最重要的一点是,分布式架构可以承受更大规模的并发流量
Dubbo 框架设计一共划分了 10 个层:
通信方式不同
1、Dubo使用的是RPC通信,而 Spring cloud使用的是 Http Resteu方式。
2、Dubbo由于是二进制的传输,占用带宽会更少(基于netty等),springCloud是http协议传输,带宽会比较多,同时使用htt协议(http+restfulapi一般会使用JsON报文,消耗会更大)
3、dubo的开发难度较大,原因是 dubbo的jar包依赖(存在代码级别的强依赖)问题很
多大型工程无法解决,springcloud的接口协议约定比较自由且松散,需要有强有力的行政措施来限制接口无序升级
4、dubo的改进是通过 dubbofilter,很多东西没有,需要自己继承,如监控,如日志,如
限流,如追踪,springcloud具有配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性 token、全局锁、选主、分布式会话和集群状态等,满足了构建微服务所需的所有解决方案。
组成部分不同
适用范围:传入传出参数数据包较小(建议小于 100K),消费者比提供者个数多,单一消费者无法压满提供者,尽量不要用 dubbo 协议传输大文件或超大字符串。
适用场景:常规远程服务方法调用
dubbo 协议补充:
连接个数:单连接
连接方式:长连接
传输协议:TCP
传输方式:NIO 异步传输
序列化:Hessian 二进制序列化
采用 JDK 标准的 java.rmi.*实现,采用阻塞式短连接和 JDK 标准序列
化方式,Java 标准的远程调用协议。
连接个数:多连接
连接方式:短连接
传输协议:TCP
传输方式:同步传输
序列化:Java 标准二进制序列化
适用范围:传入传出参数数据包大小混合,消费者与提供者个数差不多,可传文件。
适用场景:常规远程服务方法调用,与原生 RMI 服务互操作
Hessian 协议用于集成 Hessian 的服务,Hessian 底层采用 Http 通讯,采用
Servlet 暴露服务,Dubbo 缺省内嵌 Jetty 作为服务器实现基于 Hessian 的远程调用协议。
连接个数:多连接
连接方式:短连接
传输协议:HTTP
传输方式:同步传输
序列化:Hessian 二进制序列化
适用范围:传入传出参数数据包较大,提供者比消费者个数多,提供者压力较大,可传文件。
适用场景:页面传输,文件传输,或与原生 hessian 服务互操作
采用 Spring 的 HttpInvoker 实现基于 http 表单的远程调用协议。
连接个数:多连接
连接方式:短连接
传输协议:HTTP
传输方式:同步传输
序列化:表单序列化(JSON)
适用范围:传入传出参数数据包大小混合,提供者比消费者个数多,可用浏览器查看,可用表单或 URL 传入参数,暂不支持传文件。
适用场景:需同时给应用程序和浏览器 JS 使用的服务。
基于 CXF 的 frontend-simple 和 transports-http 实现,基于 WebService 的远程调用协议。
连接个数:多连接
连接方式:短连接
传输协议:HTTP
传输方式:同步传输
序列化:SOAP 文本序列化
适用场景:系统集成,跨语言调用。
Thrift 是 Facebook 捐给 Apache 的一个 RPC 框架,当前 dubbo 支持的 thrift
协议是对 thrift 原生协议的扩展,在原生协议的基础上添加了一些额外的头信
息,比如 service name,magic number 等
基于 memcached 实现的 RPC 协议
基于 redis 实现的 RPC 协议
不需要,如果硬要用web容器,只会增加复杂性,也浪费资源
Dubbo的服务容器只是一个简单的Main方法,并加载一个简单的 Spring容器,用于暴露
服务。
推荐使用 Zookeeper作为注册中心,还有 Redis、 Multicast、 Simple注册中心,但不推荐。
Redis方案需要服务器时间同步,且性能消耗过大
标签 | 用途 | 解释 |
---|---|---|
|
服务配置 | 用于暴露一个服务,定义服务的元信息,一个服务可以用多个协议暴露,一个服务也可以注册到多个注册中心 |
|
引用配置 | 用于创建一个远程服务代理,一个引用可以指向多个注册中心 |
|
协议配置 | 用于配置提供服务的协议信息,协议由提供方指定,消费方被动接受 |
|
应用配置 | 用于配置当前应用信息,不管该应用是提供者还是消费者 |
|
模块配置 | 用于配置当前模块信息,可选 |
|
注册中心配置 | 用于配置连接注册中心相关信息 |
|
监控中心配置 | 用于配置连接监控中心相关信息,可选 |
|
提供方配置 | 当 ProtocolConfig 和 ServiceConfig 某属性没有配置时,采用此缺省值,可选 |
|
消费方配置 | 当 ReferenceConfig 某属性没有配置时,采用此缺省值,可选 |
|
方法配置 | 用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息 |
|
参数配置 | 用于指定方法参数配置 |
配置关系如下:
Dubbo缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止 Spring初始化完成,默认 check=“true“,可以通过 check=“ false“关闭检查。
推荐使用 Hessian序列化,还有 Duddo、 FastJjson、Java自带序列化。
Dubo默认使用Netty框架,也是推荐的选择,另外内容还集成有Mina、 Grizzly
可以配置环境点对点直连,绕过注册中心,将以服务接口为单位,忽略注册中心的提供者列表
在开发及测试环境下,经常需要绕过注册中心,只测试指定服务提供者,这时候可能需要点对点直连,点对点直联方式,将以服务接口为单位,忽略注册中心的提供者列表,服务注册中心,动态的注册和发现服务,使服务的位置透明,并通过在消费方获取服务提供方地址列表,实现软负载均衡和 Failover, 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互,注册中心不转发请求,服务消费者向注册中心获取服务提供者地址列表,并根据负载算法直接调用提供者,注册中心,服务提供者,服务消费者三者之间均为长连接,监控中心除外,注册中心通过长连接感知服务提供者的存在,服务提供者宕机,注册中心将立即推送事件通知消费者。
注册中心和监控中心全部宕机,不影响已运行的提供者和消费者,消费者在本地缓存了提供者列表。
注册中心和监控中心都是可选的,服务消费者可以直连服务提供者。
Dubbo允许配置多协议,在不同服务上支持不同协议或者同一服务上同时支持多种协议。
当一个接口有多种实现时,可以用 group属性来分组,服务提供方和消费方都指定同一个 group即可。
可以用版本号( version)过渡,多个不同版本的服务注册到注册中心,版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。
可以, Dubbo提供了声明式缓存,用于加速热门数据的访问速度,以减少用户加缓存的工作量。
默认是同步等待结果阻塞的,支持异步调用。
Dubbo是基于NO的非阻塞实现并行调用,客户端丕需要启动多线程即可完成并行调用多个远程服务,相对多线程开销较小,异步调用会返回一个 Future对象。
异步调用流程图如下
目前暂时不支持,后续可能采用基于JTA/XA规范实现,或者TCC等方式、
具体参考:分布式事务解决方案(总览)_vincent-CSDN博客
dubo通过 telnet命令来进行服务治理,具体使用看这篇文章《dubo服务调试管理实用命令》。
telnet local host 8090
Dubbo2.2.0以上版本支持。
Dubbo是通过JDK的 Shutdown hook来完成优雅停机的,所以如果使用kill -9 PID等强制关闭指令,是不会执行优雅停机的,只有通过kill PID时,才会执行。
服务失效踢岀基于 Zookeeper的临时节点原理。(服务机器会在k上注册一个临时节点,服务失效则临时节点被删除)
Dubo可以使用 Pinpoint和 Apache Skywalking( Incubator)实现分布式服务追踪,当然还有其他很多方案。
读操作建议使用 Failove失败自动切换,默认重试两次其他服务器。
写操作建议使用 Failfast快速失败,发一次调用失败就立即报错。
Dubbo必须依赖JDK,其他为可选。
管理控制台主要包含:路由规则,动态配置,服务降级,访问控制,权重调整,负载均衡,等管理功能
Dubbo会在 Spring实例化完bean之后,在刷新容器最后一步发布 Context RefreshEvent事件的时候,通知实现了ApplicationListener的 ServiceBean类进行回调 onApplication Event事件方法,Dubbo会在这个方法中调用 ServiceBean父类 ServiceConfig的 export方法,而该方法真正实现了服务的(异步或者非异步)发布。
2014年开始停止维护过几年,17年开始重新维护,并进入了 Apache项目
Dubbox是继 Dubbo停止维护后,当当网基于Dubo做的一个扩展项目,如加了服务可 Restful调用,更新了开源组件等。
别的还有 Spring cloud、 Facebook的 Thrift、 Twitter的 Finagle等。
可以的,项目地址如下。
单一长连接和NIO异步通讯,适合大并发小数据量的服务调用,以及消费者远大于提供者。 Dubbo的设计目的是为了满足高并发小数据量的rpc调用,在大数据量下的性能表现并不好,建议使用rmi或http协议
因 dubbo 协议采用单一长连接,假设网络为千兆网卡(1024Mbit=128MByte),根据测试经验数据每条连接最多只能压满 7MByte(不同的环境可能不一样,供参考),理论上 1 个服务提供者需要 20个服务消费者才能压满网卡。
因 dubbo 协议采用单一长连接,如果每次请求的数据包大小为 500KByte,假设网络为千兆网卡(1024Mbit=128MByte),每条连接最大 7MByte(不同的环境可能不一样,供参考),
单个服务提供者的 TPS(每秒处理事务数)最大为:128MByte / 500KByte = 262。
单个消费者调用单个服务提供者的 TPS(每秒处理事务数)最大为:7MByte / 500KByte = 14。
如果能接受,可以考虑使用,否则网络将成为瓶颈。
http://songwie.com/attached/dubbo/dubbo2.0.pdf
扩展性的问题,没有好坏,只有适合不适合,不过我好像更倾向于使用Dubbo, Spring Cloud版本升级太快,组件更新替换太频繁,配置太繁琐.... (公司需要什么架构就夸什么)
Dubbo 通过 Token 令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo 还提供服务黑白名单,来控制服务所允许的调用方。