鐵路人像檢索平臺流量智能調度研究

李貝貝，朱建生，閻志遠，戴琳琳，解敏森

（1.中國鐵道科學研究院 研究生部，北京 100081；2.中國鐵道科學研究院集團有限公司 電子計算技術研究所，北京 100081）

鐵路電子客票已于2020年6月20日在全國普速鐵路推廣實施[1]，是客運提質的基礎工程，推動客運智能發展的重要載體，以及解決旅客在票務、進站、候車、乘車、出站、換乘全過程信息化服務的必要手段。在電子客票的推行進程中，為便于旅客乘降組織的智能化發展，鐵路客運部門已于2018年通過搭建人臉識別平臺，支持鐵路實名制進站核驗系統，解決人證一致性自動檢驗的問題[2]。但該場景下的人臉識別技術，屬于1v1模式，而刷臉出站、鐵路車站內刷臉查詢[3]等場景，需要研究基于1 v N模式的人像檢索技術及其應用[4]。

2020年，鐵路客票系統團隊首次開展了基于人像檢索技術的研究，鐵路人像檢索平臺的建設主要滿足車站無障礙式刷臉辦理業務的需求，并實現無證件、無二維碼僅通過一張“臉”知行程的功能。鐵路人像檢索平臺上線之初，通過手動配置能夠滿足業務的基本需要，但隨著業務場景應用范圍的不斷擴大，業務運維效率低下、操作流程復雜等問題日益突出，平臺的流量調度模塊逐漸臃腫，需要進一步優化平臺的流量調度機制。

1 人像檢索平臺概述

平臺主要應用于鐵路客運場景，對終端獲取的現場人臉進行人像檢索，進而識別旅客身份，關聯旅客車票信息，實現旅客在特定場景下的“無障礙”式出行。平臺的搭建需關聯多個鐵路內的信息系統資源，實現人像檢索算法的集成與業務邏輯的封裝。

1.1 平臺微服務功能

人像檢索平臺的軟件設計采用微服務架構，基于開源的ServiceComb微服務框架[5]進行構建。平臺的微服務主要包含以下幾部分。

1.1.1 公共服務

公共服務包括公安服務、圖片服務、配置服務等。公安服務主要通過實名制信息獲取旅客的證件照；圖片服務主要實現人像證件照、現場照等圖片在文件系統中的增、刪、查、改；配置服務針對Apollo配置中心中的配置，對其它微服務進行配置熱更新。

1.1.2 基礎服務

主要包括初始化、心跳、日志接收等簡單的基礎業務服務。初始化實現對終端設備業務開展前的鑒權認證；心跳負責監控終端設備的存活狀態；日志接收實現了終端業務開展時日志向平臺的實時上報，便于統計分析與故障運維等。

1.1.3 外部對接

外部對接包括管控服務、實名制消費、席位數據查詢等。管控服務對開展人像檢索業務的車站進行定義與維護；實名制消費用于接收電子客票推送的旅客實名制信息，并根據規則進行人像建桶；席位數據查詢實現根據實名制信息查詢電子客票，進而獲得旅客車票信息的功能。

1.1.4 業務服務

業務服務包括人像檢索、錯誤標注、證件類查詢等。人像檢索實現了在人臉桶中根據人臉現場照檢索人像底庫，獲取對應旅客標識及車票、候車等信息的功能；錯誤標注用于現場旅客對人像檢索結果確定非本人時，根據證件進行業務查詢并響應，同時記錄現場人像用于后續的算法精進；證件類查詢實現在人像檢索失敗后，通過識讀證件實名制信息，直接向電子客票集群獲取旅客車票信息的功能。

1.1.5 導航服務

導航服務根據車站電報碼或列車全車次信息，實現代理地址的路由與導航。為提升人像檢索的檢索效率，減少內部資源加載時磁盤I/O的消耗。人臉桶、人像檢索算法、人像檢索邏輯調用等均處于同一物理位置，因此對人臉桶創建與維護時的地址路由、人像檢索業務開展時服務地址尋址等，均通過導航服務動態代理來實現。

1.2 平臺技術架構

人像檢索服務平臺的開發，使用ServiceComb實現一整套微服務的框架。各微服務之間弱耦合，且內部以gRPC協議互聯，所有微服務通過Service-Comb注冊中心統一管理，通過Apollo配置中心統一配置[6]，并以Docker容器化方式運行[7]。平臺的技術架構，如圖1所示。

圖1 人像檢索平臺技術架構

（1）接入層：解析多種消息協議，實現多服務的負載均衡與統一注冊管理等。

（2）服務層：通過Apollo配置中心，區分生產環境與測試環境，同時內部組建微服務集群，實現業務邏輯。內部所有業務邏輯集群，均通過導航服務進行分發。所有集群日志通過ELK進行搜集、過濾與存儲，基于Kibana實現分析與展示[6]，利用DingTalk進行實時告警。

（3）資源層：整合人像檢索平臺外部相關資源，主要包括鐵路電子客票集群、鐵路公安系統、人臉識別算法、管控平臺及站車無線交互平臺等。

1.3 人像檢索平臺問題描述

1.3.1 手動配置，運維難度大

人像檢索平臺建設初期，導航服務作為服務入口，承擔著地址路由、流量分發及請求重定向等功能，其中所有的導航規則全部在Apollo配置文件中定義，該配置文件要手動進行增加、刪除等維護。當車站需要開通人像檢索業務時，除需在業務管控定義中進行新增車站信息以外，還需通過Apollo配置中心，手動添加該車站相關的導航信息；當車站停用人像檢索業務時，又需手動刪除配置中該車站的導航規則。因此，當開通人像檢索業務的車站較少時，系統可勉強運維，但當需開通人像檢索業務的車站較多時，配置文件會變得異常臃腫，手動運維復雜度顯著提升。

1.3.2 流量負載不均衡

既有方式未能考慮車站客流量大小不同時，因流量差異而產生的服務并發不均衡問題。既有的鐵路人像檢索平臺服務資源分配不合理，日均客流量5000人次的車站與日均客流量50000人次的車站，其對應的平臺資源不應相同，不應以最高客流量的車站作為其它車站資源劃分的標準，以滿足并發冗余等。因此，平臺的建設需要評估車站客流量的大小，實現流量的智能調度與均衡路由，合理分配系統服務資源。

2 平臺流量智能調度

流量智能調度的設計摒棄既有需要手工完成導航定義的操作方式。當車站需要新開通或注銷人像檢索業務時，僅需修改車站管控定義，即可在平臺完成車站的導航規則更新流程。在保持原有業務導航的前提下，人像檢索業務中對車站導航規則的維護將更加智能，顯著降低運維復雜度。

2.1 配置改造

業務應用服務運行于容器Docker中，實際業務處理均可在容器啟動時指定地址與端口，因此平臺所有業務的邏輯處理，都具有資源池的概念。配置改造中，不再指定具體車站的標識與應用地址，轉為僅根據業務場景指定資源，實際車站的路由選擇由導航服務進行處理。

例如，平臺支持站內刷臉查詢、刷臉出站等業務，在配置中，針對不同的業務場景，記錄所有利用的資源，多個資源以逗號作為分割，形成場景地址資源池。

刷臉查詢機、刷臉機器人等業務資源地址配置如下：

刷臉出站業務資源地址配置如下：

實際導航時，先對業務場景進行分析，獲取資源池中定義的相應資源，此時獲取的資源暫與車站無關，再結合車站日均客流量的大小，分析如何均衡且充分的利用相關資源。

2.2 新增數據表

假設鐵路各類車站中，單車站日客運量最大為12萬人，對不同車站的日客流量進行分析[8]，確定車站等級，便于進行人像檢索業務的流量合理調度，車站日客流量預估及級別定義如表1所示。

表1 平臺車站等級定義

表1中，當日客流量的評估一般根據前日客流量放大1.5倍進行冗余考慮。車站等級劃分為7個級別，隨著客流量的增加，車站等級逐漸增高，等級越高，導航實現時業務尋址的權重越大，實際業務訪問的請求越多，該車站每日生成的人臉底庫的個數越多。據此為車站的導航記錄設計導航尋址數據表，如表2所示。

表2 新增導航記錄表

2.3 依托權重的調度策略

不同鐵路車站的日客流量不同，在人像檢索的定義中該車站的權重就不同。如圖2所示，業務流量根據導航規則進行路由時，基于車站電報碼獲取對應的權重，并結合Apollo中的地址池對資源進行分配，將檢索權重值較小的車站進行業務合并，自動做到服務資源的合理分配。

圖2 導航服務路由策略

假設配置Apollo中的路由地址池未在導航記錄表中用盡，則將未使用的地址直接分配給新開通人像檢索業務的車站使用。若路由地址池中的所有導航地址均已在導航記錄表中使用，導航服務則根據傳入的車站電報碼，評估該車站的權重等級。根據權重等級，計算路由地址之間的權重總和，并取權重之和最小的地址作為此次導航地址進行分配，如果導航地址的權重之和相同，隨機選取一個地址作為路由地址進行導航。

2.4 流量調度案例分析

假設Apollo中的業務資源地址配置為：

導航服務會根據導航記錄表中的數據，計算每個導航地址下分配的車站碼權重之和，例如：

IpA:porta下已經分配的車站電報碼列表為[QIP,VAP]，權重級別分別為2、3，即IpA:porta的權重總和為5；

IpB:portb下已經分配的車站電報碼列表為[QBP,VJP]，權重級別分別為4、5，即IpB:portb的權重總和為9；

Ipc:portc下已經分配的車站電報碼列表為[BXP,IZP,BJP]，權重級別分別為2、1、6，即Ipc:portc的權重總和為9。

此時權重之和最小為5的地址為IpA:porta，導航服務會將其分配給新開通人像檢索業務的車站電報碼，并進行業務導航。

3 結束語

本文通過對車站的日客流量進行預測，定義車站等級，進而形成權重，通過權重均衡路由地址池中資源，并分配給相關車站，構建鐵路人像檢索平臺智能流量調度，保障了平臺的流量分發與路由地址管理，降低了運維復雜度，顯著提升了平臺的研發與運維效率。目前，雖已實現平臺的流量智能分配，但仍存在一些不足，導航后置的業務處理服務若出現故障，仍需對調度信息進行手動修改，尚未能實現故障自愈機制，未來研究需在滿足業務智能化發展的同時，進一步提升系統建設的魯棒性。