【Dubbo】启停原理解析

清疚 2023-01-19 07:27 144阅读 0赞

主要内容 ：

*  Dubbo 配置解析 ；
 *  Dubbo 优雅停机解析 。

将详细探讨 Dubbo 配置的设计模型 、 服务暴露的原理 、 服务消费的原理和优雅停机的原理 。 首先 ， 学习优雅的分层配置设计 ， 能够帮助我们更好地理解框架的启动配置逻辑 ， 不管是注解还是 XML 配置都需要配置对象来承载 。 最后研究优雅停机特性 ， 能够保证线上服务和消费方平滑地退出

# 1 配置解析 #

目前 Dubbo 框架同时提供了 3 种配置方式: XML 配置 、 注解 、 属性文件 (properties 和 ymal) 配置 ， 最常用的还是 XML 和注解两种方式 。

## 1.1 基于 schema 设计解析 ##

Spring 框架对 Java 产生了深远的影响 ， Dubbo 框架也直接集成了 Spring 的能力 ， 利用了 Spring 配置文件扩展出自定义的解析方式 Dubbo 配置约束文件在 dubbo-conf ig/dubbo-config-spring/src/main/resources/dubbo.xsd 中 ， 在 IntelliD IDEA 中能够自动查找这个文件 ， 当用户使用属性时进行自动提示 。

dubbo.xsd 文件用来约束使用 XML 配置时的标签和对应的属性 ， 比如 Dubbo 中的<dubbo:service＞ 和 <dubbo:reference> 标签等 。 Spring 在解析到自定义的 namespace 标签时 （ 比如 ＜dubbo:service＞ 标签 ） ， 会查找对应的 spring.schemas 和 spring.handlers 文件 ， 最终触发Dubbo 的 DubboNamespaceHandler 类来进行初始化和解析 。 我们先看以下两个文件的内容 ：

// spring,schemas 文件
    http\://dubbo.apache.org/schema/dubbo/dubbo.xsd=META-INF/dubbo.xsd
    http\://code.alibabatech.com/schema/dubbo/dubbo.xsd=META-INF/compat/dubbo.xsd
    
    
    // spring.handlers 文件
    http\://dubbo.apache.org/schema/dubbo=org.apache.dubbo.config.spring.schema.DubboNamespaceHandler
    http\://code.alibabatech.com/schema/dubbo=org.apache.dubbo.config.spring.schema.DubboNamespaceHandler

其中 ， spring.schemas 文件指明约束文件的具体路径 ， spring, handlers 文件指明DubboNamespaceHandler 类来解析标签 。 在重启开源之后 ， Dubbo 捐给了 Apache 组织 ，因此每个文件多出来了一行 ：

// spring, schemas 文件
    http\://dubbo. apache.org/schema/dubbo/dubbo.xsckMETA-INF/dubbo.xsd
    
    // spring.handlers 文件
    http\://dubbo.apache.org/schema/dubbo=org.apache.dubbo.config.spring.schema.DubboNamespaceHandler

在捐给 Apache 组织后 ， 项目包名需要改动 ， 因此整个项目也进行了相应的调整 ， 主要是遵循 Apache 标准和兼容 Dubbo 原来的版本 。

详细讲解 Spring 解析扩展超出了本节的范围 ， 感兴趣的读者可以阅读相关 Spring 源码实现 BeanDefinitionParserDelegatet\#parseCustomElement

Dubbo 设计之初也考虑到属性最大限度的复用 ， 因此对 schema 进行了精心的设计 ， Dubbo schema 层级的详细设计如图所示  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]

Dubbo 设计的粒度很多都是针对方法级别设计的 ， 比如方法级别的 timeout 、 retries 和 mock特性 。 这里包含的模块详细用法可以参考文档 ： http://dubbo.apache.org/zh-cn/docs/user/references/xml/introduction.html。 在图中 ， 左边代表 schema 有继承关系的类型 ，右边是独立的类型 。 schema 模块说明如表所示 。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]  
图中没有体现出来的是 annotationType 模块,这个模块主要配置项目要扫描的注解包 。

因为篇幅和完整性 ， 这里特意说明一下 ， 接下来我们详细探讨 Dubbo 框架是如何对 dubbo.xsd做扩展的 。接下来我们看一个 dubbo.xsd 的真实的配置 ， 以 protocolType 模块为例

*协议类型属性定义*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]  
在代码清单中 ， 我们可以简单理解其为协议定义约束字段 ， 只有在这里定义的属性才会在 Dubbo 的 XML 配置文件中智能提示 ， 当我们基于 Dubbo 做二次开发时 ， 应该在 schema 中添加合适的字段 ， 同时应该在 dubbo-config-api 对应的 Config 类中添加属性和 get & set 方法 ，这样用户在配置属性框架时会自动注入这个值 。 只有属性定义是不够的 ， 为了让 Spring 正确解析标签 ， 我们要定义 element 标签 ， 与代码清单中的 protocolType 进行绑定 ， 这里以protocolType 示例展示

*定义标签配置*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]  
目前绝大多数场景使用默认的 Dubbo 配置就足够了 ， 如果新增特性 ， 比如增加 epoll 特性 ，则只需要在 providerType、 consumerType、 ProviderConfig 和 ConsumerConfig 中增加 epoll属性和方法即可 。 如果使用已经存在 schema 类型(比如说 protocolType), 则只需要添加新属性即可 ， 也不需要定义新的 element 标签 。 如果接口是级别通用的 ， 一般我们只需要在 interfaceType 中增加属性即可 ， 继承自 interfaceType 的类型会拥有该字段 。 同理 ， 在 Dubbo对应类 AbstractInterfaceConfig 中增加属性和方法即可

## 1.2 基于 XML 配置原理解析 ##

通过 1.1 节 ， 我们应该熟悉了 dubbo.xsd 中约束的定义 ， 以及如何扩展字段 ， 接下来我们探讨框架是如何解析配置的 。 主要解析逻辑入口是在 DubboNamespaceHandler 类中完成的 ，

*Dubbo 注册属性解析处理器*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]  
DubboNamespaceHandler 主要把不同的标签关联至 U 解析实现类中 o registerBeanDef initionParser 方法约定了在 Dubbo 框架中遇到标签 application 、 module 和 registry 等都会委托给DubboBeanDefinitionParser 处理 。 需要注意的是 ， 在新版本中重写了注解实现 ， 主要解决了以前实现的很多缺陷 （ 比如无法处理 AOP 等 ） ， 相关重写注解的逻辑会在后面讲解 。

接下来我们进入 DubboBeanDefinitionParser 实现 ， 因为解析逻辑比较长 ， 为了更清晰地表达实现原理 ， 下面分段拆解

*Dubbo 配置解析*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 5]  
前面的逻辑主要负责把标签解析成对应的 Bean 定义并注册到 Spring 下文中 ， 同时保证了 Spring 容器中相同 id 的 Bean 不会被覆盖 。

接下来分析具体的标签是如何解析的 ， 我们依次分析 <dubbo:service>、 <dubbo:provider>和 <dubbo:consumer> 标签

*service 标签解析*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 6]

通过对 ServiceBean 的解析我们可以看到只是特殊处理了 class 属性取值 ， 并且在解析过程中调用了 parseProperties 方法 ， 这个方法主要解析 〈dubbo:service〉 标签中的 name 、 class和 ref 等属性 。 parseProperties 方法会把 key-value 键值对提取出来放到 BeanDefinition 中 ，运行时 Spring 会自动处理注入值 ， 因此 ServiceBean 就会包含用户配置的属性值了 。

其中 〈dubbo:provider〉 和 〈dubbo:consumer〉 标签复用了解析代码 (parseNested), 主要逻辑是处理内部嵌套的标签 ， 比如 ＜dubbo:provider＞ 内部可能嵌套了 〈dubbo:service〉 ， 如果使用了嵌套标签 ， 则内部的标签对象会自动持有外层标签的对象 ， 例如 ＜dubbo:provider＞ 内部定义了 ＜dubbo:service＞, 解析内部的 service 并生成 Bean 的时候 ， 会把外层 provider 实例对象注入service, 这种设计方式允许内部标签直接获取外部标签属性 。

前面逻辑处理了嵌套标签的场景 ， 当前标签的 attribute 是如何提取的呢 ？ 主要分为两种场景 ：

*  查找配置对象的 get 、 set 和 is 前缀方法 ， 如果标签属性名和方法名称相同 ， 则通过反射调用存储标签对应值 。
 *  如果没有和 get 、 set 和 is 前缀方法匹配 ， 则当作 parameters 参数存储 ， parameters 是一个 Map 对象 。

以上两种场景的值最终都会存储到 Dubbo 框架的 URL 中 ， 唯一区别就是 get 、 set 和 is 前缀方法当作普通属性存储 ,parameters 是用 Map 字段存储的

*标签属性值解析*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 7]  
这里给出了核心属性值解析的注释代码 ， 省略了特殊属性解析 。 本质上都是把属性注入 Spring框架的 BeanDefinition 。 如果属性是引用对象 ， 则 Dubbo 默认会创建 RuntimeBeanReference类型注入 ， 运行时由 Spring 注入引用对象 。 通过对属性解析的理解 ， 其实 Dubbo 只做了属性提取的事情 ， 运行时属性注入和转换都是 Spring 处理的 ， 感兴趣的读者可以了解 Spring 是如  
何做数据初始化和转换的(参见 Spring 类 BeanWrapperImpl)

Dubbo 框架生成的 BeanDefinition 最终还是会委托 Spring 创建对应的 Java 对象 , dubbo.xsd中定义的类型都会有与之对应的 POJO, Dubbo 承载对象和继承关系如图所示

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 8]

## 1.3 基于注解配置原理解析 ##

重启开源后 , Dubbo 的注解己经完全重写了 ， 因为原来注解是基于 AnnotationBean 实现的 ，主要存在以下几个问题 ：

*  注解支持不充分 ， 需要 XML 配置 ＜dubbo:annotation＞ ；
 *  @ServiceBean 不支持 Spring AOP ；
 *  @Reference 不支持字段继承性 。

在原来实现思路的基础上无法解决历史遗留问题 ， 但采用另外一种思路实现可以很好地修复并改进遗留问题 。

在开始探讨注解解析机制实现之前 ， 通过图可以看到注解用到的核心组件 。注解处理逻辑主要包含 3 部分内容 ， 第一部分是如果用户使用了配置文件 ， 则框架按需生成对应 Bean, 第二部分是要将所有使用 Dubbo 的注解 @Service 的 class 提升为 Bean, 第三部分要为使用 @Reference 注解的字段或方法注入代理对象 。 我们先看一下 EnableDubbo 注解  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 9]  
*注解 EnableDubbo*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 10]

当 Spring 容器启动的时候 ， 如果注解上面使用 .Import, 则会触发其注解方法 selectimports, 比如 EnableDubboConfig 注解中指定的 DubboConfigConfigurationSelector.class, 会自动触发 DubboConfigConfigurationSelector\#selectImports 方法 。 如果业务方配置了 Spring 的 @PropertySource 或 XML 等价的配置（比如配置了框架 dubbo. registry .address 和 dubbo. application 等属性) ， 则 Dubbo 框架会在 DubboConfigConfigurationSelector\#selectlmports 中自动生成相应的配置承载对象 ， 比如 Applicationconfig 等 。

细心的读者可能发现 DubboConfigConfiguration 里面标注了 @EnableDubboConfigBindings , @EnableDubboConfigBindings 同样指定了 @Import(DubboConfigBindingsRegistrar.class) 。 因为 @EnableDubboConfigBindings 允许指定多个 @EnableDubboConfigBinding 注解, Dubbo 会根据用户配置属性自动填充这些承载的对象

*Dubbo 解析注解属性*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 11]  
可以发现处理用户指定配置代码的逻辑比较简单 ， 在 DubboConfigBindingRegistrar 实现中做了下面几件事情 ：

*  (1) 如果用户配置了属性 ， 比如 dubbo . application . name, 则会自动创建对应 Spring Bean 到容器 。
 *  (2) 注册和配置对象 Bean 属性绑定处理器 DubboConfigBindingBeanPostProcessor, 委托Spring 做属性值绑定 。

接下来我们看一下是如何对服务提供者通过注 @Service 进行暴露的 ， 注解扫描也委托给Spring, 本质上使用 asm 库进行字节码扫描注解元数据 ， 感兴趣的读者可以参考 Spring 源代码SimpleMetadataReader。 当用户使用注解旧 DubboComponentScan 时 ， 会激活 DubboComponentScanRegistrar, 同时生成 ServiceAnnotationBeanPostProcessor 和ReferenceAnnotationBeanPostProcessor两种处理器 ， 通过名称很容易知道分别是处理服务注解和消费注解 。

我们首先分析服务注解逻辑 ， 因为 ServiceAnnotationBeanPostProcessor 处理器实现了 BeanDefinitionRegistryPostProcessor接口 ， Spring 容器中所有 Bean 注册之后回调 postProcessBeanDefinitionRegistry 方法开始扫描旧 Service 注解并注入容器

*服务注解扫描和注册*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 12]  
①：Dubbo 框架首先会提取用户配置的扫描包名称 ， 因为包名可能使用 $\{…\} 占位符 ， 因此框架会调用 Spring 的占位符解析做进一步解码 。 ② ： 开始真正的注解扫描 ， 委托 Spring 对所有符合包名的 .class 文件做字节码分析 ， 最终通过③配置扫描 @Service 注解作为过滤条件 。 在④中将 @Service 标注的服务提升为不同的 Bean, 这里并没有设置 beanClass 。在⑤中主要根据注册的普通 Bean 生成 ServiceBean 的占位符 ， 用于后面的属性注入逻辑 。 在⑥中会提取普通 Bean上标注的 Service 注解生成新的 RootBeanDefinition, 用于 Spring 启动后的服务暴露 ， 具体服务暴露的逻辑会在后面详细解析 。

这里做注入用的是 ServiceBean 类 ， 它同样继承自 ServiceConfig, 并在此基础上增加了 Spring 初始化等生命周期方法 ， 实现了 InitializingBean 接口，在 afterPropertiesSet 中调用 super.export() 方法进行暴露。

在实际使用过程中 ， 我们会在旧 Service 注解的服务中注入旧 Reference 注解 ， 这样就可以很方便地发起远程服务调用 ， Dubbo 中做属性注入是通过 ReferenceAnnotationBeanPostProcessor 处理的 ， 主要做以下几种事情：

*  (1) 获取类中标注的 @Reference 注解的字段和方法 。
 *  (2) 反射设置字段或方法对应的引用 。

*消费注解注入*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 13]

因为处理器 ReferenceAnnotationBeanPostProcessor 实现了 InstantiationAwareBeanPostProcessor 接口 ， 所以在 Spring 的 Bean 中初始化前会触发 postProcessPropertyValues 方法 ， 该方法允许我们做进一步处理 ， 比如增加属性和属性值修改等 。 在①中主要利用这个扩展点查找服务引用的字段或方法 。 在②中触发字段或反射方法值的注入 ， 字段处理会调用 findFieldReferenceMetadata方法 ， 在③中会遍历类所有字段 ， 因为篇幅的原因 ， 方法级别注入最终会调用findMethodReferenceMetadata 方法处理上面的注解 。

在②中会触发字段或方法 inject 方法 ，使用泛化调用的开发人员可能用过 ReferenceConfig 创建引用对象 ， 这里做注入用的是ReferenceBean 类 ， 它同样继承自 ReferenceConfig, 在此基础上增加了 Spring 初始化等生命周期方法 ， 比如触发 afterPropertiesSet 从容器中获取一些配置 (protocol) 等 ， 当设置字段值的时候因为实现了 factoryBean 接口，所以仅调用 referenceBean.getObject() 获取远程代理即可

# 2 优雅停机原理解析 #

优雅停机特性是所有 RPC 框架中非常重要的特性之一 ， 因为核心业务在服务器中正在执行时突然中断可能会出现严重后果 。 接下来我们详细探讨 Dubbo 框架内部实现优雅停机的原理  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 14]  
Dubbo 中实现的优雅停机机制主要包含 6 个步骤 ：

*  （1) 收到 kill 9 进程退出信号 ， Spring 容器会触发容器销毁事件
 *  （2） provider 端会取消注册服务元数据信息 。
 *  （3） consumer 端会收到最新地址列表 （ 不包含准备停机的地址 ） 。
 *  （4） Dubbo 协议会发送 readonly 事件报文通知 consumer 服务不可用 。
 *  （5） 服务端等待已经执行的任务结束并拒绝新任务执行 。

可能读者会有疑问 ， 既然注册中心已经通知了最新服务列表 ， 为什么还要再发送 readonly报文呢 ？ 这里主要考虑到注册中心推送服务有网络延迟 ， 以及客户端计算服务列表可能占用一些时间 。 Dubbo 协议发送 readonly 时间报文时 ， consumer 端会设置响应的 provider 为不可用状态 ， 下次负载均衡就不会调用下线的机器 。

Dubbo 2.6.3 以后修复了优雅停机的一些 bug, 在以前的版本中没有做到完全优雅停机的原因是 Spring 注册了 JVM 停止的钩子 ， Dubbo 也注册了 JVM 停止的钩子 ， 这种场景下两个并发执行的线程可能引用已经销毁的资源 ， 导致优雅停机失去了意义 。 比如 ， Dubbo 正在执行的任务需要引用 Spring 中的 Bean, 但这时 Spring 钩子函数已经关闭了 Spring 的上下文状态 ， 导致访问任何 Spring 资源都会报错 。

# 3 小结 #

我们首先对 Dubbo 中 XML schema 约束文件进行了讲解 ， 也包括如何映射到对应 Java对象中 。 现在越来越多地使用注解的方式 ， 我们也对注解的解析核心流程进行了探讨 。 最后我们对优雅停机的原理进行了探讨 ， 也对以前的实现缺陷的原因进行了概述 。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]: /images/20221021/175ee082dbe2428c968d56b023f8f574.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]: /images/20221021/1a64dfce6fa9487c9d3c78ae21e3a2de.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]: /images/20221021/ccb51b9aef63447d94587ec440aaf67b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]: /images/20221021/0ef5d9bad883418bb723877413ad968a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]: /images/20221021/3bcb7a4e94a8480ea2a6ee42b909780f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 5]: /images/20221021/6e9391a92b814d6fb2ca06fb1bbfe633.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 6]: /images/20221021/2aa83d0da3154529b34757909ce9e65c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 7]: /images/20221021/e298b46c32c342c9994f28979086bfe5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 8]: /images/20221021/7e5de56aaac4493b8a8b491f9189776a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 9]: /images/20221021/23ee773f5069424ead5d6ddce1047921.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 10]: /images/20221021/56aa618da4774c369b4eef334e006cd1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 11]: /images/20221021/1da6b2c36666496a93e60ff0fd303f0f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 12]: /images/20221021/86a4dfde901641e58fd19ec38d88cf46.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 13]: /images/20221021/904735b29c234181a17743e0d064a652.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 14]: /images/20221021/394f6595ea5f46c393dd4be200d2ce67.png