4 istio的策略和遥测与适配器

- 日理万妓 2023-01-17 13:55 81阅读 0赞

Istio中策略和遥测要解决的问题、实现原理和使用方式;并讲解Istio基于Adapter机制提供的Prometheus、Fluentd、Quota 等策略和遥测功能，包括这些Adapter的工作机制和使用方法等;并基于这种扩展机制在不修改代码的情况下收集服务的运行数据和 执行策略。

4.1 istio策略和遥测的原理

4.1.1 应用场景  
除了需要具备服务治理功能，还需要知道服务运行的怎么样、有没有问题、以及哪里有问题等。  
这一班是APM的职能，设计数据采集、存储、检索。

1、传统的遥测数据收集方式  
将数据采集的代码混合到业务代码中，会侵入业务代码。  
如图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70][]

问题场景  
1）apm升级，如协议发生了变化，从Restful改为gRPC  
2）apm上报字段被修改，如领导需要多关心一个信息。  
上面的场景业务都没有修改，但是由于apm对业务的侵入，导致apm修改时，业务需要同时修改。

2 sidecar的遥测数据收集  
sidecar代理了业务的各种能力，监控数据采集流程如图：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1][]

访问都被透明的Sidecar代理了，可以通过Sidecar代理上报监控数据。

为了提供综合的APM能力，需要上报多种数据，即可能会对接多个APM后端，  
问题：  
如果以上任何一个 APM 后端的上报格式或者其他逻辑有变更， Sidecar 就必须要升级。  
如果用户因为业务需要再对接一个新的APM，则不但整个访问拓扑更乱，每个 Sidecar 都还要重新开发去支持这个后端，然后全局升级。

3 istio基于mixer的遥测数据收集  
在遥测数据采集场景下，Istio更前进了一步，将Envoy里的这部分 功能提取出来，放到一个服务端组件Mixer上，在逻辑上将Envoy和各种遥测数据的收集解耦，并将Envoy 和真正的遥测后端解耦。  
应用、代理、遥测后端的关系如下图：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 2][]

上面三种场景下mixer的表现：  
◎ 场景 1:当 APM协议改变时，只需修改 Mixer对接的 Adapter的对应接口即可，数据面代理无须随 之变更。  
◎ 场景 2:当某个 APM上报的数据格式发生变化时，只需修改 Adapter的数据定义即可，数据面代 理无感知。  
◎ 场景3:在对接一个新的后端时，只需基于Mixer的Adapter机制开发一个对应的Adapter即可，数据 面代理无感知。

4.1.2基于mixer遥测数据收集的工作原理  
mixer的adapter机制，主要流程如图：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 3][]  
每个经过 Envoy的请求都会调用Mixer上报数据，流程主要有两步：  
1）Envoy生成数据并将数据上报给Mixer，例如Envoy生成一条服务A访问服务B的数据，包括时 间、服务A的IP、服务B的IP等  
2）Mixer调用对应的服务后端处理收到的数据，例如Mixer调用一个APM的Adapter，通过这个 Adapter将数据上报到APM后端

Adapter里封装了对数据的处理逻辑和和对后端服务的调用接口，提供通用接口供Mixer调用，然后将调用转到对应的后端服务。

4.1.3 属性及其表达式  
1 istio属性的含义  
envoy上报的数据在istio中被称为属性，描述服务请求或服务运行环境的信息。  
每个属性都包括一个属性名和属性类型，如下图：  
![20210429175932227.png][]

2.Istio支持的属性表达式  
把右边的属性赋给左边的字段，比如在Metric的数据中 收集的 response\_code就是 response.code这个属性在请求中的取值，具体属性包括：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 4][]

除了直接使用上面的属性，在 Istio 中允许基于表达式描述属性。例如  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 5][]

例如，若response.code为空， response\_code就会被赋默认值200。  
这在Mixer中是简单的表达式，实际上，在Metric的定义中经常 有这样一个reporter字段，可以通过如下表达式描述Metric是从source还是destination端上报上去的:  
![20210429180140147.png][]

4.1.4 mixer的配置模型  
通过handler(业务处理)、Instance(数据定义)和 Rule(关联规则)这三个资源对象来描述对Adapter的配置。  
在Rule中定义了基于满足match条件的请求构造的Instance对象，并 将Instance对象发送给配置的Handler处理。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 6][]

1 handler  
首先mixer中是支持多种adapter的，不同的adapter有不同的配置，也可以看成是不同的模板。  
handler就是对某模板的一个具体实现。

mixer支持如下图所示的adapter：

![20210429180246906.png][]  
下面是stdio对应的adapter模板定义，  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 7][]

handler是adapter定义的模板的实现，通过给模板上的参数赋值来进行实例化。一个adapter可以有任意多个实现。  
如下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 8][]

Handler对outputAsJson参数的赋值为true，表示使用JSON的格式输出。

handler的定义规则;  
◎ name:必选字段，为Handler的名称，在Rule中引用的正是这个字段定义的Handler名称。  
◎ compiledAdapter:必选字段，为进程内Adapter的名称，匹配Mixer的一个Adapter，其实就是  
Adapter代码中的常量定义。  
◎ adapter:必选字段，非进程内的Adapte名称，是Adapter代码中的常量定义。  
◎ params:在 Handler中配置的参数。例如，本节的配置示例在 Stdio的 Adapter中定义了多个参数，  
在Handler的Manifest中对参数进行配置。  
◎ connection:配置对一个进程外的 Adapter 的连接信息，主要是一个 Adapter 服务的地址。当然， 根据Adapter的要求，还包括相关认证的配置。

2 instance  
定义了Adapter要处理的数据对象，通过模板为Adapter提供对元数据的定义。  
mixer通过instance把来自代理的属性拆分并分发给不同的适配器。  
日志的instance配置如下图  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 9][]

Instance包括如下几个重要字段。  
◎ name:必选字段，指Instance的名称。在Rule的Action定义中引用该名称表示对该Instance的引用。  
◎ compiledTemplate:必选字段，指模板名，匹配编译模板名。  
◎ template:必选字段，指模板名，匹配非编译模板名。  
◎ params:必选字段，真正的参数定义。不同的模板会有不同的参数定义及不同的参数赋值和配  
置。  
◎ attributeBindings:用来配置将Adapter生成的属性映射到属性列表中。

3 Rule    
配置匹配规则，告诉 Mixer有哪个 Instance 在什么时候被发送给哪个 Handler来处理。

如下所示为给stdio配置一个规则:将协议是HTTP或者gRPC的请求转发到Stdio这个Handler上，并且 通过logentry这个Instance定义处理的数据格式:  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 10][]

rule的规则定义主要包括两个字段：  
1)match:是一个必选字段，表示匹配条件。Mixer在收到请求时会根据该条件来决定是否执行在 下面的actions中定义的动作。  
如果未定义条件，则判定为总是匹配。当然，最常见的是使用属性的操作表达式来描述条件，  
例如match(source.workload.name，"forecast\*")或者一般的context.protocol=="http"||context.protocol=="grpc"这种。  
(2)actions:是一个数组，表示在满足条件后执行的动作。主要包括如下信息。  
◎ handler:必选字段，Handler名称，需要是全名。  
◎ instances:Instance 的全名，通过解析字段的取值来构造 Instance，并将构造的对象传给定义的  
handler。

4.2 istio遥测适配器配置  
4.2.1 prometheus适配器  
先介绍prometheus:当前应用最广的开源系统监控和报警平台，存在数据此埃及能力强、查询语法灵活、扩展性强、方便集成的特点，尤其与云原生生态的结合，获得了越来越广泛的应用。

prometheus的工作原理如图所示：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 11][]

prometheus主要工作为：抓取数据存储，提供PromQL语法进行查询，对接Grafana\\Kiali等dashboard进行显示。

1 adapter的功能  
一般可以使用Promethus提供的各种语言的sdk在业务代码中添加Metric的生成逻辑，通过http发不满足格式的metric接口。  
更通用的方式是提供Prometheus Exporter的代理，和应用一起部署，收集应用的Metric并将其转换成Prometheus的格式发布出来。

Exporter方式的最大优点不需要修改用户的代码，所以应用非常广泛。Prometheus社区提供了丰富的 Exporter 实现(https://prometheus.io/docs/instrumenting/exporters/)，除了包括我们熟知的 Redis、 MySQL、TSDB、Elasticsearch、Kafka 等数据库、消息中间件，还包括硬件、存储、HTTP服务器、日志 监控系统等。

如图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 12][]  
在Istio中通过Adapter收集服务生成的Metric供Prometheus采集，这个Adatper就是 Prometheus Exporter的一个实现。  
上图中完整流程如下：  
(1)Envoy通过Report接口上报数据给Mixer。  
(2)Mixer根据配置将请求分发给Prometheus Adapter。  
(3)Prometheus Adapter通过HTTP接口发布Metric数据。  
(4)Prometheus 服务作为 Addon 在集群中进行安装，并拉取、存储 Metric 数据，提供Query接口进  
行检索。  
(5)集群内的Dashboard如Grafana通过Prometheus的检索API访问Metric数据。

2 prometheus的adapter的配置  
1）hander配置  
(1)metricsExpirationPolicy:配置 Metric 的老化策略，metricsExpiryDuration 定义老化周期， expiryCheckIntervalDuration定义老化的检查间隔。  
实例如下图：

![20210429191105122.png][]

含义：可清理5分钟未更新的Metric，并且每隔30秒做一次检查，检查  
周期 expiryCheckIntervalDuration 是个可选字段，若未配置，则使用老化周期的一半时间:  
(2)metrics:配置在Prometheus中定义的Metric。这里是一个数组，每个元素都是一个MetricInfo类 型的结构，分别定义Metric的namespace、name、instanceName、description、kind、buckets、 labelNames，这些都是要传给Prometheus的定义。有以下几个注意点。  
◎ Metric的namespace和name会决定Prometheus中的Metric全名。例如requests\_total这个请求统计的 Metric对应图4-13中Prometheus的Metric:istio\_requests\_total，即由命名空间istio和Metric名称requests\_total 拼接而成。  
◎ instanceName是一个必选字段，表示instance定义的全名。  
◎ kind 表示指标的类型，根据指标的业务特征，请求计数 requests\_total 的类型为COUNTER，请求 耗时 request\_duration\_seconds 的类型为 DISTRIBUTION。对于DISTRIBUTION类型的指标可以定义其 buckets。

Prometheus Handler 的一个定义示例，定义了 15 秒的老化时间及Prometheus中的多个 Metric，有的是HTTP的Metric，有的是TCP的Metric  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 13][]

2)Instance的配置  
Metric Instance的定义如图

![20210429191257985.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 14][]

说明：  
dimensions记录每个请求上的重要属性信息。  
value:"1"表示每个请求被记录一次。

3）rule配置  
通过 Rule可以将 Handler 和 Instance建立关系，例如，下面两个 Rule可以分别处理HTTP和TCP的 Instance:  
如图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 15][]

4.2.2 Fluentd适配器  
Fluentd 是一个被广泛应用的开源日志数据收集器，提供了可高度定制化的功能，通过简单的配置，  
可以将不同来源的日志收集到对应的日志后端。  
Adapter通过Fluentd收集日志并与Elasticsearch、Kibana相结合的一个典型场景。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 16][]

4.2.3 statsD适配器  
StatsD 接收客户端发送来的数据，将数据解析、聚合并定期推送给后端，一 般是个时序数据库，再通过Dashboard显示。StatsD默认在UDP上监听数据，速度很快。

4.2.4 stdio适配器  
Stdio只是将数据通过标准输出打印出来，Mixer的Stdio Adapter也是最简单的一种数据输出。

4.2.5 zipkin适配器  
Zipkin是较早出现的一种开源实时分布式调用链跟踪系统，也是对大名鼎鼎的Dapper论文的比较经典 的实现。Zipkin 提供了一种完整的从调用链埋点、收集、存储、检索到UI的完整方案。虽然后期出现的 Opentracing标准和以Jaeger为代表的新的调用链框架获得了越来越多的关注和使用，Zipkin的使用仍然广 泛。

4.2.6 厂商适配器

4.3 Istio策略适配器配置  
除了遥测数据收集，Istio Adapter 机制的另外一个重要应用是策略执行。  
策略执行Adapter 负责处理 Mixer 转发的 Check 请求，并将该请求分发给对应的策略执行后端，根据后端的判断逻辑返回拒绝或通过，来控制网格内服务之间的访问。

4.3.1 List适配器  
最简单的判断逻辑的 Adapter，它配置了一个黑名单或者白名单，匹配白名单则放行; 匹配黑名单则拒绝。  
1.Handler的配置 对Handler的配置如下。  
◎ providerUrl:名单的地址，当使用本地名单时可以不进行配置。  
◎ refreshInterval:获取名单的刷新间隔。  
◎ ttl:名单保存时长。  
◎ cachingInterval:缓存的间隔。  
◎ cachingUseCount:缓存的记录数。  
◎ overrides:重要字段，该列表中的名单覆盖从providerUrl获取的名单。  
◎ entryType:名单条目的类型，可以是STRINGS、CASE\_INSENSITIVE\_STRINGS、  
IP\_ADDRESSES 和 REGEX，分别表示字符串、大小写不敏感的字符串、IP 地址(段)和表达式。 ◎ blacklist:是否是黑名单，影响匹配后的判断逻辑。 如下所示配置了一个白名单的Handler，只有满足IP段条件的检查通过:  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 17][]

2.Instance的配置  
策略执行的模板一般比遥测数据的模板简单，就是配置待检 查的字段，在如下Instance中定义了从请求中提取IP作为检查输入。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 18][]

3.Rule的配置  
配置如下Rule关联Handler和Instance，只有来源负载上标签是"forecast"的请求执行名单检查:  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 19][]

4.3.2 Denier适配器  
Denier适配器也是一个比较简单的Adapter，按照配置总是返回拒绝。  
1.Handler的配置  
Denier 适配器的 Handler 的主要配置(见图 4-26)就是定义拒绝的状态信息 status，包括状态码  
(code)、消息(message)和详情(details)，类似在写代码时定义的异常信息。还有两个有意思的字 段:validDuration和validUseCount，分别表示有效间隔和有效次数。当时间不超过validDuration时，检查 次数若不超过validUseCount，则不再做检查。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 20][]  
在满足条件时将会返回“1333”状态码:

2.Instance的配置   
Denier的检查对象同List名单中的检查对象定义。

3.Rule的配置  
只需配置如下所示的 Rule 让上面的 Handler 生效，来自标签为“forecast”的服务请求就都会被拒绝， 并返回“1333”状态码  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 21][]

4.3.3 Memory Quota适配器  
使用场景是设置一个生效时间进行限流，即 设置在一个时间段内的访问配额。

4.3.4 Redis Quota适配器  
具备 HA 能力，功能类似Memory Quota

4.4 Kubernetes Env适配器配置  
用于提取Kubernetes中服务的元数据并交给后续的Adapter处理。

下面是一个具体场景：  
在Envoy上报数据时，在上报的访问源和目标信息中一般只包含IP等基础信 息，不会包含服务的命名空间信息，但后端APM需要基于命名空间对数据进行分组管理。这时基于负载 的标识关联和补齐其他需要的属性就可以通过Kubernetesenv Adapter来实现，补齐的属性就可以在后续的 APM Adapter中使用。

1.Handler的配置  
Kubernetes Env最主要的一个参数是通过kubeconfigPath配置Kubeconfig的文件位置，即找到Kube- apiserver，从Kube-apiserver上获取需要的信息。配置如下:  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 22][]

2.Instance的配置  
在Kubernetes Instance中定义Kubernetesenv Adapter如何发现和生成需要的与Pod相关的数据，如下所 述。  
◎ sourceUid:源Pod的UID。  
◎ sourceIp:源Pod的IP。  
◎ destinationUid:目标Pod的UID。  
◎ destinationIp:目标Pod的IP。  
◎ destinationPort:目标容器的端口。

另外，通过定义 attribute\_binding 将 Kubernetesenv Adapter 输出的属性绑定到 Mixer的属性上，可以  
供其他Adapter使用。  
在Kubernetes Output模板中能提取的属性如下。  
(1)源 Pod 的信息:sourcePodUid、sourcePodIp、sourcePodName、sourceLabels、  
sourceNamespace、sourceServiceAccountName、sourceHostIp、sourceWorkloadUid、 sourceWorkloadName、sourceWorkloadNamespace、sourceOwner。  
 (2)目标 Pod 的信息:destinationPodUid、destinationPodIp、destinationPodName、  
destinationContainerName、destinationLabels、destinationNamespace、destinationService AccountName、 destinationHostIp、destinationOwner、destinationWorkloadUid、destination WorkloadName、 destinationWorkloadNamespace。

istio安装时会定义Kubernetes的如下模板实例，  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 23][]

3.Rule的配置  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 24][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70]: /images/20221021/845ff23d546648b7a59a0fc3d425248a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1]: /images/20221021/de423c2dab8a4926b007053256ae7534.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 2]: /images/20221021/d4e84aa9e8a041ed8c3ea9c82eb9a156.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 3]: /images/20221021/db5ac6ada3e24231a41833bd830b97d8.png
[20210429175932227.png]: /images/20221021/0c8d312e90724ec1a2c74006d17f5490.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 4]: /images/20221021/d6f482af620f49748973372de8bd07e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 5]: /images/20221021/06bea959bef742cbbfb06f5fee5a1c80.png
[20210429180140147.png]: /images/20221021/8acd085a3ce149ff9c835f5e1b59cd69.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 6]: /images/20221021/2d36f31f53264d2cb81a689930497e35.png
[20210429180246906.png]: /images/20221021/91cd40e2a6fd46608746cb6cf58b3925.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 7]: /images/20221021/7b79e669af3b434ebd13c28484ef92b5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 8]: /images/20221021/f975be8f55e7498f856903c0eb1a2563.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 9]: /images/20221021/7e292507186e4afab8757e71faf1dc9b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 10]: /images/20221021/be375eaee3a14b82bdaac4bfa7beb541.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 11]: /images/20221021/86196b9fbc944e738337953de94d5c0f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 12]: /images/20221021/7eea4e1fcb714e65aa8d6960a6f2330f.png
[20210429191105122.png]: /images/20221021/696da72f4d024c3bb1d1307eb521af82.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 13]: /images/20221021/597fbf4a65714c1fb9c8479be341b4f9.png
[20210429191257985.png]: /images/20221021/835651a4b706428a90609cb2c6a03007.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 14]: /images/20221021/d403518ed20f4d1dbd2730c31c399cda.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 15]: /images/20221021/6a4f6cb6a4a041189328f9a1e2f65bf6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 16]: /images/20221021/7aca4b34cfb946df9f8d20ea0f5630e8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 17]: /images/20221021/23501e7312774f03a0161cf57f4713d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 18]: /images/20221021/966202a31277402285e45963846c6612.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 19]: /images/20221021/80835da699054f419e3c0127f80b0cdb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 20]: /images/20221021/94a14cba7de24ce1a3d007f4387cc8ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 21]: /images/20221021/a78440c5495347ec89ce9119e5a27aac.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 22]: /images/20221021/a2a221469e294c5a924d1deb5d7000a8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 23]: /images/20221021/5d606634c9624e938a89438d0d5006c6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 24]: /images/20221021/451e736f00044eb1a4d38bbe85b6bc17.png