彭 琨，丁小波，蔡茂貞，鐘地秀，黎蘊玉

（中移互聯(lián)網(wǎng)有限公司云產(chǎn)品事業(yè)部，廣州 510000）

0 引言

基于深度學習的智能技術被廣泛應用在計算機視覺、自然語言處理、人機交互、智能決策、推薦系統(tǒng)、安全診斷與防護等各個領域。本文主要圍繞計算機視覺領域進行應用分析，結(jié)合目前應用現(xiàn)狀，圖像解析系統(tǒng)主要存在以下幾個特點：

（1）圖片請求的獨立性。人工智能算法服務對圖形處理器（Graphics Processing Unit，GPU）有較大的依賴。雖然一個GPU 可以批量識別圖片，但在實際應用中無法適用。因為如果請求等待達到批量處理數(shù)目再處理，會導致部分請求等待時間過長。在實際應用中，常是一個GPU 承載一個請求。在生產(chǎn)環(huán)境中，不可能為滿足偶發(fā)性的高并發(fā)請求部署大量GPU 服務器，這會導致閑時服務器資源的極大浪費。

（2）網(wǎng)絡環(huán)境復雜、多變。大型業(yè)務服務系統(tǒng)往往是由多節(jié)點、多集群組成。不同分布式集群系統(tǒng)的拓撲、帶寬和延遲等參數(shù)各不相同，這導致網(wǎng)絡環(huán)境復雜。因此同一個網(wǎng)絡性能指標在不同的集群、不同的節(jié)點，甚至不同的時間點測試時都可能存在不小的差異。網(wǎng)絡環(huán)境的復雜性造成網(wǎng)絡性能的波動。

（3）通信傳輸數(shù)據(jù)量大。作為圖像識別類服務，必不可少需要依據(jù)用戶提供的圖像進行識別分析。在線圖像識別類服務對請求處理有兩種情況，一種是直接根據(jù)用戶提供的圖片請求進行應用程序編程接口（Application Program?ming Interface，API）請求調(diào)用；另一種是先進行圖像存儲，再進行API 調(diào)用。目前主流手機搭配的攝像均達到了千萬像素級別，手機拍照的圖像分辨率的提升帶來了圖片容量的增大。一張手機拍攝的圖像容量達到MB 以上的存儲空間。如果待處理請求量大，不管使用哪一種處理方法，用戶請求圖像均要在網(wǎng)絡中做多節(jié)點搬運與同步。

（4）算法處理速度慢。為了保障實際商用中的算法準確率與召回率，數(shù)據(jù)集規(guī)模和網(wǎng)絡層數(shù)的增加使得深度學習最后的模型也在不斷增大，在實際應用調(diào)用過程中也需要耗費更多的存儲與計算資源。在生產(chǎn)環(huán)境中，每臺機器算力有限，服務器、GPU 計算資源擴容都需要一定時間進行補給。

綜上所述，盡管在不少場景下通過在線的分布式圖像解析系統(tǒng)可以實現(xiàn)用戶體驗的交互，但在更大規(guī)模應用上此系統(tǒng)仍存在種種問題與挑戰(zhàn)。本文嘗試從AI 算法服務系統(tǒng)的架構(gòu)優(yōu)化和功能解耦方面出發(fā)，旨在通過建立任務分配系統(tǒng)、引入容器化技術、消息隊列異步處理來提高分布式系統(tǒng)的穩(wěn)定性，減少服務器資源浪費，更好地滿足圖像應用的商用需求。

1 消息隊列概述

消息隊列通過它異步通信的特點，實現(xiàn)了將系統(tǒng)進行解耦，通過高并發(fā)緩沖、流量削鋒極大地提升了系統(tǒng)的性能。當前消息隊列已經(jīng)在企業(yè)中廣泛應用于各種大型分布式系統(tǒng)中，目前主流的消息中間件包括ActiveMQ、Rock?etMQ、RabbitMQ及Kafka 等。

RabbitMQ 是一款由Erlang 語言開發(fā)的基于高級消息隊列協(xié)議的開源消息框架，用于在分布式系統(tǒng)中存儲和轉(zhuǎn)發(fā)消息，其優(yōu)勢在于高可用性、高可靠性、可伸縮性和易用性方面。RabbitMQ 中主要包括消息生產(chǎn)者（Producer）、消息隊列任務服務器（broker）、消息消費者（Consumer）幾 個 角 色，其 運 行 原 理 如 圖1所示。

圖1 RabbitMQ運行原理圖

整個消息隊列服務過程通過消息隊列任務服務器連接消息隊列生產(chǎn)者和消息隊列消費者。消息生產(chǎn)者負責將消息發(fā)布到任務服務器；消息消費者負責接收并處理消息，消費者和生產(chǎn)者之間系統(tǒng)解耦。任務服務器包括交換路由（Exchange）、消息隊列（Queue）。交換路由用來接收發(fā)布的消息,并根據(jù)路由策略將這些消息分發(fā)到消息隊列中。Binding 是基于路由鍵將交換器和消息隊列連接起來的路由規(guī)則；Channel是一條雙向數(shù)據(jù)流通道，通過它可以完成發(fā)布、接收消息及訂閱隊列操作。

2 系統(tǒng)架構(gòu)設計

2.1 分布式系統(tǒng)的需求分析

從平臺延展性、功能豐富度、服務優(yōu)先級、突發(fā)情況處理四個維度進行需求分析，并以此進行分布式圖像服務系統(tǒng)架構(gòu)設計。

2.1.1 平臺延展性

系統(tǒng)延展性主要考慮針對業(yè)務應用擴展的平臺延展性和針對業(yè)務規(guī)模擴大后的服務資源擴展的平臺延展性。業(yè)務應用方面延展性，即考慮在增加新業(yè)務應用情況下，既能兼容之前業(yè)務應用，又能保障新業(yè)務的穩(wěn)定擴展?？紤]到圖像服務系統(tǒng)內(nèi)主要承載的是圖像業(yè)務服務，往往一項圖像解析能力可以衍生為多項業(yè)務場景應用，例如回憶相冊、以圖搜圖、圖像去重、影集制作等業(yè)務應用。這些業(yè)務應用可以用于不同的產(chǎn)品需求下，但其底層所應用的人工智能算法是相近或是一致的。服務資源方面的平臺延展性，指的是在服務資源，如GPU、服務器、虛擬機等形式的資源擴展。

2.1.2 功能豐富度

系統(tǒng)設計需支持多語言環(huán)境，如C/C++、.NET、JAVA、Go、Python、PHP 等。系統(tǒng)需支持多種業(yè)務需求方的客戶端，如Web 網(wǎng)頁端、Wap/H5 網(wǎng)頁端、安卓客戶端、iOS 客戶端等。系統(tǒng)服務需具備豐富的跨終端、跨平臺、跨語言的支撐能力。

2.1.3 服務優(yōu)先級

服務具有不同的請求優(yōu)先級，需要在保障基礎服務的同時，可以為業(yè)務方請求服務設置不同的優(yōu)先級，請求可以根據(jù)實際需求按照優(yōu)先級從高到低進行處理。

2.1.4 突發(fā)情況處理

可對業(yè)務請求提供鏈路追蹤服務，既包括歷史處理完的請求任務，也包括處理過程中的請求任務。對處理的請求可以逐一溯源，可以查看請求任務流轉(zhuǎn)過程中的全生命周期信息，包括請求來源、請求任務的觸發(fā)時間、請求任務的子系統(tǒng)、平臺之間的流轉(zhuǎn)時間、人工智能算法模塊流轉(zhuǎn)時間、請求處理結(jié)果等信息，進而可以進行問題的快速定位與排查，保障平臺各節(jié)點的穩(wěn)定性。

2.2 分布式系統(tǒng)的架構(gòu)設計

在實際工程應用中，資源并不是可以無止境擴增；即使服務器能得到有效的補充，也需要考慮服務器資源的整體利用率。故在分布式圖像識別系統(tǒng)設計中既需充分考慮算法模塊資源高耗損性，也需考慮算法服務資源空閑情況；既需考慮任務管理系統(tǒng)的并發(fā)管理能力，也需考慮實時任務即時響應能力?？紤]到實際業(yè)務應用中需要將系統(tǒng)用于不同的產(chǎn)品需求下，但其底層所應用的人工智能算法是相近或一致的。如圖2所示為分布式圖像解析系統(tǒng)架構(gòu)圖。

圖2 分布式圖像解析系統(tǒng)架構(gòu)圖

整個系統(tǒng)組織結(jié)構(gòu)主要包括觸點感知模塊、任務配置系統(tǒng)、調(diào)度執(zhí)行管理系統(tǒng)、圖像處理系統(tǒng)和分布式云存儲系統(tǒng)。觸點感知模塊，相當于網(wǎng)絡應用中的用戶層，用于獲取智能終端等其他電子設備的用戶操作行為，并對用戶需求進行獲取判斷。觸點感知模塊需對來自PC端、移動端的任務進行標注，支持Web 端、微信端、App端、H5端等多種方式的管理。

任務配置系統(tǒng)由請求調(diào)度機制與節(jié)點調(diào)度機制組成，各個模塊分布于不同區(qū)域。根據(jù)業(yè)務的請求類型、請求信息和請求中圖像屬性，判斷任務歸屬的調(diào)度執(zhí)行管理系統(tǒng)中的子模塊。根據(jù)多端請求，進行任務的過濾與合并，減少多端同步過程中造成的計算資源浪費。根據(jù)業(yè)務請求中圖像數(shù)據(jù)的存儲節(jié)點和調(diào)度執(zhí)行管理系統(tǒng)資源池使用情況判斷任務分發(fā)的處理節(jié)點。

調(diào)度執(zhí)行管理系統(tǒng)存在兩種管理模塊，分別為任務消息隊列模塊和實時任務分發(fā)模塊。每種模塊都由多個功能相同的分布式管理模塊組成。這些管理模塊不限于為服務器或部署在服務器的docker 鏡像。任務消息隊列模塊和實時任務分發(fā)模塊為任務處理方式完全不同的功能模塊。任務消息隊列模塊可以是Kafka、rab?bitMQ、ActiveMQ、redis 等消息中間件。實時任務分發(fā)模塊可以是Apache、Nginx、IIS 等Web服務器。任務配置系統(tǒng)確定任務類型、處理節(jié)點與處理優(yōu)先級，將實時性要求不高的任務推送至指定消息隊列中；將需要實時返回結(jié)果的任務推送至實時任務分發(fā)模塊。

圖像處理系統(tǒng)由多個圖像處理模塊組成。為待處理請求中的圖像數(shù)據(jù)提供圖像解析服務。圖像解析服務包括但不限于圖像識別、圖像特征提取等深度學習圖像算法。

分布式云存儲系統(tǒng)作為云存儲資源統(tǒng)一管理系統(tǒng)，對所有數(shù)據(jù)進行云存儲與管理。

3 系統(tǒng)實現(xiàn)

分布式圖像識別系統(tǒng)中主要通過任務配置模塊進行系統(tǒng)優(yōu)化，將具體用戶請求根據(jù)業(yè)務需求進行分配調(diào)整，具體任務處理流程如圖3所示。

圖3 任務處理流程圖

獲取客戶端的用戶請求后，需要對用戶請求進行獲取判斷。根據(jù)用戶圖像相關業(yè)務需求，通過客戶端應用程序?qū)⒋幚淼膱D像資源上傳到云平臺協(xié)助管理，并將與之相對應的請求交由圖像資源任務配置系統(tǒng)?？紤]到圖像解析請求占用傳輸帶寬是常規(guī)請求十幾倍甚至上百倍，設計方案中將用戶的操作請求進行業(yè)務劃分，任務配置系統(tǒng)據(jù)此建立請求調(diào)度機制。依據(jù)業(yè)務的請求類型、請求信息結(jié)合請求中圖像屬性自動分配任務執(zhí)行單元。例如圖像搜索、圖像對比等圖像相關請求具有更高的實時權重；對用戶資產(chǎn)上傳、下載、圖像資產(chǎn)查看這類請求的實時權重更低。

確定好處理模塊后，系統(tǒng)以傳輸帶寬和服務器間傳輸時延進行智能化節(jié)點調(diào)度判斷，將請求分配到對應的延時低、帶寬占用率少的云平臺處理節(jié)點。任務分配到實時任務處理模塊，會直接調(diào)用圖像處理系統(tǒng)，為待處理請求提供圖像解析服務，請求處理完成后直接返回給用戶。任務分配到任務消息隊列模塊后，會根據(jù)請求用戶優(yōu)先級配置消息隊列優(yōu)先級。在任務消息隊列中會針對用戶在智能終端等其他電子設備上執(zhí)行不斷下拉刷新、查看等重復之前的請求操作，適度調(diào)整消息隊列優(yōu)先級，使得用戶的請求可以在中度優(yōu)先級消息隊列與低度優(yōu)先級消息隊列中調(diào)整。圖像處理系統(tǒng)中的圖像處理模塊在算力資源充沛的情況下，會從其指定的任務消息隊列按照優(yōu)先級獲取對應的消息進行圖像解析。請求處理完成后直接返回給用戶。

本文利用Python 完成主要系統(tǒng)服務的開發(fā)，通過docker 鏡像完成多功能系統(tǒng)的分布式部署。從實踐結(jié)果來看，在不增加服務器的基礎上，通過將部分請求導流到消息隊列，能有效地提升算法服務能力和閑時資源利用率。

4 結(jié)語

本文根據(jù)目前人工智能算法應用中處理響應速度問題，針對目前主流的應用程序編程接口請求方式進行分析，提出了結(jié)合異步的分布式消息隊列圖像解析系統(tǒng)，減少算法服務峰值壓力，提升閑時資源利用率。這對人工智能算法在云服務中的應用具有一定的指導意義與參考價值。