浅谈Dubbox原理

Dubbox介绍

• Dubbox是一个分布式服务框架，前身是阿里旗下的开源项目Dubbo，后来阿里停止维护，当当网在Dubbo的基础上进行优化，并继续维护，为了与原来的Dubbo区分故将其改名为Dubbox，当当网在其原有的基础上实现了一些新功能REST（Representational State Transfer）风格，REST调用也是的Dubbox可以对当今特别流行的"微服务"架构提供支持。

  什么是REST风格：资源表述性状态转移，简单来说，就是统一请求响应的规范，在我们进行CRUD（增删改查）操作的时候，使用对应的HTTP请求（GET、PUT、DELETE）一般博主常用这三种GET对应查，PUT对应增和改，DELETE顾名思义删。且统一json响应格式（规范），一般来说响应格式可以大概分为元数据和返回值，元数据表示操作是否成功，操作返回值消息等，而返回值则是执行方法放回的数据。ps:可根据业务的不同规范不同的响应格式。只需要保证各个"微服务"模块之间的请求和响应遵循这个规范就是REST风格编程

• Dubbox是一个远程服务调用的分布式框架，致力于提供高性能和透明化的RPC远程服务调用方案，一级SOA的服务治理

Dubbox的特性

• 透明化远程方法调用：就像调用本地方法一样调用远程方法，只需要简单的配置，没有任何API侵入
• 软负载均衡及容错机制：可在内网替代F5等硬件负载均衡器，降低成本，减少单点
• 服务自动注册与发现：不需要写死服务提供方地址，驻车中心基于接口名查询服务提供的IP地址，并且能平滑的添加或删除服务提供者

Dubbox工作流程

节点角色说明:

• provider:暴露服务的提供方:Service
• Consumer:调用远程服务的消费方:Controller
• Registry:服务注册与发现的注册中心
  • zookeeper(Dubbox官方推荐使用)
  • redis
  • 广播机制
  • Simple
• Monitor:统计服务的调用次数和调用时间的监控中心:dubbo提供监控服务状态的web应用
• Container：服务运行的容器
  • service服务提供者：spring容器
  • controller服务消费者：SpringMvc容器

调用关系说明：

• 调用服务容器负责启动，加载，运行服务提供者
• 服务提供者在启动时，向注册中心注册自己提供的服务（接口为名称：服务地址信息）
• 服务消费者在启动时，像注册中心订阅自己所需要的服务（把接口名称取出在注册中心中查找）
• 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
• 服务消费者，从提供地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，在算另一台调用（注：这里是不经过注册中心的，而是Duboox框架）
• 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

Dubbox默认请求时间是1000ms，请求三次，如果在业务加载时间较长时可以设置请求超时时间

DDuboox的工作原理

原理图如下：dubbox底层采用Netty进行网络通信

• Dubbox底层分为10层，每层作用如下
  • service层，接口层，给服务提供者和消费者实现
  • config层，配置层，主要对Dubbo进行各种配置
  • proxy层，服务代理层，透明生成客户端的stub和服务层的skeleton
  • registry层，服务注册层，负责服务的注册与发现
  • cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
  • monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
  • protocol层，远程调用层，封装rpc调用
  • exchange层，信息交换层，封装请求响应模式，同步转异步
  • transport层，网络传输层，抽象mina和netty为统一接口
  • serialize层，数据序列化层

Dubbox支持那些通讯协议？支持那些序列化协议？

Duboox支持的通讯协议

长连接：指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。
短连接：短连接（short connnection）是相对于长连接而言的概念，指的是在数据传送过程中，只在需要发送数据时，才去建立一个连接，数据发送完成后，则断开此连接，即每次连接只完成一项业务的发送

• dubbo协议：（如dubbo://192.168.0.1:20188）,dubbo默认的协议，单一长连接，NIO异步通信，基于hessian作为序列化协议，适用于并发高，传输数据量小。

为了要支持高并发场景，一般是服务提供者就几台机器，但服务消费者有上百台，可能每天调用量就达到上亿次！此时使用长连接最合适就是跟每个服务消费者维持一个长连接，然后后面直接基于长连接NIO异步通信，可以支撑高并发请求

• rmi协议：走java二进制序列化，多个短链接，适合消费者和提供者差不多的情况下，适合用于文件传输，一般较少使用
• hessian协议：走hessian序列化协议，多个短链接，适用于提供者数量比消费者数量还多，适用与文件传输，一般较少使用
• http协议：走json序列化
• webservice协议：走soap文本序列化

Dubbo支持的序列化协议：

dubbo实际基于不同的通讯协议，支持hessian、java二进制序列化、json、SOAP文本序列化协议。hessian是其默认的序列化协议

Dubbo负载均衡策略、动态代理策略、集群容错策略

Dubbo 负载均衡策略

• random loadbalance:默认情况下，dubbo是random load balance 随机调用实现负载均衡策略，可以对provider（对外暴露的服务）不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般默认就好
• 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扩展机制配置自己的动态代理策略

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中配置
	
	将mock修改为true，然后在跟接口同一个路径下实现一个Mock类，命名规则是接口名称加Mock后缀。然后在Mock类里实现自己的降级逻辑。
*/
public class HelloServiceMock implements HelloService {

	public void sayHello() {
		// 降级逻辑
	}

}

失败重试和超时重试：
所谓失败重试就是consumer调用provider（消费方调用服务）失败了，比如抛出异常，此时是可以重试的，或者调用超时了也可以重试。Dubbox默认请求时间是1000ms，请求三次，可以通过timeout设置超时时间，以及设置retries重试次数

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

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

Dubbo如何保证服务的安全

通过令牌验证在注册中心控制权限，可以在配置文件中决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者，另外注册中心可以灵活改变授权方式，而不需修改或升级提供者

参考网址:https://dubbo.gitbooks.io/dubbo-user-book/content/preface/background.html