Dubbox介绍
1. Dubbox介绍
Dubbox是一个远程服务调用的分布式框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA的服务治理
Dubbox的特性:
- 1.透明化远程方法调用:就像调用本地方法一样调用远程方法,只需要简单配置,没有任何API侵入
- 2.软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点.
- 3.服务自动注册与发现,不需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者.
Dubbox是一个分布式服务框架前身是阿里巴巴开源项目Dubbo,后来当当网在Dubbo的基础上进行优化,并继续维护,为了与原有的Dubbo区分,故将其改名为Dubbox.Dubbox和Dubbo不同的是,为其实现了一些新的功能,包括REST(Representational State Transfer)风格,即资源表述性状态转移.
REST调用也使得Dubbox可以对当今特别流行的"微服务"架构提供基础性支持.
2. Dubbox工作流程
[外链图片转存失败(img-JFcP3DeM-1563862209554)(http://py.ppy.party:8080/pic/dubbox.png)]
节点角色说明:
-
provider:暴露服务的服务提供方： Service
-
Consumer:调用远程服务的服务消费方 : Controller
-
Registry:服务注册与发现的注册中心
-
Monitor:统计服务的调用次数和调用时间的监控中心 : dubbo提供的监控服务状态的web应用
-
Container:服务运行容器.
service服务提供者 ： Spring容器
controller服务消费者：SpringMvc容器
调用关系说明:
- 0.服务容器负责启动,加载,运行服务提供者
- 1.服务提供者在启动时,向注册中心注册自己提供的服务 （接口为名称：服务地址信息）
- 2.服务消费者在启动时,向注册中心订阅自己所需的服务 （把接口名称取注册中心中查找）
- 3.注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者
- 4.服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用(注:这里是不经过注册中心的,而是Dubbox的框架)
- 5.服务消费者和提供者,在内存中累积调用次数和调用时间,定时每分钟发送一次统计数据到监控中心
Dubbox默认请求时间是1000ms,请求三次.所以在需要较多业务加载的情况下,可以设置请求超时时间.
##3. Dubbox的工作原理
原理图如下：dubbox底层采用Netty进行网络通信
[外链图片转存失败(img-FLtDt1qM-1563862209555)(http://py.ppy.party:8080/pic/dubbo_02.png)]
说明：dubbox底层分为10层，每层作用如下
第一层：service层，接口层，给服务提供者和消费者来实现的
第二层：config层，配置层，主要是对dubbo进行各种配置的
第三层：proxy层，服务代理层，透明生成客户端的stub和服务单的skeleton
第四层：registry层，服务注册层，负责服务的注册与发现
第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
第七层：protocol层，远程调用层，封装rpc调用
第八层：exchange层，信息交换层，封装请求响应模式，同步转异步
第九层：transport层，网络传输层，抽象mina和netty为统一接口
第十层：serialize层，数据序列化层
##4. dubbox支持哪些通信协议？支持哪些序列化协议？
dubbo支持不同的通信协议:
- dubbo协议:比如(dubbo://192.168.0.1:20188).默认就是走dubbo协议的，单一长连接，NIO异步通信，基于hessian作为序列化协议
适用的场景就是：传输数据量很小（每次请求在100kb以内），但是并发量很高
为了要支持高并发场景，一般是服务提供者就几台机器，但是服务消费者有上百台，可能每天调用量达到上亿次！此时用长连接是最合适的，就是跟每个服务消费者维持一个长连接就可以，可能总共就100个连接。然后后面直接基于长连接NIO异步通信，可以支撑高并发请求。
- rmi协议:走java二进制序列化，多个短连接，适合消费者和提供者数量差不多，适用于文件的传输，一般较少用
- hessian协议:走hessian序列化协议，多个短连接，适用于提供者数量比消费者数量还多，适用于文件的传输，一般较少用
- http协议:走json序列化
- webservice协议：走SOAP文本序列化
dubbo支持的序列化协议：
dubbo实际基于不同的通信协议，支持hessian、java二进制序列化、json、SOAP文本序列化多种序列化协议。但是hessian是其默认的序列化协议
##5. dubbo负载均衡策略和集群容错策略都有哪些？动态代理策略呢？
dubbo负载均衡策略：
- random loadbalance：默认情况下，dubbo是random load balance随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。
- roundrobin loadbalance：还有roundrobin loadbalance，这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。
- leastactive loadbalance：这个就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求
- consistanthash loadbalance：一致性Hash算法，相同参数的请求一定分发到一个provider上去，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。
dubbo集群容错策略：
- failover cluster模式：失败自动切换，自动重试其他机器，默认就是这个，常见于读操作
- failfast cluster模式：一次调用失败就立即失败，常见于写操作
- failsafe cluster模式：出现异常时忽略掉，常用于不重要的接口调用，比如记录日志
- failbackc cluster模式：失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种
- forking cluster：并行调用多个provider，只要一个成功就立即返回
- broadcacst cluster：逐个调用所有的provider
dubbo动态代理策略：
- 默认使用javassist动态字节码生成，创建代理类但是可以通过spi扩展机制配置自己的动态代理策略
##6. dubbo的服务治理、降级、重试
服务降级：
比如说服务A调用服务B，结果服务B挂掉了，服务A重试几次调用服务B，还是不行，直接降级，走一个备用的逻辑，给用户返回响应
public interface HelloService {
void sayHello();
}
public class HelloServiceImpl implements HelloService {
public void sayHello() {
System.out.println("hello world......");
}
}
/*在provider中配置
<dubbo:reference id="fooService" interface="com.test.service.FooService" timeout="10000" check="false" mock="true">
将mock修改为true，然后在跟接口同一个路径下实现一个Mock类，命名规则是接口名称加Mock后缀。然后在Mock类里实现自己的降级逻辑。
*/
public class HelloServiceMock implements HelloService {
public void sayHello() {
// 降级逻辑
}
}
失败重试和超时重试:
所谓失败重试，就是consumer调用provider要是失败了，比如抛异常了，此时应该是可以重试的，或者调用超时了也可以重试。Dubbox默认请求时间是1000ms,请求三次.可以通过timeout设置超时时间，以及设置retries重试次数
面试问题：注册中心挂了可以继续通信吗？
可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信
dubbox如何保证服务的安全？
通过令牌验证在注册中心控制权限，以决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者，另外通过注册中心可灵活改变授权方式，而不需修改或升级提供者
参考网址：https://dubbo.gitbooks.io/dubbo-user-book/content/preface/background.html