“健康码”背后，腾讯慧眼高可用架构设计

爱被打了一巴掌 2022-10-20 13:50 326阅读 0赞

# **一、腾讯云慧眼简介** #

腾讯云慧眼人脸核身，是一组对用户身份信息真实性进行验证审核的服务套件，提供各类认证功能模块，包含证件 OCR 识别、活体检测、人脸比对, 及各类要素信息核验能力，以解决行业内大量对用户身份信息在线核实的需求，广泛应用于金融、政务民生等领域。

抗疫期间，全国多个省份的健康码都会用到身份核验的过程，功能调用了腾讯云慧眼的后台认证能力。比如深圳公安、山西公安、云南公安等一系列的公安机关，还有人社、税务、政务综合、住建等政务机构，都对接到了腾讯云慧眼。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70][]

举个例子，当你在深圳公安的公众号上办理任何一样业务的时候，都会提示要先做实名认证，确保是你本人操作。另外，还有很多金融业，比如银行的远程开户都会运用到。

腾讯云慧眼目前支持40+行业，共计3000+项目，客户对系统可用性和稳定性有着高要求，希望真实用户能够快速通过核验，通过率极高。但是如果有些人想通过一些翻拍、面具等方式冒充他人录制一些视频，我们要能准确拦截，要求误通过率极低。业务也经常会有一些线上的活动，会导致请求量急速的上升，所以我们的整个系统架构需要能扛住大流量、高并发。最后就是，要保证用户的体验。

面临客户的这么多的要求，我们也会有很多问题：

*  对于深度学习模型，目前还做不到100%的准确率。线上偶尔可能还会有一些攻击的视频，有很小概率的会通过。
 *  后台服务基本上都是用户传过来的图片或视频，对资源的消耗特别大。
 *  我们依赖于一些证照库去做核验，它会有一个网络传输的过程，有qps限制，增加了耗时。
 *  我们的应用行业广泛，客户多，某一个客户搞活动的时候，不能影响到其他的客户，所以我们需要做到按客户级别做到资源隔离。
 *  引擎会经常面临着升级，太频繁的话会带来很大的挑战，因为很多故障都是在发布的过程中带来的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 1][]

# **二、AI引擎技术原理** #

## **1. 动作活体** ##

动作活体动物特点是：随机产生动作序列（张嘴、眨眼，摇头，点头），用户根据提示进行交互，整个过程2-3秒完成，对用户配合度有要求。攻击成功率<0.01%，真人通过率超过99%。

基本原理就是通过增加一些交互式的动作来进行活体的检测，引导客户眨眼、摇头、张嘴等。在做动作时，产生动作的脸部器官会产生皱纹，我们通过判断脸部皱纹（眼角皱纹、嘴角皱纹）等对活体进行检测。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 2][]

## **2. 数字活体** ##

数字活体基于唇动、语音、翻拍检测的多维活体检测方案。对口音、环境噪音有要求。攻击成功率<0.01%，真人通过率超过99%。

数字活体会随机生成一串数字，要求用户完成指定的读数任务，采集客户说话声音，通过算法判断唇部口型与数字的相似度来进行活体判断。攻击者事先无法知道随机数字是什么，可以很好地防御静态照片攻击和翻拍攻击，更加安全、可靠。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 3][]

## **3. 静默活体** ##

静默活体的特点：无需交互动作，整个过程2～3秒完成，通过率高。攻击成功率<0.01%，真人通过率超过99%。

静默活体是与用户交互最少的一种活体检测技术，它通过检测屏幕摩尔纹、屏幕边缘检测，通过大量活体和非活体的局部区域训练，实现客户不做动作，也能判断活体。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 4][]

## **4. 光线活体** ##

光线活体特点：无需交互动作，2s内完成刷脸。攻击成功率<0.01%，真人通过率超过99%。

光线活体基本原理就是，屏幕发出随机光信号同时采集图像，通过随机光不同的波长，照射脸部，验证是否为人脸的三维形状和质感，再基于漫反射模型，算法先对人脸上的反射光增量进行建模，提取面部隐式含有的法向量信息，增强并重建人脸深度图。摄像头接收光信号序列，只有当前光特征、序列、面容特性全部匹配，并且验证采集的时效性，最后与防翻拍进行集合，全部匹配后才会返回成功结果，安全性得到大大提升。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 5][]

# **三、腾讯云慧眼方案及架构设计** #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 6][]

目前客户有5种方式可以接入到腾讯云慧眼，可以通过微信H5、安卓SDK、iOS SDK，小程序SDK和API调用接入。接着进入到统一的接入层：腾讯云API 3.0。这一层逻辑非常简单，只有请求转发，签名校验等，之后会把相应的请求转发到我们的业务逻辑层。

腾讯云API 3.0 接收到的不同请求类型会导入到不同的模块进行处理。如果涉及到一些引擎服务，就会调用到引擎中台，所有的引擎能力都可以通过引擎中台去做调度和分发。引擎中台的基本含义就是会提供很多的引擎原子能力，然后对业务提供服务。所有的业务就可以在需要任何引擎能力的时候，通过引擎中台去获取。

引擎中台对接的是腾讯以及外部的各大实验室，比如腾讯优图实验室、AILab实验室、XLab实验室等等，还有一些安全平台，证照库等。

业务中台，是指在逻辑层有很多公用的服务，我们不需要每一个模块都去实现，有很多公用的服务可以抽取到业务中台去实现，比如像图像的处理、视频处理、下载代理，计费上报等。

数据中台,因为每个业务都会有很多相关的数据处理，比如说计费、统计、业务报表、质量、分析、收入成本、客户分析对账等等，所以这一块我们统一抽象成了一个数据中台。

整个慧眼的逻辑层，还有引擎中台层都会基于腾讯云的服务去做开发，比如腾讯云的对象存储、云数据库、CVM集群、TKE容器，如果需要的话，我们都是基于腾讯云服务去开发和使用。

管理平台，在引擎中台我们接入了上百种引擎，相应会有很多的配置，还有一些排障平台，比如客户反馈的一些case，我们需要去及时定位。天鉴评测，是跟引擎中台一起配合去对引擎实验室提供的引擎服务能力做评测，在业务上线之前或者是引擎升级之前，我们都会出一些很专业的评测报告，都是基于天鉴评测平台去实现的。QTA测试，是因为腾讯云API 3.0对外提供很多的引擎能力，很多接口需要去写很多的测试用例，不定期去执行实时监控腾讯云对外的一个接口质量。

## **1. 腾讯慧眼架构演变过程** ##

我们先假设了一个最简单的模型，接到一个需求，为了测试能不能做到核验以及交付能力，最开始我们只做一个demo，只需要身份证OCR、数字活体和证照库三个能力就可以了，涉及到接入层和逻辑层，在逻辑层会直接调用后台的引擎。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 7][]

但是这里会有一个很明显的问题，因为很多引擎能力都会有自己的签名和通信协议，所以逻辑层直接去调用引擎的话，会导致逻辑层跟引擎的耦合非常重。

所以我们对逻辑层和引擎层做了一层解耦，加了一个固定的Adapter层，来进行协议转换，再调用AI引擎。随着客户越来越多, 为了满足不同客户的使用场景要求，活体模式也越来越多, 可以支持身份证ocr+数字活体/动作活体/静默活体+证照库等多种认证方式，支持替换多家证照库和引擎提供方。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 8][]

刚开始发现还是挺有用的，因为我们逻辑层发布变更少了, 故障风险降低了很多，大部分时候都是在测试引擎、分析引擎效果, 挑选更好的引擎能力上线的工作。然而很快就有一些新的问题出现了，我们引入的新引擎越来越多, 同一个引擎能力也会有多个引擎提供方同时提供服务。于是我们做了如下调整：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 9][]

演变后最大的问题是什么？我们的版本开始变得越来越多，难以管理，也会产生很多的重复开发。同时随着引擎数量越来越多，我们的评测需求也会变得越来越多，因为每来一家引擎我们都要去评测看它的效果是不是比当前的更好，如果好的话，才会上云。

那么接下来该怎么样去优化呢？针对所有的Adapter，我们做了一个收敛，全部收到了一个统一的server里，它会把所有的能力都接进来，同时增加了引擎的调度分发，引擎参数的配置化转换，引擎效果融合等能力。

如果有新引擎接入的时候，我们只用发配置就可以了。同时在评测方面也复用了这样一个模块，评测会基于引擎中台去访问后台的引擎，不用再去单点接入每一个引擎提供的过来的能力，只需要访问整个中台提供的标准协议就可以。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 10][]

但是这样改了以后，我们也会面临一些新的问题，因为随着业务的发展，对于逻辑层的要求会越来越高，所以接下来我们又对逻辑层做一系列的优化，把一些核心的模块抽离出来,做了水平分解。这样以后我们要针对某一个逻辑反复优化，只需要发布这一个服务就可以了。有效的降低了某个逻辑模块修改发布带来整体不可用的风险。

## **2. 腾讯慧眼方案和架构设计** ##

腾讯慧眼方案和架构设计主要分为4个部分：可扩展性设计、分层设计、容错设计、开发运维。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 11][]

在扩展这一层，其实每个模块都要有具备水平扩展的能力，层与层之间的调用是分布式的，任何一台机器挂了都不会影响上一层的调用。

在分层设计上，根据架构的演变过程，会有水平分解、垂直分解，还有解耦。

解耦包括高内聚低耦合、大系统小做、稳定模块不能依赖于易变模块。

对于容错设计，其实每一层包括每一个模块都有相应的一些容灾措施。在负载均衡上，能自动屏蔽故障节点，自动做探测恢复。在容灾上，消除单点，服务的部署和运维上都是跨机房。还有包括过载保护、服务降级、动态伸缩、资源隔离等方式。

另外对于证照库，我们有兜底的策略，如果在证照库接口扛不住流量洪峰的时候，可以把多家引擎拿过来做权重分布，甚至我们可以支持4、5家同时去扛住并发。但是它带来的缺点就是有些客户在证照库覆盖不齐全的情况下，会有核验通不过的问题。

最后是开发和运维，这也是非常重要的一个环节，包括测试，发布，监控，部署等等。

# **四、AI引擎中台的架构设计** #

中台需要解决以下的问题：

*  提供高可用的引擎服务，不能经常down掉，不能故障。不能每接一个引擎就发布变更
 *  保障上线使用的引擎质量符合业务诉求，准确率要高
 *  支持引擎资源的业务隔离，避免业务间互相干扰
 *  引擎流量的调度和分发，支持个性化的业务诉求

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 12][]

引擎中台向上对接腾讯云的多款产品，向下对接多个引擎实验室，属于一个中间层，主要目的就是对接各大引擎算法训练实验室，统一对业务提供原子的引擎能力，实现产品和使用的具体引擎解偶。而引擎实验室则只需要专注于各种引擎能力的算法模型训练。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 13][]

整个中台架构主要分两套系统：在线系统和离线系统。在线系统主要是支持云上的多个业务，比如腾讯云慧眼、神图等，离线系统主要是为评测平台提供引擎访问服务。

任何一个引擎接到引擎中台以后，都会有离线的环境，接入进去以后，首先通过离线系统去做一系列的评测，这一块基本上都是自动化进行的。

关于引擎中台使用的场景，有下面4个主要情景：

情景一：静默活体默认使用引擎A，大部分业务效果不错。有一天接入一个新的客户，通过率特别低，经过测试发现该客户在引擎B通过率非常好。希望为该客户单独使用引擎B。

情景二：证照库A价格比较便宜，但是覆盖度比较低。证照库B 覆盖度很高，但是价格也贵一些。业务希望优先使用证照库A，如果没有覆盖到的请求再使用证照库B进行兜底。

情景三：某业务搞活动，预计要500QPS, 很多时候业务预估的QPS并不准确，可能多了也可能少了。这个时候为了不影响其他客户的正常使用。我们需要为该客户准备独立的资源池。

情景四：引擎实验室推出新版本引擎2.0，线下测试完成，希望线上能够使用新的版本。引擎中台如何保证新版本在所有客户的使用场景都是更好的？升级的过程中，如果保证客户质量不受影响？

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 14][]

# **五、AI引擎质量效果分析** #

## **1. 样本分类** ##

每一种引擎能力都有自己的样本分类, 这里主要以下四个部分做为例子：静默活体标准测试集、车牌类OCR标准测试集、通用印刷体类OCR标准测试集合，以及身份证OCR标准测试集。

为什么需要对评测的样本进行这么多的分类呢，因为在不同的场景下，每个引擎的效果差别非常大。我们接入了上百家的引擎能力，每一种能力都可能有不同的场景。所以我们会分很多很多场景，如活体的各种攻击场景，不同光线场景等等。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 15][]

## **2. 指标计算** ##

评测指标时，将引擎主要分为二分类引擎和文字OCR引擎两类。二分类引擎主要针对人脸比对、动作活体、数字活体、静默活体、证照库二要素等等。要么过，要么不过，不存在中间状态，最终一定会给一个是或否的结果。

文字OCR引擎适用与通用OCR、身份证OCR、营业执照OCR、英文OCR、车牌OCR、行驶证OCR等等。

对于引擎评测,我们除了会评估引擎准确率相关的指标,如通过率、误通过率、准确率、召回率等, 还会对引擎的鲁棒性做一些测试, 如统计失败率、持续高压引擎看稳定性等等。

我们整个评测流程基本都是自动化，评测完成后会自动计算好效果指标，和一些性能相关的指标, 然后以报告的形式发出来, 根据评测的报告可以整体评价引擎在各个维度的效果。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 16][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 17][]

## **3. 效果分析** ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 18][]

# **六、突发流量的应对策略** #

情况一：业务提前预告业务涨量？

情况二：没有任何预告，某个业务流量突然上涨？

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 19][]

怎么去处理？情况一考验的是架构设计，每一层每一个模块是否都是可以做到水平扩展的. 如果是, 那么在资源充足的情况下, 提前做好资源准备和资源隔离，做好服务监控，做好服务降级准备，自动过载保护，负载均衡等措施就ok啦。

情况二最先考察的是服务监控的能力，需要第一时间能发现突发的大流量, 不能等到服务已经完全扛不住, 才发现, 就来不及处理了。在流量上涨初期及时根据业务涨量情况，确定是正常流量还是异常流程, 再来决定是否需要启用接入层限频，准备好做资源隔离。确保其它业务能正常服务的前提下, 为突然涨量业务提供最大能力的支持。

假设流量太大, 所有资源加起来也不够使用的话, 引擎层和逻辑层自动过载保护, 确保在能力范围内提供稳定服务, 不能因为大流量导致整体雪崩,不可用。

整体架构上有了接入层的限频, 逻辑层和引擎层的过载保护, 加上核心模块的资源隔离以及完善的监控能力, 在高峰值流量突发情况下, 基本上可以确保整体业务上的正常运行。

# **七、架构师如何利用好中台思想** #

## **1. 什么是中台？** ##

总结为以下4点：

1.对业务、数据和技术的抽象，对服务能力进行复用，构建企业级的服务能力

2.中台是企业级的共享服务平台

3.中台是能力的枢纽和对能力的共享

4.以服务的方式提供共享能力的平台

还有人认为中台是企业级的一个共享服务平台，以服务的方式，提供共享能力的服务，其实我们的引擎中台不是一个公司级别的中台，而是整个视觉AI层的一个能力复用中台。

## **2. 中台能解决什么问题呢？** ##

1.消除企业内部各业务部门、各子公司间的壁垒

2.基于中台，可快速构建面向最终消费者和客户的前台应用

3.快速试错

4.减少重复造轮子

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 20][]

## **3. 如何建设属于业务的中台呢？** ##

第一步，理解业务的需求，任何架构的设计，对需求的深入理解是关键，如果需求理解不是很清楚的话，架构设计肯定不会好。

第二步，业务建模。如果是做了一些充分的需求调研，也能预测一些后面也有发展的一个方向，然后我们再基于需求去对业务建模，做一些抽象建模，完成以后我们决定哪些可以复用。

第三步，最后再去做架构设计，哪些地方需要分层，哪些逻辑需要复用？

第四步，就是开发和运维了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 21][]

# **Q&A** #

**Q：调用链路这么长，怎么保证一次调用成功的？**

**A：**每一层功能很清晰简单，稳定性是非常高的，整体上不会因为多一层两层导致可用性下降的。每一层的每一个模块都有相应的容灾措施，不会因为某一台机器挂掉，导致不可用。

**Q：怎么多适配 依赖的接口升级后都要修改适配吗？**

**A：**对的，最初的架构中，如果后端引擎协议修改，需要修改适配层代码。在后来优化以后的架构中，引擎的修改，都只用修改协议配置参数即可的。

**Q：动态伸缩是自动的吗？**

**A：**后端有一些引擎部署在腾讯的tke(Tencent Kubernetes Engine)上，TKE是基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务。腾讯云容器服务完全兼容原生 kubernetes API ，扩展了腾讯云的 CBS、CLB 等 kubernetes 插件，为容器化的应用提供高效部署、资源调度、服务发现和动态伸缩等一系列完整功能。

**Q：这些配置都是手动操作吗？还是自动化的？**

**A：**配置是需要手动修改，然后push后才会正式生效的。

**Q：如果有一张图片会导致后台引擎挂掉的话,你们会怎么处理?**

**A：**第一步：利用天鉴自动化平台的自动测试功能，在测试环境，全面的测试引擎准确性和鲁棒性，其中鲁棒性测试环节就包含这种挂掉的情况，尽量确保引擎在各种异常入参和持续高压下具备一定的稳定性。

第二步：线上环境，万一发生异常参数导致引擎core掉，引擎层具备自我恢复的能力，自动秒级拉起进程，提供服务。

第三步：如果遇到有恶意攻击，用这种同一张异常的图片持续多次重复请求，导致引擎不停挂掉重启，引擎中台层会针对这种异常请求做屏蔽。

**Q：你们评测流程自动化是怎么做的?**

**A：**简单讲第一步搭建引擎中台，所有引擎协议标准化，提供统一的引擎访问服务，引擎接入使用脚本配置化；第二步按引擎类型对评测样本做标准化格式；现实样本统一管理服务；第三步实现通用的评测指标计算方法；第四步实现评测框架，把标准样本解析、访问引擎服务，得到引擎结果数据，然后根据引擎类型计算相应评测指标，把整个流程串接起来。这样就可以按引擎类型，创建不同的评测任务，并自动化执行。

**Q：还有你说内部的rpc框架也是自研的？**

**A：**是自研的，已经开源。请参考：https://tarscloud.org/

**Q：旁路 会造成耗时大很多吗**

**A：**经过观察对耗时不会有影响，旁路就是多一份请求转发，而且是纯异步发送的，不会对正常请求路径有干扰；会有一点cpu消耗和带宽消耗。对于逻辑模块，这两个都不是瓶颈。

**Q：旁路不会造成资源浪费吗，旁路是为了测试数据源的可靠性吗？**

**A：**会消耗一些资源，不会很多。因为旁边只是在有某一个新引擎版本发布升级时，会临时启用，来验证新引擎的效果。避免对客户使用造成影响。验证完成后，旁路开关就会被关掉。并不是所有引擎都会一直启用旁路。

**Q：AI识别错了一般怎么处理啊？**

**A：**客户如果发现有识别错误的案例，会反馈这些badcase给到我们，天鉴评测平台会对这些badcase进行验证确认问题。之后会反馈给引擎实验室重点跟进优化。总体目前正样本通过率超过99%，负样本误通过率低于0.01%。

![20210518104628715.jpeg][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70]: /images/20221020/2eb3c48d01b844ad93b94cc1e43ac7ea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 1]: /images/20221020/6a4f46a600394a2b9bc4886a1fdd34be.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 2]: /images/20221020/b9fb3a1a6f5942f7ae1baa8224f3bba3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 3]: /images/20221020/4624d829bc9144fabd974fa27c5b3d28.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 4]: /images/20221020/6b3d0887fa864004a65654f7bec7474d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 5]: /images/20221020/ed45e65383a54946b4472191d5bc69cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 6]: /images/20221020/63f3b006c7194231835917bf35a27008.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 7]: /images/20221020/8afdc598adc044c5929e0ffd7c7baa79.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 8]: /images/20221020/b6713e1bce5e446cb3ef288c40c70f32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 9]: /images/20221020/5ada1dd4c9db4ae1a549643db667c236.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 10]: /images/20221020/df37216a2f4d4916b9b41ecf373bb7fc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 11]: /images/20221020/016d7c356499438da3430fbc1aabf129.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 12]: /images/20221020/5e1a66d9ce1e4cac8cb10c3d0c8ed7b6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 13]: /images/20221020/b4221c535bcd426a8873dc143bebe1b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 14]: /images/20221020/85e5c540368a4f6d9232b2a2c284d15f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 15]: /images/20221020/35e4d25dad0a45e08a2760cfd53c115f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 16]: /images/20221020/42c87fb106784fab9ed35fb6e7c90767.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 17]: /images/20221020/d0d7f9d29ef14f3da72b085cd3d8f696.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 18]: /images/20221020/6c75ec26db3446e5906e0a41c9eb00f9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 19]: /images/20221020/072148260bbf4c0dae164a55e3f9eb81.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 20]: /images/20221020/515e986044ea4d65a28ac4d73b9b7703.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FfQmxhY2tNb29u_size_16_color_FFFFFF_t_70 21]: /images/20221020/c3fbf4e9eb984632a9e08fa76ee4597d.png
[20210518104628715.jpeg]: /images/20221020/58886ceb3d31409da3a744cb381ee7ab.png