Dubbo源码：应用级别注册发现

左手的ㄟ右手 2024-03-24 12:10 61阅读 0赞

## 前言 ##

本章基于dubbo2.7.6。

分析**应用级别服务注册与发现**特性，使用默认local模式元数据服务。

主要内容包括：

1）rpc服务级别 vs 应用级别

2）DubboBootstrap\#start API的作用，整体流程梳理

3）应用级别服务注册发现如何适配rpc服务级别老逻辑

该特性在rpc调用期间没有变更（运行期间也不依赖注册中心），主要在**启动**阶段和**注册表变更**阶段做了适配。

## 现状 ##

2.7.5之前dubbo仅支持**rpc服务级别**注册与发现。

注册中心以zk为例。

provider在暴露rpc服务阶段，向注册中心注册数据如下，在/dubbo/\{rpc服务\}/providers下列举了所有服务提供者：

![format_png][]

在同一个rpc服务下，会有多个providers，每个provider对应一个url，如：

> dubbo://127.0.0.1:20881/org.apache.dubbo.demo.DemoService?anyhost=true&application=heihei-app&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello,sayHelloAsync&pid=7451&release=&scope=remote&side=provider&timestamp=1679471005075

consumer在引用阶段，根据订阅rpc服务，找到所有providers，用url构造Invoker缓存在RegistryDirectory中。

### 优势 ###

假设DemoService要进行迁移，从a服务迁移到b服务。

在传统Dubbo中，对于consumer来说不需要关心谁提供了这个服务，不需要进行代码变更。

而用SpringCloud+OpenFeign，如果DemoService迁移，我们就需要改代码。

consumer在rpc调用阶段，从RegistryDirectory选择invoker，调用目标节点的rpc服务。

虽然FeignClient注解支持根据Environment解析占位符，但是本质上consumer对于服务迁移有感知。

![format_png 1][]

### 劣势 ###

1）和当下的流行的服务注册发现模型不匹配

比如SpringCloud服务注册发现的模型都是基于**应用级别**，每个ServiceInstance代表一个应用实例。

![format_png 2][]

2）注册中心压力大

压力大体现在几个方面：

如果1个应用有n个实例，每个实例提供m个rpc服务，则注册中心会有n\*m条数据；

如果1个实例下线，该实例有n个rpc服务，每个rpc服务有m个consumer，则注册中心需要通知n\*m个consumer；

单从zk的znode存储来看，providers的url包含了大量数据，随着特性越来越多，数据也越来越多；

## DubboBootstrap ##

针对于上述基于**rpc服务级别**服务注册发现带来的问题，dubbo提出了服务自省架构。

笔者认为通俗来说，一个是**应用级别**服务注册发现，另一个是**元数据服务**。

为了支撑新的服务自省架构，在用户侧提供了全新的**DubboBootstrap** api，统一管理dubbo的配置和启动时序。

### 案例 ###

服务提供方：

ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
    service.setInterface(DemoService.class);
    service.setRef(new DemoServiceImpl());
    // DubboBootstrap单例对象创建
    DubboBootstrap bootstrap = DubboBootstrap.getInstance();
    RegistryConfig registryConfig = new RegistryConfig("zookeeper://127.0.0.1:2181");
    registryConfig.setParameters(new HashMap<>());
    // 【关键】 开启【应用级别】服务注册发现
    registryConfig.getParameters().put(
            RegistryConstants.REGISTRY_TYPE_KEY/*registry-type*/,
            RegistryConstants.SERVICE_REGISTRY_TYPE/*service*/);
    bootstrap.application(new ApplicationConfig("hahaha-app"))
            .registry(registryConfig)
            .service(service)
            .start() // 启动dubbo
            .await();
    复制代码

服务消费方：

ReferenceConfig<DemoService> reference = new ReferenceConfig<>();
    reference.setInterface(DemoService.class);
    // 【关键】设置rpc服务提供方应用名称（可省略）
    // reference.setProvidedBy("hahaha-app");
    RegistryConfig registryConfig = new RegistryConfig("zookeeper://127.0.0.1:2181");
    // 【关键】 开启【应用级别】服务注册发现
    registryConfig.setParameters(new HashMap<>());
    registryConfig.getParameters().put(
            RegistryConstants.REGISTRY_TYPE_KEY/*registry-type*/,
            RegistryConstants.SERVICE_REGISTRY_TYPE/*service*/);
    // DubboBootstrap单例对象创建
    DubboBootstrap bootstrap = DubboBootstrap.getInstance();
    bootstrap.application(new ApplicationConfig("service-consumer-app"))
            .registry(registryConfig)
            .reference(reference)
            .start(); // 启动dubbo
    DemoService demoService = ReferenceConfigCache.getCache().get(reference);
    String message = demoService.sayHello("dubbo");
    System.out.println(message);
    复制代码

### 效果 ###

基于上述改动，provider注册到zk里的数据如下。

rpc服务->应用列表：

![format_png 3][]

应用->应用实例列表：

![format_png 4][]

应用实例信息：

![format_png 5][]

### 源码概览 ###

DubboBootstrap\#application、registry、service、reference都是往全局ConfigManager里存配置。

> ConfigManager在第二章介绍过，用于统一存储AbstractConfig

![format_png 6][]

![format_png 7][]

![format_png 8][]

DubboBootstrap\#start控制Dubbo客户端整体启动流程，一共分为5步：

1）DubboBootstrap\#initialize：初始化，之前讲传统服务暴露与引用时说到过，就是初始化全局Envrionment；

2）DubboBootstrap\#exportServices：暴露rpc服务，底层循环调用ServiceConfig\#export；

3）DubboBootstrap\#exportMetadataService：如果启用应用级别服务注册，暴露元数据rpc服务；

4）DubboBootstrap\#registerServiceInstance：如果启用应用级别服务注册，向注册中心注册应用实例；

5）DubboBootstrap\#referServices：引用rpc服务，底层循环调用ReferenceConfig\#get；

接下来除了第一步，分析后面四步。

![format_png 9][]

## rpc服务暴露 ##

### rpc服务注册 ###

ServiceConfig\#doExportUrls：在执行暴露逻辑之前，构造注册url发生变更。

![format_png 10][]

**ConfigValidationUtils\#loadRegistries**：如果设置了**registry-type=service**，则注册协议会变为**service-discovery-registry**，而不是原来的registry协议。

![format_png 11][]

![format_png 12][]

注册协议变更，不走RegistryProtocol，走**ServiceDiscoveryRegistryProtocol**继承RegistryProtocol。

![format_png 13][]

但是新的实现ServiceDiscoveryRegistryProtocol并没有重写export主方法，所以整体暴露流程还是和原来一致：

1）开启nettyserver

2）服务注册（发生变更）

由于ServiceDiscoveryRegistryProtocol\#getRegistryUrl重写，所以最终**Registry实现发生变更**。

其实这个方法不重写，逻辑上也没有问题，主要是消费侧的那个getRegistryUrl要重写。

![format_png 14][]

RegistryProtocol\#register：这里registryUrl的协议从zookeeper变为service-discovery-registry。

![format_png 15][]

原来工厂会创建一个具体的注册中心Registry，如**ZookeeperRegsitry**。

![format_png 16][]

现在变更为service-discovery-registry实现，工厂创建**ServiceDiscoveryRegistry**。

ServiceDiscoveryRegistry内部url协议是具体注册中心协议，如zookeeper。

![format_png 17][]

ServiceDiscoveryRegistry调用元数据服务，暴露url。

![format_png 18][]

元数据服务分为两大类，一类是local本地内存元数据服务，一类是远程remote中心化元数据服务（比如zk、nacos）。

![format_png 19][]

**默认使用InMemoryWritableMetadataService，本地元数据服务**。

将暴露url存储到内存map中，key是serviceKey（接口+分组+版本），value是原始暴露url。

**相当于将原来注册到zk的providers节点下的url，注册到了内存中**。

![format_png 20][]

### rpc服务与应用映射 ###

在服务暴露之后，ServiceConfig\#exported发送服务暴露完成事件。

public synchronized void export() {
        // 【step1】2.7.5新单例api 初始化Environment全局配置
        if (bootstrap == null) {
            bootstrap = DubboBootstrap.getInstance();
            bootstrap.init();
        }
        // 【step2】serviceConfig二次填充并校验
        checkAndUpdateSubConfigs();
        // 【step3】暴露【核心】
        doExport();
        // 2.7.5 发布ServiceConfigExportedEvent事件
        exported();
    }
    复制代码

![format_png 21][]

**ServiceNameMappingListener**调用ServiceNameMapping\#map。

![format_png 22][]

默认实现**DynamicConfigurationServiceNameMapping**：

**用配置中心保存rpc服务和应用的映射关系**。

![format_png 23][]

对于zk来说，保存znode=/dubbo/config/mapping/rpc服务/应用名。

![format_png 24][]

为什么在没有设置配置中心的情况下，这里会走zk来存储？

因为在DubboBoostrap\#initialize中做了特殊处理。

如果用户没有设置配置中心，且注册中心具备配置中心能力（zk、consul、nacos），就会用注册中心作为配置中心使用。

![format_png 25][]

## 元数据服务暴露 ##

回到DubboBoostrap\#start，在所有rpc服务暴露完成后，执行DubboBoostrap\#exportMetadataService。

![format_png 26][]

底层**ConfigurableMetadataServiceExporter**将Dubbo自己内部的MetadataService暴露为rpc服务。

![format_png 27][]

需要注意几个细节。

第一，由于使用ConfigManager管理的全局注册中心配置，所以这里registry-type还是service，暴露流程和应用级别服务注册一致。

![format_png 28][]

区别在于MetadataService不会向配置中心发布rpc服务和应用的映射关系。

即对于zk配置中心，/dubbo/config/mapping下不会存在MetadataService。

![format_png 29][]

第二，MetadataService固定使用Dubbo协议，且端口从20880向上找到一个未被占用的port。

![format_png 30][]

这意味着通讯层会为了MetadataService会新开一个NettyServer。

元数据rpc服务和业务rpc服务底层通讯io线程和业务线程都是隔离的。

## 注册应用实例 ##

回到DubboBootstrap\#start，在暴露元数据服务之后，注册应用实例。

![format_png 31][]

DubboBootstrap\#registerServiceInstance：

1）获取serviceName、host、port，封装ServiceInstance应用实例模型；

2）向注册中心注册ServiceInstance；

![format_png 32][]

一个注册中心对应一个ServiceDiscoveryRegistry。

![format_png 33][]

每个ServiceDiscoveryRegistry会根据实际注册中心协议，创建一个**ServiceDiscovery**实例。

public class ServiceDiscoveryRegistry extends FailbackRegistry {
    
        private final ServiceDiscovery serviceDiscovery;
    
        public ServiceDiscoveryRegistry(URL registryURL) {
            super(registryURL);
            this.serviceDiscovery = createServiceDiscovery(registryURL);
            // ...
        }
    }
    复制代码

比如zookeeper对应**ZookeeperServiceDiscovery**。

![format_png 34][]

ZookeeperServiceDiscovery利用Curator客户端扩展包curator-x-discovery实现应用实例注册。

![format_png 35][]

正因为使用**应用级别注册**，curator-x-discovery可以直接使用。

相比较**rpc服务级别注册**，dubbo需要自己写逻辑。

![format_png 36][]

curator-x-discovery底层创建"/services/应用/实例地址"临时znode。

![format_png 37][]

## rpc服务引用 ##

### 主流程 ###

rpc服务引用，和provider一样，由于配置了registry-type=service，底层Registry变为ServiceDiscoveryRegistry，导致服务引用行为发生变更。

![format_png 38][]

RegistryProtocol\#doRefer：主流程不变

1）Directory\#subscribe：向注册中心订阅并注册监听

2）Directory\#subscribe：首次同步刷新RegistryDirectory中的内存注册表（invokers）

3）Cluster\#join：将RegistryDirectory通过Cluster封装为Invoker

![format_png 39][]

区别在于Registry从ZookeeperRegistry变为**ServiceDiscoveryRegistry**。

RegistryDirectory\#subscribe：调用ServiceDiscoveryRegistry。

![format_png 40][]

**ServiceDiscoveryRegistry\#subscribeURLs**：这里是应用级别服务发现的核心逻辑入口

![format_png 41][]

1）InMemoryWritableMetadataService\#subscribeURL：在元数据服务内存中存储订阅url

![format_png 42][]

2）ServiceDiscoveryRegistry\#getServices：根据订阅rpc服务找应用

优先走用户配置reference.providedBy指定的应用（可多个）；

否则走配置中心，取serviceKey对应所有应用；

比如zk取/dubbo/config/mapping/rpcService下的所有应用。

![format_png 43][]

3）ServiceDiscoveryRegistry\#subscribeURLs：

找应用的应用实例，构造providerUrls，通知RegistryDirectory。

![format_png 44][]

根据应用找应用实例比较简单，对于zk来说，就是找"/services/应用"下的所有节点，构造ServiceInstance实例。

![format_png 45][]

接下来是核心：

![format_png 46][]

**ServiceDiscoveryRegistry\#getExportedURLs：找对应元数据，拼接rpc服务级别url，从而实现适配老逻辑**；

RegistryDirectory\#notify：老逻辑，根据providerUrls构造Rpc协议Invoker，放入内存；

### 怎么适配 ###

为了适配rpc服务级别注册发现，实现的关键是将现有的信息转换为原来注册中心的providerUrl，比如zk中/dubbo/\{rpc服务\}/providers存储的urls。

#### 暴力 ####

循环所有ServiceInstance，调用对应ServiceInstance的MetadataService Rpc服务，获取对端暴露的url。

但是一般情况下，同一个应用提供的所有rpc服务都是一样的。

#### revision ####

所以这里会提出一个revision的概念，revision相同代表元数据相同。

> 比如rpc方法A，在不同应用实例中，配置的超时时间可能不同，就会导致元数据不同。

那么相同revision的情况下，多个ServiceInstance只需要调用一次MetadataService，调用次数取决于revision数量。

在provider应用实例注册之前会计算一个revision，代表当前ServiceInstance负责的所有rpc服务信息。

URLRevisionResolver\#resolve：

1）统计所有rpc服务参数、rpc服务方法，整理成一个有序String集合

2）用URLRevisionResolver\#hashCode计算哈希值

3）将所有哈希值求和作为最终的revision

其实也比较容易想到，这个revision就是提取当前应用实例的关键信息，形成一个摘要，比如md5等算法也可以。

![format_png 47][]

将这个revision连同ServiceInstance一同注册到注册中心，给consumer拼接provider的url做准备。

比如zk注册中心/services/hahaha-app/127.0.0.1:21880节点数据包含**dubbo.exported-services.revision**，就是上面计算出来的revision。

![format_png 48][]

对于consumer来说，同一个revision对应同样的元数据，对应多个url（多个rpc服务），这些url称为模板url。

**ServiceDiscoveryRegistry\#serviceRevisionExportedURLsCache**：缓存模板url，应用名->revision->模板urls。

![format_png 49][]

根据模板url，多个ServiceInstance只需要改变host和port就能构造出多个providerUrl，适配老逻辑的同时减少了MetadataService远程调用。

#### 热点问题 ####

如果/services/hahaha-app节点下有多个应用实例，且revision相同。

对于consumer来说请求谁来获取元数据呢？

如果每个consumer都走第一个实例获取，那么将会导致热点问题。

所以目前dubbo的实现是随机选实例调用MetadataService。

### 适配逻辑 ###

整体流程如下。

ServiceDiscoveryRegistry\#getExportedURLs：

1）计算revision对应模板url

1-1）去除缓存中过期的revision

1-2）重新根据revision初始化模板urls

2）根据模板url，改变host和port，得到所有url

![format_png 50][]

ServiceDiscoveryRegistry\#prepareServiceRevisionExportedURLs：

![format_png 51][]

#### 去除过期revision ####

ServiceDiscoveryRegistry\#expungeStaleRevisionExportedURLs：

从缓存里获取应用名对应revision和模板urls，删除注册中心中不存在的revision，保留注册中心中存在的revision。

![format_png 52][]

ServiceDiscoveryRegistry\#initializeRevisionExportedURLs：初始化revision对应模板url。

![format_png 53][]

#### 初始化模板url ####

ServiceDiscoveryRegistry\#initializeSelectedRevisionExportedURLs：

为了避免热点问题，会先走RandomServiceInstanceSelector\#select随机选择ServiceInstance调用MetadataService获取暴露urls，这部分忽略，我们直接看公共方法initializeRevisionExportedURLs。

![format_png 54][]

随机选实例之后，还有可能有revision的模板url没覆盖到，所以循环所有ServiceInstance再来走一次initializeRevisionExportedURLs。

ServiceDiscoveryRegistry\#initializeRevisionExportedURLs：

判断缓存中是否有ServiceInstance.revision对应模板urls，

如果没有，需要走rpc调用ServiceInstance对应MetadataService\#getExportedURLs()获取对端暴露的所有rpc服务urls。

![format_png 55][]

这里MetadataService是一个rpc服务代理，和普通referenceConfig差不多，不深入分析。

![format_png 56][]

provider会收到consumer查询暴露url的rpc请求，返回自己暴露的所有url，即InMemoryWritableMetadataService\#exportedServiceURLs。

![format_png 57][]

#### 根据模板url构造所有url ####

ServiceDiscoveryRegistry\#cloneExportedURLs：最终根据模板urls构造所有provider暴露url，比如：

dubbo://127.0.0.1:20990/org.apache.dubbo.demo.DemoService，

dubbo://127.0.0.1:20880/org.apache.dubbo.demo.DemoService。

![format_png 58][]

## 总结 ##

本章分析了应用级别服务注册与发现的特性。

**启用该特性需要两步**：

1）使用DubboBootstrap Api，统一管理dubbo启动；

2）RegistryConfig需要配置registry-type=service；

**启用该特性后zk中的注册数据会发生变化**：

启用前，在/dubbo/\{rpc服务\}/providers下列举了所有服务提供者。

![format_png 59][]

**启用后，数据被分为三份**：

1）rpc服务->应用列表：/dubbo/config/mapping/\{rpc服务\}/\{应用\} - 注册时间

![format_png 60][]

2）应用->应用实例列表：/services/\{应用\}/\{实例地址\} - 实例信息

![format_png 61][]

![format_png 62][]

3）元数据都：放在内存**InMemoryWritableMetadataService**本地内存元数据服务中

最关键的是当前实例暴露的所有url，即原来/dubbo/\{rpc服务\}/providers下当前实例暴露的urls。

![format_png 63][]

应用级别会适配老逻辑，所有适配在启动阶段完成（1-7），整体流程如下：

![format_png 64][]

Provider侧：

1）ServiceConfig\#doExport：暴露rpc服务，开启底层通讯Server

2）ServiceNameMapping\#map：向配置中心发布rpc服务和应用名称的关系

![format_png 65][]

3）DubboBootstrap\#exportMetadataService：暴露内置的元数据rpc服务，开启底层通讯Server

4）DubboBootstrap\#registerServiceInstance：向注册中心注册应用实例

![format_png 66][]

Consumer侧：

5）ServiceDiscoveryRegistry\#getServices：根据rpc服务，从配置中心获取应用列表

> 比如zk取/dubbo/config/mapping/\{rpc服务\}下的所有znode

注：设置ReferenceConfig.providedBy可以指定应用列表，则可以不依赖配置中心。

6）ServiceDiscoveryRegistry\#subscribeURLs：根据5的应用列表，从注册中心获取应用下所有实例

> 比如zk取/services/\{应用名\}下所有znode

7）ServiceDiscoveryRegistry\#getExportedURLs：新老逻辑适配的核心。

对6的部分应用实例，发起rpc调用MetadataService\#getExportedURLs，获取provider暴露url，拼接后通知RegistryDirectory构建invoker。

> rpc调用次数取决于第六步中应用实例的revision数量

8）rpc调用阶段，所有逻辑不变

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/9049bbd8dab34d8f98f3caeba9e0c2d1.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/422e4f2f041e46729ec61010fe18ccb8.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ab57210fe34b4ae98dface724ec81e75.png
[format_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/5848936a5f124962bd5d0fbba1c457e2.png
[format_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/b0cb3afac64c49668208e34f3036a7ec.png
[format_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/5acc78fb314c45f8bef68ea1c3f71efe.png
[format_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/bc6a587b63e942d38106a7805d6c3aad.png
[format_png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/aee30e5e13394c639f6d7b552b8db61a.png
[format_png 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/71533c51fb0e448698422079a3d78a31.png
[format_png 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f6efe8e8901541f6bf68c6c757d6d1db.png
[format_png 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a3a4ef54d81d49d3b6dbb1756d3e250c.png
[format_png 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a1c47347d13c404b8b65bc3101ca5c13.png
[format_png 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f3cf737190704365bb06c92c73cd5271.png
[format_png 13]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/e8dafabd11334757b317ddc87064de36.png
[format_png 14]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/fa14ddd96dbf424ba96f7e3d8212ba8a.png
[format_png 15]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ec7eb7f1099d421db9478720966389ac.png
[format_png 16]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/d7699fa2aee84e53a6e4d2f56d3e39f8.png
[format_png 17]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/9fca9e0b63164a2eb7f8fba483c6150c.png
[format_png 18]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/c37449635a1c492a9b815ca5432204af.png
[format_png 19]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/1bae92487789473b997486db0fa5840d.png
[format_png 20]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ef7902b5d9e04e26b020da51b2f436d5.png
[format_png 21]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/eac4071306a0447282edc2b0a62bc7ba.png
[format_png 22]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/0eb15fa08885450d9a20c7e7e482df75.png
[format_png 23]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/126ec76ea1774bef8681a387f6f9f830.png
[format_png 24]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/191244bb67154c7198cbcd720c10daa4.png
[format_png 25]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/3c0ad43f6be64c79aac5d63e23927d66.png
[format_png 26]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/8c0c41e4418845e8b410ef8548f524e9.png
[format_png 27]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/fff8e3def5fa45cdb1e34df93367f711.png
[format_png 28]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/78e26d1ccee84c6193c9e58a4c25bef7.png
[format_png 29]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/768b0c44ec8a422eb58e3c84c988478d.png
[format_png 30]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/62d284cbe8734a92ae2ef0619e2f93dc.png
[format_png 31]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f29219ad18d34d9892c60514ba1f97c5.png
[format_png 32]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/8f70883f297f4368a302d39b709b4544.png
[format_png 33]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/9c81c71830d24753a30923103f20ac68.png
[format_png 34]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/4328fcfd5a5d427eb8b6b4a7e4dc1812.png
[format_png 35]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/7b8c627f166049ed99ee8f17669d9641.png
[format_png 36]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/52fd17c1194840a4a5d92516cb14fc09.png
[format_png 37]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/aaad291951a144cf864b916411a57b0a.png
[format_png 38]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/e68ab3e083174e20a8a93b5b84926248.png
[format_png 39]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/b4541fc1f17149788576cf8fc23a6f9c.png
[format_png 40]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/5771c117436f43309ccfdd5a2421fdbf.png
[format_png 41]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ce91fe21590d4a42b369482ad5b4f151.png
[format_png 42]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/6b7a6ceecd934c63b599a3e1f9f4bd61.png
[format_png 43]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/b17684144d1c481089b56be0ed9564a1.png
[format_png 44]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/43ad3f0548f840fe85254481002ab188.png
[format_png 45]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/2e325a47f3224649877db9fb2b05f440.png
[format_png 46]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/5215cc9fb17144c8b78effadf7b303fc.png
[format_png 47]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/fa42bd0bad0547f99ad63ed260d0d096.png
[format_png 48]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/3b1407a91a83414f88c2e943e92c1ad5.png
[format_png 49]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/fa870b84f68d4388a37b3ba57d015007.png
[format_png 50]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/e0eac71e494a4fd4a7ee0851aba2c7b8.png
[format_png 51]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/c1f2056194ae413395d0ca4c2e1a2f2c.png
[format_png 52]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ec30963e03a94f68acdc9e7b8d9c529b.png
[format_png 53]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/7a2324fd1aa042c0927a48d05f7ae25d.png
[format_png 54]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/25c94a5a76564bcabb01eaf9462e1ac3.png
[format_png 55]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a4fc075dbef54b80b9e237c5c93911b9.png
[format_png 56]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/78973cf9cb0d44628bced4e63c678cec.png
[format_png 57]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/b638ea002a35472ab0c706ddc01789cc.png
[format_png 58]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a537dbe44bc04c0ba0e06a696446e9bf.png
[format_png 59]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/9de2fd8c27f943b6bead5676397d2afb.png
[format_png 60]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/c00541c1d8a14c419f179819dc6368f2.png
[format_png 61]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/12cdc287aeec4b92a4d06b8e4acaf487.png
[format_png 62]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/8f712a1ddd58428789945d582c10859f.png
[format_png 63]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/375e3cede8cd40908069dca6db842a6f.png
[format_png 64]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/b64e62b6487f4d0599039487ae9ac384.png
[format_png 65]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/482a3a0e939246b495eb1498e6f3173e.png
[format_png 66]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ac822f25e50a4679903fbe10ca4fa229.png