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

编程

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

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

一、腾讯云慧眼简介

腾讯云慧眼人脸核身,是一组对用户身份信息真实性进行验证审核的服务套件,提供各类认证功能模块,包含证件 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啦

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

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

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

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

首先我们需要思考什么是中台?

总结为以下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视觉产品部的引擎中台的建设,支持腾讯慧眼、明视、神图、棱镜多款产品的后台引擎服务。

以上是 “健康码”背后,腾讯慧眼高可用架构设计 的全部内容, 来源链接: utcz.com/z/516340.html

回到顶部