“健康碼”背后，騰訊慧眼高可用架構設計

騰訊“防疫健康碼”於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視覺產品部的引擎中台的建設，支持騰訊慧眼、明視、神圖、棱鏡多款產品的后台引擎服務。