腾讯慧眼高可用架构设计

一、腾讯云慧眼简介

 

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

 

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

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

 

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

 

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

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

二、AI引擎技术原理

 

1. 动作活体

 

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

 

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

2. 数字活体

 

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

 

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

3. 静默活体

 

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

 

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

4. 光线活体

 

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

 

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

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

目前客户有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、数字活体和证照库三个能力就可以了，涉及到接入层和逻辑层，在逻辑层会直接调用后台的引擎。

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

 

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

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

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

 

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

 

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

五、AI引擎质量效果分析

 

1. 样本分类

 

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

 

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

2. 指标计算

 

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

 

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

 

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

 

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

3. 效果分析

六、突发流量的应对策略

 

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

 

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

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

 

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

 

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

 

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

 

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

 

1. 什么是中台？

 

总结为以下4点：

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

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

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

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

 

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

 

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

 

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

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

3.快速试错

4.减少重复造轮子

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

 

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

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

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

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

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%。