「健康碼」背後，騰訊慧眼高可用架構設計

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