【Dubbo】Transport 层实现

ゝ一世哀愁。 2023-01-19 07:28 0阅读 0赞

主要内容 ：

*  Dubbo 核心调用流程 ；
 *  Dubbo 协议详解 ；
 *  Dubbo 编解码器原理 ；

首先介绍 Dubbo 的核心调用流程 ， 接下来讲解 Dubbo 内部协议的设计和实现 ， 通过对具体协议细节的理解 ， 我们可以更好地掌握 RPC 通信的核心原理 。 在理解现有 RPC 协议的基础上 ， 我们会对编解码器实现展开深入解析。

# 1 Dubbo 调用介绍 #

在讲解 Dubbo 中的 RPC 调用细节之前 ， 我们先回顾一次调用过程经历了哪些处理步骤 。

如果我们动手写简单的 RPC 调用 ， 则需要把服务调用信息传递到服务端 ， 每次服务调用的一些公用的信息包括服务调用接口 、 方法名 、 方法参数类型和方法参数值等 ， 在传递方法参数值时需要先序列化对象并经过网络传输到服务端 ， 在服务端需要按照客户端序列化顺序再做一次反序列化来读取信息 ， 然后拼装成请求对象进行服务反射调用 ， 最终将调用结果再传给客户端

在 Dubbo 中实现调用也是基于相同的原理 ， 下面看一下 Dubbo 在一次完整的 RPC 调用流程中经过的步骤 ， 如图所示  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]  
首先在客户端启动时会从注册中心拉取和订阅对应的服务列表 ， Cluster 会把拉取的服务列表聚合成一个 Invoker, 每次 RPC 调用前会通过 Directory\#list 获取 providers 地址 （ 已经生成好的 Invoker 列表 ） ， 获取这些服务列表给后续路由和负载均衡使用 。 在①中主要是将多个服务提供者做聚合 。 在框架内部另外一个实现 Directory 接口是 RegistryDirectory类 ， 它和接口名是一对一的关系 （ 每一个接口都有一个 RegistryDirectory 实例 ） ， 主要负责拉取和订阅服务提供者 、 动态配置和路由项 。

在 Dubbo 发起服务调用时 ， 所有路由和负载均衡都是在客户端实现的 。 客户端服务调用首先会触发路由操作 ， 然后将路由结果得到的服务列表作为负载均衡参数 ， 经过负载均衡后会选出一台机器进行 RPC 调用 ， 这 3 个步骤依次对应于② 、 ③和④ 。 客户端经过路由和负载均衡后 ，会将请求交给底层 I/O 线程池 （ 比如 Netty ） 处理 ， I/O 线程池主要处理读写 、 序列化和反序列化等逻辑 ， 因此这里一定不能阻塞操作 ， Dubbo 也提供参数控制 （ decode.in.io ） 参数 ， 在处理反序列化对象时会在业务线程池中处理 。 在⑤中包含两种类似的线程池 ， 一种是 I/O 线程池（ Netty ） , 另一种是 Dubbo 业务线程池 （ 承载业务方法调用 ） 。

目前 Dubbo 将服务调用和 Telnet 调用做了端口复用 ， 在编解码层面也做了适配 。 在 Telnet 调用时 ， 会新建立一个 TCP 连接 ， 传递接口 、 方法和 JSON 格式的参数进行服务调用 ， 在编解码层面简单读取流中的字符串 （ 因为不是 Dubbo 标准头报文 ） ， 最终交给 Telnet 对应的 Handler 去解析方法调用 。 如果是非 Telnet 调用 ， 则服务提供方会根据传递过来的接口 、 分组和版本信息查找 Invoker 对应的实例进行反射调用 。 在⑦中进行了端口复用 ， 如果是 Telnet 调用 ， 则先找到对应的 Invoker 进行方法调用 。 Telnet 和正常 RPC 调用不一样的地方是序列化和反序列化使用的不是 Hessian 方式 ， 而是直接使用 fastjson 进行处理 。 如果读者对目前的流程没有完全理解也没有关系 ， 后面会逐渐深入讲解 。

讲解完主要调用原理 ， 我们接下来集中精力探讨更细节的一些知识点 ， 比如 Dubbo 协议 、编解码实现和线程模型等 ， 本章篇幅主要放在⑤ 、 ⑥和⑦中 ， 我们首先看一下目前 Dubbo 的协议细节 。

# 2 Dubbo 协议详解 #

本节我们讲解 Dubbo 协议设计 ， 其协议设计参考了现有 TCP/IP 协议  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]

我们发现一次 RPC 调用包括协议头和协议体两部分 。 16 字节长的报文头部主要携带了魔法数(Oxdabb), 以及当前请求报文是否是 Request 、 Response ＞ 心跳和事件的信息 ， 请求时也会携带当前报文体内序列化协议编号 。 除此之外 ， 报文头部还携带了请求状态 ， 以及请求唯一标识和报文体长度

理解协议本身的内容对后面的编码器和解码器的实现非常重要 ， 我们先逐字节 、 逐比特位讲解协议内容(具体内容参考表)  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]  
在消息体中 ， 客户端严格按照序列化顺序写入消息 ， 服务端也会遵循相同的顺序读取消息 ，客户端发起请求的消息体依次保存下列内容 ： Dubbo 版本号 、 服务接口名 、 服务接口版本 、 方法名 、 参数类型 、 方法参数值和请求额外参数 ( attachment) 。在协议报文头部的 status 中 ， 完整状态响应码和作用如表所示  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]  
主要根据以下标记判断返回值 ， 如表所示  
![在这里插入图片描述][2021050819440474.png]  
在返回消息体中 ， 会先把返回值状态标记写入输出流 ， 根据标记状态判断 RPC 是否正常,比如一次正常 RPC 调用成功 ， 则先往消息体中写一个标记 1, 紧接着再写方法返回值 。

我们知道在网络通信中 （ 基于 TCP ） 需要解决网络粘包/解包的问题 ， 一些常用解决办法比如用回车 、 换行 、 固定长度和特殊分隔符等进行处理 ， 通过对前面协议的理解 ， 我们很容易发现 Dubbo 其实就是用特殊符号 exdabb 魔法数来分割处理粘包问题的 。在实际使用场景中 ， 客户端会使用多线程并发调用服务 ， Dubbo 是如何做到正确响应调用线程的呢 ？ 关键点在于协议头全局请求 id 标识 ， 我们先来看一下原理图  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]  
当客户端多个线程并发请求时 ， 框架内部会调用 DefaultFuture 对象的 get 方法进行等待 。在请求发起时 ， 框架内部会创建 Request 对象 ， 这个时候会被分配一个唯一 id, DefaultFuture 可以从 Request 对象中获取 id, 并将关联关系存储到静态 HashMap 中 ， 就是图中的 Futures集合 。 当客户端收到响应时 ， 会根据 Response 对象中的 id, 从 Futures 集合中查找对应DefaultFuture 对象 ， 最终会唤醒对应的线程并通知结果 。 客户端也会启动一个定时扫描线程去探测超时没有返回的请求 。

# 3 编解码器原理 #

2 节主要给出了 Dubbo 目前的协议格式 ， 有了标准协议约束 ， 我们需要再探讨 Dubbo 是怎么实现编解码的 。 在讲解编解码实现前 ， 先熟悉一下编解码设计关系 ， 如图所示  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 5]  
在图中, AbstractCodec 主要提供基础能力 ， 比如校验报文长度和查找具体编解码器等 。TransportCodec 主要抽象编解码实现 ， 自动帮我们去调用序列化 、 反序列实现和自动 cleanup 流 。

我们通过 Dubbo 编解码继承结构可以清晰看到 ， DubboCodec 继承自 ExchangeCodec, 它又再次继承了 TelnetCodec 实现 。 我们前面说过 Telnet 实现复用了 Dubbo 协议端口 ， 其实就是在这层编解码做了通用处理 。 因为流中可能包含多个 RPC 请求 ， Dubbo 框架尝试一次性读取更多完整报文编解码生成对象 ， 也就是图中的 DubboCountCodec, 它的实现思想比较简单 ， 依次调用DubboCodec 去解码 ， 如果能解码成完整报文 ， 则加入消息列表 ， 然后触发下一个 Handler 方法调用 。

# 3.1 Dubbo 协议编码器 #

Dubbo 中的编码器主要将 Java 对象编码成字节流返回给客户端 ， 主要做两部分事情 ， 构造报文头部 ， 然后对消息体进行序列化处理 。 所有编解码层实现都应该继承自 Exchangecodec,Dubbo 协议编码器也不例外 。 当 Dubbo 协议编码请求对象时 ， 会调用 ExchangeCodec\#encode方法 。 我们首先分析编码请求对象 。

*请求对象编码*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 6]  
代码清单的主要职责是将 Dubbo 请求对象编码成字节流(包括协议报文头部) 。 在①中主要提取 URL 中配置的序列化协议或默认协议 。 在②中会创建 16 字节的报文头部 。 在③中首先会将魔法数写入头部并占用 2 个字节 。 在④中主要设置请求标识和消息体中使用的序列化协议 。 在⑤中会复用同一个字节 ， 标记这个请求需要服务端返回 。 在⑥中主要承载请求的唯一标识 ， 这个标识用于匹配响应的数据 。 在⑦中会在 buffer 中预留 16 字节存储头部 ， 在⑧中会序列化请求部分， 比如方法名等信息 ， 后面会讲解 。 在⑨中会检查编码后的报文是否超过大小限制(默认是 8MB) 。 在⑩中将消息体长度写入头部偏移量(第 12 个字节) ， 长度占用 4 个字节 。在⑪中将 buffer 定位到报文头部开始 ， 在⑫中将构造好的头部写入 buffer 。 在⑬中再将 buffer写入索引执行消息体结尾的下一个位置 。

通过上面的请求编码器实现 ， 在理解 2 节协议的基础上很容易理解这里的代码 ， 在⑧中会调用 encodeRequestData 方法对 Rpclnvocation 调用进行编码 ， 这部分主要就是对接口 、 方法 、方法参数类型 、 方法参数等进行编码 ， 在DubboCodec\#encodeRequestData 中重写了这个方法实现 ，

*编码请求对象体*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 7]  
代码清单的主要职责是将 Dubbo 方法调用参数和值编码成字节流 。 在编码消息体的时候 ， 在①中主要先写入框架的版本 ， 这里主要用于支持服务端版本隔离和服务端隐式参数透传给客户端的特性 。 在②中向服务端写入调用的接口 。 在③中指定接口的版本 ， 默认版本为 0.0.0,Dubbo 允许同一个接口有多个实现 ， 可以指定版本或分组来区分 。 在④中指定远程调用的接口方法 。 在⑤中将方法参数类型以 Java 类型方式传递给服务端 。 在⑥中循环对参数值进行序列化 。在⑦中写入隐式参数 HashMap, 这里可能包含 timeout 和 group 等动态参数 。

在处理完编码请求后 ， 我们继续分析编码响应对象 ， 理解了编码请求对象后 ， 比较好理解响应 ， 响应实现在ExchangeCodec\#encodeResponse 中

*编码响应对象*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 8]  
代码清单的主要职责是将 Dubbo 响应对象编码成字节流(包括协议报文头部) 。 在编码响应中 ， 在①中获取用户指定或默认的序列化协议 ， 在②中构造报文头部 ( 16 字节) 。 在③中同样将魔法数填入报文头部前 2 个字节 。 在④中会将服务端配置的序列化协议写入头部 。 在⑤中报文头部中 status 会保存服务端调用状态码 。 在⑥中会将请求唯一 id 设置回响应头中 。 在⑦中空出 16 字节头部用于存储响应体报文 。 在⑧中会对服务端调用结果进行编码 ， 后面会进行详细解释 。 在⑨中主要对响应报文大小做检查 ， 默认校验是否超过 8MB 大小 。 在⑩中将消息体长度写入头部偏移量(第 12 个字节) ， 长度占用 4 个字节 。 在⑪中将 buffer 定位到报文头部开始 ，在⑫中将构造好的头部写入 buffer 。 在⑬中再将 buffer 写入索引执行消息体结尾的下一个位置 。在⑭中主要处理编码报错复位 buffer, 否则导致缓冲区中数据错乱 。在⑥中会将异常响应返回到客户端 ， 防止客户端只有等到超时才能感知服务调用返回 。 在⑯和⑰中主要对报错进行了细分 ， 处理服务端报文超过限制和具体报错原因 。 为了防止报错对象无法在客户端反序列化 ， 在服务端会将异常信息转成字符串处理 。

我们再回到编码响应消息提的部分 ， 在⑧中处理响应 ， 具体实现在 DubboCodec\#encodeResponseData 中

*编码响应对象*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 9]  
代码清单的主要职责是将 Dubbo 方法调用状态和返回值编码成字节流 。 编码响应体也是比较简单的 ， 在①中判断客户端的版本是否支持隐式参数从服务端传递到客户端 。 在②和③中处理正常服务调用 ， 并且返回值为 null 的场景 ， 用一个字节标记 。 在④中处理方法正常调用并且有返回值 ， 先写一个字节标记并序列化结果 。 在⑤中处理方法调用发生异常 ， 写一个字节标记并序列化异常对象 。 在⑥中处理客户端支持隐式参数回传 ， 记录服务端 Dubbo 版本 ， 并返回服务端隐式参数 。

除了编码请求和响应对象 ， 还有一种处理普通字符串的场景 ， 这种场景正是为了支持 Telnet协议调用实现的 ， 这里主要是简单读取字符串值处理 ， 后面会继续分析 。 接下来我们会在 3.2节探讨解码器的实现 。

## 3.2 Dubbo 协议解码器 ##

3.1 节主要完成了对编码的分析 ， 本节聚焦解码的实现 ， 相比较编码而言 ， 解码要复杂一些 。 解码工作分为 2 部分 ， 第 1 部分解码报文的头部 ( 16 字节) ， 第 2 部分解码报文体内容 以及如何把报文体转换成 Rpclnvocation

当服务端读取流进行解码时 ， 会触发ExchangeCodec\#decode 方法 ， Dubbo 协议解码继承了这个类实现 ， 但是在解析消息体时 ， Dubbo协议重写了 decodeBody 方法 。 我们先分析解码头部的部分 ，

*解码报文头*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 10]  
整体实现解码过程中要解决粘包和半包问题 。 在①中最多读取 Dubbo 报文头部 ( 16 字节) ，如果流中不足 16 字节 ， 则会把流中数据读取完毕 。 在 decode 方法中会先判断流当前位置是不是 Dubbo 报文开始处 ， 在流中判断报文分割点是通过②判断的 (Oxdabb 魔法数) 。 如果当前流中没有遇到完整 Dubbo 报文(在③中会判断流可读字节数) ， 在④中会为剩余可读流分配存储空间 ， 在⑤中会将流中数据全部读取并追加在 header 数组中 。 当流被读取完后 ， 会查找流中第一个 Dubbo 报文开始处的索引 ， 在⑥中会将 buffer 索引指向流中第一个 Dubbo 报文开始处( Oxdabb ) ， 在⑦中主要将流中从起始位置(初始 buffer 的 readerindex) 到第一个 Dubbo 报文开始处的数据保存在 header 中 ， 用于⑧解码 header 数据 ， 目前常用的场景有 Telnet 调用等 。

在正常场景中解析时 ， 在⑨中首先判断当次读取的字节是否多于 16 字节 ， 否则等待更多网络数据到来 。 在⑩中会判断 Dubbo 报文头部包含的消息体长度 ， 然后校验消息体长度是否超过限制 （ 默认为 8MB ） 。 在⑪中会校验这次解码能否处理整个报文 。 在⑫中处理消息体解码 ， 这个是强协议相关的 ， 因此 Dubbo 协议重写了这部分实现 ， 我们先看一下在 DubboCodec 中是如何处理的

*解码请求报文*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 11]  
站在解码器的角度 ， 解码请求一定是通过标志判断类别的 ， 否则不知道是请求还是响应 ，Dubbo 报文 16 字节头部长度包含了 FLAG\_REQUEST 标志位 。 ① ： 根据这个标志位创建请求对象 ，② ： 在 I/O 线程中直接解码(比如在 Netty 的 I/O 线程中) ， 然后简单调用 decode 解码 ， 解码逻辑在后面会详细探讨 。 ③ ： 实际上不做解码 ， 延迟到业务线程池中解码 。 ④ ： 将解码消息体作为 Rpclnvocation 放到请求数据域中 。 如果解码失败了 ， 则会通过⑤标记 ， 并把异常原因记录下来 。 这里没有提到的是心跳和事件的解码 ， 这两种解码非常简单 ， 心跳报文是没有消息体的 ，事件有消息体 ， 在使用 Hessian2 协议的情况下默认会传递字符 R, 当优雅停机时会通过发送readonly 事件来通知客户端服务端不可用 。

接下来 ， 我们分析一下如何把消息体转换成 Rpclnvocation 对象 ， 具体解码会触发DecodeableRpcInvocation\#decode 方法

*解码请求消息体*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 12]  
在解码请求时 ， 是严格按照客户端写数据顺序来处理的 。 在①中会读取远端传递的框架版本 ， 在②中会读取调用接口全称 ， 在③中会读取调用的服务版本 ， 用来实现分组和版本隔离 。在④中会读取调用方法的名称 ， 在⑤中读取方法参数类型 ， 通过类型能够解析出实际参数个数 。在⑥中会对方法参数值依次读取 ， 这里具体解析参数值是和序列化协议相关的 。 在⑦中读取隐式参数 ， 比如同机房优先调用会读取其中的 tag 值 。 ⑧是为了支持异步参数回调 ， 因为参数是回调客户端方法 ， 所以需要在服务端创建客户端连接代理 。

解码响应和解码请求类似 ， 解码响应会调用 DubboCodec\#decodeBody 方法 ， 为了节省篇幅 ，我们重点讲解解码响应的结果值 。 当方法调用返回时 ， 会触发 DecodeableRpcResult\#decode 方法调用

*解析响应报文*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 13]  
在读取服务端响应报文时 ， 先读取状态标志 ， 然后根据状态标志判断后续的数据内容 。 在代码清单 编码响应对象中 ， 响应结果首先会写一个字节标记位 。 在①中处理标记位代表返回值为 Null 的场景 。 ②代表正常返回 ， 首先判断请求方法的返回值类型 ， 返回值类型方便底层反序列化正确读取 ，将读取的值存在 result 字段中 。 在④中处理服务端返回异常对象的场景 ，同时会将结果保存在exception 字段中 。 在⑤中处理返回值为 Null, 并且支持服务端隐式参数透传给客户端 ， 在客户端会继续读取保存在 HashMap 中的隐式参数值 。 当然 ， 还有其他场景 ， 比如 RPC 调用有返回值 ， RPC 调用抛出异常时需要隐式参数给客户端的场景 ， 可以举一反三 ， 不再重复说明 。

# 小结 #

首先讲解了 Dubbo 调用原理和流程 ， 同时对 Dubb 。 的协议做了详细的讲解 ， 这里的基础知识对 RPC 调用来说至关重要 。 在讲解完协议的基础上 ， 我们又对 Dubbo 实现编解码 、 解决粘包和解包做了深入探讨 。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]: /images/20221021/843a2d2350fa4bc8bb2eee4a1559ee32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]: /images/20221021/9c2978fb4abf4db0b98024852538712b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]: /images/20221021/1cbff662c2dc4f0daaa285123e1ed0d9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]: /images/20221021/6eabea90d4d4425781eba11747af6789.png
[2021050819440474.png]: /images/20221021/2e66f29e2f124db0ab3319aefbb262c9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]: /images/20221021/a2ecc9b6bddb4556b9824484be46ff32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 5]: /images/20221021/770cf984f78f4218a60bae57bbc64145.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 6]: /images/20221021/9eeb8ee22da14bb3b61088784f1ffbf1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 7]: /images/20221021/f85ff60b248a43d9a808dd74b47e4f84.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 8]: /images/20221021/6595b35ca8ef4ff6b28fee0f1b2cf938.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 9]: /images/20221021/85a23c9bd9ec44c684cfebca7985e4d0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 10]: /images/20221021/c3faa5945a114d24a579964820cc4001.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 11]: /images/20221021/1c10ab36d57248729ccb6c805b5ddc91.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 12]: /images/20221021/4a314731c0e54aba911248737b6aa963.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 13]: /images/20221021/0033a9680d504c6193f2963fd007f540.png