基于微服務(wù)架構(gòu)的眾包圖像數(shù)據(jù)集標(biāo)注系統(tǒng)①

袁曉晨,張衛(wèi)山,高紹姝,時 斌,趙永俊,王 冶,安云云

1(中國石油大學(xué)(華東)計算機科學(xué)與技術(shù)學(xué)院,青島 266580)

2(青島海爾空調(diào)電子有限公司 電控模塊開發(fā)部,青島 266101)

3(解放軍9144 部隊,青島 266102)

4(國網(wǎng)山東省電力公司 青島市黃島區(qū)供電公司,青島 266500)

計算機視覺圖像識別是人工智能的重要應(yīng)用,廣泛應(yīng)用在工業(yè)、醫(yī)學(xué)、軍事、教育、商業(yè)、體育、安防檢測等行業(yè)與領(lǐng)域中.機器學(xué)習(xí),尤其是深度學(xué)習(xí)展現(xiàn)出了針對圖像識別領(lǐng)域優(yōu)秀的識別性能.而機器學(xué)習(xí)本身需要建立在大量的帶有指導(dǎo)意義的既有數(shù)據(jù)集基礎(chǔ)之上.在進行深度學(xué)習(xí)模型訓(xùn)練流程中,往往需要針對海量圖片進行人工數(shù)據(jù)標(biāo)注,繁重的圖像標(biāo)注任務(wù)增添了大量時間成本.

傳統(tǒng)的圖像標(biāo)注工具,如表1所示,大多以單機運行的傳統(tǒng)單體式系統(tǒng)架構(gòu)為主,運行在單機之上,同一時間同一系統(tǒng)運行實例上只允許一個用戶對本地資源進行圖像標(biāo)定.當(dāng)使用傳統(tǒng)圖像標(biāo)注工具進行協(xié)作標(biāo)定時,需要用戶手動進行圖像集的分組并拷貝至協(xié)作組員的工作站.協(xié)作組員各自完成任務(wù)后仍需要用戶自行合并制作數(shù)據(jù)集.由于缺少集中化的圖像與工作流,導(dǎo)致傳統(tǒng)單機標(biāo)注工具在協(xié)作場景下存在大量的文件與數(shù)據(jù)傳輸,在海量圖像文件的壓縮、打包與傳輸過程中產(chǎn)生了大量的時間與人工成本.

表1 傳統(tǒng)圖像標(biāo)注工具對比

為了解決機器學(xué)習(xí)圖像識別訓(xùn)練的各種前置準備工作費時費力的問題,本文提出并設(shè)計實現(xiàn)了一種基于Spring Cloud、面向機器學(xué)習(xí)模型訓(xùn)練的協(xié)作式圖像數(shù)據(jù)管理與標(biāo)注平臺,通過眾包任務(wù)的方式,優(yōu)化圖像標(biāo)注流程,設(shè)計實現(xiàn)了面向海量圖像的存儲、標(biāo)定集管理、圖像標(biāo)定任務(wù)管理等功能模塊.系統(tǒng)采用微服務(wù)架構(gòu),將系統(tǒng)各個部分進行解耦[1],實現(xiàn)服務(wù)注冊與發(fā)現(xiàn)、負載均衡、容錯處理,提升了系統(tǒng)的高可用性、可維護性與可擴展性.基于GitLab-CICD 實現(xiàn)了微服務(wù)的增量更新、持續(xù)部署與灰度更新.通過將海量圖像標(biāo)定數(shù)據(jù)進行分組劃分,簡化數(shù)據(jù)標(biāo)注過程中的操作,降低了數(shù)據(jù)標(biāo)注人員的時間成本,提升了數(shù)據(jù)標(biāo)注工作效率.

1 概述

1.1 眾包任務(wù)模式

眾包任務(wù)模式指的是將本應(yīng)當(dāng)由單一機構(gòu)或個人執(zhí)行的工作內(nèi)容在公開或非公開網(wǎng)絡(luò)上以公開的方式外包給特定或非特定用戶[2].通過采用眾包任務(wù)的模式,將龐大的圖像標(biāo)注任務(wù)切分為小的任務(wù),能夠有效提升標(biāo)定的速度與質(zhì)量,從而加速深度學(xué)習(xí)模型訓(xùn)練流程.

1.2 微服務(wù)架構(gòu)

微服務(wù)[3]是一系列功能簡單、互相之間采用輕量級通信協(xié)議協(xié)同工作的功能區(qū)塊.每個小的功能區(qū)塊具有高內(nèi)聚、低耦合的特點,能夠獨立自主地運行.

微服務(wù)架構(gòu)是一種架構(gòu)模式,它是SOA 架構(gòu)(Service Of Application)的進一步發(fā)揚,通過將龐大的系統(tǒng)根據(jù)業(yè)務(wù)邊界細粒度地拆分為小的服務(wù)模塊.每個小的服務(wù)模塊具有高內(nèi)聚、低耦合的特點,均能夠獨立地運行.每個模塊可以由不同的團隊進行開發(fā)[4].

微服務(wù)架構(gòu)擁有著許多傳統(tǒng)單體式應(yīng)用所不具備的優(yōu)勢[5]:

① 復(fù)雜度可控:通過將復(fù)雜的系統(tǒng)細粒度地拆分為小體積、業(yè)務(wù)簡單的模塊,降低了每個模塊的開發(fā)難度與復(fù)雜度.各個模塊間互相解耦[6],當(dāng)需求變更時,只需要修改對應(yīng)的模塊即可實現(xiàn)系統(tǒng)整體功能上的變更,無需考慮其他模塊可能因為接口實現(xiàn)的變更而無法正常工作的問題.

② 團隊協(xié)作效率高:當(dāng)確定系統(tǒng)各個微服務(wù)接口定義后即可分組并行開發(fā)不同的微服務(wù)模塊,從而提升了整體開發(fā)效率.同時不同微服務(wù)模塊無需集成為一個整體,只需要能夠互相調(diào)用即可保證系統(tǒng)的正常運行,避免了單體式應(yīng)用集成過程中出現(xiàn)的組件源碼不兼容,降低了集成成本.

③ 獨立部署:每個小模塊都能夠獨立地運行,不會因為其他服務(wù)故障而受到影響.通過微服務(wù)調(diào)度系統(tǒng)的支持,能夠?qū)崿F(xiàn)快速部署在單機或集群上,從而充分利用計算性能.

④ 維護難度低:配合持續(xù)集成與持續(xù)部署(CI/CD),即可實現(xiàn)灰度發(fā)布與服務(wù)熱更新,無需系統(tǒng)全部停機或重啟即可完成功能更新.

⑤ 多種技術(shù)允許共存:微服務(wù)獨立部署使得微服務(wù)間只需要約定技術(shù)、語言無關(guān)的RPC 協(xié)議即可實現(xiàn)不同技術(shù)、語言實現(xiàn)的微服務(wù)共存并配合工作[7].

⑥ 系統(tǒng)穩(wěn)定性高:微服務(wù)架構(gòu)的系統(tǒng)擁有熔斷機制,當(dāng)系統(tǒng)部分組件失效時能夠及時阻止故障船體,從而避免系統(tǒng)發(fā)生雪崩式功能失效,提升了系統(tǒng)的穩(wěn)定性.

1.3 對象存儲系統(tǒng)

基于對象的云存儲即對象存儲(object storage)是近幾年逐漸流行的一個新興且切實可行的大規(guī)模存儲方案[8],使用較為簡便的方法實現(xiàn)數(shù)據(jù)存儲,即充分利用已有的存儲組件、網(wǎng)絡(luò)技術(shù)和處理技術(shù),使系統(tǒng)擁有較好的可擴展性以及高吞吐量[9].對象存儲思想的核心為對象,每個對象都有唯一的標(biāo)識[10].對象存儲將文件劃分為一個個對象,為用戶提供了統(tǒng)一的存儲空間,從而能更好的對文件進行訪問控制和存儲管理[11].這些對象被分布在整個集群之中,為保障數(shù)據(jù)安全、防止數(shù)據(jù)丟失將每一個對象多重備份復(fù)制到多個設(shè)備上.對象存儲系統(tǒng)將數(shù)據(jù)塊列表映射為對象列表,將各類數(shù)據(jù)塊簡化成為一個個對象來進行管理[12],極大改善了系統(tǒng)的可伸縮性,可以輕易實現(xiàn)海量數(shù)據(jù)的管理.

2 系統(tǒng)設(shè)計

2.1 需求分析

傳統(tǒng)的數(shù)據(jù)集標(biāo)注往往在單終端中進行,大量的圖像需要由一個部門或者個人完成.使用傳統(tǒng)的標(biāo)注工具進行多人協(xié)作式圖像標(biāo)注時,在圖像整理上浪費了大量時間.協(xié)作前需要人工將大量圖像打包分組,協(xié)作后需要將圖像與標(biāo)定數(shù)據(jù)回收合并為同一個數(shù)據(jù)集合.常見的文件系統(tǒng)針對海量小文件的處理性能往往不及少量大文件,導(dǎo)致人工打包也是一項耗時的工作.針對以上痛點,圖像標(biāo)注系統(tǒng)主要有以下需求:

① 圖像數(shù)據(jù)托管:為避免文件系統(tǒng)直接頻繁操作大量小文件,從而節(jié)省任務(wù)分配數(shù)據(jù)打包的時間,圖像數(shù)據(jù)應(yīng)當(dāng)由專門的機制進行托管,必要時以圖像為基本單位提供圖像及其元數(shù)據(jù)檢索服務(wù).

② 任務(wù)劃分與管理:為實現(xiàn)眾包模式的圖像標(biāo)注,需要將包含大量圖像的任務(wù)拆分為小任務(wù),交由不同的個人進行標(biāo)注.

③ 支持多種標(biāo)注模式:系統(tǒng)應(yīng)當(dāng)支持機器視覺訓(xùn)練常用的關(guān)鍵點、矩形、多邊形標(biāo)注模式.

④ 支持多種導(dǎo)出格式:針對主流深度學(xué)習(xí)源碼所接受的格式,系統(tǒng)應(yīng)當(dāng)具備良好的擴展性以支持更多的深度學(xué)習(xí)框架.

⑤ 數(shù)據(jù)統(tǒng)計:任務(wù)發(fā)起者應(yīng)當(dāng)能夠看到子任務(wù)的標(biāo)注進度、標(biāo)簽數(shù)量等統(tǒng)計信息,從而有針對性地決定是否需要增加或者調(diào)整圖像組成.

⑥ 支撐模塊需求:除此之外,系統(tǒng)應(yīng)當(dāng)具有基本的用戶與權(quán)限控制功能.

2.2 微服務(wù)劃分與系統(tǒng)架構(gòu)設(shè)計

① 系統(tǒng)微服務(wù)劃分

根據(jù)系統(tǒng)需求分析結(jié)果,將系統(tǒng)劃分為4 個功能性微服務(wù)和3 個架構(gòu)支撐服務(wù):圖像對象存儲服務(wù)、圖像集合管理服務(wù)、標(biāo)定集合管理服務(wù)、數(shù)據(jù)輸入輸出服務(wù)、用戶及授權(quán)管理和服務(wù)網(wǎng)關(guān).

圖像對象存儲服務(wù)用于面向海量圖片的對象存儲,將圖片統(tǒng)一以相同規(guī)則生成的不重復(fù)定位符作為索引,避免圖片重復(fù)存儲與圖片文件名重復(fù)沖突的問題.

圖像集合管理服務(wù)用于將離散的圖片在邏輯上組成一個集合,作為系統(tǒng)中圖片操作的基本單位.

標(biāo)定集合管理服務(wù)用于管理和存儲圖像集對應(yīng)的標(biāo)定數(shù)據(jù),同時提供標(biāo)定任務(wù)的劃分與分配.

數(shù)據(jù)導(dǎo)入導(dǎo)出服務(wù)主要用于圖像、標(biāo)簽數(shù)據(jù)的解包導(dǎo)入與打包導(dǎo)出.提供常見的壓縮與視頻格式的解析與常見數(shù)據(jù)集格式的導(dǎo)出等功能.

② 系統(tǒng)架構(gòu)設(shè)計

系統(tǒng)整體采用分層式結(jié)構(gòu),如圖1所示.為了開發(fā)過程中能夠更明確的分工,其中服務(wù)層按照微服務(wù)的思想進行拆分.各層主要包含內(nèi)容如下:

持久化層:為了方便使用微服務(wù)編排框架進行部署,所有有狀態(tài)的服務(wù)均從整體架構(gòu)中分離整合在持久化層中.其中包括用于對象數(shù)據(jù)存儲的NoSQL 數(shù)據(jù)庫;用于關(guān)系型信息數(shù)據(jù)存儲的SQL 數(shù)據(jù)庫;用于全局數(shù)據(jù)緩存的內(nèi)存NoSQL 數(shù)據(jù)庫;用于全局消息同步的消息隊列中間件.

微服務(wù)層:包含了業(yè)務(wù)邏輯微服務(wù)群和架構(gòu)支撐服務(wù)群兩部分.架構(gòu)支撐服務(wù)群中包含了微服務(wù)架構(gòu)必需的注冊發(fā)現(xiàn)中心、日志監(jiān)控、配置中心等基礎(chǔ)微服務(wù).業(yè)務(wù)邏輯微服務(wù)群提供了實現(xiàn)業(yè)務(wù)邏輯的相關(guān)微服務(wù),包括圖像對象存儲微服務(wù)、圖像集管理微服務(wù)、標(biāo)定管理微服務(wù)和數(shù)據(jù)導(dǎo)入導(dǎo)出微服務(wù).

網(wǎng)關(guān)層:網(wǎng)關(guān)層包含了由Spring Gateway 實現(xiàn)的API 網(wǎng)關(guān)微服務(wù)、前端站點微服務(wù)和Nginx 總代理微服務(wù),提供了系統(tǒng)接入入口.

CI/CD 支撐部分:系統(tǒng)源代碼采用了Gitlab 私服進行托管,Gitlab 也提供了對持續(xù)集成的支持,故直接采用Gitlab-CICD 實現(xiàn)系統(tǒng)開發(fā)過程中的持續(xù)集成與部署.

系統(tǒng)采用現(xiàn)有完整的微服務(wù)方案,使用服務(wù)發(fā)現(xiàn)實現(xiàn)松散的服務(wù)間耦合,采用聲明式RPC 客戶端實現(xiàn)微服務(wù)間的互相調(diào)用,使用統(tǒng)一網(wǎng)關(guān)代理微服務(wù)作為系統(tǒng)入口,添加負載均衡機制以擴展系統(tǒng)負載容量,使用OAuth2 開放認證協(xié)議作為認證機制.

圖1 圖像標(biāo)注系統(tǒng)架構(gòu)

3 持續(xù)集成、持續(xù)部署與微服務(wù)架構(gòu)實現(xiàn)

3.1 微服務(wù)注冊與發(fā)現(xiàn)

在微服務(wù)架構(gòu)的系統(tǒng)中,為了實現(xiàn)微服務(wù)間既有松散的耦合度,又能夠互相訪問,微服務(wù)注冊與發(fā)現(xiàn)機制是一種常用方法[13].通過由微服務(wù)自行將自身的信息主動注冊至注冊中心的方式,使得其他微服務(wù)可以通過查詢注冊中心注冊記錄的方式間接地發(fā)現(xiàn)其存在并獲得訪問相關(guān)參數(shù).注冊中心是注冊與發(fā)現(xiàn)中最重要的一部分,在Spring Cloud 微服務(wù)套件中,提供了注冊中心的一種原生實現(xiàn)和兩種接入實現(xiàn):

① Eureka Server:由Netflix 開發(fā)的基于原生Java的開源注冊中心實現(xiàn),Spring Cloud 套件給出了基于Spring Boot 快速構(gòu)建注冊中心的方案.

② Spring Cloud Consul:Consul是由HashiCorp 公司開發(fā)的一種服務(wù)網(wǎng)格解決方案,提供具有服務(wù)發(fā)現(xiàn),配置和分段功能的全功能控制平面[14].通過添加org.springframework.cloud.spring-cloud-starter-consul-all 依賴,同樣可以實現(xiàn)類似的注冊發(fā)現(xiàn)功能.

Spring Cloud Zookeeper:Apache ZooKeeper是一項集中式服務(wù),用于維護配置信息,命名,提供分布式同步和提供組服務(wù)[15].基于Spring Cloud的微服務(wù)可以通過添加org.springframework.cloud.spring-cloudstarter-zookeeper-all 依賴實現(xiàn)基于ZooKeeper的注冊發(fā)現(xiàn).

由于后兩種注冊發(fā)現(xiàn)的方案需要單獨部署第三方的應(yīng)用實例來支撐微服務(wù)注冊與發(fā)現(xiàn)的功能,故選擇可自行構(gòu)建的Eureka Server 方案.

Eureka的注冊與發(fā)現(xiàn)方案整體流程如圖2所示,主要分為兩部分.

圖2 基于Eureka的注冊發(fā)現(xiàn)實現(xiàn)流程

第一部分為Eureka 注冊中心.Spring 提供了一套項目生成工具Spring Initializer[16],允許開發(fā)人員直接通過可視化配置直接生成Spring Boot 項目,這里借用Spring Initializer 可以直接生成Eureka Server的項目.

如圖3所示,在Spring Initializer 中輸入項目信息并選中Eureka Server 依賴,點擊Generate 即可得到初始項目模板.在Spring Boot 啟動類上添加@EnableEurekaServer參數(shù)即可開啟項目依賴中的Eureka Server.

圖3 使用Spring Initializer 生成Eureka Server 實例

第二部分即業(yè)務(wù)微服務(wù)中的Discovery Client.在需要通過服務(wù)發(fā)現(xiàn)感知其他服務(wù)實例的微服務(wù)中,增加org.springframework.cloud.spring-cloud-starter-netflixeureka-client 依賴,并在項目引導(dǎo)類上添加@Enable-DiscoveryClient 注解,即可為Feign 客戶端添加服務(wù)發(fā)現(xiàn)的功能.

完成其他業(yè)務(wù)微服務(wù)開發(fā)后,同時啟動各個微服務(wù),可通過登錄Eureka 監(jiān)控頁面看到各個微服務(wù)的注冊情況,如圖4所示.

圖4 通過Eureka Server 查看服務(wù)發(fā)現(xiàn)注冊狀態(tài)

3.2 微服務(wù)接口網(wǎng)關(guān)與負載均衡

相較于傳統(tǒng)的單體式應(yīng)用,微服務(wù)架構(gòu)的應(yīng)用更接近于單體式應(yīng)用站群.微服務(wù)架構(gòu)應(yīng)用為了實現(xiàn)從外部表現(xiàn)為與單體式應(yīng)用類似的形式,需要一個微服務(wù)作為接口網(wǎng)關(guān),同時需要提供負載均衡的特性.

對于API 網(wǎng)關(guān),Spring Cloud 提供了兩套方案:

① Zuul:Zuul 來源于Netflix 開源的微服務(wù)架構(gòu)套件.Zuul 底層采用了Tomcat Embeded 版本作為HTTP支撐層.

② Spring Cloud Gateway:Spring Cloud Gateway是由Spring 項目組基于其自研Web 框架WebFlux 實現(xiàn)的API 網(wǎng)關(guān).Spring Cloud Gateway是Spring Cloud去Netflix 進程中非常重要的一個項目,旨在替代Zuul成為未來的Spring Cloud 框架下的API 網(wǎng)關(guān)組件.

WebFlux 底層為直接使用Netty 等高性能非阻塞服務(wù)器,相較于采用Servlet 架構(gòu)的Tomcat(Embeded)性能上略勝一籌[17].考慮到未來Spring 項目組開發(fā)的方向與性能預(yù)期,采用Spring Cloud Gateway 作為系統(tǒng)API 網(wǎng)關(guān).

Spring Cloud Gateway 同樣可以使用Spring Initializer進行項目初始化,初始化完成后可以通過在application.yml 中的spring.cloud.gateway.route 字段中配置接口路徑與微服務(wù)的映射.

代碼1.Spring Cloud Gateway 路由配置spring:application:name:application-gateway cloud:gateway:routes:# 用戶服務(wù)-id:user-service uri:lb://user-service predicates:-＞Path=/oauth/**,/user/**,/role/**# 其他服務(wù)#…

對于負載均衡,Spring Cloud 框架提供了Ribbon組件.Ribbon是一款客戶端側(cè)負載均衡器,它可以自動從Discovery Client 中獲取微服務(wù)實力列表,應(yīng)用常見的負載均衡算法實現(xiàn)在同一服務(wù)的多個冗余實例上的負載均衡[18].通過添加org.springframework.cloud.spring-cloud-starter-netflix-ribbon 依賴即可在服務(wù)調(diào)用側(cè)引入負載均衡組件.

3.3 微服務(wù)熔斷機制

微服務(wù)之間往往避免不了互相調(diào)用對方的服務(wù).當(dāng)進行同步接口調(diào)用時,被調(diào)用方宕機、接口調(diào)用超時往往會引起調(diào)用方的異常.為了避免因微服務(wù)之間的依賴關(guān)系而出現(xiàn)大面積故障,調(diào)用方服務(wù)應(yīng)當(dāng)感知被調(diào)用方的異常并作出防御性動作,防止故障繼續(xù)的蔓延.

在Spring Cloud 框架中,提供了Hystrix 組件.Hystrix 能夠在被調(diào)用微服務(wù)出現(xiàn)異常時及時熔斷,觸發(fā)調(diào)用方的異常處理流程,防止調(diào)用方產(chǎn)生異常.Hystrix組件可以通過在微服務(wù)中添加org.springframework.cloud.spring-cloud-starter-netflix-hystrix 依賴來添加至微服務(wù)中.在微服務(wù)啟動類上添加@EnableHystrix 注解即可啟用熔斷器.

3.4 基于SSDB的圖像對象存儲系統(tǒng)

在深度學(xué)習(xí)圖像識別模型訓(xùn)練過程中往往需要準備大量圖像,而實現(xiàn)存儲并快速索引圖像數(shù)據(jù)就是標(biāo)注系統(tǒng)性能提升的關(guān)鍵點.

SSDB是一個高性能的支持豐富數(shù)據(jù)結(jié)構(gòu)的NoSQL數(shù)據(jù)庫,其底層實現(xiàn)為Google的高性能鍵值對數(shù)據(jù)庫LevelDB.

首先是一個高性能SSDB 集群,SSDB 采用的是與Redis 相同的網(wǎng)絡(luò)通信實現(xiàn),故可以采用Redis 集群常用的TwemProxy 代理實現(xiàn)如圖5所示的對象存儲架構(gòu).

圖5 SSDB 集群架構(gòu)

圖5上部分是圖像對象存儲微服務(wù).圖像存儲微服務(wù)使用圖像原始數(shù)據(jù)經(jīng)哈希運算得到的索引號作為圖像在對象系統(tǒng)中的唯一索引.每一張圖像采用一個哈希表進行存儲,在哈希表中額外增加有關(guān)圖像內(nèi)容相關(guān)的元信息,對于重復(fù)上傳的內(nèi)容采取增加元信息中記錄的索引數(shù)量而不重復(fù)存儲.

3.5 基于Gitlab-CICD的持續(xù)集成與部署

在傳統(tǒng)的單體式應(yīng)用中,只需要編譯一次即可得到可運行的產(chǎn)物,而在微服務(wù)架構(gòu)應(yīng)用中,因為劃分為了多個實例,這種類似于“站群”的系統(tǒng)往往需要編譯多個“單體式應(yīng)用”并封裝為Docker 鏡像進行部署.為了減少編譯部署階段的工作量,使用Gitlab-CICD 實現(xiàn)全自動化的編譯、測試與部署.

首先是準備一個Gitlab 實例,可以使用Gitlab 官方站點或者建立開源的Gitlab-CE 實例,本文不再贅述有關(guān)Gitlab 實例搭建的內(nèi)容.

系統(tǒng)采用了Docker Swarm 作為微服務(wù)編排框架,使用Harbor 作為Docker Swarm 集群的私有鏡像源.

Gitlab-CICD 中另一個重要組成部分便是Gitlab-Runner.Gitlab-Runner是實際執(zhí)行持續(xù)集成任務(wù)的主體.Gitlab-Runner 支持多種部署方式,本項目選擇了基于裸機系統(tǒng)的編譯環(huán)境,方便做一些特殊的環(huán)境配置.

Gitlab-CICD 執(zhí)行流程如圖6所示,主要環(huán)節(jié)包括:

① 代碼提交:在各個微服務(wù)中建立Git 倉庫,并將倉庫托管至Gitlab.當(dāng)微服務(wù)代碼得到更新并推送提交至Gitlab 時,Gitlab 會自動檢查倉庫目標(biāo)分支中的.gitlab-ci.yml 文件中的配置,并在流水線(pipeline)中添加持續(xù)集成的任務(wù).

② CICD 任務(wù)的執(zhí)行:Gitlab-Runner 定時向Gitlab的流水線隊列請求任務(wù),當(dāng)Gitlab-Runner 得到任務(wù)后在其宿主機上執(zhí)行配置文件中定義的腳本.腳本中定義的動作完成微服務(wù)的編譯、測試、鏡像打包與提交、灰度更新.

圖6 Gitlab-CICD 執(zhí)行流程

以圖像管理服務(wù)為例,編寫了如代碼2 所示的gitlab-CICD.yml 配置文件.

代碼2.Gitlab 持續(xù)集成與持續(xù)部署配置stages:-測試-構(gòu)建-部署測試:stage:測試only:-master tags:-dlp script:-mvn test構(gòu)建:

stage:構(gòu)建only:-master tags:-dlp script:-mvn package-Dmaven.test.skip=true-docker build-t ${DOCKER_REGISTRY}/dlp/${SERVICE_NAME}:latest.-docker push ${DOCKER_REGISTRY}/dlp/${SERVICE_NAME}:latest部署:stage:部署only:-master tags:-dlp script:-docker-H ${DOCKER_SWARM} service update--image ${DOCKER_REGISTRY}/dlp/${SERVICE_NAME}:latest${DOCKER_SWARM_ STACK_NAME}_${SERVICE_NAME}

如代碼2 所示,CICD 一次任務(wù)將分為3 個階段:構(gòu)建、測試與部署.其中測試階段由Maven 進行編譯并執(zhí)行系統(tǒng)中的單元測試;構(gòu)建階段直接使用Maven進行服務(wù)器端編譯,隨后使用Gitlab-Runner 宿主機上的docker 構(gòu)建鏡像并推送至Harbor;部署階段通過暴露Docker Swarm 中的Manager 節(jié)點上dockerd的2375端口,實現(xiàn)從Gitlab-Runner 宿主機直接控制集群并觸發(fā)微服務(wù)鏡像更新.運行效果如圖7所示.

通過在各個微服務(wù)實例中分別修改相同邏輯后分別以手動部署與持續(xù)集成在多節(jié)點集群上部署并統(tǒng)計用時,得到邏輯更新至生產(chǎn)環(huán)境的耗時如表2所示.

圖7 Gitlab-CICD 執(zhí)行效果

表2 手動部署與CICD 部署效率對比

由表2可知,CICD 有效減少了系統(tǒng)集成過程中的集成與部署時間成本,提升了系統(tǒng)邏輯變更同步至生產(chǎn)環(huán)境的效率.

4 系統(tǒng)測試

4.1 系統(tǒng)后端接口測試

項目采用了微服務(wù)系統(tǒng)常見的前后端分離結(jié)構(gòu),前端在接口確定后采用樁服務(wù)器(mock-server)與后端并行開發(fā).后端系統(tǒng)測試過程中使用了postman 進行接口的測試,如圖8所示.

Postman[19]是一個用于API 接口開發(fā)的協(xié)作平臺.它提供了一套API 接口開發(fā)工具,包括API 客戶端、文檔生成、自動化測試、API 接口監(jiān)控、API 設(shè)計與樁服務(wù)器與接口文檔協(xié)作.

Postman 內(nèi)嵌了OAuth2的認證模型,通過配置即可實現(xiàn)一系列共用同認證服務(wù)的API 同時獲得登錄認證的功能.

圖8 使用postman 對后端接口進行測試

4.2 系統(tǒng)功能測試

以深度學(xué)習(xí)圖像數(shù)據(jù)制備流程為例,對系統(tǒng)中圖像導(dǎo)入、任務(wù)分配與標(biāo)定、數(shù)據(jù)導(dǎo)出流程進行功能測試.

首先是圖像導(dǎo)入.圖像標(biāo)注系統(tǒng)支持圖像、視頻、PDF、OpenDocument 等格式混合打包上傳,上傳界面如圖9所示.上傳完成數(shù)據(jù)傳輸后轉(zhuǎn)入異步解壓處理流程,異步解壓完成后前端顯示實際圖像集大小.

在圖像集中創(chuàng)建出標(biāo)定集后即可向系統(tǒng)中其他用戶分配標(biāo)定任務(wù)進行圖像標(biāo)定的團隊協(xié)作.分配任務(wù)過程如圖10 所示.

切換至任務(wù)執(zhí)行用戶,可以在“我的任務(wù)”頁面中看到由任務(wù)發(fā)起用戶分配的任務(wù),點擊“開始”按順序?qū)D像進行標(biāo)定.進入標(biāo)定流程后,如圖11 所示,通過在圖像上拖拽創(chuàng)建圖像區(qū)域,完成對圖像內(nèi)容的標(biāo)記.

圖9 創(chuàng)建圖像集

圖10 分配標(biāo)定任務(wù)

標(biāo)注過程中發(fā)起任務(wù)的用戶能夠看到各個任務(wù)執(zhí)行用戶的標(biāo)定進度與當(dāng)前已標(biāo)定圖像的標(biāo)簽統(tǒng)計信息.當(dāng)圖像集標(biāo)定完成后,任務(wù)發(fā)起者可以對圖像進行最終修正并導(dǎo)出圖像集合與標(biāo)定集合開展深度學(xué)習(xí)模型訓(xùn)練.以導(dǎo)出的VOC XML 格式為例,最終導(dǎo)出的標(biāo)簽集如圖12 所示.

圖11 圖像標(biāo)注過程

圖12 標(biāo)簽集合導(dǎo)出

4.3 系統(tǒng)性能測試

本文采用開源Apache Benchmark 對系統(tǒng)中圖像對象存儲系統(tǒng)進行多并發(fā)場景下的性能測試,測試環(huán)境如表3所示.

如表4所示為模擬多用戶進行每個終端進行10次訪問(總計訪問次數(shù)=并發(fā)數(shù)量×10)的資源響應(yīng)速度的測試的測試結(jié)果.

由表4可知,采用微服務(wù)架構(gòu)有效提升了系統(tǒng)容量,允許更多的用戶參與到眾包圖像標(biāo)定工作中.

表3 性能測試節(jié)點環(huán)境配置

表4 圖像存儲服務(wù)性能測試結(jié)果(單位:ms)

5 結(jié)束語

本文設(shè)計實現(xiàn)了面向深度學(xué)習(xí)的圖像標(biāo)注系統(tǒng),與傳統(tǒng)的本地標(biāo)注工具不同,本系統(tǒng)引入了眾包協(xié)作的思想與多種圖像格式存儲支持,將繁重的數(shù)據(jù)標(biāo)注任務(wù)進行合作完成,并提供了多種導(dǎo)出格式,避免了傳統(tǒng)工具協(xié)作標(biāo)注工作流中大量圖像數(shù)據(jù)的分包與標(biāo)簽數(shù)據(jù)合并操作,簡化了協(xié)作標(biāo)定流程,有效提升了數(shù)據(jù)準備階段的工作效率.同時,系統(tǒng)架構(gòu)層面采用了微服務(wù)架構(gòu),開發(fā)階段引入基于Gitlab-CICD的持續(xù)集成與持續(xù)部署,加速了系統(tǒng)開發(fā)到部署的更新迭代.