程序员小潘

记录一次 Dubbo 线上故障排查和原因分析。线上 Dubbo 消费者启动有错误日志如下，但是不影响服务启动。消费者尝试重启，RPC 调用偶尔成功，偶尔失败，没有规律。

Apache Dubbo 3.3 对 Triple 协议做了升级，现在 Dubbo 不仅可以处理东西向流量，也可以处理南北向流量。**东西向流量（East-West Traffic） **指数据中心或网络内部同级设备/服务之间的通信。例如，微服务之间的内部调用。指网络外部用户与内部服务之间的通信。例如，客户端访问微服务。之前的 Dubbo 一般只用来处理服务内部的高性能RPC调用，外部用户要想访问 Dubbo 服务，只能再额外部署一个网关层，网关负责把 HTTP 协议转换成 dubbo 协议。

Dubbo3 发布了基于 HTTP1、HTTP2、HTTP3 的 triple 通信协议，相较于之前的 dubbo 私有化协议，triple 协议在跨语言、云原生、服务治理方面有显著优势。为了方便用户平滑迁移到 triple 协议，Dubbo3 新增了一项能力，，做到协议迁移几乎没有额外负担。

本文分析了Dubbo框架中序列化机制的安全性问题，重点探讨如何防范反序列化导致的RCE攻击。文章首先展示了通过Hessian2反序列化危险HashMap子类导致JVM退出的攻击实例，说明序列化漏洞的严重性。随后介绍了Dubbo 3.1.6版本引入的类检查机制，包括DISABLE、WARN和STRICT三种安全等级，以及通过allowlist/blockedlist配置信任类。文章还详细说明了自动信任机制的实现原理，该机制会智能地将Service相关的类加入白名单，既保证安全又简化配置。最后通过源码分析揭示了

随着越来越多的应用逐渐微服务化后，分布式服务之间的RPC调用使得异常排查的难度骤增，最明显的一个问题，就是整个调用链路的日志不在一台机器上，往往定位问题就要花费大量时间。如何在一个分布式网络中把单次请求的整个调用日志给串起来，变得刻不容缓。

Dubbo 的 Telnet 特性允许开发者通过 Telnet 客户端直接连接到 Dubbo 服务提供者，执行一系列命令以获取服务状态、调试信息和进行服务管理。这种特性在开发和运维过程中非常有用，尤其是在需要快速定位问题或查看服务状态时。本文介绍 Telnet 中最为常用的 trace 命令，它可以追踪服务提供者的某个服务的某个方法，把服务调用的入参出参以及执行耗时输出到 Telnet 客户端。

然后是定义grpc的 Service 和消息格式DispatcherService.proto 请求分发服务的定义RequestData.proto 请求消息的定义，主要是对 Invocation 的描述ResponseData.proto 响应消息的定义，主要是对 AppResponse 的描述使用插件把 proto 文件生成对应的 Java 类。

Dubbo 框架采用分层设计，自上而下共分为十层。最底下的 Serialize 层关心的是如何序列化对象、往上的 Transporte 层关心的是如何把数据传输到远程、再往上的 Exchange 层关心的则是如何实现 请求-应答 消息交换模式、再往上就是 Protocol 层，它关心的是如何封装 RPC 调用，屏蔽底层细节。

Dubbo Exchanger 也可以基于 SPI 一键替换，我们实现一个自定义的 Exchanger，加深理解。首先，我们新建一个模块，并引入依赖：

新建一个模块用来封装我们自己的传输层实现。因为要写的是 Dubbo 传输层的一个实现策略，所以要依赖

Dubbo 框架采用分层设计，最底下的 Serialize 层负责把对象序列化为字节序列，再经过 Transport 层网络传输到对端。一次 RPC 调用，在 Dubbo 看来其实就是一段请求报文和一段响应报文的传输过程。

Serialization 被设计成 SPI 接口，所以它可以很轻松的被替换。接下来，我们就基于 Fastjson2 写一个序列化模块，替换掉默认的 hessian2，让你对整个序列化过程理解的更加清楚。首先，我们新建一个模块。因为我们要依赖 Dubbo 提供的接口去实现一套新的序列化组件，所以自然要引入模块。又因为我们是基于 fastjson2 实现的，所以也得引入 fastjson2 的依赖。

Dubbo 框架的 RPC 调用除了可以传递正常的接口参数外，还支持隐式参数传递。隐式参数的传递依赖 RpcContext 对象，它持有一个 Map 对象，消费者往 Map 里写入数据，客户端在发起 RPC 调用前会构建 RpcInvocation，然后把 RpcContext 里的 Map 数据拷贝到 RpcInvocation 的 attachments 属性，最后客户端把 RpcInvocation 序列化后再传输给服务端。隐式参数传递的一个典型的应用场景：分布式链路追踪。

Dubbo3 已经从一开始的 RPC 框架改头换面，现在的定位是微服务框架，除了提供基本的 RPC 功能外，它还提供了一整套的服务治理方案。。Dubbo3 专门提供了一个模块来和 Spring Boot 做整合，模块名是一般我们直接引入即可开启 Dubbo 的自动装配，在 Spring Boot 项目里使用 Dubbo。</</</</所以我们以这个模块为切入点，看看 Dubbo 做了什么。

Dubbo 在 2.7 之前的版本只配备了注册中心，主流使用的注册中心为 zookeeper。后来 2.7 版本官方进行了三大中心的改造，分别是：注册中心、元数据中心、配置中心。元数据定义为描述数据的数据，在服务治理中，例如服务接口名，重试次数，版本号等等都可以理解为元数据。。Dubbo 2.7 进行了大刀阔斧的改动，只将真正属于服务治理的数据发布到注册中心之中，大大降低了注册中心的压力；同时，将全量的元数据发布到另外的元数据中心；配置中心主要是外部化配置的集中存储。

Dubbo3 推出的 Triple 协议开始支持 Streaming 流式通信，流式通信适用于大文件、大数据传输、直播流推送等场景。Stream 分为三种类型：客户端流、服务端流、双向流。由于 Java 语言的限制，客户端流和双向流实现方案是一样的。

Triple 是 Dubbo3 主推的新协议，基于 HTTP2 ，完全兼容 gRPC，旨在解决 Dubbo2 私有协议带来的互通性问题。本文分析一下 Triple 协议客户端调用源码，加深协议的理解。

在 RPC 调用中，消息的打包和解包是实现数据的传输和交互的关键步骤之一。当客户端发起一次 RPC 调用时，客户端需要将调用的相关参数打包成一个消息，然后将消息发送给服务端。服务端接收到消息后，需要对消息进行解包，提取出参数进行处理，最后将处理结果打包成响应消息发送回客户端。消息打包是将调用参数和其他相关信息组装成一个字节序列的过程，即序列化。消息解包是将接收到的字节流还原为原始的调用参数和相关信息的过程，即反序列化。

Dubbo3 提供了一个挺有意思的 Executor，用来将提交到线程池里的任务按顺序串行执行。需求背景：你有一个线程池，但是你不想修改它，现在你的需求是要把提交上去的任务按顺序串行执行。在这样一个需求背景下，SerializingExecutor 诞生了。SerializingExecutor 在 Dubbo3 的应用场景是：针对 HTTP2 上的 Stream 接收到的 Frame 要按顺序处理。

Dubbo3 推出了下一代RPC通信协议——Triple，译为第三代的。Triple 完全兼容 gRPC 协议，运行在 HTTP2 协议之上。Dubbo 框架提供了 Triple 协议的多种语言实现，可以帮助你构建浏览器、gRPC 兼容的 HTTP API 接口。已经有了 dubbo 协议，为啥还要推出 Triple 协议？？？Triple 协议的推出，旨在解决 Dubbo2 私有协议带来的互通性问题。Triple 协议就是要解决这些问题的。

Dubbo3开始支持在单个端口上监听多个协议的不同服务。比如使用Triple协议启动端口复用后，可以在相同的端口上为服务增加 Dubbo协议支持，以及Qos协议支持。这些协议的识别都是由一个统一的端口复用服务器进行处理的，可以用于服务的协议迁移，并且可以节约端口以及相关的资源，减少运维的复杂性。

1. 前言前面的文章已经分析了，Dubbo在做集群调用时，Directory会先根据Router做路由规则过滤，最后幸存下来的Invoker才会对它们做负载均衡。​LoadBalance是Dubbo提供的负载均衡接口，截止2.7.8版本，Dubbo内置了五种负载均衡策略。LoadBalance也是可以通过SPI加载的，开发者可以很方便的扩展自定义的负载均衡策略。2. 源码分析LoadBalance接口定义十分简单，它只有一个功能，从一组Invoke里选出一个最终等待被调用的Invoker。@SP

1. 前言前面的文章分析了Dubbo集群容错层之Cluster和ClusterInvoker，我们已经知道，Directory会提供可调用的服务列表，Cluster会将这一组服务聚合成单个具备集群容错能力的ClusterInvoker，上层服务还是对ClusterInvoker发起invoke调用，透明的实现了集群容错。本文重点分析下Directory接口，Dubbo目前提供了两种实现，分别是基于注册中心的RegistryDirectory，和静态服务StaticDirectory。可以这么说，Dubb

1. 前言线上服务很少会单机部署，它不满足互联网三高架构的需求。服务一旦挂了，高可用就无从谈起，另外Dubbo单机默认最大200的并发处理也不满足所谓的高并发、高性能。所以，作为一款优秀的分布式服务框架，Dubbo是支持集群容错的。​Dubbo整个集群容错层的实现在dubbo-cluster模块，它包含很多组件，例如：Cluster、ClusterInvoker、Directory、LoadBalance等等，本文主要分析Cluster以及ClusterInvoker，其它组件会在后面的文章讨论。2

1. 前言之前的文章分析了Provider线程模型，本文开始分析客户端Consumer的线程模型，其实两者还是有很多相似之处的。​Consumer同样有IO线程和业务线程两类，IO线程负责和服务端建立连接和IO数据读写，业务线程主要处理Body反序列化，应该还包括服务端回调客户端的逻辑。相比于服务端，其实客户端的业务线程做的事很少，主要是解析响应结果。​Consumer在创建NettyClient时，也会对ChannelHandler进行包装，其中就包括具有线程派发能力的ChannelHandle

1. 前言前面的文章分析了Dubbo Provider是如何处理RPC调用请求的，整个处理链路是清晰了，但是关于线程模型却一笔带过，Dispatcher也只是简单介绍了一下，本篇文章会全面分析Provider线程模型。​Dubbo线程可以分为两大类，一类是用于处理底层网络通信的IO线程，一类是处理业务逻辑的业务线程，也可称作Dubbo线程。IO线程以Netty为例，又细分为Boss和Worker，Boss专门用于处理IO连接，Worker用于处理IO读写。​本文会从NettyServer的创建开始

1. 前言前面的文章分析了Consumer是如何发起RPC调用，以及请求对象Request是如何从客户端编码然后经过网络发送到服务端，服务端再解码的一个过程，接下来，开始分析服务端Provider是如何处理RPC调用请求的。​本文会从两个纬度去分析，首先是ChannelHandler，既然是处理网络请求，那么必然要处理网络IO事件，Provider从接收到字节序列的那一刻起，是如何将它们一步一步转化为Request对象并进行处理的。然后是Invoker，得到Request对象后Provider是如何执

1. 前言前面分析了Consumer是如何发起远程服务调用的，最终DubboInvoker会利用ExchangeClient客户端发送网络请求。Dubbo会将网络请求封装为Request对象发送，但是网络传输的总是字节序列，Request对象必须经过编码才能被发送。同理，服务端在接收到客户端的请求后，也必须先解码才能得到Request对象，Response亦是如此。​Dubbo网络通讯协议分为两部分，分别是Header和Body，Header部分采用Codec编解码，Body部分使用序列化。本篇文章会

1. 前言之前的文章对Dubbo服务暴露和引用流程进行了分析，再然后了解了Dubbo网络通讯协议的设计细节，现在终于到了最激动人心的时刻，我们将分析Dubbo是如何实现服务调用的。篇幅原因，文章会拆分成两篇，本篇从Consumer的视角，分析服务的调用过程和对响应结果的处理，下一篇会从Provider的视角分析Dubbo是如何处理RPC请求并响应结果的。这是官方文档给的图，从中就可以看出大概的处理流程。代理对象通过客户端发送网络请求，请求/响应对象会经过Codec编解码、序列化发送到对端，对端接收到数

1. 前言前面已经分析了Dubbo是如何暴露以及引用远程服务的，接下来自然是服务调用的实现细节了，但是在那之前，有必要先了解Dubbo的网络通信协议。​在单机系统中，调用本地方法获取结果很简单，因为同一个进程里内存是共享的。但是在分布式系统中，远程方法调用就显得较为复杂，必须通过网络将内存中的数据传输给对方，数据以何种格式传输呢？这就需要双方约定一个协议。2. 通讯协议细节这是Dubbo官方文档给的图，可以看出协议主要分为两块：16字节定长的Header、变长的Body。2.1 协议头和协议体

1. 前言DubboBootstrap启动时，首先会通过initialize()方法完成初始化，装配各种Config对象，为后续的服务暴露和引用准备好环境。ReferenceConfig是Dubbo对服务引用的描述类，它记录了需要引用的服务的协议、版本、服务名称、服务地址等信息，get()方法可以获取接口对象，接口是不能实例化的，这个对象其实是Dubbo创建的代理对象，Dubbo会在生成的代理对象中帮我们处理RPC调用、集群容错、负载均衡等复杂的逻辑。​DubboBootstrap初始化结束后，会调

1. 前言DubboBootstrap启动时，首先会通过initialize()方法完成初始化，装配各种Config对象，为后续的服务暴露和引用准备好环境。​ServiceConfig对象就是Dubbo对服务的描述对象，服务暴露的逻辑都在ServiceConfig#export()里面，Dubbo暴露服务也就是遍历所有的ServiceConfig，挨个进行暴露。上图是官方文档给的图，在Dubbo的架构体系中，像集群容错、负载均衡等逻辑都是客户端实现的，所以服务暴露的过程相对会简单很多。Servic

1. 前言Dubbo一般很少单独使用，更多的是和Spring框架做集成，但是不管怎样，Dubbo最终都是创建并启动DubboBootstrap。Dubbo系列文章只研究Dubbo，因此不会和Spring扯上任何关系。DubboBootstrap被设计成单例的，通过双重检查加锁的方式，这意味着在一个JVM进程内只能启动一个实例（不准确）。​从名字也可以看的出来，DubboBootstrap只是一个启动引导类，它本身并没有实现什么业务逻辑。它依赖于其他组件类，将它们进行装配，彼此协同工作。例如：Conf

1. 前言Dubbo服务框架采用了「微内核+插件」的设计原则，Dubbo自身的核心功能点也是通过扩展点实现的，这意味着Dubbo几乎所有的功能点都可以由用户自定义的扩展和替换，这也大大的提高了Dubbo框架本身的高度可扩展性。举例来说，如果你觉得Dubbo内置的对象序列化方式不好用，你完全可以自定义一个；如果你觉得Netty网络传输不好用，你也完全可以自定义一个。​SPI的全称是「Service Provider Interface」，在介绍Dubbo SPI前，先来看看Java自带的SPI机制。​

什么是泛化调用泛化接口调用方式主要用于客户端没有 API 接口及模型类元的情况，参数及返回值中的所有 POJO 均用 Map 表示，通常用于框架集成，比如：实现一个通用的服务测试框架，可通过 GenericService 调用所有服务实现。官方文档说白了，消费者可以在没有Interface接口的情况下去调用远程服务，由于没有接口和模型类元，消费者必须手动指定要调用的接口名、方法名、参数列表、版本号等信息。正是因为没有接口和模型类元，所以泛化调用的接口返回结果Dubbo不得不转换成HashMap返