Dubbo源码（四）应用级别注册发现

Bertha 。 2023-10-08 23:04 38阅读 0赞

![format_png][]

## 前言 ##

本章基于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 1][]

在同一个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 2][]

### 劣势 ###

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

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

![format_png 3][]

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 4][]

应用->应用实例列表：

![format_png 5][]

应用实例信息：

![format_png 6][]

### 源码概览 ###

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

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

![format_png 7][]

![format_png 8][]

![format_png 9][]

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 10][]

## rpc服务暴露 ##

### rpc服务注册 ###

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

![format_png 11][]

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

![format_png 12][]

![format_png 13][]

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

![format_png 14][]

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

1）开启nettyserver

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

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

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

![format_png 15][]

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

![format_png 16][]

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

![format_png 17][]

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

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

![format_png 18][]

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

![format_png 19][]

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

![format_png 20][]

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

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

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

![format_png 21][]

### 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 22][]

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

![format_png 23][]

默认实现**DynamicConfigurationServiceNameMapping**：

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

![format_png 24][]

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

![format_png 25][]

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

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

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

![format_png 26][]

## 元数据服务暴露 ##

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

![format_png 27][]

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

![format_png 28][]

需要注意几个细节。

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

![format_png 29][]

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

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

![format_png 30][]

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

![format_png 31][]

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

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

## 注册应用实例 ##

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

![format_png 32][]

DubboBootstrap\#registerServiceInstance：

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

2）向注册中心注册ServiceInstance；

![format_png 33][]

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

![format_png 34][]

每个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 35][]

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

![format_png 36][]

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

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

![format_png 37][]

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

![format_png 38][]

## rpc服务引用 ##

### 主流程 ###

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

![format_png 39][]

RegistryProtocol\#doRefer：主流程不变

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

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

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

![format_png 40][]

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

RegistryDirectory\#subscribe：调用ServiceDiscoveryRegistry。

![format_png 41][]

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

![format_png 42][]

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

![format_png 43][]

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

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

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

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

![format_png 44][]

3）ServiceDiscoveryRegistry\#subscribeURLs：

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

![format_png 45][]

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

![format_png 46][]

接下来是核心：

![format_png 47][]

**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 48][]

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

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

![format_png 49][]

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

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

![format_png 50][]

根据模板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 51][]

ServiceDiscoveryRegistry\#prepareServiceRevisionExportedURLs：

![format_png 52][]

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

ServiceDiscoveryRegistry\#expungeStaleRevisionExportedURLs：

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

![format_png 53][]

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

![format_png 54][]

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

ServiceDiscoveryRegistry\#initializeSelectedRevisionExportedURLs：

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

![format_png 55][]

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

ServiceDiscoveryRegistry\#initializeRevisionExportedURLs：

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

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

![format_png 56][]

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

![format_png 57][]

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

![format_png 58][]

#### 根据模板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 59][]

## 总结 ##

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

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

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

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

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

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

![format_png 60][]

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

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

![format_png 61][]

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

![format_png 62][]

![format_png 63][]

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

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

![format_png 64][]

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

![format_png 65][]

Provider侧：

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

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

![format_png 66][]

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

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

![format_png 67][]

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://img-blog.csdnimg.cn/img_convert/3dabdf5235211220536f14897977e196.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/3778bda9a931d3fcf92d3df0aa94da2c.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/082bb982ff9e59bbf4eb5fa715548198.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/1dfd72d4a2b56f0e33fa417c74d44b14.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/e24597f87acb2822c90a899bb86d58a9.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/31e4265ec99d0be59bf6bc8c4cd7d6c6.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/102f5720cd86370fce902c7eda76f7ed.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/0f80a11dba5630810b28aac8a76d36b2.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/2476cdd91f524de4fe4a1fd6f4a462d2.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/b6a63bb39dbb50e6ad0ef3fae1c3e20f.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/fadfdafa49f7b5cd208241c7d40f5060.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/e2d6ce9d3699d51da6de5ea047aba27c.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/815e9eb8187ca12058bc4e8892ba634e.webp?x-oss-process=image/format,png
[format_png 13]: https://img-blog.csdnimg.cn/img_convert/b5fd2871fee42fdc27f36e320a5d5707.webp?x-oss-process=image/format,png
[format_png 14]: https://img-blog.csdnimg.cn/img_convert/9114afdd23db1e13c0af4be244dd56e5.webp?x-oss-process=image/format,png
[format_png 15]: https://img-blog.csdnimg.cn/img_convert/32d751d0965f7b0e9eeae6e88a0d169b.webp?x-oss-process=image/format,png
[format_png 16]: https://img-blog.csdnimg.cn/img_convert/96c4f1030a08fd3f81e4a3d0bde00079.webp?x-oss-process=image/format,png
[format_png 17]: https://img-blog.csdnimg.cn/img_convert/bec534e35df5f98e26aa18c4d0a9fb6e.webp?x-oss-process=image/format,png
[format_png 18]: https://img-blog.csdnimg.cn/img_convert/377d054854bde74ecf3d1de17379f98a.webp?x-oss-process=image/format,png
[format_png 19]: https://img-blog.csdnimg.cn/img_convert/5fb6d3a83eb4be855e001e7176885546.webp?x-oss-process=image/format,png
[format_png 20]: https://img-blog.csdnimg.cn/img_convert/ec125680ea21c4feef81dc97e4ae0c6a.webp?x-oss-process=image/format,png
[format_png 21]: https://img-blog.csdnimg.cn/img_convert/9906b1442e8d9055170be168595b0f26.webp?x-oss-process=image/format,png
[format_png 22]: https://img-blog.csdnimg.cn/img_convert/4deeb09400dfc15332e2e8737e9fde28.webp?x-oss-process=image/format,png
[format_png 23]: https://img-blog.csdnimg.cn/img_convert/9e47e220810b0b64842e20d257aad4de.webp?x-oss-process=image/format,png
[format_png 24]: https://img-blog.csdnimg.cn/img_convert/f6036d036a8667382b755077f566bcb0.webp?x-oss-process=image/format,png
[format_png 25]: https://img-blog.csdnimg.cn/img_convert/44cc3ecde0f1039d927c0887f1b5f378.webp?x-oss-process=image/format,png
[format_png 26]: https://img-blog.csdnimg.cn/img_convert/b11c544b5d7b7e5adc093d5d77216c54.webp?x-oss-process=image/format,png
[format_png 27]: https://img-blog.csdnimg.cn/img_convert/2bc2bc5a1cfe49b31db9f795e9e6bd51.webp?x-oss-process=image/format,png
[format_png 28]: https://img-blog.csdnimg.cn/img_convert/7b9204c442aa5391ba3c11dc7743386b.webp?x-oss-process=image/format,png
[format_png 29]: https://img-blog.csdnimg.cn/img_convert/b829f75b7d7484672332966c752aa392.webp?x-oss-process=image/format,png
[format_png 30]: https://img-blog.csdnimg.cn/img_convert/766ff40a13c45aa0c8d89c0501123ef9.webp?x-oss-process=image/format,png
[format_png 31]: https://img-blog.csdnimg.cn/img_convert/9cfd41359f4f4dce705bea256cc8800f.webp?x-oss-process=image/format,png
[format_png 32]: https://img-blog.csdnimg.cn/img_convert/23239755f69187d9b69909669633c57e.webp?x-oss-process=image/format,png
[format_png 33]: https://img-blog.csdnimg.cn/img_convert/7d824a349630a6cdf75d0ad01bb8d0e2.webp?x-oss-process=image/format,png
[format_png 34]: https://img-blog.csdnimg.cn/img_convert/91f6a86de986ebf2741c08f1e7ce5385.webp?x-oss-process=image/format,png
[format_png 35]: https://img-blog.csdnimg.cn/img_convert/c0b89c2026dd18fbee92585fb20e6bdf.webp?x-oss-process=image/format,png
[format_png 36]: https://img-blog.csdnimg.cn/img_convert/3cb0a6f30b4dc4ae55a837c060d25fd1.webp?x-oss-process=image/format,png
[format_png 37]: https://img-blog.csdnimg.cn/img_convert/070f595120cb35800470c0ee67e9773b.webp?x-oss-process=image/format,png
[format_png 38]: https://img-blog.csdnimg.cn/img_convert/fce0326deddb5f63f12bf8db153a557f.webp?x-oss-process=image/format,png
[format_png 39]: https://img-blog.csdnimg.cn/img_convert/2b668aa684b3a06a20737df00f10f894.webp?x-oss-process=image/format,png
[format_png 40]: https://img-blog.csdnimg.cn/img_convert/ec2851a30d683662fdf72a63202ed4b7.webp?x-oss-process=image/format,png
[format_png 41]: https://img-blog.csdnimg.cn/img_convert/6751405bc889891a9d25c08227f082d6.webp?x-oss-process=image/format,png
[format_png 42]: https://img-blog.csdnimg.cn/img_convert/7d9375d654696aec7add236c908aa828.webp?x-oss-process=image/format,png
[format_png 43]: https://img-blog.csdnimg.cn/img_convert/0575209819881990fa548b64f96dd6cf.webp?x-oss-process=image/format,png
[format_png 44]: https://img-blog.csdnimg.cn/img_convert/7045a07cbf7e76ce2c654baea134ea39.webp?x-oss-process=image/format,png
[format_png 45]: https://img-blog.csdnimg.cn/img_convert/c383599192d02678fe4078913a913074.webp?x-oss-process=image/format,png
[format_png 46]: https://img-blog.csdnimg.cn/img_convert/77a5a330995da181f19793c523b54651.webp?x-oss-process=image/format,png
[format_png 47]: https://img-blog.csdnimg.cn/img_convert/c4c316c5c8771cd585e632bc196d54c3.webp?x-oss-process=image/format,png
[format_png 48]: https://img-blog.csdnimg.cn/img_convert/cfe45548beb9969e7df5bebb6d82a888.webp?x-oss-process=image/format,png
[format_png 49]: https://img-blog.csdnimg.cn/img_convert/49f3925a10c82e924abfcd472decbbf6.webp?x-oss-process=image/format,png
[format_png 50]: https://img-blog.csdnimg.cn/img_convert/561bdebf4da1afb8041413e1acdceced.webp?x-oss-process=image/format,png
[format_png 51]: https://img-blog.csdnimg.cn/img_convert/235afef29f9e5875d66e605621eec7e4.webp?x-oss-process=image/format,png
[format_png 52]: https://img-blog.csdnimg.cn/img_convert/955d25a1d801a994cb679bacad3a28c3.webp?x-oss-process=image/format,png
[format_png 53]: https://img-blog.csdnimg.cn/img_convert/160bd9aabccb74e81f000046df03bcbd.webp?x-oss-process=image/format,png
[format_png 54]: https://img-blog.csdnimg.cn/img_convert/a64dec7c14119b069eb5fff30dcf7bb0.webp?x-oss-process=image/format,png
[format_png 55]: https://img-blog.csdnimg.cn/img_convert/bfcbbe5c1d4d9ce55046868e1b1de09f.webp?x-oss-process=image/format,png
[format_png 56]: https://img-blog.csdnimg.cn/img_convert/1beb866befdbec6661a8ea9b119ebb95.webp?x-oss-process=image/format,png
[format_png 57]: https://img-blog.csdnimg.cn/img_convert/60d6e0399a0fb3058242ee8d051fcaa9.webp?x-oss-process=image/format,png
[format_png 58]: https://img-blog.csdnimg.cn/img_convert/a14a9c583ae9b14d587e12926e1c3339.webp?x-oss-process=image/format,png
[format_png 59]: https://img-blog.csdnimg.cn/img_convert/6e7e2bf52800f4f0c38e59dc210de141.webp?x-oss-process=image/format,png
[format_png 60]: https://img-blog.csdnimg.cn/img_convert/88a67b92722c66f394587a1719a9c1cc.webp?x-oss-process=image/format,png
[format_png 61]: https://img-blog.csdnimg.cn/img_convert/6840b9d0b0bf081df6a59b2205a6efd4.webp?x-oss-process=image/format,png
[format_png 62]: https://img-blog.csdnimg.cn/img_convert/46a5256e0d2b46cdb343dc6a7bced8ca.webp?x-oss-process=image/format,png
[format_png 63]: https://img-blog.csdnimg.cn/img_convert/b97b34dbd15df4bd0014d77435fb96ee.webp?x-oss-process=image/format,png
[format_png 64]: https://img-blog.csdnimg.cn/img_convert/6c487a4bdce412b4318893b6f4904fb6.webp?x-oss-process=image/format,png
[format_png 65]: https://img-blog.csdnimg.cn/img_convert/593035cecbda232f9851e76e2894b505.webp?x-oss-process=image/format,png
[format_png 66]: https://img-blog.csdnimg.cn/img_convert/8cc02d12429b3010d178bd01c0fa00d2.webp?x-oss-process=image/format,png
[format_png 67]: https://img-blog.csdnimg.cn/img_convert/abbf5e6a62bc184445d1a6b5d41a36f1.webp?x-oss-process=image/format,png