張宇光,王俊杰,胡淵喆,王 青,3

1(中國(guó)科學(xué)院軟件研究所 互聯(lián)網(wǎng)軟件技術(shù)實(shí)驗(yàn)室,北京 100190)

2(中國(guó)科學(xué)院大學(xué),北京 100049)3(中國(guó)科學(xué)院軟件研究所 計(jì)算機(jī)科學(xué)國(guó)家重點(diǎn)實(shí)驗(yàn)室,北京 100190)

面向工作流的Gitlab服務(wù)化設(shè)計(jì)①

張宇光1,2,王俊杰1,胡淵喆1,王 青1,2,3

1(中國(guó)科學(xué)院軟件研究所 互聯(lián)網(wǎng)軟件技術(shù)實(shí)驗(yàn)室,北京 100190)

2(中國(guó)科學(xué)院大學(xué),北京 100049)3(中國(guó)科學(xué)院軟件研究所 計(jì)算機(jī)科學(xué)國(guó)家重點(diǎn)實(shí)驗(yàn)室,北京 100190)

軟件制品間使用服務(wù)化的方法進(jìn)行交互,能夠?qū)⒅破穬?nèi)部產(chǎn)生的事件和數(shù)據(jù)以服務(wù)的形式產(chǎn)出.工作流是一種常見(jiàn)的用于處理消息流和事件流的方式,使得制品產(chǎn)生的事件和數(shù)據(jù)能夠在不同制品間流轉(zhuǎn).Gitlab作為開(kāi)源的、被廣泛使用的代碼與文檔管理工具,針對(duì)其在工作流環(huán)境中進(jìn)行對(duì)外服務(wù)能力的研究是很有意義的.在研究中發(fā)現(xiàn),Gitlab的服務(wù)化能力有靈活性差,拓展能力弱,服務(wù)粒度粗等問(wèn)題.基于這樣的問(wèn)題,本文提出GITService服務(wù)化方法,重新定義了Gitlab的服務(wù)流程和服務(wù)標(biāo)準(zhǔn),在服務(wù)實(shí)現(xiàn)中,使用消息隊(duì)列和異步機(jī)制,設(shè)計(jì)實(shí)現(xiàn)了新的監(jiān)聽(tīng)服務(wù)和執(zhí)行服務(wù)方案,并針對(duì)該解決方案進(jìn)行了實(shí)驗(yàn)分析.實(shí)驗(yàn)表明,在保證Gitlab運(yùn)行時(shí)間幾乎不受影響的情況下,GITService擁有靈活性好、擴(kuò)展性強(qiáng)、細(xì)粒度的服務(wù)化能力.本文所提供的方法,能夠?yàn)槠渌麍?chǎng)景下的服務(wù)化設(shè)計(jì)和實(shí)現(xiàn)提供有益參考.

Gitlab;工作流;服務(wù)化;RESTful;服務(wù)粒度

1 引言

工作流系統(tǒng)的作用是“使在多個(gè)參與者之間按照某種預(yù)定義的規(guī)則傳遞文檔、信息或任務(wù)的過(guò)程自動(dòng)進(jìn)行,從而實(shí)現(xiàn)某個(gè)預(yù)期的業(yè)務(wù)目標(biāo),或者促使此目標(biāo)的實(shí)現(xiàn)”[1].為使信息能夠在工作流運(yùn)行的過(guò)程中流轉(zhuǎn),就需要由工作流串聯(lián)起來(lái)的各個(gè)工具之間能夠滿(mǎn)足工作流傳輸數(shù)據(jù)的標(biāo)準(zhǔn),滿(mǎn)足工作流對(duì)于實(shí)際業(yè)務(wù)的需求.

在軟件開(kāi)發(fā)過(guò)程中,為了實(shí)現(xiàn)復(fù)雜的開(kāi)發(fā)和管理流程,通常需要多個(gè)開(kāi)發(fā)工具之間的事件交互和消息交互,在實(shí)踐中,經(jīng)常選擇工作流平臺(tái)來(lái)實(shí)現(xiàn)軟件開(kāi)發(fā)工具間的事件和消息的流轉(zhuǎn).在自動(dòng)化的軟件開(kāi)發(fā)與管理過(guò)程中,會(huì)有多個(gè)軟件制品協(xié)同對(duì)外提供服務(wù),由于軟件開(kāi)發(fā)與管理的復(fù)雜性,其所需要的服務(wù)種類(lèi)多種多樣,這就對(duì)各個(gè)制品的對(duì)外服務(wù)能力提出很高的要求.代碼與文檔管理作為軟件開(kāi)發(fā)過(guò)程的核心部分,其對(duì)外服務(wù)能力直接影響到軟件開(kāi)發(fā)與管理的質(zhì)量.Gitlab作為軟件開(kāi)發(fā)過(guò)程最重要的文檔及代碼管理工具,在接入工作流平臺(tái)后發(fā)揮了重要的作用,在工作流平臺(tái)中被頻繁使用.

被接入工作流后,Gitlab現(xiàn)有的服務(wù)化方案展現(xiàn)出了諸多問(wèn)題,在靈活性方面,Gitlab的服務(wù)化參數(shù)是固化的,不能通過(guò)解析參數(shù)的方法靈活地選取服務(wù);在拓展性方面,Gitlab只能提供固定的服務(wù),當(dāng)前架構(gòu)難以對(duì)服務(wù)拓展;在服務(wù)粒度方面,Gitlab只能在project和group的維度提供服務(wù),不能提供更細(xì)粒度的服務(wù).對(duì)工具的服務(wù)化而言,文獻(xiàn)[2,3]研究了通用領(lǐng)域的服務(wù)選擇和組合方法.文獻(xiàn)[4]指出,由于Web應(yīng)用的廣泛性,在諸多種類(lèi)Web中進(jìn)行Web服務(wù)化的相關(guān)研究時(shí),只有考慮Web服務(wù)所應(yīng)用的領(lǐng)域才有意義,本文基于Gitlab在軟件開(kāi)發(fā)領(lǐng)域的重要作用,研究發(fā)現(xiàn)Gitlab現(xiàn)有的服務(wù)化方案存在的三類(lèi)問(wèn)題,并提出了針對(duì)該專(zhuān)用領(lǐng)域的解決方案.

針對(duì)在與工作流協(xié)同工作時(shí),Gitlab所展現(xiàn)出的靈活性差,拓展性差和服務(wù)粒度粗等情況,本文對(duì)Gitlab進(jìn)行了深入研究,在兼容原有對(duì)外服務(wù)體系的基礎(chǔ)上,提出了更靈活,拓展性更強(qiáng),細(xì)粒度的服務(wù)化解決方案GITService,實(shí)驗(yàn)表明GITService提升了Gitlab的服務(wù)化能力.

2 相關(guān)工作

羅海濱等[5]結(jié)合不同研究者的定義,將工作流定義為,工作流是通過(guò)計(jì)算機(jī)軟件進(jìn)行定義執(zhí)行并監(jiān)控的經(jīng)營(yíng)過(guò)程,而這種計(jì)算軟件就是工作流管理系統(tǒng).文中對(duì)工作流技術(shù)進(jìn)行了全面而詳盡的綜述.

文獻(xiàn)[6,7]提到后前有很多研究基于W e b service 展開(kāi),Web 服務(wù)化有諸多優(yōu)點(diǎn).張衛(wèi)等[8]結(jié)合HLA仿真與Web的優(yōu)點(diǎn),通過(guò)服務(wù)化的方法實(shí)現(xiàn)了分布式的HLA仿真系統(tǒng).將Web服務(wù)的優(yōu)勢(shì)附加給HLA,實(shí)現(xiàn)了 HLA Web 服務(wù)化的三個(gè)層次.文章借助Web服務(wù)化的優(yōu)勢(shì),對(duì)軟件結(jié)合Web實(shí)現(xiàn)服務(wù)化能力提出了一種實(shí)踐方案.

文獻(xiàn)[9-12]提到RESTful Web服務(wù)的簡(jiǎn)便性、輕量性、可擴(kuò)展性和安全性,RESTful架構(gòu)已經(jīng)成為Web服務(wù)的主流技術(shù).它基于RESTful Web服務(wù)的特點(diǎn),提出了有服務(wù)發(fā)現(xiàn)與識(shí)別、服務(wù)搜索和服務(wù)接入三個(gè)模塊的RESTful Web服務(wù)開(kāi)放平臺(tái)的實(shí)現(xiàn)方案.在Web服務(wù)化的相關(guān)研究中,由于RESTful Web的諸多優(yōu)勢(shì),針對(duì) RESTful Web 服務(wù)化的研究越來(lái)越多,針對(duì) RESTful Web 的實(shí)現(xiàn)案例也越來(lái)越多,因此,針對(duì)RESTful Web的研究是很有意義的.在需求越來(lái)越多與場(chǎng)景變化多樣的情況下,能否提供高質(zhì)量的服務(wù)顯得十分關(guān)鍵,針對(duì)Web服務(wù)化存在諸多挑戰(zhàn),文獻(xiàn)[13,14]研究了如何提供更好的服務(wù)化方法.本文提出的基于Gitlab的服務(wù)化解決方案就是基于RESTful Web實(shí)現(xiàn)的.

3 研究介紹

本章節(jié)面向工作流,基于Gitlab的服務(wù)化能力無(wú)法滿(mǎn)足工作流對(duì)服務(wù)集成的需求的背景,首先介紹了工作流和Gitlab相關(guān)的背景知識(shí);然后指出Gitlab服務(wù)化的現(xiàn)狀和不足;最后,著重從服務(wù)流程、服務(wù)標(biāo)準(zhǔn)和服務(wù)實(shí)現(xiàn)這三方面介紹GITService服務(wù)化模型.

3.1 背景介紹

3.1.1 工作流

工作流系統(tǒng)的作用是“使在多個(gè)參與者之間按照某種預(yù)定義的規(guī)則傳遞文檔、信息或任務(wù)的過(guò)程自動(dòng)進(jìn)行,從而實(shí)現(xiàn)某個(gè)預(yù)期的業(yè)務(wù)目標(biāo),或者促使此目標(biāo)的實(shí)現(xiàn)”[1].本文基于軟件開(kāi)發(fā)過(guò)程中的工作流平臺(tái)開(kāi)展研究,該平臺(tái)是以JBPM為核心開(kāi)發(fā),集任務(wù)管理,代碼管理,缺陷管理等工作為一體的自動(dòng)化軟件開(kāi)發(fā)任務(wù)流程管理平臺(tái),任務(wù)管理、代碼管理和缺陷管理等工具通過(guò)工作流平臺(tái)被串聯(lián)起來(lái),開(kāi)發(fā)任務(wù)在工作流平臺(tái)發(fā)布后自動(dòng)在任務(wù)管理工具間流轉(zhuǎn).

在工作流中存在包含子流程的情況.子流程中涉及當(dāng)前服務(wù)與前置服務(wù),當(dāng)前服務(wù)是指當(dāng)前的工作流節(jié)點(diǎn)所提供的執(zhí)行或監(jiān)聽(tīng)服務(wù),前置服務(wù)是子流程最開(kāi)始的節(jié)點(diǎn)所對(duì)應(yīng)的執(zhí)行或監(jiān)聽(tīng)服務(wù),前置服務(wù)與當(dāng)前服務(wù)相關(guān)聯(lián),若當(dāng)前服務(wù)為子流程中最后一個(gè)節(jié)點(diǎn),如果此時(shí)判斷最后一個(gè)節(jié)點(diǎn)的狀態(tài)滿(mǎn)足子流程結(jié)束條件,則終止子流程,若不滿(mǎn)足,則重置當(dāng)前服務(wù)節(jié)點(diǎn)與前置服務(wù)節(jié)點(diǎn)狀態(tài),以前置節(jié)點(diǎn)為起始點(diǎn),重新執(zhí)行子流程,直至子流程滿(mǎn)足終止條件.

3.1.2 Gitlab

Gitlab是后前被廣泛使用的基于git的開(kāi)源代碼管理平臺(tái),基于 Ruby on Rails構(gòu)建,主要針對(duì)軟件開(kāi)發(fā)過(guò)程中產(chǎn)生的代碼和文檔進(jìn)行管理,Gitlab主要針對(duì)group和project兩個(gè)維度進(jìn)行代碼和文檔管理,其中g(shù)roup 是群組,project是工程項(xiàng)后,一個(gè) group 可以管理多個(gè)project,可以理解為一個(gè)群組中有多項(xiàng)軟件開(kāi)發(fā)任務(wù),而一個(gè)project中可能包含多個(gè)branch,意為每個(gè)項(xiàng)后中有多個(gè)分支,分支間相互獨(dú)立,不同分支可以進(jìn)行歸并.如表 1 所示,在 Gitlab 中,除 push 操作外,其他操作都可以通過(guò)Web的形式進(jìn)行交互.

Gitlab有兩種服務(wù)化能力,監(jiān)聽(tīng)服務(wù)和執(zhí)行服務(wù).監(jiān)聽(tīng)服務(wù)是指,監(jiān)聽(tīng)某一任務(wù)執(zhí)行,執(zhí)行后,將結(jié)果返回給服務(wù)調(diào)用方;執(zhí)行服務(wù)是指,直接執(zhí)行所調(diào)用的服務(wù),并將結(jié)果返回給服務(wù)調(diào)用方.兩種服務(wù)化能力均以RESTful Web服務(wù)化體系為基礎(chǔ).

表1 Gitlab 基本操作介紹

3.2 Gitlab服務(wù)化現(xiàn)狀與不足

在與工作流協(xié)同工作時(shí),Gitlab的服務(wù)化能力難以滿(mǎn)足工作流的需求,Gitlab的服務(wù)化主要是針對(duì)具體資源進(jìn)行的,在Gitlab的26種資源服務(wù)中,當(dāng)前僅提供針對(duì) project,group,merge 三種資源在 project和 group維度上的服務(wù)化能力.如表2所示,通過(guò)對(duì)有代表性的幾種服務(wù)分析后發(fā)現(xiàn),Gitlab現(xiàn)存服務(wù)化能力難以滿(mǎn)足工作流的需求,我們將問(wèn)題歸類(lèi)為靈活性差、拓展性弱以及服務(wù)粒度粗等三個(gè)方面.

表2 Gitlab 固有服務(wù)化存在的問(wèn)題

在靈活性方面,Gitlab的服務(wù)化標(biāo)準(zhǔn)難以應(yīng)對(duì)多種參數(shù)解析和配置的需求,使得服務(wù)化能力不靈活;在拓展性方面,在Gitlab服務(wù)化流程中,增加資源監(jiān)聽(tīng)只能以修改數(shù)據(jù)標(biāo)準(zhǔn)和關(guān)鍵部分為代價(jià)添加,在應(yīng)對(duì)復(fù)雜監(jiān)聽(tīng)需求的情況下,展現(xiàn)出了較弱的拓展性;在服務(wù)粒度方面,Gitlab的服務(wù)化只能在粗粒度的資源上提供事件監(jiān)聽(tīng)服務(wù),卻無(wú)法以定制化的方法針對(duì)資源下發(fā)生的事件提供更加細(xì)粒度的服務(wù).代碼管理作為整個(gè)軟件開(kāi)發(fā)過(guò)程中最重要的環(huán)節(jié),為了實(shí)現(xiàn)對(duì)整個(gè)開(kāi)發(fā)任務(wù)的管理,Gitlab需要有更強(qiáng)的服務(wù)化能力.

3.3 GITService服務(wù)化模型

3.3.1 服務(wù)流程

基于Gitlab的服務(wù)化問(wèn)題,我們提出了基于Gitlab的GITService服務(wù)化模型,新的服務(wù)化方法依然基于RESTful API構(gòu)建,兼容了固有的 Gitlab 服務(wù)化方法,提供了更加靈活、拓展性更強(qiáng)、可定制的細(xì)粒度的對(duì)外服務(wù).從流程上講,如圖 1 所示,根據(jù)所請(qǐng)求的服務(wù)種類(lèi)的不同,使用不同的解析方式對(duì)參數(shù)解析,并繼續(xù)執(zhí)行對(duì)應(yīng)的服務(wù)化流程.在GITService服務(wù)化流程中,當(dāng)前服務(wù)完成后,首先判斷當(dāng)前服務(wù)是否與前置服務(wù)有關(guān)聯(lián),如果判斷為真,說(shuō)明當(dāng)前服務(wù)與前置服務(wù)在同一個(gè)子流程中,需要判斷子流程是否滿(mǎn)足終止條件,如果不滿(mǎn)足,則繼續(xù)執(zhí)行子流程,若當(dāng)前服務(wù)為子流程最后一個(gè)節(jié)點(diǎn),則將當(dāng)前服務(wù)狀態(tài)更新為未完成,以前置服務(wù)為起點(diǎn),重新執(zhí)行整個(gè)子流程,直至流程中最后的服務(wù)節(jié)點(diǎn)的執(zhí)行狀態(tài)滿(mǎn)足子流程終止條件.

圖1 GitService 服務(wù)化流程圖

3.3.2 服務(wù)標(biāo)準(zhǔn)

通過(guò)分析Gitlab現(xiàn)有服務(wù)的數(shù)據(jù)標(biāo)準(zhǔn),發(fā)現(xiàn)這個(gè)標(biāo)準(zhǔn)難以對(duì)不同參數(shù)靈活處理,難以拓展新的服務(wù)也難以提供更細(xì)粒度的服務(wù).

因此,為了提供更靈活、拓展性更強(qiáng)、更細(xì)粒度的服務(wù),我們需要設(shè)計(jì)新的服務(wù)標(biāo)準(zhǔn).該服務(wù)標(biāo)準(zhǔn)能夠?qū)?shù)靈活解析;能夠以參數(shù)化的方法進(jìn)行新服務(wù)的配置,從而實(shí)現(xiàn)對(duì)服務(wù)的拓展;能夠利用服務(wù)標(biāo)準(zhǔn),通過(guò)解析服務(wù)需求的方法,對(duì)資源進(jìn)行細(xì)粒度的服務(wù).新的服務(wù)數(shù)據(jù)標(biāo)準(zhǔn)如表3所示.通過(guò)iscas_type表示要執(zhí)行的對(duì)外服務(wù)編號(hào),添加新服務(wù)時(shí),在配置文件中添加新服務(wù)和對(duì)應(yīng)的編號(hào)即可,該方法以可配置的形式實(shí)現(xiàn)了較強(qiáng)的服務(wù)拓展性.在content字段中,以json格式記錄關(guān)鍵參數(shù)信息,在執(zhí)行服務(wù)時(shí)將字段靈活解析,借助json解析速度快的優(yōu)勢(shì),實(shí)現(xiàn)了靈活的服務(wù)能力且不會(huì)對(duì)于服務(wù)性能造成過(guò)多影響;根據(jù)解析得到的參數(shù),解析其具體含義,可以定制任意細(xì)粒度的服務(wù).使用issue_id作為觸發(fā)服務(wù)驗(yàn)證的標(biāo)記,如果事件中包含issue_id關(guān)鍵字內(nèi)容,則驗(yàn)證當(dāng)前事件是否為服務(wù)所監(jiān)聽(tīng)的事件.使用status字段和target_id字段,實(shí)現(xiàn)前置服務(wù)與當(dāng)前服務(wù)的關(guān)聯(lián),借助status標(biāo)記子流程完成情況的狀態(tài)信息,決定整個(gè)循環(huán)服務(wù)的結(jié)果;也可以使用flag為觸發(fā)服務(wù)驗(yàn)證的標(biāo)記,如果事件中包含flag信息,則驗(yàn)證當(dāng)前事件是否為服務(wù)所監(jiān)聽(tīng)的事件.

3.3.3 服務(wù)實(shí)現(xiàn)

依據(jù)Gitlab服務(wù)化能力類(lèi)型,將GITService分為監(jiān)聽(tīng)服務(wù)和執(zhí)行服務(wù)兩部分實(shí)現(xiàn).

3.3.3.1 監(jiān)聽(tīng)服務(wù)

監(jiān)聽(tīng)服務(wù),主要包含兩個(gè)部分,監(jiān)聽(tīng)服務(wù)信息存儲(chǔ)和監(jiān)聽(tīng)反饋.監(jiān)聽(tīng)服務(wù)信息存儲(chǔ)是指,將請(qǐng)求監(jiān)聽(tīng)服務(wù)時(shí)傳入的參數(shù)信息、狀態(tài)信息、回調(diào)地址等信息解析,將信息以服務(wù)標(biāo)準(zhǔn)格式化,并存儲(chǔ)起來(lái).監(jiān)聽(tīng)反饋是指在實(shí)際的代碼與開(kāi)發(fā)中,獲取用戶(hù)與Gitlab的交互信息,異步的判斷發(fā)生事件是否為所需要監(jiān)聽(tīng)的事件,若判斷為真,則將事件發(fā)生的情況反饋給回調(diào)地址.

監(jiān)聽(tīng)服務(wù)信息存儲(chǔ)主要包括“三步驗(yàn)證一步判斷”.如圖2所示,Gitlab獲取服務(wù)請(qǐng)求后,首先驗(yàn)證請(qǐng)求中的權(quán)限信息(驗(yàn)證1),判斷其是否被允許調(diào)用Gitlab的服務(wù),隨后根據(jù)請(qǐng)求的地址和解析的字段信息判斷所請(qǐng)求的是Gitlab事件監(jiān)聽(tīng)服務(wù)還是GITService事件監(jiān)聽(tīng)服務(wù)(判斷 1),在 GITService監(jiān)聽(tīng)中,需要再次對(duì)重要參數(shù)進(jìn)行解析,驗(yàn)證請(qǐng)求是否有權(quán)限對(duì)相應(yīng)資源監(jiān)聽(tīng)(驗(yàn)證2),將信息以服務(wù)標(biāo)準(zhǔn)格式化,對(duì)參數(shù)合法性進(jìn)行驗(yàn)證(驗(yàn)證3),驗(yàn)證成功后需要對(duì)重要參數(shù)以json的形式組合并存儲(chǔ)在content中,存儲(chǔ)格式化后的信息供監(jiān)聽(tīng)反饋階段使用.

表3 GITService 服務(wù)標(biāo)準(zhǔn)

監(jiān)聽(tīng)反饋主要包括“五步判斷”.由于監(jiān)聽(tīng)反饋過(guò)程需要對(duì)Gitlab的任何事件進(jìn)行監(jiān)聽(tīng),再刪選出需要監(jiān)聽(tīng)的事件,但如果在相同模塊同步監(jiān)聽(tīng),由于增加了判斷與驗(yàn)證機(jī)制,會(huì)使Gitlab的交互響應(yīng)時(shí)間大大延長(zhǎng).而使用消息隊(duì)列機(jī)制捕捉當(dāng)前事件的關(guān)鍵信息,使用異步機(jī)制進(jìn)行判斷與驗(yàn)證,能夠從最大程度上減少監(jiān)聽(tīng)反饋對(duì)于Gitlab的交互響應(yīng)時(shí)間的影響,所以本文采用消息隊(duì)列與異步機(jī)制進(jìn)行監(jiān)聽(tīng)反饋.如圖3所示,當(dāng)用戶(hù)與Gitlab交互時(shí),使用字符串匹配的方法,判斷交互信息中是否包含如issue_id或flag的標(biāo)記字段(判斷1),如果判斷為真,證明其有可能是所需監(jiān)聽(tīng)的事件,異步的執(zhí)行監(jiān)聽(tīng)任務(wù)和事件,在事件異步執(zhí)行的過(guò)程中,通過(guò) Ruby on Rails框架提供的消息隊(duì)列與異步機(jī)制,從消息隊(duì)列獲取所監(jiān)聽(tīng)事件的關(guān)鍵信息,結(jié)合上一步存儲(chǔ)的監(jiān)聽(tīng)服務(wù)信息,異步判斷當(dāng)前發(fā)生的事件是否為所需要監(jiān)聽(tīng)的事件(判斷2),判斷為真的情況下,封裝當(dāng)前事件的監(jiān)聽(tīng)信息,以規(guī)定的格式反饋給回調(diào)地址,繼續(xù)判斷當(dāng)前監(jiān)聽(tīng)服務(wù)是否與前置服務(wù)有關(guān)聯(lián)(判斷3),若判斷為假則結(jié)束當(dāng)前監(jiān)聽(tīng)服務(wù),若判斷為真,說(shuō)明當(dāng)前服務(wù)存在于子流程中,繼續(xù)判斷子流程是否滿(mǎn)足終止條件(判斷4),若為真,說(shuō)明已經(jīng)執(zhí)行完子流程,結(jié)束子流程,若未完成,則繼續(xù)進(jìn)行子流程,判斷當(dāng)前服務(wù)節(jié)點(diǎn)是否為子流程的最后一個(gè)節(jié)點(diǎn)(判斷 5),若判定為真,則重置前置服務(wù)狀態(tài),將前置服務(wù)狀態(tài)更新為未完成,以前置服務(wù)為起點(diǎn),重新執(zhí)行整個(gè)子流程,直至子流程滿(mǎn)足終止條件.

3.3.3.2 執(zhí)行服務(wù)

執(zhí)行服務(wù)是指在完成指定任務(wù)的執(zhí)行后,將執(zhí)行結(jié)果的相關(guān)信息反饋給回調(diào)地址.執(zhí)行服務(wù)中主要涉及“兩步驗(yàn)證三步判斷”.如圖4所示,Gitlab獲取請(qǐng)求后,驗(yàn)證請(qǐng)求是否有權(quán)限調(diào)用該執(zhí)行服務(wù)(驗(yàn)證1),在通過(guò)權(quán)限驗(yàn)證之后,解析請(qǐng)求字段,分析判斷所請(qǐng)求的是GITService執(zhí)行服務(wù)還是Gitlab執(zhí)行服務(wù)(判斷1).對(duì)于GITService執(zhí)行服務(wù)而言,需要針對(duì)請(qǐng)求中的重要字段解析,使用服務(wù)標(biāo)準(zhǔn)格式化并存儲(chǔ)重要信息,通過(guò)驗(yàn)證服務(wù)成功判斷請(qǐng)求對(duì)所需執(zhí)行資源有權(quán)限后(驗(yàn)證 2),即在 Gitlab 執(zhí)行對(duì)應(yīng)的任務(wù),執(zhí)行結(jié)束后,與監(jiān)聽(tīng)服務(wù)類(lèi)似,若判斷子流程結(jié)束(判斷2),則將執(zhí)行結(jié)果以固定格式反饋給回調(diào)地址,若不滿(mǎn)足子流程結(jié)束條件,判斷當(dāng)前服務(wù)節(jié)點(diǎn)是否為子流程的最后一個(gè)服務(wù)節(jié)點(diǎn),若判斷為假則繼續(xù)執(zhí)行子流程,若判斷為真,則重新執(zhí)行子流程.

圖2 監(jiān)聽(tīng)服務(wù)信息存儲(chǔ)流程圖

4 實(shí)驗(yàn)分析

基于Gitlab服務(wù)化存在的三類(lèi)問(wèn)題,本章首先針對(duì)GITService的服務(wù)化能力進(jìn)行評(píng)價(jià),然后針對(duì)GITService可能給Gitlab的正常業(yè)務(wù)處理和響應(yīng)時(shí)間帶來(lái)的潛在負(fù)面影響,進(jìn)行響應(yīng)時(shí)間的對(duì)比分析.

4.1 服務(wù)化能力評(píng)價(jià)

我們基于常用服務(wù),對(duì)Gitlab與GITService的服務(wù)化能力比較,在靈活性、可拓展性、服務(wù)粒度等三個(gè)指標(biāo)上評(píng)價(jià)GITService服務(wù)化能力.如表4所示,GITService在所有常用服務(wù)中,均表現(xiàn)出更優(yōu)的靈活性、能夠提供更細(xì)粒度的服務(wù);在擴(kuò)展性方面,在部分項(xiàng)后上具有更強(qiáng)的可拓展性,在其他項(xiàng)后上保持原有的可拓展性.

圖3 監(jiān)聽(tīng)反饋流程圖

4.2 時(shí)間分析

由于GITService服務(wù)化提供了更多更細(xì)粒度的監(jiān)聽(tīng)服務(wù),在實(shí)現(xiàn)時(shí),在不同資源請(qǐng)求操作中需要調(diào)用監(jiān)聽(tīng)服務(wù)模塊,雖然在設(shè)計(jì)上采用了異步的形式執(zhí)行監(jiān)聽(tīng)服務(wù),但是在執(zhí)行監(jiān)聽(tīng)服務(wù)之前需要針對(duì)事件進(jìn)行針對(duì)flag或issue_id的判斷,需要在Gitlab處理自身業(yè)務(wù)時(shí),判斷當(dāng)前處理的業(yè)務(wù)是否為目標(biāo)監(jiān)聽(tīng)事件,存在對(duì)Gitlab的Web業(yè)務(wù)交互處理時(shí)間的潛在負(fù)面影響.

我們從時(shí)間上分析了GITService是否存在對(duì)于Gitlab的Web業(yè)務(wù)交互的負(fù)面影響.我們?cè)谙嗤瑱C(jī)器、相同網(wǎng)絡(luò)環(huán)境下進(jìn)行試驗(yàn),針對(duì)Gitlab常用的幾類(lèi)資源,對(duì)比Gitlab入GITService服務(wù)體系前后的平均響應(yīng)時(shí)間.如表五所示,GITService 對(duì)于 Gitlab 在常用資源的Web業(yè)務(wù)處理與響應(yīng)時(shí)間的影響很小,根據(jù)[15]的觀點(diǎn),響應(yīng)時(shí)間在2秒以?xún)?nèi)即可以達(dá)到較好的用戶(hù)體驗(yàn),在實(shí)驗(yàn)中發(fā)現(xiàn),響應(yīng)時(shí)間在10毫秒級(jí)別的影響在3%以?xún)?nèi),可以認(rèn)為GITService幾乎不存在對(duì)Gitlab處理Web交互業(yè)務(wù)與響應(yīng)時(shí)間的負(fù)面影響.

5 結(jié)語(yǔ)

本文針對(duì)面向工作流環(huán)境的Gitlab服務(wù)化所存在的靈活性差、拓展性差和服務(wù)粒度粗的問(wèn)題,提出了一種在工作流環(huán)境中更優(yōu)的服務(wù)化方案——GITService.通過(guò)對(duì)比和實(shí)驗(yàn)發(fā)現(xiàn),GITService是一種能夠提供靈活性好、拓展性強(qiáng)、細(xì)粒度化服務(wù)的Gitlab服務(wù)化解決方案.同時(shí),GITService保證了Gitlab自身項(xiàng)后結(jié)構(gòu)的完整性,展現(xiàn)出了較優(yōu)的兼容性.最終通過(guò)對(duì)入GITService 前后,對(duì) Gitlab 交互響應(yīng)時(shí)間的實(shí)驗(yàn)對(duì)比,發(fā)現(xiàn)GITService對(duì)Gitlab處理Web交互相關(guān)業(yè)務(wù)及響應(yīng)時(shí)間的影響很小,表明GITService使用較低的代價(jià),改善了對(duì)于Gitlab對(duì)外服務(wù)體系在工作流環(huán)境下的服務(wù)能力.

本文僅針對(duì)Gitlab的服務(wù)化進(jìn)行了研究,通過(guò)提出一種新的GITService服務(wù)化解決方案,解決了Gitlab服務(wù)化中現(xiàn)存的問(wèn)題.但是對(duì)于Gitlab自身而言,依然有許多需要改進(jìn)之處,尤其是對(duì)內(nèi)的權(quán)限管理、代碼審核等方面依然有較多值得研究的工作.進(jìn)一步工作將針對(duì)Gitlab內(nèi)部體系、代碼審核等方面提出更優(yōu)的解決方案和驗(yàn)證方法.

圖4 執(zhí)行服務(wù)流程圖

表4 Gitlab 和 GITService 的服務(wù)化能力評(píng)價(jià)

表5 入 GITService 前后響應(yīng)時(shí)間分析

1 Workflow Management Coalition.WFMC-TC-1003:The workflow reference model.Cohasset:Workflow Management Coalition,1995:1–55.

2 劉書(shū)雷,劉云翔,張帆,等.一種服務(wù)聚合中 QoS 全局最優(yōu)服務(wù)動(dòng)態(tài)選擇算法.軟件學(xué)報(bào),2007,18(3):646–656.

3 張成文,蘇森,陳俊亮.基于遺傳算法的 QoS 感知的Web 服務(wù)選擇.計(jì)算機(jī)學(xué)報(bào),2006,29(7):1029–1037.

4 程強(qiáng).Web Services服務(wù)質(zhì)量模型與量化算法研究[碩士學(xué)位論文].成都:電子科技大學(xué),2008.

5 羅海濱,范玉順,吳澄.工作流技術(shù)綜述.軟件學(xué)報(bào),2000,11(7):899–907.

6 Duan Q,Yan YH,Vasilakos AV.A survey on serviceoriented network virtualization toward convergence of networking and cloud computing.IEEE Trans.on Network and Service Management,2012,9(4):373–392.[doi:10.1109/TNSM.2012.113012.120310]

7 Banerjee P,Friedrich R,Bash C,et al.Everything as a service:Powering the new information economy.Computer,2011,44(3):36–43.[doi:10.1109/MC.2011.67]

8 張衛(wèi),張童,查亞兵.基于HLA分布式仿真的Web服務(wù)化.國(guó)防科技大學(xué)學(xué)報(bào),2008,30(5):120–124.

9 周巧俊.RESTful Web服務(wù)開(kāi)放平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[碩士學(xué)位論文].杭州:浙江大學(xué),2016.

10 Lee S,Jo JY,Kim Y.Method for secure RESTful web service.IEEE/ACIS 14th International Conference on Computer and Information Science (ICIS).Las Vegas,NV,USA.2015.77–81.

11 Rathod DM,Dahiya MS,Parikh SM.Towards composition of RESTful web services.2015 6th International Conference on Computing,Communication and Networking Technologies (ICCCNT).Denton,TX,USA.2015.1–6.

12 Selvakumar G,Kaviya BJ.A survey on RESTful web services composition.2016 International Conference on Computer Communication and Informatics (ICCCI).Coimbatore,India.2016.1–4.

13 Mehdi M,Bouguila N,Bentahar J.Trust and reputation of web services through QoS correlation lens.IEEE Trans.on Services Computing,2016,9(6):968–981.[doi:10.1109/TSC.2015.2426185]

14 Zhong Y,Fan YS,Tan W,et al.Web service recommendation with reconstructed profile from mashup descriptions.IEEE Trans.on Automation Science and Engineering,2016,doi:10.1109/TASE.2016.2624310.

15 陳能技,黃志國(guó).軟件測(cè)試技術(shù)大全:測(cè)試基礎(chǔ) 流行工具項(xiàng)后實(shí)戰(zhàn).3 版.北京:人民郵電出版社,2015.

Design of Workflow Oriented Gitlab as a Service

ZHANG Yu-Guang1,2,WANG Jun-Jie1,HU Yuan-Zhe1,WANG Qing1,2,3

1(Laboratory for Internet Software Technologies,Institute of Software,Chinese Academy of Sciences,Beijing 100190,China)
2(University of Chinese Academy of Sciences,Beijing 100049,China)3(State Key Laboratory of Computer Science,Institute of Software,Chinese Academy of Sciences,Beijing 100190,China)

Web service could make events and data generated in software products as service by which software products interact with each other.Workflow is a very popular way to deal with message flow and event flow which could deliver events and data among software products.It is very meaningful to study Gitlab which is known as a widely used open source code and document management tool.However,poor flexibility,weak expandability and raw service granularity are found in Gitlab service during the study.To tackle the problems in Gitlab,this paper proposes a new service solution to Gitlab which redefines the service process,service standard and service implement.To implement the services,we design and implement new solutions for listening services and execution services which involve the message queue and asynchronous mechanism.According to experimental analysis to this solution,GITService has high flexibility,strong expandability and intensive service granularity with little cost of time.The solution we provide in this paper is of significance to design and implementation of service in other situations.

Gitlab;workflow;software as a service;RESTful;service granularity

張宇光,王俊杰,胡淵喆,王青.面向工作流的 Gitlab 服務(wù)化設(shè)計(jì).計(jì)算機(jī)系統(tǒng)應(yīng)用,2017,26(9):224–231.http://www.c-s-a.org.cn/1003-3254/5962.html

①基金項(xiàng)后:國(guó)家自然科學(xué)基金(61432001,61602450)

2016-12-29;采用時(shí)間:2017-01-20