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

腾讯“防疫健康码”于2月9日率先落地深圳后，一个月累计访问量破60亿。而民众申领健康码过程当中的“人脸识别登陆验证”，有着高准确率的要求。本文是腾讯云高级工程师丁小俊在「云加社区沙龙online」的分享整理，详述在如此大流量和高准确率的要求下，腾讯慧眼高可用架构是如何设计的呢？

点击视频，查看完整直播回放

1、腾讯云慧眼简介

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

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

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

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

面临客户的这么多的要求，咱们也会有不少问题：

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

2、AI引擎技术原理

1. 动做活体

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

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

2. 数字活体

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

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

3. 静默活体

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

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

4. 光线活体

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

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

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

目前客户有5种方式能够接入到腾讯云慧眼，能够经过微信H五、安卓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个部分：可扩展性设计、分层设计、容错设计、开发运维。

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

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

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

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

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

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

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

中台须要解决如下的问题：

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

 

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

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

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

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

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

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

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

情景四：引擎实验室推出新版本引擎2.0，线下测试完成，但愿线上可以使用新的版本。引擎中台如何保证新版本在全部客户的使用场景都是更好的？升级的过程当中，若是保证客户质量不受影响？

5、AI引擎质量效果分析

1. 样本分类

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

为何须要对评测的样本进行这么多的分类呢，由于在不一样的场景下，每一个引擎的效果差异很是大。咱们接入了上百家的引擎能力，每一种能力均可能有不一样的场景。因此咱们会分不少不少场景，如活体的各类攻击场景，不一样光线场景等等。

2. 指标计算

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

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

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

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

3. 效果分析

6、突发流量的应对策略

状况一：业务提早预告业务涨量？

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

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

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

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

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

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

首先咱们须要思考什么是中台？

总结为如下4点：

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

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

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

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

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

中台能解决什么问题呢？

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

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

3.快速试错

4.减小重复造轮子

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

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

第二步，业务建模。若是是作了一些充分的需求调研，也能预测一些后面也有发展的一个方向，而后咱们再基于需求去对业务建模，作一些抽象建模，完成之后咱们决定哪些能够复用。

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

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

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

讲师简介

丁小俊，腾讯云高级工程师。2014年加入腾讯，负责视频点播CDN后台相关开发，曾负责CDN调度模块，天天有百亿的调用量，腾讯内部全部有视频点播需求的产品均有接入，包括了腾讯视频、QQ音乐、花样直播等等产品，整体天天约有20T的流量。现任腾讯慧眼产品后台研发负责人，整体负责AI视觉产品部的引擎中台的建设，支持腾讯慧眼、明视、神图、棱镜多款产品的后台引擎服务。