【Dubbo】服务暴露与消费原理

╰+攻爆jí腚メ 2023-01-19 14:57 48阅读 0赞

主要内容 ：

*  Dubbo 服务暴露原理 ；
 *  Dubbo 服务消费原理 ；

探讨服务暴露和服务消费的细节

# 1 服务暴露的实现原理 #

前面主要探讨了 Dubbo 中 schema 、 XML 和注解相关原理 ， 这些内容对理解框架整体至关重要 ， 在此基础上我们继续探讨服务是如何依靠前面的配置进行服务暴露的 。

## 1.1 配置承载初始化 ##

不管在服务暴露还是服务消费场景下 ， Dubbo 框架都会根据优先级对配置信息做聚合处理,目前默认覆盖策略主要遵循以下几点规则 ：

*  (1) -D 传递给 JVM 参数优先级最高 ， 比如 -Ddubbo. protocol.port=20880
 *  (2) 代码或 XML 配置优先级次高 ， 比如 Spring 中 XML 文件指定 <dubbo:protocol port= 20880/>
 *  (3) 配置文件优先级最低 ， 比如 dubbo.properties 文件指定 dubbo.protocol . port=20880

一般推荐使用 dubbo.properties 作为默认值 ， 只有 XML 没有配置时 ， dubbo.properties 配置项才会生效 ， 通常用于共享公共配置 ， 比如应用名等 。

Dubbo 的配置也会受到 provider 的影响 ， 这个属于运行期属性值影响 ， 同样遵循以下几点规则 ：

*  (1) 如果只有 provider 端指定配置 ， 则会自动透传到客户端(比如 timeout)
 *  (2) 如果客户端也配置了相应属性 ， 则服务端配置会被覆盖(比如 timeout)

运行时属性随着框架特性可以动态添加 ， 因此覆盖策略中包含的属性没办法全部列出来 ，一般不允许透传的属性都会在 ClusterUtils\#mergellrl 中进行特殊处理 。

## 1.2 远程服务的暴露机制 ##

在详细探讨服务暴露细节之前 ， 我们先看一下整体 RPC 的暴露原理 ， 如图所示  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]  
在整体上看 ， Dubbo 框架做服务暴露分为两大部分 ， 第一步将持有的服务实例通过代理转换成 Invoker, 第二步会把 Invoker 通过具体的协议 （ 比如 Dubbo ） 转换成 Exporter, 框架做了这层抽象也大大方便了功能扩展 。 这里的 Invoker 可以简单理解成一个真实的服务对象实例 ， 是Dubbo 框架实体域 ， 所有模型都会向它靠拢 ， 可向它发起 invoke 调用 。 它可能是一个本地的实  
现 ， 也可能是一个远程的实现 ， 还可能是一个集群实现 。

接下来我们深入探讨内部框架处理的细节 ， 框架真正进行服务暴露的入口点在ServiceConfig\#doExport 中 ， 无论 XML 还是注解 ， 都会转换成 ServiceBean, 它继承自 ServiceConfig, 在服务暴露前会按照 2.1 节的覆盖策略生效 ， 主要处理思路就是遍历服务的所有方法 ， 如果没有值则尝试从 -D 选项中读取 ， 如果还没有则自动从配置文件 dubbo.properties中读取 。

Dubbo 支持多注册中心同时写 ， 如果配置了服务同时注册多个注册中心 ， 则会在 ServiceConfig\#doExportUrls 中依次暴露

*多协议多注册中心暴露*  
![在这里插入图片描述][20210508192922441.png]  
Dubbo 也支持相同服务暴露多个协议 ， 比如同时暴露 Dubbo 和 REST 协议 ， 框架内部会依次对使用的协议都做一次服务暴露 ， 每个协议注册元数据都会写入多个注册中心 。 在①中会自动获取用户配置的注册中心 ， 如果没有显示指定服务注册中心 ， 则默认会用全局配置的注册中心 。在②中处理多协议服务暴露的场景 ， 真实服务暴露逻辑是在 doExportUrlsForlProtocol 方法中实现的

*服务暴露*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]  
在 doExportUrlsForlProtocol 中进行暴露的代码有所删减 ， 主要突出服务暴露重点 ， 剔除不太重要细节 。 在①中主要通过反射获取配置对象并放到 map 中用于后续构造 URL 参数(比如应用名等) 。 在②中主要区分全局配置 ， 默认在属性前面增加 default. 前缀 ， 当框架获取 URL 中的参数时 ， 如果不存在则会自动尝试获取 default. 前缀对应的值 。 在③中主要处理本地内存JVM 协议暴露 ， 会在 2.3 节中探讨 。 在④中主要追加监控上报地址 ， 框架会在拦截器中执行数据上报 ， 这部分是可选的 。 在⑤中会通过动态代理的方式创建 Invoker 对象 ， 在服务端生成的是 AbstractProxylnvoker 实例 ， 所有真实的方法调用都会委托给代理 ， 然后代理转发给服务 ref 调用 。 目前框架实现两种代理 ： javassist ProxyFactory 和 DdkProxyFactory 。

JavassistProxyFactory 模式原理 ： 创建 Wrapper 子类, 在子类中实现 invokeMethod 方法 ， 方法体内会为每个 ref 方法都做方法名和方法参数匹配校验 ， 如果匹配则直接调用即可 ， 相比 JDdkProxyFactory 省去了反射调用的开销 。 JDdkProxyFactory 模式是我们常见的用法 ， 通过反射获取真实对象的方法 ， 然后调用即可 。

在⑥中主要先触发服务暴露(端口打开等) ， 然后进行服务元数据注册 。 在⑦中主要处理没有使用注册中心的场景 ， 直接进行服务暴露 ， 不需要元数据注册 ， 因为这里暴露的 URL 信息是以具体 RPC 协议开头的 ， 并不是以注册中心协议开头的 。

为了更容易地理解服务暴露与注册中心的关系 ， 以下列表项分别展示有注册中心和无注册中心的 URL ：

• registry : //host:port/com.alibaba.dubbo.registry.RegistryService?protocol=zookeeper&export=dubbo://ip:port/xxx? .. 。
    • dubbo://ip:host/xxx.Service?timeout=1000&. . 。

protocol（`protocol = (Protocol)ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();`） 实例会自动根据服务暴露 URL 自动做适配 ， 有注册中心场景会取出具体协议 ， 比如 ZooKeeper, 首先会创建注册中心实例 ， 然后取出 export 对应的具体服务 URL, 最后用服务 URL 对应的协议(默认为 Dubbo) 进行服务暴露 ， 当服务暴露成功后把服务数据注册到 ZooKeeper。如果没有注册中心 ， 则在⑦中会自动判断 URL 对应的协议 (Dubbo) 并直接暴露服务 ， 从而没有经过注册中心 。

在将服务实例 ref 转换成 Invoker 之后 ， 如果有注册中心时 ， 则会通过 RegistryProtocol\#export 进行更细粒度的控制 ， 比如先进行服务暴露再注册服务元数据 。 注册中心在做服务暴露时依次做了以下几件事情 。

*  (1) 委托具体协议 ( Dubbo) 进行服务暴露 ， 创建 NettyServer 监听端口和保存服务实例 。
 *  (2) 创建注册中心对象 ， 与注册中心创建 TCP 连接 。
 *  (3) 注册服务元数据到注册中心 。
 *  (4) 订阅 configurators 节点 ， 监听服务动态属性变更事件 。
 *  (5) 服务销毁收尾工作 ， 比如关闭端口 、 反注册服务信息等 。

*注册中心控制服务暴露*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]  
通过代码清单可以清楚地看到服务暴露的各个流程 ， 当服务真实调用时会触发各种拦截器 Filter, 这个是在哪里初始化的呢 ？ ①中进行服务暴露前 ， 框架会做拦截器初始化 ， Dubbo 在加载 protocol 扩展点时会自动注入 ProtocolListenerwrapper 和 ProtocolFilterWrappero真实暴露时会按照图所示的流程执行（即 Dubbo SPI 的 AOP 原理，会遍历 wrapperSet ，然后通过构造方法注入，实现层层包装）  
![在这里插入图片描述][20210508193210590.png]  
在 ProtocolListenerWrapper 实现中 ， 在对服务提供者进行暴露时回调对应的监听器方法 。ProtocolFilterWrapper 会调用下一级 ListenerExporterWrapper\#export 方法 ， 在该方法内部会触发 buildlnvokerChain 进行拦截器构造 ，

*拦截器构造*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]  
① ： 在触发 Dubbo 协议暴露前先对服务 Invoker 做了一层拦截器构建 ， 在加载所有拦截器时会过滤只对 provider 生效的数据 。 ② ： 首先获取真实服务 ref 对应的 Invoker 并挂载到整个拦截器链尾部 ， 然后逐层包裹其他拦截器 ， 这样保证了真实服务调用是最后触发的 。 ③ ： 逐层转发拦截器服务调用 ， 是否调用下一个拦截器由具体拦截器实现 。

在构造调用拦截器之后会调用 Dubbo 协议进行服务暴露

*Dubbo 协议暴露*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]  
①和②:中主要根据服务分组 、 版本 、 服务接口和暴露端口作为 key 用于关联具体服务 Invoker 。③ ： 对服务暴露做校验判断 ， 因为同一个协议暴露有很多接口 ， 只有初次暴露的接口才需要打开端口监听 ， 然后在④中触发 HeaderExchanger 中的绑定方法 ， 最后会调用底层 NettyServer进行处理 。

在初始化 Server 过程中会初始化很多 Handler 用于支持一些特性 ， 比如心跳 、 业务线程池处理编解码的 Handler 和口向应方法调用的 Handler, 关于 Handler 的特性和细节会在后面详解 ， 本节主要聚焦在服务暴露相关的主线上 。

## 1.3 本地服务的暴露机制 ##

2.2 节主要讲解了服务远程暴露的主流程 ， 很多使用 Dubbo 框架的应用可能存在同一个JVM 暴露了远程服务 ， 同时同一个 JVM 内部又引用了自身服务的情况 ， Dubbo 默认会把远程服务用 injvm 协议再暴露一份 ， 这样消费方直接消费同一个 JVM 内部的服务 ， 避免了跨网络进行远程通信 。

我们再看一下本地服务暴露细节 ServiceConfig\#exportLocal

*本地服务暴露*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 5]  
通过 exportLocal 实现可以发现 ， 在①中显示 Dubbo 指定用 injvm 协议暴露服务 ， 这个协议比较特殊 ， 不会做端口打开操作 ， 仅仅把服务保存在内存中而已 。 在②中会提取 URL 中的协议 ， 在 InjvmProtocol 类中存储服务实例信息 ， 它的实现也是非常直截了当的 ， 直接返回InjvmExporter 实例对象 ， 构造函数内部会把当前 Invoker 加入 exporterMap,

*本地服务暴露*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 6]

# 2 服务消费的实现原理 #

在介绍了服务暴露原理之后 ， 我们重点探讨服务是如何消费的 。 本节主要讲解如何通过注册中心进行服务发现(包括多注册中心服务消费)和绕过注册中心进行远程服务调用等细节 。服务端会执行调用拦截 ， 客户端拦截也会在本节探讨 。

## 2.1 单注册中心消费原理 ##

在详细探讨服务消费细节之前 ， 我们先看整体 RPC 的消费原理 ， 如图 5-6 所示  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 7]  
在整体上看 ， Dubbo 框架做服务消费也分为两大部分 ， 第一步通过持有远程服务实例生成 Invoker, 这个 Invoker 在客户端是核心的远程代理对象 。 第二步会把 Invoker 通过动态代理转换成实现用户接口的动态代理引用 。 这里的 Invoker 承载了网络连接 、 服务调用和重试等功能 ， 在客户端 ， 它可能是一个远程的实现 ， 也可能是一个集群实现 。

接下来我们深入探讨内部框架处理的细节 ， 框架真正进行服务引用的入口点在ReferenceBean\#getObject（由 afterPropertySet 调用）, 不管是 XML 还是注解 ， 都会转换成 ReferenceBean, 它继承自ReferenceConfig, 在服务消费前也会按照 2.1 节的覆盖策略生效 ， 主要处理思路就是遍历服务的所有方法 ， 如果没有值则会尝试从 -D 选项中读取 ， 如果还没有则自动从配置文件  
dubbo.properties 中读取 。

创建代理对象 invoker 的方法为 createProxy，不同于 export 需要先通过 proxyFacotry 生成 invoker 代理，再通过 protocol\#export 进行暴露，对于 refer，通过 protocol\#refer 传入 url 就可以返回 invoker 对象，因为 registryProtocol 第一次订阅会全量拉取数据，然后根据每个 provider 的协议，调用其对应协议的 refer 生成 invoker（一般都是有注册中心会创建 ClusterInvoker，clusterInvoker 中的 Directory 对象会监听并保存注册中心里的 providers，并为 provider 根据其协议生成 invoker，比如 provider 常见的协议是 dubbo，因为会由 dubboProtocol\#refer 去 new DubboInvoker 发牛）。由于 Dubbo 支持多注册中心同时消费 ， 如果配置了服务同时注册多个注册中心 ， 则会在将 protocol\#refer 返回的多个 invoker 包装成一个 clusterInvoker。

*多协议多注册中心暴露*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 8]  
在 createProxy 实现中完成了远程代理对象的创建及代理对象的转换等工作 ， 为了聚焦重点和方便讲解 ， 对现有代码做了部分删减(不影响理解核心流程) 。 在①中会优先判断是否在同一个 JVM 中包含要消费的服务 ， 默认场景下 ， Dubbo 会通过②找出内存中 injvm 协议的服务 ，其实 injvm 协议是比较好理解的 ， 前面提到服务实例都放到内存 map 中 ， 消费也是直接获取实  
例调用而已 。 ③ ： 主要在注册中心中追加消费者元数据信息 ， 应用启动时订阅注册中心 、 服务提供者参数等合并时会用到这部分信息 。 ④ ： 处理只有一个注册中心的场景 ， 这种场景在客户端中是最常见的 ， 客户端启动拉取服务元数据 ， 订阅 provider 、 路由和配置变更 。 ⑤和⑥ ： 分别处理多注册中心的场景 ， 详细内容会在后面讲解 。

当经过注册中心消费时 ， 主要通过 RegistryProtocol\#refer 触发数据拉取 、 订阅和服务 Invoker 转换等操作 ， 其中最核心的数据结构是 RegistryDirectory 。

*Dubbo 通过注册中心返回 Invoker*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 9]  
这段逻辑主要完成了注册中心实例的创建 ， 元数据注册到注册中心及订阅的功能 。 在①中会根据用户指定的注册中心进行协议替换 ， 具体注册中心协议会在启动时用 registry 存储对应值 。 在②中会创建注册中心实例 ， 这里的 URL 其实是注册中心地址 ， 真实消费方的元数据信息是放在 refer 属性中存储的 。 在③中主要提取消费方 refer 中保存的元数据信息 ， 如果包含多个分组值则会把调用结果值做合并处理 。 在④中触发真正的服务订阅和 Invoker 转换 。 在⑤中RegistryDirectory 实现了 NotifyListener 接口 ， 服务变更会触发这个类回调 notify 方法 ， 用于重新引用服务 。 在⑥中负责把消费方元数据信息注册到注册中心 ， 比如消费方应用名 、 IP 和端口号等 。 在⑦中处理 provider 、 路由和动态配置订阅 。 在⑧中除了通过 Cluster 将多个服务合并 ， 同时默认也会启用 FailoverCluster 策略进行服务调用重试 。

具体远程 Invoker 是在哪里创建的呢 ？ 客户端调用拦截器又是在哪里构造的呢 ？ 当在⑦中第一次发起订阅时会进行一次数据拉取操作 ， 同时触发 RegistryDirectory\#notify 方法 ， 这里的通知数据是某一个类别的全量数据 ， 比如 providers 和 routers 类别数据 。 当通知 providers 数据时 ， 在 RegistryDirectory\#toInvokers 方法内完成 Invoker 转换 。

*服务消费服务通知*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 10]  
Dubbo 框架允许在消费方配置只消费指定协议的服务 ， 具体协议过滤在①中进行处理 ， 支持消费多个协议 ， 允许消费多个协议时 ， 在配置 Protocol 值时用逗号分隔即可 。 在②中消费信息是客户端处理的 ， 需要合并服务端相关信息 ， 比如远程 IP 和端口等信息 ， 通过注册中心获取这些信息 ， 解耦了消费方强绑定配置 。 在③中消除重复推送的服务列表 ， 防止重复引用 。 在④中使用具体的协议发起远程连接等操作 。 在真实远程连接建立后也会发起拦截器构建操作 ， 其处理逻辑在 ProtocolFilterWrapper\#refer（即 SPI 的 AOP） 中触发链式构造（对返回的 invoker 使用拦截器进行层层包装） 。

具体 Invoker 创建是在 DubboProtocol\#refer 中实现的 ， Dubbo 协议在返回 Dubbolnvoker 对象之前会先初始化客户端连接对象 。 Dubbo 支持客户端是否立即和远程服务建立 TCP 连接是由参数是否配置了 lazy 属性决定的 ， 默认会全部连接 。 DubboProtocol\#refer 内部会调用DubboProtocol\#initClient 负责建立客户端连接和初始化 Handler

初始化客户端连接  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 11]

① ： 支持 lazy 延迟连接 ， 在真实发生 RPC 调用时创建 。 ② ： 立即发起远程 TCP 连接 ， 具体使用底层传输也是根据配置 transporter 决定的 ， 默认是 Netty 传输 。 在②中会触发HeaderExchanger\#connect 调用 ， 用于支持心跳和在业务线程中编解码 Handler, 最终会调用Transporters\#connect 生成 Netty 客户端处理 。 详细的 Handler 逻辑会在后面讲解 。

回到 3.1 节 ， 在⑦中把 Invoker 转换成接口代理 。 最终代理接口都会创建InvokerlnvocationHandler, 这个类实现了 JDk 的 InvocationHandler 接口 ， 所以服务暴露的Dubbo 接口都会委托给代理去发起远程调用 ( injvm 协议除外)

## 2.2 多注册中心消费原理 ##

在实际使用过程中 ， 我们更多遇到的是单注册中心场景 ， 但是当跨机房消费时 ， Dubbo 框架允许同时消费多个机房服务 。 默认 Dubbo 消费机房的服务顺序是按照配置注册中心的顺序决定的 ， 配置靠前优先消费 。

多注册中心消费原理比较简单 ， 每个单独注册中心抽象成一个单独的 Invoker, 多个注册中心实例最终通过 StaticDirectory 保存所有的 Invoker, 最终通过 Cluster 合并成一个 Invoker 。 这里还有一个特殊点 ， 在多注册中心场景下 ， 默认使用的集群策略是 available。

*多注册中心集群策略*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 12]  
在①中实现 dolnvoke 实际持有的 invokers 列表是注册中心实例 ， 比如配置了 ZooKeeper 和 etcd3 注册中心 ， 实际调用的 invokers 列表只有 2 个元素 。 在②中会判断具体注册中心中是否有服务可用 ， 这里发起的 invoke 实际上会通过注册中心 RegistryDirectory 获取真实 provider 机器列表进行路由和负载均衡调用 。 到这里 ， 读者应该能够理解 Dubbo 所有的概念都在向 Invoker靠拢 。

使用多注册中心进行服务消费时 ， 给框架开发者和扩展特性的开发人员带来了一些挑战 ，特别是在编写同机房路由时 ， 在服务路由层获取的也是注册中心实例 Invoker, 需要进入 Invoker内部判断服务列表是否符合匹配规则 ， 如果匹配到符合匹配规则的机器 ， 则这个时候只能把外层注册中心 Invoker 返回 ， 否则会破坏框架服务调用的生命周期 （ 导致跳过 MockClusterlnvoker 服务调用 ） 。

## 2.3 直连服务消费原理 ##

Dubbo 可以绕过注册中心直接向指定服务(直接指定目标 IP 和端口)发起 RPC 调用 ， 使用直连模式可以方便在某些场景下使用 ， 比如压测指定机器等 。 Dubbo 框架也支持同时指定直连多台机器进行服务调用 。

*直连服务消费*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 13]  
在①中允许用分号指定多个直连机器地址 ， 多个直连机器调用会使用负载均衡 ， 更多场景是单个直连 ， 但是不建议在生产环境中使用直连模式 ， 因为上游服务发布会影响服务调用方 。在②中允许配置注册中心地址 ， 这样可以通过注册中心发现服务消费 。 在③中指定服务调用协议 、 IP 和端口 ， 注意这里的 URL 没有添加 refer 和注册中心协议 ， 默认是 Dubbo 会直接触发DubboProtocol 进行远程消费 ， 不会经过 Registryprotocol 去做服务发现 。

# 3 小结 #

对Dubbo 框架的几种服务暴露原理进行了详解 ， 紧接着对服务消费进行了讲解 ， 这些服务暴露和消费对所有的协议都具有参考价值 。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]: /images/20221021/99e90565e04e499c9dca9e1b91f7d990.png
[20210508192922441.png]: /images/20221021/5208790153e940a3adf79966f8f1840c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]: /images/20221021/4810b236bbba480cbde4de3275dac66a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]: /images/20221021/c34bec1b57564e30a6b6f7b8bcd6a7b0.png
[20210508193210590.png]: /images/20221021/a86edcca690740ee8df6e5019f9df474.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]: /images/20221021/4c7262d070664b279fee9ee6031cca4d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]: /images/20221021/a168e05a3e7246c3bdb5beeeef7b9442.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 5]: /images/20221021/41434d812e754de4a515901797c7866b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 6]: /images/20221021/6fb08f4de3e5426dafe9c431cfd05b3c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 7]: /images/20221021/541c76d6d6154dd5beab67ce6d920074.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 8]: /images/20221021/5b359bf5c1af45498deed4a341639e31.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 9]: /images/20221021/d1784aa887c04eabaab41ea3b62af97b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 10]: /images/20221021/388061427d684099a81d5e9ae09eddb2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 11]: /images/20221021/667292ec2acc4cf1a353108c8eab48ca.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 12]: /images/20221021/7f7329dba6d34fbb9489ac27ee0dd878.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 13]: /images/20221021/f9cd6c62884148428f4952d5915813fd.png