基于微服務架構的眾包圖像數據集標注系統①

袁曉晨,張衛山,高紹姝,時 斌,趙永俊,王 冶,安云云

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

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

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

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

計算機視覺圖像識別是人工智能的重要應用,廣泛應用在工業、醫學、軍事、教育、商業、體育、安防檢測等行業與領域中.機器學習,尤其是深度學習展現出了針對圖像識別領域優秀的識別性能.而機器學習本身需要建立在大量的帶有指導意義的既有數據集基礎之上.在進行深度學習模型訓練流程中,往往需要針對海量圖片進行人工數據標注,繁重的圖像標注任務增添了大量時間成本.

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

表1 傳統圖像標注工具對比

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

1 概述

1.1 眾包任務模式

眾包任務模式指的是將本應當由單一機構或個人執行的工作內容在公開或非公開網絡上以公開的方式外包給特定或非特定用戶[2].通過采用眾包任務的模式,將龐大的圖像標注任務切分為小的任務,能夠有效提升標定的速度與質量,從而加速深度學習模型訓練流程.

1.2 微服務架構

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

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

微服務架構擁有著許多傳統單體式應用所不具備的優勢[5]:

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

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

③ 獨立部署:每個小模塊都能夠獨立地運行,不會因為其他服務故障而受到影響.通過微服務調度系統的支持,能夠實現快速部署在單機或集群上,從而充分利用計算性能.

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

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

⑥ 系統穩定性高:微服務架構的系統擁有熔斷機制,當系統部分組件失效時能夠及時阻止故障船體,從而避免系統發生雪崩式功能失效,提升了系統的穩定性.

1.3 對象存儲系統

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

2 系統設計

2.1 需求分析

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

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

② 任務劃分與管理:為實現眾包模式的圖像標注,需要將包含大量圖像的任務拆分為小任務,交由不同的個人進行標注.

③ 支持多種標注模式:系統應當支持機器視覺訓練常用的關鍵點、矩形、多邊形標注模式.

④ 支持多種導出格式:針對主流深度學習源碼所接受的格式,系統應當具備良好的擴展性以支持更多的深度學習框架.

⑤ 數據統計:任務發起者應當能夠看到子任務的標注進度、標簽數量等統計信息,從而有針對性地決定是否需要增加或者調整圖像組成.

⑥ 支撐模塊需求:除此之外,系統應當具有基本的用戶與權限控制功能.

2.2 微服務劃分與系統架構設計

① 系統微服務劃分

根據系統需求分析結果,將系統劃分為4 個功能性微服務和3 個架構支撐服務:圖像對象存儲服務、圖像集合管理服務、標定集合管理服務、數據輸入輸出服務、用戶及授權管理和服務網關.

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

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

標定集合管理服務用于管理和存儲圖像集對應的標定數據,同時提供標定任務的劃分與分配.

數據導入導出服務主要用于圖像、標簽數據的解包導入與打包導出.提供常見的壓縮與視頻格式的解析與常見數據集格式的導出等功能.

② 系統架構設計

系統整體采用分層式結構,如圖1所示.為了開發過程中能夠更明確的分工,其中服務層按照微服務的思想進行拆分.各層主要包含內容如下:

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

微服務層:包含了業務邏輯微服務群和架構支撐服務群兩部分.架構支撐服務群中包含了微服務架構必需的注冊發現中心、日志監控、配置中心等基礎微服務.業務邏輯微服務群提供了實現業務邏輯的相關微服務,包括圖像對象存儲微服務、圖像集管理微服務、標定管理微服務和數據導入導出微服務.

網關層:網關層包含了由Spring Gateway 實現的API 網關微服務、前端站點微服務和Nginx 總代理微服務,提供了系統接入入口.

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

系統采用現有完整的微服務方案,使用服務發現實現松散的服務間耦合,采用聲明式RPC 客戶端實現微服務間的互相調用,使用統一網關代理微服務作為系統入口,添加負載均衡機制以擴展系統負載容量,使用OAuth2 開放認證協議作為認證機制.

圖1 圖像標注系統架構

3 持續集成、持續部署與微服務架構實現

3.1 微服務注冊與發現

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

① Eureka Server:由Netflix 開發的基于原生Java的開源注冊中心實現,Spring Cloud 套件給出了基于Spring Boot 快速構建注冊中心的方案.

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

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

由于后兩種注冊發現的方案需要單獨部署第三方的應用實例來支撐微服務注冊與發現的功能,故選擇可自行構建的Eureka Server 方案.

Eureka的注冊與發現方案整體流程如圖2所示,主要分為兩部分.

圖2 基于Eureka的注冊發現實現流程

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

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

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

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

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

圖4 通過Eureka Server 查看服務發現注冊狀態

3.2 微服務接口網關與負載均衡

相較于傳統的單體式應用,微服務架構的應用更接近于單體式應用站群.微服務架構應用為了實現從外部表現為與單體式應用類似的形式,需要一個微服務作為接口網關,同時需要提供負載均衡的特性.

對于API 網關,Spring Cloud 提供了兩套方案:

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

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

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

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

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

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

3.3 微服務熔斷機制

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

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

3.4 基于SSDB的圖像對象存儲系統

在深度學習圖像識別模型訓練過程中往往需要準備大量圖像,而實現存儲并快速索引圖像數據就是標注系統性能提升的關鍵點.

SSDB是一個高性能的支持豐富數據結構的NoSQL數據庫,其底層實現為Google的高性能鍵值對數據庫LevelDB.

首先是一個高性能SSDB 集群,SSDB 采用的是與Redis 相同的網絡通信實現,故可以采用Redis 集群常用的TwemProxy 代理實現如圖5所示的對象存儲架構.

圖5 SSDB 集群架構

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

3.5 基于Gitlab-CICD的持續集成與部署

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

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

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

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

Gitlab-CICD 執行流程如圖6所示,主要環節包括:

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

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

圖6 Gitlab-CICD 執行流程

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

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

stage:構建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 一次任務將分為3 個階段:構建、測試與部署.其中測試階段由Maven 進行編譯并執行系統中的單元測試;構建階段直接使用Maven進行服務器端編譯,隨后使用Gitlab-Runner 宿主機上的docker 構建鏡像并推送至Harbor;部署階段通過暴露Docker Swarm 中的Manager 節點上dockerd的2375端口,實現從Gitlab-Runner 宿主機直接控制集群并觸發微服務鏡像更新.運行效果如圖7所示.

通過在各個微服務實例中分別修改相同邏輯后分別以手動部署與持續集成在多節點集群上部署并統計用時,得到邏輯更新至生產環境的耗時如表2所示.

圖7 Gitlab-CICD 執行效果

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

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

4 系統測試

4.1 系統后端接口測試

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

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

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

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

4.2 系統功能測試

以深度學習圖像數據制備流程為例,對系統中圖像導入、任務分配與標定、數據導出流程進行功能測試.

首先是圖像導入.圖像標注系統支持圖像、視頻、PDF、OpenDocument 等格式混合打包上傳,上傳界面如圖9所示.上傳完成數據傳輸后轉入異步解壓處理流程,異步解壓完成后前端顯示實際圖像集大小.

在圖像集中創建出標定集后即可向系統中其他用戶分配標定任務進行圖像標定的團隊協作.分配任務過程如圖10 所示.

切換至任務執行用戶,可以在“我的任務”頁面中看到由任務發起用戶分配的任務,點擊“開始”按順序對圖像進行標定.進入標定流程后,如圖11 所示,通過在圖像上拖拽創建圖像區域,完成對圖像內容的標記.

圖9 創建圖像集

圖10 分配標定任務

標注過程中發起任務的用戶能夠看到各個任務執行用戶的標定進度與當前已標定圖像的標簽統計信息.當圖像集標定完成后,任務發起者可以對圖像進行最終修正并導出圖像集合與標定集合開展深度學習模型訓練.以導出的VOC XML 格式為例,最終導出的標簽集如圖12 所示.

圖11 圖像標注過程

圖12 標簽集合導出

4.3 系統性能測試

本文采用開源Apache Benchmark 對系統中圖像對象存儲系統進行多并發場景下的性能測試,測試環境如表3所示.

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

由表4可知,采用微服務架構有效提升了系統容量,允許更多的用戶參與到眾包圖像標定工作中.

表3 性能測試節點環境配置

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

5 結束語

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