文章目录
1.dubbo产生的背景
单一应用架构（ORM）–>垂直应用架构（MVC）–>分布式服务架构(RPC)–>流动计算架构（SOA）
关注点在一直变化：
- 简化增删改查工作量的数据访问框架ORM是关键
- 应用拆分，加速前端页面开发的Web框架MVC是关键
- 核心业务抽离，作为独立服务，业务复用及整合的分布式服务RPC框架是关键
- 服务越来越多，增加调度中心基于访问压力管理集群，提高机器利用率的资源调度和治理中心SOA是关键
2.dubbo可以满足的需求
- 远程服务调用（最基本的）
- 注册中心：地址维护，服务注册和上下线感知，
- 服务调用之间链路监控，
- 服务熔断限流，
- 服务负载均衡问题，
3.dubbo架构图
3.1 dubbo各节点之间调用关系
- 0.服务容器负责启动, 加载，运行服务提供者
- 1.服务提供者启动时会将服务注册到注册中心
- 2.消费者启动时从注册中心订阅服务
- 3.注册中心返回给消费者服务端的地址列表，如有变更，注册中心将基于长连接将变更数据给消费者
- 4.消费者基于负载均衡算法从注册中心返回的地址列表中选择一台提供者进行调用，如果调用失败，换另一台重试
- 5.服务消费者和服务提供者从内存中累计调用次数和调用时间，定时每分钟发送一次数据到监控中心；
3.2 dubbo各个节点角色
| 节点 | 角色说明 |
|---|---|
Provider |
暴露服务的服务提供方 |
Consumer |
调用远程服务的服务消费方 |
Registry |
服务注册与发现的注册中心 |
Monitor |
统计服务的调用次数和调用时间的监控中心 |
Container |
服务运行容器 |
3.3 dubbo架构特点
连通性：注册中心，提供者，消费者之间都是长连接
健壮性：
- 注册中心任一台宕机不影响使用，自动切换至其他机器；全部宕机，提供者和消费者可根据本地缓存继续通信；
- 提供者任一台宕机，不影响使用；全部宕机消费端无法使用可无限次重连等待提供者恢复；
- 数据库宕机，不能注册新服务
- 监控中心宕机，不影响使用，只丢失部分采样数据；
可伸缩性：
- 注册中心可以加集群，动态扩容
- 服务端可以动态扩容，注册中心会推送新的服务提供者信息给消费者
升级性
** 升级后节点角色说明**
| 节点 | 角色说明 |
|---|---|
Deployer |
自动部署服务的本地代理 |
Repository |
仓库用于存储服务应用发布包 |
Scheduler |
调度中心基于访问压力自动增减服务提供者 |
Admin |
统一管理控制台 |
Registry |
服务注册与发现的注册中心 |
Monitor |
统计服务的调用次数和调用时间的监控中心 |
4.dubbo所支持的协议：
| Feature | Maturity(成熟度) | Strength | Problem | Advise | User |
| Dubbo协议 （默认的） |
Stable | 单连接，长连接，TCP，NIO异步传输，Hessian 二进制序列化 | 在大文件传输时，单一连接会成为瓶颈 | 可用于生产环境， 适合大并发小数据量的服务调用，消费者远大于提供者的，不能传输大数据量 适用:常规远程服务方法调用 |
|
|---|---|---|---|---|---|
| Rmi协议 | Stable | 多连接，短链接，TCP，同步传输，java标准二进制序列化 | 偶尔会连接失败，需重建Stub | 可用于生产环境。适合消费者与提供者个数差不多，可传文件 适用：常规远程服务方法调用，与原生RMI服务互操作 |
|
| Hessian协议 | Stable | 多连接，短链接，HTTP，同步传输，Hessian二进制序列化 | 需hessian.jar支持，http短连接的开销大 | 可用于生产环境 入参，出参数据包较大，提供者大于消费者，提供者压力较大，可传文件 适用：页面传输，文件传输，或与原生hessian服务互操作 |
|
| http | 多连接，短链接，http, 同步传输，表单序列化 | 适用于入参出参大小混合，提供者多，消费者少，可用浏览器查看，可用表单url传参，不支持传文件 适用：需同时给应用程序和浏览器 JS 使用的服务 |
|||
| webservice | 多连接，短链接，http，同步传输，soap文本序列化 | - 适用场景：系统集成，跨语言调用 |
|||
| thrift | |||||
| memcached |
5. Dubbo核心的配置：
| 标签 | 用途 | 解释 |
|---|---|---|
<dubbo:service/> |
服务配置 | 用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心 |
<dubbo:reference/>[2] |
引用配置 | 用于创建一个远程服务代理，一个引用可以指向多个注册中心 |
<dubbo:protocol/> |
协议配置 | 用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受 |
<dubbo:application/> |
应用配置 | 用于配置当前应用信息，不管该应用是提供者还是消费者 |
<dubbo:module/> |
模块配置 | 用于配置当前模块信息，可选 |
<dubbo:registry/> |
注册中心配置 | 用于配置连接注册中心相关信息 |
<dubbo:monitor/> |
监控中心配置 | 用于配置连接监控中心相关信息，可选 |
<dubbo:provider/> |
提供方配置 | 当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值，可选 |
<dubbo:consumer/> |
消费方配置 | 当 ReferenceConfig 某属性没有配置时，采用此缺省值，可选 |
<dubbo:method/> |
方法配置 | 用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息 |
<dubbo:argument/> |
参数配置 | 用于指定方法参数配置 |
5.2 配置之间的关系：
5.3 配置优先级
方法级优先，接口级次之，全局配置再次之；
如果级别一样，则消费方优先，提供方次之；
提供者的配置会通过url经由注册中心传递给消费方；
6.服务调用时阻塞的吗？调用流程图？
默认是同步等待结果阻塞的，支持异步调用。
Dubbo 是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个 Future 对象。
7.容错机制
在集群的某些情况加，可包容范围内，允许某些错误发生。
eg:程序当前无法响应，可选择等待响应。
分布式中，链路调用，调用链路中某节点网络延迟故障，可能会导致雪崩，为减少某个节点故障的影响范围，需要构建容错服务，优雅处理终端的相应结果；
cloud的容错机制–熔断机制对该服务做熔断，提供该节点的备份服务。
7.1 dubbo提供了哪些容错机制？
- failsafe：当请求调用失败后，记录失败请求，屏蔽掉错误，定时重发。
- failover: 调用失败后会重试其他服务器 ,可设置默认次数 retries （默认情况,默认重试2次，不包含首次，即3次
- failfast: 快速失败，失败以后立马报错
- failback: 失败会自动恢复，失败后记录请求，然后重发(考虑幂等问题)
- forking: 并发请求，forks设置并行数
- broadcast：广播，任意一台报错，则是执行方法报错。
7.2 如何配置？
事务请求建议使用 failfast,failover；
配置cluster方式配置指定容错方案
8.服务降级？
降级是为了保证核心服务可用。
8.1 服务降级分类和应用场景？
降级有分类：自动降级，人工降级
人工降级：
对非核心服务进行人工降级，关闭对主流程没有影响的功能；（比如双11来临时，暂时关闭推荐，评价模块内容）
出现异常后我们做的其他处理
- 异常降级：
- 降低数据的实时性要求，提供默认数据给客户端（电商推荐信息）
- 限流降级：
- 达到最大并发数之后是继续处理还是选择丢弃
- 类似线程池的拒绝策略
- 熔断降级：
8.2 dubbo的降级方式
8.3 实现步骤？
提供了mock机制，放在客户端来处理
创建一个Mock类实现对应接口，类名必须以Mock结尾；
注解方式配置：
xml方式配置：
9.Dubbo 集群的负载均衡算法和特点?
在消费端和服务端都可以配置此算法，为什么可以配置在服务端呢？
客户端拿到注册中心返回给url列表后可以解析所有的配置，可以解析url里面配置的负载均衡算法
在调用端做负载均衡处理
配置方式：loadbalance:
- 随机-random 权重 随机 （默认）
- 最小活跃-：
- 某个服务处理的请求越高，堆积的请求较少，活跃数越低，负载数量就越高，是最均衡的算法
- 权重轮询-roundrobin
- 按A、B、C 顺序来轮询，同时根据权重调整轮询次数
- 一致性hash
- hash算法，根据请求的方法和参数生成一个hash值，客户端调用同一个方法时候会轮询到同一台机器上