dubbo源码v2.7分析:结构、container入口及线程模型

简介: Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架,提供了六大核心能力:面向接口代理的高性能RPC调用,智能容错和负载均衡,服务自动注册和发现,高度可扩展能力,运行期流量调度,可视化的服务治理与运维。

系列文章:

RPC 框架 -dubbo:架构及源码分析 - 初篇

一 概述

   Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架,提供了六大核心能力:面向接口代理的高性能RPC调用,智能容错和负载均衡,服务自动注册和发现,高度可扩展能力,运行期流量调度,可视化的服务治理与运维。

1.1 微服务框架-dubbo vs SpringCloud

   在微服务框架选择上,通常都会讨论dubbo 和 springcloud。当然,大家应该也知道这两个并不完全是竞争关系,因为严格来说,二者并非同一个层面的东西,dubbo是RPC框架。

1.2 RPC与HTTP

RPC 是远端过程调用,其调用协议通常包含传输协议和编码协议。HTTP 严格来说跟 RPC 不是一个层级的概念,HTTP 本身也可以作为 RPC 的传输层协议

传输协议包含: 如著名的 gRPC 使用的 HTTP 2.0 协议,也有如 Dubbo 一类的自定义报文的 TCP 协议。编码协议包含: 如基于文本编码的 XML Json,也有二进制编码的 ProtoBuf Binpack 等。

所谓的效率优势是针对 HTTP 1.1 协议来讲的,HTTP 2.0 协议已经优化编码效率问题,像 gRPC 这种 RPC 库使用的就是 HTTP 2.0 协议。

在跨语言调用的时候,REST 风格直接把 HTTP 作为应用协议(直接和服务打交道),不同语言之间调用比较方便。

RPC 可以把 HTTP 作为一种传输协议(比如 gRPC 使用 HTTP 2.0 协议传输),本身还会封装一层 RPC 框架的应用层协议,不同语言之间调用需要依赖 RPC 协议(需要跨语言 RPC 库实现,比如 Thrift)。

1.3 开篇

   本章将开始介绍dubbo源码,通过学习源码深入了解dubbo的运行机制,也以此深入了解rpc框架的组成、应用和潜在问题及解决方案。

二 负载均衡策略

2.1 四种策略

根据官方文档中对负载均衡的描述,在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为 random 随机调用。另外开发者也可以自行扩展负载均衡策略,参见:负载均衡扩展

默认支持以下四种:

Random LoadBalance:

  • 随机,按权重设置随机概率。
  • 在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。

RoundRobin LoadBalance:

  • 轮询,按公约后的权重设置轮询比率。
  • 存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。

LeastActive LoadBalance:

  • 最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
  • 使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance:

  • 一致性 Hash,相同参数的请求总是发到同一提供者。
  • 当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
  • 算法参见:http://en.wikipedia.org/wiki/Consistent_hashing
  • 缺省只对第一个参数 Hash,如果要修改,请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
  • 缺省用 160 份虚拟节点,如果要修改,请配置 <dubbo:parameter key="hash.nodes" value="320" />

2.2 源码

在org.apache.dubbo.rpc.cluster.loadbalance包下,包内包含了抽象类AbstractLoadBalance,继承自LoadBalance接口。

LoadBalance接口通过SPI机制提供扩展。接口中只有一个方法,就是select,用于选择一个合适的服务来提供功能:

@SPI(RandomLoadBalance.NAME)
public interface LoadBalance {
    /**
     * select one invoker in list.
     *
     * @param invokers   invokers.
     * @param url        refer url
     * @param invocation invocation.
     * @return selected invoker.
     */
    @Adaptive("loadbalance")
    <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;
}

ConsistentHashLoadBalance,LeastActiveLoadBalance,RandomLoadBalance,RoundRobinLoadBalance这四个类就是2.1中四种策略的实现。

可见select方法的参数有三个:

1、List<Invoker<T>> invokers

2、URL url

3、Invocation invocation

其中Invoker就是dubbo的核心模型,代表一个可执行体,可向它发起invoke调用。在服务提供方,Invoker用于调用服务提供类。在服务消费方,Invoker用于执行远程调用

三 线程模型

3.1 场景

   如果事件处理的逻辑能迅速完成,并且不会发起新的 IO 请求,比如只是在内存中记个标识,则直接在 IO 线程上处理更快,因为减少了线程池调度。

   但如果事件处理逻辑较慢,或者需要发起新的 IO 请求,比如需要查询数据库,则必须派发到线程池,否则 IO 线程阻塞,将导致不能接收其它请求。

   如果用 IO 线程处理事件,又在事件处理过程中发起新的 IO 请求,比如在连接事件中发起登录请求,会报“可能引发死锁”异常,但不会真死锁。

因此,需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景:

<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />

3.2 Dispatcher

  • all 所有消息都派发到线程池,包括请求,响应,连接事件,断开事件,心跳等。
  • direct 所有消息都不派发到线程池,全部在 IO 线程上直接执行。
  • message 只有请求响应消息派发到线程池,其它连接断开事件,心跳等消息,直接在 IO 线程上执行。
  • execution 只有请求消息派发到线程池,不含响应,响应和其它连接断开事件,心跳等消息,直接在 IO 线程上执行。
  • connection 在 IO 线程上,将连接断开事件放入队列,有序逐个执行,其它消息派发到线程池。

3.3 ThreadPool

  • fixed 固定大小线程池,启动时建立线程,不关闭,一直持有。(缺省)
  • cached 缓存线程池,空闲一分钟自动删除,需要时重建。
  • limited 可伸缩线程池,但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
  • eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时,优先创建Worker来处理任务。当任务数量大于maximumPoolSize时,将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)
相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
2天前
|
存储 安全 Java
Qt线程池+生产者消费者模型
Qt线程池+生产者消费者模型
23 5
|
3天前
|
NoSQL 网络协议 关系型数据库
redis-学习笔记(redis 单线程模型)
redis-学习笔记(redis 单线程模型)
14 3
|
4天前
|
Linux 调度 Windows
【操作系统】线程、多线程模型
【操作系统】线程、多线程模型
14 1
|
4天前
|
NoSQL 关系型数据库 MySQL
Redis -- 单线程模型
Redis -- 单线程模型
22 1
|
5天前
|
设计模式 安全 Java
【Linux 系统】多线程(生产者消费者模型、线程池、STL+智能指针与线程安全、读者写者问题)-- 详解
【Linux 系统】多线程(生产者消费者模型、线程池、STL+智能指针与线程安全、读者写者问题)-- 详解
|
13天前
|
安全 API 数据库
【转】Android线程模型(AsyncTask的使用)
【转】Android线程模型(AsyncTask的使用)
15 1
|
13天前
|
消息中间件 存储 网络协议
Kafka 线程模型痛点攻克: 提升分区写入 2 倍性能
Apache Kafka的单分区写入性能在某些严格保序场景中至关重要,但其现有线程模型限制了性能发挥。本文分析了Kafka的串行处理模型,包括SocketServer、KafkaChannel、RequestChannel等组件,指出其通过KafkaChannel状态机确保请求顺序处理,导致处理效率低下。AutoMQ提出流水线处理模型,简化KafkaChannel状态机,实现网络解析、校验定序和持久化的阶段间并行化,提高处理效率。测试结果显示,AutoMQ的极限吞吐是Kafka的2倍,P99延迟降低至11ms。
26 3
Kafka 线程模型痛点攻克: 提升分区写入 2 倍性能
|
13天前
|
存储 NoSQL Redis
深入浅出Redis(二):Redis单线程模型与通信流程
深入浅出Redis(二):Redis单线程模型与通信流程
|
13天前
|
Java
【Java多线程】分析线程加锁导致的死锁问题以及解决方案
【Java多线程】分析线程加锁导致的死锁问题以及解决方案
28 1
|
13天前
|
NoSQL Redis
Redis 线程模型
Redis 线程模型