彭 琨,丁小波,蔡茂貞,鐘地秀,黎蘊(yùn)玉
(中移互聯(lián)網(wǎng)有限公司云產(chǎn)品事業(yè)部,廣州 510000)
基于深度學(xué)習(xí)的智能技術(shù)被廣泛應(yīng)用在計(jì)算機(jī)視覺(jué)、自然語(yǔ)言處理、人機(jī)交互、智能決策、推薦系統(tǒng)、安全診斷與防護(hù)等各個(gè)領(lǐng)域。本文主要圍繞計(jì)算機(jī)視覺(jué)領(lǐng)域進(jìn)行應(yīng)用分析,結(jié)合目前應(yīng)用現(xiàn)狀,圖像解析系統(tǒng)主要存在以下幾個(gè)特點(diǎn):
(1)圖片請(qǐng)求的獨(dú)立性。人工智能算法服務(wù)對(duì)圖形處理器(Graphics Processing Unit,GPU)有較大的依賴。雖然一個(gè)GPU 可以批量識(shí)別圖片,但在實(shí)際應(yīng)用中無(wú)法適用。因?yàn)槿绻?qǐng)求等待達(dá)到批量處理數(shù)目再處理,會(huì)導(dǎo)致部分請(qǐng)求等待時(shí)間過(guò)長(zhǎng)。在實(shí)際應(yīng)用中,常是一個(gè)GPU 承載一個(gè)請(qǐng)求。在生產(chǎn)環(huán)境中,不可能為滿足偶發(fā)性的高并發(fā)請(qǐng)求部署大量GPU 服務(wù)器,這會(huì)導(dǎo)致閑時(shí)服務(wù)器資源的極大浪費(fèi)。
(2)網(wǎng)絡(luò)環(huán)境復(fù)雜、多變。大型業(yè)務(wù)服務(wù)系統(tǒng)往往是由多節(jié)點(diǎn)、多集群組成。不同分布式集群系統(tǒng)的拓?fù)?、帶寬和延遲等參數(shù)各不相同,這導(dǎo)致網(wǎng)絡(luò)環(huán)境復(fù)雜。因此同一個(gè)網(wǎng)絡(luò)性能指標(biāo)在不同的集群、不同的節(jié)點(diǎn),甚至不同的時(shí)間點(diǎn)測(cè)試時(shí)都可能存在不小的差異。網(wǎng)絡(luò)環(huán)境的復(fù)雜性造成網(wǎng)絡(luò)性能的波動(dòng)。
(3)通信傳輸數(shù)據(jù)量大。作為圖像識(shí)別類服務(wù),必不可少需要依據(jù)用戶提供的圖像進(jìn)行識(shí)別分析。在線圖像識(shí)別類服務(wù)對(duì)請(qǐng)求處理有兩種情況,一種是直接根據(jù)用戶提供的圖片請(qǐng)求進(jìn)行應(yīng)用程序編程接口(Application Program?ming Interface,API)請(qǐng)求調(diào)用;另一種是先進(jìn)行圖像存儲(chǔ),再進(jìn)行API 調(diào)用。目前主流手機(jī)搭配的攝像均達(dá)到了千萬(wàn)像素級(jí)別,手機(jī)拍照的圖像分辨率的提升帶來(lái)了圖片容量的增大。一張手機(jī)拍攝的圖像容量達(dá)到MB 以上的存儲(chǔ)空間。如果待處理請(qǐng)求量大,不管使用哪一種處理方法,用戶請(qǐng)求圖像均要在網(wǎng)絡(luò)中做多節(jié)點(diǎn)搬運(yùn)與同步。
(4)算法處理速度慢。為了保障實(shí)際商用中的算法準(zhǔn)確率與召回率,數(shù)據(jù)集規(guī)模和網(wǎng)絡(luò)層數(shù)的增加使得深度學(xué)習(xí)最后的模型也在不斷增大,在實(shí)際應(yīng)用調(diào)用過(guò)程中也需要耗費(fèi)更多的存儲(chǔ)與計(jì)算資源。在生產(chǎn)環(huán)境中,每臺(tái)機(jī)器算力有限,服務(wù)器、GPU 計(jì)算資源擴(kuò)容都需要一定時(shí)間進(jìn)行補(bǔ)給。
綜上所述,盡管在不少場(chǎng)景下通過(guò)在線的分布式圖像解析系統(tǒng)可以實(shí)現(xiàn)用戶體驗(yàn)的交互,但在更大規(guī)模應(yīng)用上此系統(tǒng)仍存在種種問(wèn)題與挑戰(zhàn)。本文嘗試從AI 算法服務(wù)系統(tǒng)的架構(gòu)優(yōu)化和功能解耦方面出發(fā),旨在通過(guò)建立任務(wù)分配系統(tǒng)、引入容器化技術(shù)、消息隊(duì)列異步處理來(lái)提高分布式系統(tǒng)的穩(wěn)定性,減少服務(wù)器資源浪費(fèi),更好地滿足圖像應(yīng)用的商用需求。
消息隊(duì)列通過(guò)它異步通信的特點(diǎn),實(shí)現(xiàn)了將系統(tǒng)進(jìn)行解耦,通過(guò)高并發(fā)緩沖、流量削鋒極大地提升了系統(tǒng)的性能。當(dāng)前消息隊(duì)列已經(jīng)在企業(yè)中廣泛應(yīng)用于各種大型分布式系統(tǒng)中,目前主流的消息中間件包括ActiveMQ、Rock?etMQ、RabbitMQ及Kafka 等。
RabbitMQ 是一款由Erlang 語(yǔ)言開(kāi)發(fā)的基于高級(jí)消息隊(duì)列協(xié)議的開(kāi)源消息框架,用于在分布式系統(tǒng)中存儲(chǔ)和轉(zhuǎn)發(fā)消息,其優(yōu)勢(shì)在于高可用性、高可靠性、可伸縮性和易用性方面。RabbitMQ 中主要包括消息生產(chǎn)者(Producer)、消息隊(duì)列任務(wù)服務(wù)器(broker)、消息消費(fèi)者(Consumer)幾 個(gè) 角 色,其 運(yùn) 行 原 理 如 圖1所示。
圖1 RabbitMQ運(yùn)行原理圖
整個(gè)消息隊(duì)列服務(wù)過(guò)程通過(guò)消息隊(duì)列任務(wù)服務(wù)器連接消息隊(duì)列生產(chǎn)者和消息隊(duì)列消費(fèi)者。消息生產(chǎn)者負(fù)責(zé)將消息發(fā)布到任務(wù)服務(wù)器;消息消費(fèi)者負(fù)責(zé)接收并處理消息,消費(fèi)者和生產(chǎn)者之間系統(tǒng)解耦。任務(wù)服務(wù)器包括交換路由(Exchange)、消息隊(duì)列(Queue)。交換路由用來(lái)接收發(fā)布的消息,并根據(jù)路由策略將這些消息分發(fā)到消息隊(duì)列中。Binding 是基于路由鍵將交換器和消息隊(duì)列連接起來(lái)的路由規(guī)則;Channel是一條雙向數(shù)據(jù)流通道,通過(guò)它可以完成發(fā)布、接收消息及訂閱隊(duì)列操作。
從平臺(tái)延展性、功能豐富度、服務(wù)優(yōu)先級(jí)、突發(fā)情況處理四個(gè)維度進(jìn)行需求分析,并以此進(jìn)行分布式圖像服務(wù)系統(tǒng)架構(gòu)設(shè)計(jì)。
2.1.1 平臺(tái)延展性
系統(tǒng)延展性主要考慮針對(duì)業(yè)務(wù)應(yīng)用擴(kuò)展的平臺(tái)延展性和針對(duì)業(yè)務(wù)規(guī)模擴(kuò)大后的服務(wù)資源擴(kuò)展的平臺(tái)延展性。業(yè)務(wù)應(yīng)用方面延展性,即考慮在增加新業(yè)務(wù)應(yīng)用情況下,既能兼容之前業(yè)務(wù)應(yīng)用,又能保障新業(yè)務(wù)的穩(wěn)定擴(kuò)展??紤]到圖像服務(wù)系統(tǒng)內(nèi)主要承載的是圖像業(yè)務(wù)服務(wù),往往一項(xiàng)圖像解析能力可以衍生為多項(xiàng)業(yè)務(wù)場(chǎng)景應(yīng)用,例如回憶相冊(cè)、以圖搜圖、圖像去重、影集制作等業(yè)務(wù)應(yīng)用。這些業(yè)務(wù)應(yīng)用可以用于不同的產(chǎn)品需求下,但其底層所應(yīng)用的人工智能算法是相近或是一致的。服務(wù)資源方面的平臺(tái)延展性,指的是在服務(wù)資源,如GPU、服務(wù)器、虛擬機(jī)等形式的資源擴(kuò)展。
2.1.2 功能豐富度
系統(tǒng)設(shè)計(jì)需支持多語(yǔ)言環(huán)境,如C/C++、.NET、JAVA、Go、Python、PHP 等。系統(tǒng)需支持多種業(yè)務(wù)需求方的客戶端,如Web 網(wǎng)頁(yè)端、Wap/H5 網(wǎng)頁(yè)端、安卓客戶端、iOS 客戶端等。系統(tǒng)服務(wù)需具備豐富的跨終端、跨平臺(tái)、跨語(yǔ)言的支撐能力。
2.1.3 服務(wù)優(yōu)先級(jí)
服務(wù)具有不同的請(qǐng)求優(yōu)先級(jí),需要在保障基礎(chǔ)服務(wù)的同時(shí),可以為業(yè)務(wù)方請(qǐng)求服務(wù)設(shè)置不同的優(yōu)先級(jí),請(qǐng)求可以根據(jù)實(shí)際需求按照優(yōu)先級(jí)從高到低進(jìn)行處理。
2.1.4 突發(fā)情況處理
可對(duì)業(yè)務(wù)請(qǐng)求提供鏈路追蹤服務(wù),既包括歷史處理完的請(qǐng)求任務(wù),也包括處理過(guò)程中的請(qǐng)求任務(wù)。對(duì)處理的請(qǐng)求可以逐一溯源,可以查看請(qǐng)求任務(wù)流轉(zhuǎn)過(guò)程中的全生命周期信息,包括請(qǐng)求來(lái)源、請(qǐng)求任務(wù)的觸發(fā)時(shí)間、請(qǐng)求任務(wù)的子系統(tǒng)、平臺(tái)之間的流轉(zhuǎn)時(shí)間、人工智能算法模塊流轉(zhuǎn)時(shí)間、請(qǐng)求處理結(jié)果等信息,進(jìn)而可以進(jìn)行問(wèn)題的快速定位與排查,保障平臺(tái)各節(jié)點(diǎn)的穩(wěn)定性。
在實(shí)際工程應(yīng)用中,資源并不是可以無(wú)止境擴(kuò)增;即使服務(wù)器能得到有效的補(bǔ)充,也需要考慮服務(wù)器資源的整體利用率。故在分布式圖像識(shí)別系統(tǒng)設(shè)計(jì)中既需充分考慮算法模塊資源高耗損性,也需考慮算法服務(wù)資源空閑情況;既需考慮任務(wù)管理系統(tǒng)的并發(fā)管理能力,也需考慮實(shí)時(shí)任務(wù)即時(shí)響應(yīng)能力。考慮到實(shí)際業(yè)務(wù)應(yīng)用中需要將系統(tǒng)用于不同的產(chǎn)品需求下,但其底層所應(yīng)用的人工智能算法是相近或一致的。如圖2所示為分布式圖像解析系統(tǒng)架構(gòu)圖。
圖2 分布式圖像解析系統(tǒng)架構(gòu)圖
整個(gè)系統(tǒng)組織結(jié)構(gòu)主要包括觸點(diǎn)感知模塊、任務(wù)配置系統(tǒng)、調(diào)度執(zhí)行管理系統(tǒng)、圖像處理系統(tǒng)和分布式云存儲(chǔ)系統(tǒng)。觸點(diǎn)感知模塊,相當(dāng)于網(wǎng)絡(luò)應(yīng)用中的用戶層,用于獲取智能終端等其他電子設(shè)備的用戶操作行為,并對(duì)用戶需求進(jìn)行獲取判斷。觸點(diǎn)感知模塊需對(duì)來(lái)自PC端、移動(dòng)端的任務(wù)進(jìn)行標(biāo)注,支持Web 端、微信端、App端、H5端等多種方式的管理。
任務(wù)配置系統(tǒng)由請(qǐng)求調(diào)度機(jī)制與節(jié)點(diǎn)調(diào)度機(jī)制組成,各個(gè)模塊分布于不同區(qū)域。根據(jù)業(yè)務(wù)的請(qǐng)求類型、請(qǐng)求信息和請(qǐng)求中圖像屬性,判斷任務(wù)歸屬的調(diào)度執(zhí)行管理系統(tǒng)中的子模塊。根據(jù)多端請(qǐng)求,進(jìn)行任務(wù)的過(guò)濾與合并,減少多端同步過(guò)程中造成的計(jì)算資源浪費(fèi)。根據(jù)業(yè)務(wù)請(qǐng)求中圖像數(shù)據(jù)的存儲(chǔ)節(jié)點(diǎn)和調(diào)度執(zhí)行管理系統(tǒng)資源池使用情況判斷任務(wù)分發(fā)的處理節(jié)點(diǎn)。
調(diào)度執(zhí)行管理系統(tǒng)存在兩種管理模塊,分別為任務(wù)消息隊(duì)列模塊和實(shí)時(shí)任務(wù)分發(fā)模塊。每種模塊都由多個(gè)功能相同的分布式管理模塊組成。這些管理模塊不限于為服務(wù)器或部署在服務(wù)器的docker 鏡像。任務(wù)消息隊(duì)列模塊和實(shí)時(shí)任務(wù)分發(fā)模塊為任務(wù)處理方式完全不同的功能模塊。任務(wù)消息隊(duì)列模塊可以是Kafka、rab?bitMQ、ActiveMQ、redis 等消息中間件。實(shí)時(shí)任務(wù)分發(fā)模塊可以是Apache、Nginx、IIS 等Web服務(wù)器。任務(wù)配置系統(tǒng)確定任務(wù)類型、處理節(jié)點(diǎn)與處理優(yōu)先級(jí),將實(shí)時(shí)性要求不高的任務(wù)推送至指定消息隊(duì)列中;將需要實(shí)時(shí)返回結(jié)果的任務(wù)推送至實(shí)時(shí)任務(wù)分發(fā)模塊。
圖像處理系統(tǒng)由多個(gè)圖像處理模塊組成。為待處理請(qǐng)求中的圖像數(shù)據(jù)提供圖像解析服務(wù)。圖像解析服務(wù)包括但不限于圖像識(shí)別、圖像特征提取等深度學(xué)習(xí)圖像算法。
分布式云存儲(chǔ)系統(tǒng)作為云存儲(chǔ)資源統(tǒng)一管理系統(tǒng),對(duì)所有數(shù)據(jù)進(jìn)行云存儲(chǔ)與管理。
分布式圖像識(shí)別系統(tǒng)中主要通過(guò)任務(wù)配置模塊進(jìn)行系統(tǒng)優(yōu)化,將具體用戶請(qǐng)求根據(jù)業(yè)務(wù)需求進(jìn)行分配調(diào)整,具體任務(wù)處理流程如圖3所示。
圖3 任務(wù)處理流程圖
獲取客戶端的用戶請(qǐng)求后,需要對(duì)用戶請(qǐng)求進(jìn)行獲取判斷。根據(jù)用戶圖像相關(guān)業(yè)務(wù)需求,通過(guò)客戶端應(yīng)用程序?qū)⒋幚淼膱D像資源上傳到云平臺(tái)協(xié)助管理,并將與之相對(duì)應(yīng)的請(qǐng)求交由圖像資源任務(wù)配置系統(tǒng)。考慮到圖像解析請(qǐng)求占用傳輸帶寬是常規(guī)請(qǐng)求十幾倍甚至上百倍,設(shè)計(jì)方案中將用戶的操作請(qǐng)求進(jìn)行業(yè)務(wù)劃分,任務(wù)配置系統(tǒng)據(jù)此建立請(qǐng)求調(diào)度機(jī)制。依據(jù)業(yè)務(wù)的請(qǐng)求類型、請(qǐng)求信息結(jié)合請(qǐng)求中圖像屬性自動(dòng)分配任務(wù)執(zhí)行單元。例如圖像搜索、圖像對(duì)比等圖像相關(guān)請(qǐng)求具有更高的實(shí)時(shí)權(quán)重;對(duì)用戶資產(chǎn)上傳、下載、圖像資產(chǎn)查看這類請(qǐng)求的實(shí)時(shí)權(quán)重更低。
確定好處理模塊后,系統(tǒng)以傳輸帶寬和服務(wù)器間傳輸時(shí)延進(jìn)行智能化節(jié)點(diǎn)調(diào)度判斷,將請(qǐng)求分配到對(duì)應(yīng)的延時(shí)低、帶寬占用率少的云平臺(tái)處理節(jié)點(diǎn)。任務(wù)分配到實(shí)時(shí)任務(wù)處理模塊,會(huì)直接調(diào)用圖像處理系統(tǒng),為待處理請(qǐng)求提供圖像解析服務(wù),請(qǐng)求處理完成后直接返回給用戶。任務(wù)分配到任務(wù)消息隊(duì)列模塊后,會(huì)根據(jù)請(qǐng)求用戶優(yōu)先級(jí)配置消息隊(duì)列優(yōu)先級(jí)。在任務(wù)消息隊(duì)列中會(huì)針對(duì)用戶在智能終端等其他電子設(shè)備上執(zhí)行不斷下拉刷新、查看等重復(fù)之前的請(qǐng)求操作,適度調(diào)整消息隊(duì)列優(yōu)先級(jí),使得用戶的請(qǐng)求可以在中度優(yōu)先級(jí)消息隊(duì)列與低度優(yōu)先級(jí)消息隊(duì)列中調(diào)整。圖像處理系統(tǒng)中的圖像處理模塊在算力資源充沛的情況下,會(huì)從其指定的任務(wù)消息隊(duì)列按照優(yōu)先級(jí)獲取對(duì)應(yīng)的消息進(jìn)行圖像解析。請(qǐng)求處理完成后直接返回給用戶。
本文利用Python 完成主要系統(tǒng)服務(wù)的開(kāi)發(fā),通過(guò)docker 鏡像完成多功能系統(tǒng)的分布式部署。從實(shí)踐結(jié)果來(lái)看,在不增加服務(wù)器的基礎(chǔ)上,通過(guò)將部分請(qǐng)求導(dǎo)流到消息隊(duì)列,能有效地提升算法服務(wù)能力和閑時(shí)資源利用率。
本文根據(jù)目前人工智能算法應(yīng)用中處理響應(yīng)速度問(wèn)題,針對(duì)目前主流的應(yīng)用程序編程接口請(qǐng)求方式進(jìn)行分析,提出了結(jié)合異步的分布式消息隊(duì)列圖像解析系統(tǒng),減少算法服務(wù)峰值壓力,提升閑時(shí)資源利用率。這對(duì)人工智能算法在云服務(wù)中的應(yīng)用具有一定的指導(dǎo)意義與參考價(jià)值。