微服务治理框架Dubbo入门
Dubbo 概念
Dubbo 是一款微服务开发框架,它帮助解决微服务开发中的通信问题,同时为构建企业级微服务提供服务治理能力。
从一句话定义中,我们知道 Dubbo 的角色就是微服务治理框架,解决两个问题:
- 服务间通信问题
- 服务治理,如服务注册与发现、流量管控、负载均衡、配置中心、可视化运维等
架构图
基本架构
Dubbo 从架构图上分为数据面和控制面。
-
数据面
使用 Dubbo 开发的微服务进程间基于 RPC 协议通信。
- 服务消费者 (Dubbo Consumer),发起业务调用或 RPC 通信的 Dubbo 进程
- 服务提供者 (Dubbo Provider),接收业务调用或 RPC 通信的 Dubbo 进程
-
控制面
DubboAdmin 控制面作为服务治理的抽象入口,由一系列可选的服务治理组件构成,负责 Dubbo集群的服务发现、流量管控策略、可视化监测。
链路顺序示意图
核心能力
Dubbo 为业务应用提供了微服务开发API、RPC 协议、服务治理三大核心能力,让开发者真正的专注业务逻辑开发。
特性
- RPC
- 负载均衡
- 服务注册与发现
- 高可扩展性 - 插件
- 流量调度 如灰度发布、重试降级
- 可视化运维
服务注册与发现
Dubbo 提供的是一种 Client-Based 的服务发现机制,依赖第三方注册中心组件来协调服务发现过程,支持常用的注册中心如 Nacos、Consul、Zookeeper 等。
服务发现包含提供者、消费者和注册中心三个参与角色,其中,Dubbo 提供者实例注册 URL 地址到注册中心,注册中心负责对数据进行聚合,Dubbo 消费者从注册中心读取地址列表并订阅变更,每当地址列表发生变化,注册中心将最新的列表通知到所有订阅的消费者实例。
注册中心挂了,服务消费者也可以利用本地缓存下来的提供者信息,调用服务。没有注册中心,也可以采用直连对端服务的方式。
注册中心zk Dubbo 2.x
负载均衡
客户端负载均衡,即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。
-
轮询
-
权重轮询
-
随机
-
最小活跃数(最小负载)
(某个提供者) 活跃数 = 请求发送数 - 响应返回数
-
最短响应时间
-
一致性哈希
服务降级
从服务消费者角度来说:
- 一种是 不再调用某个服务提供者,可以禁掉(干脆不调用);
- 另一种是调用,但对服务端返回失败做的一个容错处理,给定一个返回空值而非抛异常。
流量管控
路由器接收一个服务的实例地址集合作为输入,基于请求上下文 (Request Context) 和 (Router Rule) 实际的路由规则定义对输入地址进行匹配,所有匹配成功的实例组成一个地址子集,最终地址子集作为输出结果继续交给下一个路由器或者负载均衡组件处理。
路由规则同样Client-Based实现。
路由规则
- 条件路由规则
- 标签路由规则
- 脚本路由规则
- 动态配置规则
用法
当前Java 流行的微服务开发框架还是SpringBoot,整合Dubbo进来。
RPC
步骤
- 引入 dubbo-starter 依赖
- properties 配置文件 写上应用名称、注册中心信息、RPC协议信息如协议、提供端口 (服务提供者)
- 服务提供者在暴露的服务上,打上 Dubbo 提供的 @Service 注解;服务消费者 打上 @Reference 注解;(@EnableDubbo)
配置用法
配置生效优先级:方法级别优先于接口级别,再优先于应用级别;级别相同时,消费者优先于提供者
- 启动检查配置:某消费服务启动时,假设当前还没有对应的服务提供者,默认会启动失败。可以配置启动时不检查
- RPC 超时时间配置
- RPC 重试次数配置
- 灰度发布,接口版本配置
- 等等…
负载均衡
服务端和消费端都可以配置参数
降级
Hystrix 组件 (Spring Cloud 同样使用),fallbackMethod 降级的容错方法
原理
RPC通信框架
Dubbo 的底层通信是利用 Netty 来实现的,Netty 采用事件驱动模型,其IO模型 (IO多路复用+非阻塞IO) 和 线程模型 (支持单Reactor线程、主从Reactor + Worker线程池 等方式)。
- 服务提供者 建立 Netty Server
- 服务消费者 建立 Netty Client
同时两者都有和注册中心建立连接,注册与订阅服务的变化
调用链路细节图
Dubbo 2.x 调用链路图,有助于理解