葉 盛，王 菁*，辛建峰，王桂玲，郭陳虹

（1.北方工業(yè)大學(xué) 信息學(xué)院，北京 100144；2.大規(guī)模流數(shù)據(jù)集成與分析技術(shù)北京市重點(diǎn)實(shí)驗(yàn)室（北方工業(yè)大學(xué)），北京 100144；3.中國(guó)網(wǎng)絡(luò)安全審查技術(shù)與認(rèn)證中心，北京 100013）

0 引言

微服務(wù)架構(gòu)風(fēng)格是應(yīng)用程序被分解成小的獨(dú)立構(gòu)建塊（微服務(wù)），每個(gè)構(gòu)建塊都專注于單個(gè)業(yè)務(wù)能力。微服務(wù)以輕量級(jí)機(jī)制相互通信，它們可以獨(dú)立部署和維護(hù)。但是微服務(wù)分散性的風(fēng)格無(wú)法獨(dú)立滿足一個(gè)完善的系統(tǒng)，需要組合微服務(wù)提供復(fù)雜而精細(xì)的功能。

微服務(wù)組合可以理解為：通過(guò)靈活組裝多個(gè)高度自治的微服務(wù)給用戶提供強(qiáng)大的功能或者滿足上層的各種復(fù)雜的業(yè)務(wù)需求。本文的微服務(wù)系統(tǒng)基于云邊環(huán)境下的微服務(wù)演化框架，并通過(guò)本文提出的方法進(jìn)行微服務(wù)的組合和演化來(lái)滿足用戶的需求；但是，微服務(wù)組合的不確定性為云邊環(huán)境的有效利用帶來(lái)了新的挑戰(zhàn)。用戶需求具有不確定性，微服務(wù)組合邏輯會(huì)隨著業(yè)務(wù)需求的變化而動(dòng)態(tài)調(diào)整，微服務(wù)組合系統(tǒng)需要隨著用戶需求的變化而快速演化。為了支持微服務(wù)組合的高效執(zhí)行，保證服務(wù)質(zhì)量，本文提出了一種云邊環(huán)境下的微服務(wù)組合系統(tǒng)的動(dòng)態(tài)演化方法（Dynamic Evolution method for Microservice Composition system，DE4MC），通過(guò)業(yè)務(wù)流程中的發(fā)布/訂閱通信手段使云邊節(jié)點(diǎn)上的微服務(wù)之間建立協(xié)作，綜合考慮微服務(wù)實(shí)例的遷移代價(jià)、微服務(wù)與用戶的數(shù)據(jù)通信代價(jià)和微服務(wù)之間的數(shù)據(jù)流傳輸代價(jià)，支持業(yè)務(wù)流程的優(yōu)化部署和動(dòng)態(tài)調(diào)整。其中，包含了以業(yè)務(wù)流程運(yùn)行時(shí)間和微服務(wù)系統(tǒng)演化開銷為目標(biāo)優(yōu)化的兩個(gè)階段的云邊調(diào)度算法：一是在業(yè)務(wù)流程部署階段，通過(guò)業(yè)務(wù)流程部署算法對(duì)流程和微服務(wù)進(jìn)行優(yōu)化部署；二是在業(yè)務(wù)流程動(dòng)態(tài)調(diào)整階段，通過(guò)業(yè)務(wù)流程動(dòng)態(tài)調(diào)整算法進(jìn)行微服務(wù)組合系統(tǒng)的動(dòng)態(tài)演化。這兩個(gè)階段的算法可保證微服務(wù)系統(tǒng)在演化開銷低和業(yè)務(wù)流程運(yùn)行時(shí)間短的條件下及時(shí)演化，并提供用戶滿意的服務(wù)質(zhì)量。

1 相關(guān)工作

1.1 微服務(wù)組合相關(guān)工作

傳統(tǒng)的服務(wù)組合風(fēng)格有編制（Orchestration）和編排（Choreography）。很多微服務(wù)組合的相關(guān)研究借鑒了傳統(tǒng)的Web 服務(wù)組合的思想和策略。

編制風(fēng)格（Orchestration）Cocconi 等［1］提出了一種依靠中心協(xié)調(diào)器的協(xié)作業(yè)務(wù)流程（Collaborative Business Processes）的方法組合微服務(wù)。Oberhauser［2］提出了一種微流程的方法，通過(guò)使用代理編制語(yǔ)義注釋的微服務(wù)。Ben Hadj Yahia 等［3］提出了基于事件驅(qū)動(dòng)的輕量級(jí)服務(wù)編制平臺(tái)——Medley。Monteiro 等［4］提出了基于事件驅(qū)動(dòng)的輕量級(jí)微服務(wù)編制平臺(tái)——貝多芬（Beethoven）。Gao 等［5］提出了一個(gè)微服務(wù)組的概念，用工作流的方式在多云環(huán)境下考慮服務(wù)質(zhì)量和用戶的偏好以組合微服務(wù)。本文借鑒了編制風(fēng)格的一些組合微服務(wù)的思想。

編排風(fēng)格（Choreography）Valderas 等［6］用業(yè)務(wù)流程建模與標(biāo)注（Business Process Model and Notation，BPMN）可視化為微服務(wù)組合的大圖，將大圖拆成BPMN 片段的小圖，允許每個(gè)微服務(wù)以解耦的方式運(yùn)行，并采用BPMN2.0 原生自帶的消息任務(wù)和事件通信。Safina 等［7］介紹了一個(gè)將實(shí)現(xiàn)的編排操作通過(guò)編譯器轉(zhuǎn)換為可執(zhí)行代碼并分發(fā)給參與者的程序。Decker 等［8］將BPMN 模型轉(zhuǎn)換為業(yè)務(wù)可編排的流程執(zhí)行語(yǔ)言（Business Process Execution Language for Choreographies，BPEL4Chor）描述以 執(zhí)行編 排 。Gutiérrez-Fernández 等［9］采用BPM 語(yǔ)言開發(fā)微服務(wù)，用業(yè)務(wù)流程引擎執(zhí)行它，并確定了業(yè)務(wù)流程集成到微服務(wù)體系結(jié)構(gòu)的要求和流程引擎如何處理微服務(wù)之間的部署和通信。Ortiz 等［10］利用BPMN 可以描述控制流的方式編排組合微服務(wù)，并仔細(xì)描述了自底向上的方式，即對(duì)單個(gè)微服務(wù)進(jìn)行改變會(huì)影響全局大圖。Jayawardana 等［11］提出了一種新的方法，在統(tǒng)一的規(guī)范中對(duì)業(yè)務(wù)流程和領(lǐng)域知識(shí)進(jìn)行建模，該規(guī)范可以生成與微服務(wù)體系結(jié)構(gòu)兼容的樣板代碼。Valderas等［12］使用靈活的微服務(wù)架構(gòu)執(zhí)行BPMN 并促進(jìn)它與物理設(shè)備的集成，實(shí)現(xiàn)了兩者之間的解耦，并且不會(huì)增加BPMN 元模型的復(fù)雜性。Dai 等［13］提出了一種微服務(wù)編排分析方法，從給定的編排中生成參與復(fù)合服務(wù)的微服務(wù)。Giallorenzo等［14］討論了編排的不同解釋如何幫助開發(fā)正確的微服務(wù)系統(tǒng)架構(gòu)，即那些真正實(shí)現(xiàn)所需的分布式交互，同時(shí)避免死鎖和競(jìng)爭(zhēng)的微服務(wù)系統(tǒng)架構(gòu)。受上述工作啟發(fā)，本文通過(guò)采用業(yè)務(wù)流程的方式編排微服務(wù)。

微服務(wù)組合方法［15］可分為三種：一是基于工作流模型的微服務(wù)組合方法，上述文獻(xiàn)多為這種方法，是微服務(wù)體系結(jié)構(gòu)中使用較多的一種服務(wù)組合方式；二是基于狀態(tài)演化的微服務(wù)組合方法，本質(zhì)上也是一種工作流的微服務(wù)組合方法，但主要完成微服務(wù)組合方案的可行性驗(yàn)證和對(duì)微服務(wù)的形式化建模；三是基于形式化語(yǔ)言的微服務(wù)組合方法，其思想是為微服務(wù)組合定義一種特殊語(yǔ)言，讓用戶在更深的抽象層次描述微服務(wù)組合并實(shí)現(xiàn)。采用面向服務(wù)的編程語(yǔ)言Jolie［16］作為描述微服務(wù)組合的語(yǔ)言，通過(guò)定義描述服務(wù)行為的語(yǔ)法結(jié)構(gòu)和服務(wù)部署的端口等信息解決服務(wù)組合等問(wèn)題。在組合服務(wù)實(shí)現(xiàn)過(guò)程中，需要對(duì)Jolie 進(jìn)行一定的擴(kuò)展完成服務(wù)組合調(diào)用所需的條件，如數(shù)據(jù)傳輸?shù)?，所以相較于工作流形式的微服務(wù)組合方法更復(fù)雜。但是基于本文的研究背景，盡管統(tǒng) 一建模語(yǔ)言（Unified Modeling Language，UML）、BPMN、BPEL、Medley、Jolie 等方法都可以創(chuàng)建微服務(wù)，但它們很少關(guān)注微服務(wù)的演化［10］，本文引入BPMN 片段解決這個(gè)問(wèn)題，允許自上而下和自下而上的編排方式演化微服務(wù)。利用BPMN 建模的可視化性特點(diǎn)組合微服務(wù)的方式給開發(fā)者和用戶帶來(lái)良好的使用體驗(yàn)［6］。

1.2 微服務(wù)調(diào)度和演化相關(guān)工作

為了解決不同微服務(wù)之間不同版本的復(fù)雜依賴關(guān)系，賀祥等［17］提出面向演化的微服務(wù)編程框架和微服務(wù)系統(tǒng)自適應(yīng)架構(gòu)，并設(shè)計(jì)基于貪婪的優(yōu)化算法找到最優(yōu)的微服務(wù)系統(tǒng)演化方案以實(shí)現(xiàn)微服務(wù)系統(tǒng)的自適應(yīng)演化。在這兩個(gè)框架的基礎(chǔ)上，He 等［18］提出了云邊環(huán)境下的微服務(wù)自適應(yīng)演化優(yōu)化方法，滿足移動(dòng)端用戶的質(zhì)量需求。Wang 等［19］采用Java 中輕量級(jí)的方法實(shí)現(xiàn)了微服務(wù)演化編程框架，支持單個(gè)微服務(wù)的自適應(yīng)演化。這些工作的自適應(yīng)機(jī)制是由一個(gè)自適應(yīng)控制回路參考模型MAPE-K（Monitor-Analyze-Plan-Execute-Knowledge）［20］實(shí)現(xiàn)的。但這些工作中并沒有考慮微服務(wù)組合系統(tǒng)的特殊演化需求。本文在這些工作的基礎(chǔ)上擴(kuò)展了通過(guò)業(yè)務(wù)流程組合微服務(wù)的方法及技術(shù)。

微服務(wù)調(diào)度方面，Gao 等［21］提出了一種新的基于免疫記憶克隆和克隆選擇算法的人工免疫算法，在大量候選微服務(wù)中組成復(fù)雜的工作流，該算法通過(guò)構(gòu)造與用戶相關(guān)的模糊權(quán)重將多最優(yōu)問(wèn)題轉(zhuǎn)換成單最優(yōu)問(wèn)題。該工作結(jié)合了工作流和微服務(wù)，但是該工作沒有考慮演化的問(wèn)題。Lin 等［22］提出的一種蟻群算法，考慮物理節(jié)點(diǎn)的計(jì)算利用率、存儲(chǔ)資源的利用率、微服務(wù)請(qǐng)求的數(shù)量和物理節(jié)點(diǎn)的故障率以提供最優(yōu)路徑的選擇概率。該算法在集群服務(wù)可靠性、集群負(fù)載均衡和網(wǎng)絡(luò)傳輸開銷優(yōu)化等方面取得了較好的效果，但也沒有考慮微服務(wù)的演化問(wèn)題，不過(guò)在服務(wù)可靠性和資源利用率等方面的部分工作可以借鑒。

以上的工作有結(jié)合微服務(wù)組合和調(diào)度、微服務(wù)組合和演化、微服務(wù)演化和調(diào)度，但是本文方法結(jié)合了微服務(wù)的組合、演化和調(diào)度。

2 DE4MC

本文提出了一種云邊環(huán)境下的微服務(wù)組合系統(tǒng)的動(dòng)態(tài)演化方法（DE4MC）去支持微服務(wù)組合和及時(shí)演化。

2.1 相關(guān)定義

一個(gè)云邊環(huán)境下的微服務(wù)組合系統(tǒng)由一組邏輯服務(wù)組成，每個(gè)邏輯服務(wù)都有部署在不同云邊節(jié)點(diǎn)的物理實(shí)例。一個(gè)業(yè)務(wù)流程是一組邏輯的特定服務(wù)，根據(jù)優(yōu)化算法（詳情見第3 章）選擇這些服務(wù)的特定實(shí)例滿足業(yè)務(wù)需求。

定義5 業(yè)務(wù)流程定向狀態(tài)。業(yè)務(wù)流程定向狀態(tài)BP（b）記錄了業(yè)務(wù)流程片段與微服務(wù)實(shí)例之間的映射。對(duì)于?r∈V(b)，假定r=s，u，c，為r選擇一個(gè)請(qǐng)求的服務(wù)s的實(shí)例τ(s)和該服務(wù)相關(guān)的功能接口Ii（s），(τ(s)，Ij) ∈BP(b)。一個(gè)合法的業(yè)務(wù)流程定向狀態(tài)必須滿足微服務(wù)實(shí)例τ(s)提供的質(zhì)量等級(jí)Li（s）必須大于等于用戶的要求的條件。

定義6 微服務(wù)演化操作。

OPS={Composite，Split，Keep}：

1）Composite(…，Ii(si)，…) ?(s，I1(s))：表示把不同原子服務(wù)通過(guò)業(yè)務(wù)流程組合成一個(gè)新的服務(wù)。

2）Split(s，Ii(s))：表示把一個(gè)組合服務(wù)切成不同的原子服務(wù)。

3）Keep(s)：表示該服務(wù)的接口不改變。

定義7 微服務(wù)實(shí)例演化操作。

OPI={Adjust，Add，Remove，Retain}：

1）Adjust(τ(s)，Li(s)，Lj(s))：調(diào)整該微服務(wù)實(shí)例的質(zhì)量等級(jí)。

2）Add(τ(s)，n，Lj(s))：在節(jié)點(diǎn)n上創(chuàng)建一個(gè)質(zhì)量等級(jí)要求為L(zhǎng)j的微服務(wù)s的實(shí)例。

3）Remove(τ(s))：刪除該實(shí)例。

4）Retain(τ(s))：保持該實(shí)例不發(fā)生改變。

定義8 業(yè)務(wù)流程定向狀態(tài)的演化操作。

OPU={Deploy，Switch，Keep}，其中：Deploy(b，τ(s))表示把流程片段b跟微服務(wù)s實(shí)例建立映射；Switch(b，τi(s)，τj(s))表示業(yè)務(wù)流程片段b跟微服務(wù)s的實(shí)例τi的映射關(guān)系轉(zhuǎn)移到另一個(gè)實(shí)例τj上。

定義9 部署狀態(tài)。一個(gè)微服務(wù)系統(tǒng)在時(shí)間t的部署狀態(tài)可以 表示為Θ(t)=S(t)，E(t)，N(t)，V(t)，BP(t)，S、E、N、V和BP分別是微服務(wù)集合、節(jié)點(diǎn)集合、微服務(wù)實(shí)例集合、業(yè)務(wù)流程集合和業(yè)務(wù)流程定向狀態(tài)。

2.2 微服務(wù)組合系統(tǒng)演化框架

本文動(dòng)態(tài)演化方法基于EI4MS 的微服務(wù)系統(tǒng)基礎(chǔ)架構(gòu)和EPF4M 微服務(wù)自適應(yīng)編程框架的擴(kuò)展，該架構(gòu)有7 個(gè)組件如圖1 所示。

圖1 微服務(wù)系統(tǒng)的演化架構(gòu)Fig.1 Evolution architecture of microservice system

1）控制中心。用戶直接通過(guò)可視化建模工具創(chuàng)建新的業(yè)務(wù)流程或者修改已運(yùn)行的微服務(wù)實(shí)例，該工具把用戶建?；蛐薷牡男畔⒅苯犹峤唤o分析器，它能識(shí)別業(yè)務(wù)流程文件和業(yè)務(wù)流程實(shí)例并轉(zhuǎn)化成算法需要的輸入格式，再通過(guò)計(jì)劃器中的兩個(gè)算法計(jì)算得出一組系統(tǒng)演化操作，然后放到執(zhí)行器上執(zhí)行。

2）日志收集器。收集每個(gè)節(jié)點(diǎn)上微服務(wù)實(shí)例的運(yùn)行日志，并把所有日志傳遞到邊緣集群中的日志數(shù)據(jù)庫(kù)。

3）微服務(wù)構(gòu)建中心。把自動(dòng)生成相關(guān)的流程片段描述信息、服務(wù)功能語(yǔ)義描述和流程引擎語(yǔ)義描述打包構(gòu)建相應(yīng)的Docker 鏡像，為Composite 和Split 演化操作提供支持。它從控制中心接收Composite 和Split 的作業(yè)，生成 Docker 鏡像并推送到鏡像倉(cāng)庫(kù)進(jìn)行添加操作。它部署在一個(gè)集中的云節(jié)點(diǎn)上。

4）集群代理。負(fù)責(zé)獲取邊緣節(jié)點(diǎn)的運(yùn)行時(shí)信息并傳遞給控制中心，包括日志數(shù)據(jù)庫(kù)的日志、注冊(cè)表、Kubernetes API 服務(wù)器的信息和微服務(wù)的實(shí)例信息。Kubernetes API 服務(wù)器和網(wǎng)關(guān)能夠接收控制中心的演化操作并部署到相應(yīng)節(jié)點(diǎn)。它必須部署在一個(gè)邊緣節(jié)點(diǎn)上。

5）網(wǎng)關(guān)。將用戶請(qǐng)求重定向到服務(wù)實(shí)例，并依賴于用戶請(qǐng)求的路由表。來(lái)源控制中心的Switch 演化操作會(huì)讓路由表發(fā)生改變。它必須部署在邊緣節(jié)點(diǎn)上。

6）用戶可視化建模工具。用戶可以在上面建模自己的業(yè)務(wù)流程，也可以動(dòng)態(tài)修改業(yè)務(wù)流程。

7）通信總線。用通信總線的方式支持部署在云邊節(jié)點(diǎn)上的業(yè)務(wù)流程的消息事件傳遞和消息任務(wù)的執(zhí)行。

2.3 方法原理

如圖2 所示，DE4MC 分為業(yè)務(wù)流程部署和業(yè)務(wù)流程動(dòng)態(tài)調(diào)整兩個(gè)階段。

圖2 微服務(wù)組合系統(tǒng)的動(dòng)態(tài)演化方法Fig.2 Dynamic evolution method of microservice composition system

業(yè)務(wù)流程部署階段 用戶提交業(yè)務(wù)流程后，系統(tǒng)根據(jù)云邊節(jié)點(diǎn)的狀況采用業(yè)務(wù)流程部署調(diào)度算法（詳見第3 章）合理切分業(yè)務(wù)流程并部署在相應(yīng)的節(jié)點(diǎn)上，使業(yè)務(wù)流程運(yùn)行的時(shí)間最短和微服務(wù)演化開銷最低。

由于全國(guó)快遞運(yùn)輸量巨大且每個(gè)快遞公司各地的營(yíng)業(yè)網(wǎng)點(diǎn)數(shù)量多，如果在云上部署相應(yīng)的微服務(wù)會(huì)導(dǎo)致響應(yīng)速度慢和云邊節(jié)點(diǎn)信息不匹配。為了更好地安排人員和交通工具，應(yīng)把相關(guān)的微服務(wù)部署到附近邊緣節(jié)點(diǎn)進(jìn)行準(zhǔn)確且快速的計(jì)算。首先，快遞公司在公司云節(jié)點(diǎn)收到用戶寄快遞的訂單后會(huì)創(chuàng)建一個(gè)最初的流程，其中指派快遞員、支付訂單和貨車運(yùn)輸服務(wù)都在同一個(gè)邊緣節(jié)點(diǎn)且有連續(xù)的控制流和數(shù)據(jù)流關(guān)系；然后，演化系統(tǒng)根據(jù)微服務(wù)演化操作Composite 把這3 個(gè)功能組合成一個(gè)新的復(fù)合服務(wù)以減少數(shù)據(jù)流傳輸和縮短響應(yīng)時(shí)間，通過(guò)Add 生成相應(yīng)的實(shí)例；最后，通過(guò)Deploy 操作建立實(shí)例和流程片段的關(guān)系。系統(tǒng)對(duì)應(yīng)的演化操作如表1所示。

表1 部署和調(diào)整階段演化操作Tab.1 Evolution operations in deployment and adjustment stages

業(yè)務(wù)流程動(dòng)態(tài)調(diào)整階段 用戶提交的業(yè)務(wù)流程已經(jīng)部署運(yùn)行，但是用戶需求臨時(shí)發(fā)生改變，用戶想要修改正在運(yùn)行的流程，系統(tǒng)需要及時(shí)演化響應(yīng)用戶修改后的流程。例如，由于原定的路線上北京通州區(qū)發(fā)生疫情導(dǎo)致快遞公司不得不及時(shí)修改業(yè)務(wù)流程，把原定從廣州白云區(qū)運(yùn)到北京通州區(qū)的飛機(jī)服務(wù)和之后的貨車運(yùn)輸服務(wù)刪除，然后根據(jù)實(shí)際業(yè)務(wù)需求重新添加高鐵服務(wù)、火車服務(wù)等。系統(tǒng)對(duì)應(yīng)演化操作如表1 所示。

3 微服務(wù)組合系統(tǒng)演化算法

本章描述用戶在建模業(yè)務(wù)流程和修改業(yè)務(wù)流程兩個(gè)階段下系統(tǒng)運(yùn)行的演化算法，兩種情況下的問(wèn)題定義是一致的。

其中：A、B和C分別為OP(I)、OP(U)和OP（S）的數(shù)量。

進(jìn)一步，整個(gè)流程的運(yùn)行時(shí)間可以被定義為：

其中：n為該流程中服務(wù)實(shí)例的數(shù)量，rt(·)為每個(gè)微服務(wù)的運(yùn)行時(shí)間，ct(·，·)為業(yè)務(wù)流程片段之間的通信時(shí)間。

本文算法優(yōu)化的調(diào)度目標(biāo)如下：

其中：eij是滿足用戶ui提交的業(yè)務(wù)流程wj需求的一個(gè)微服務(wù)實(shí)例；Q（）表示獲得的服務(wù)級(jí)別協(xié)議（Service Level Agreement，SLA）；r（）用來(lái)計(jì)算資源的大?。籸max（）代表該節(jié)點(diǎn)所有的資源大?。籲s（）代表當(dāng)前使用該微服務(wù)實(shí)例用戶的數(shù)量；nsmax（）表示該實(shí)例設(shè)定的最大用戶數(shù)；δ表示自上次演化以來(lái)經(jīng)過(guò)的時(shí)間間隔。

3.1 算法原理

本文方法由兩個(gè)階段的算法組成，兩個(gè)算法由兩個(gè)原子算法組成：一是追求反應(yīng)快速但可能只得到局部最優(yōu)解的啟發(fā)式算法（Heuristic Algorithm，HA），二是能得到全局最優(yōu)的遺傳算法，該算法以系統(tǒng)的演化開銷和業(yè)務(wù)流程的運(yùn)行時(shí)間為優(yōu)化目標(biāo)。如式（4）所示，系統(tǒng)演化操作必須滿足3 個(gè)約束，分別是節(jié)點(diǎn)上的資源不能被使用完、微服務(wù)的質(zhì)量必須大于用戶的要求和微服務(wù)的實(shí)例數(shù)量不能超過(guò)服務(wù)最大實(shí)例數(shù)。需要注意的是，由于本文采用業(yè)務(wù)流程的方式組合微服務(wù)，業(yè)務(wù)流程中各個(gè)元素之間可能存在數(shù)據(jù)流關(guān)系，在綜合其他約束條件下，算法也會(huì)考慮把兩個(gè)具有數(shù)據(jù)流關(guān)系的微服務(wù)部署在同一個(gè)物理節(jié)點(diǎn)上以降低通信傳輸?shù)拈_銷。如果一個(gè)微服務(wù)的輸出是另外一個(gè)微服務(wù)的輸入且兩者都被頻繁調(diào)用，根據(jù)本文提出的微服務(wù)演化框架，這兩個(gè)微服務(wù)通過(guò)Composite 演化操作聚合成一個(gè)功能更強(qiáng)大的微服務(wù)，方便實(shí)例化和調(diào)度。

3.1.1 基于啟發(fā)算法改造后的算法原理

本文針對(duì)業(yè)務(wù)流程具有數(shù)據(jù)流的特點(diǎn)改造了傳統(tǒng)HA，提出了業(yè)務(wù)流程管理啟發(fā)式算法（Business process management Heuristic Algorithm，BpmHA）算法，通過(guò)節(jié)點(diǎn)評(píng)估函數(shù)選擇節(jié)點(diǎn)進(jìn)行部署。評(píng)估函數(shù)如下：

該評(píng)估函數(shù)綜合考慮三方面因素，分別是遷移代價(jià)（微服務(wù)實(shí)例從云邊節(jié)點(diǎn)到另一個(gè)節(jié)點(diǎn)的代價(jià)，否則代價(jià)為0）、通信代價(jià)（微服務(wù)實(shí)例部署節(jié)點(diǎn)跟所分配用戶通信的代價(jià)，如果該微服務(wù)不需要跟用戶交互就為0）和微服務(wù)之間通信代價(jià)（微服務(wù)之間可能存在數(shù)據(jù)流交互的通信）。根據(jù)實(shí)際用戶的需要或者經(jīng)驗(yàn)分別配置權(quán)重，本文按照各占1/3的權(quán)重進(jìn)行實(shí)驗(yàn)驗(yàn)證，后期通過(guò)不斷實(shí)驗(yàn)得出經(jīng)驗(yàn)再進(jìn)行權(quán)重的合理分配。

算法1 BpmHA。

輸入 業(yè)務(wù)流程文件或?qū)嵗鼴P，所有節(jié)點(diǎn)的運(yùn)行狀態(tài)SN；

輸出 業(yè)務(wù)流程定向狀態(tài)的演化操作OP（U），微服務(wù)實(shí)例演化操作OP（I），微服務(wù)演化操作OP（S）。

如算法1 所示，系統(tǒng)首先把用戶提交的業(yè)務(wù)流程文件分成一個(gè)個(gè)最小的微服務(wù)，遍歷所有云邊節(jié)點(diǎn)查找目標(biāo)微服務(wù)加入微服務(wù)集合，并查找資源能滿足目標(biāo)微服務(wù)部署的節(jié)點(diǎn)放入備選節(jié)點(diǎn)（第3）～4）行），在這些備選節(jié)點(diǎn)上遍歷計(jì)算NE，選最小值的節(jié)點(diǎn)與目標(biāo)服務(wù)關(guān)聯(lián)。如果滿足算法1 所有IF 語(yǔ)句中的微服務(wù)演化操作要求，就進(jìn)行相應(yīng)的演化操作（第10）～23）行）。如果所需的目標(biāo)服務(wù)是已組合服務(wù)的一部分且別的節(jié)點(diǎn)沒有目標(biāo)服務(wù)的鏡像，就需要把目標(biāo)服務(wù)從已組合的服務(wù)通過(guò)Split 操作拆解出來(lái)。如果目標(biāo)微服務(wù)在目標(biāo)節(jié)點(diǎn)已存在實(shí)例，就通過(guò)Switch 演化操作把相關(guān)流程片段與該實(shí)例形成映射。如果目標(biāo)節(jié)點(diǎn)的資源不滿足目標(biāo)微服務(wù)所需要的資源，通過(guò)Adjust 操作進(jìn)行資源的動(dòng)態(tài)調(diào)整。如果目標(biāo)服務(wù)需要被幾個(gè)服務(wù)組合且滿足定義6 的條件，就通過(guò)Composite 操作組合幾個(gè)服務(wù)。如果目標(biāo)節(jié)點(diǎn)沒有該實(shí)例，則需要遷移目標(biāo)服務(wù)鏡像并重新通過(guò)Add 操作創(chuàng)建一個(gè)目標(biāo)服務(wù)實(shí)例。

啟發(fā)算法相較于遺傳算法，執(zhí)行時(shí)間較短。算法的時(shí)間復(fù)雜度為O（mn），m是需要部署的目標(biāo)服務(wù)的數(shù)量，n是所有微服務(wù)的數(shù)量，如果邊緣節(jié)點(diǎn)上沒有相應(yīng)的微服務(wù)實(shí)例，系統(tǒng)會(huì)去云端查找該實(shí)例，但是平均響應(yīng)時(shí)間會(huì)變長(zhǎng)。

3.1.2 基于遺傳算法改造后的算法原理

本文使用第二代非支配排序遺傳算法（Non-dominated Sorting Genetic Algorithm-Ⅱ，NSGA-Ⅱ）［23］，部署狀態(tài)和運(yùn)行實(shí)例轉(zhuǎn)換成種群基因的詳情請(qǐng)參考文獻(xiàn)［18］。

算法2 NSGA-Ⅱ。

輸入 所有節(jié)點(diǎn)的運(yùn)行狀態(tài)SN；

輸出 業(yè)務(wù)流程定向狀態(tài)的演化操作OP（U），微服務(wù)實(shí)例演化操作OP（I），微服務(wù)演化操作OP（S）。

NSGA-Ⅱ引入了精英策略，達(dá)到保留優(yōu)秀個(gè)體淘汰劣等個(gè)體的目的。精英策略通過(guò)將父代與子代個(gè)體混合形成新的群體，擴(kuò)大了產(chǎn)生下一代個(gè)體的篩選范圍。P0表示最初的父代，Q0表示最初的子代，N代表個(gè)體數(shù)。算法具體步驟如下：將父代種群和子代種群形成新的群體，對(duì)新種群進(jìn)行非支配排序，生成新的父代，先將Pareto 等級(jí)為1 的非支配個(gè)體放入新的父代集合中，之后將Pareto 等級(jí)為2 的個(gè)體放入新的父代種群中，以此類推。若等級(jí)為i的個(gè)體全部放入新的父代集合中后，集合中個(gè)體的數(shù)量小于N，而等級(jí)為i+1 的個(gè)體全部放入新的父代集合中后，集合中的個(gè)體數(shù)量大于N，則對(duì)i+1 等級(jí)的全部個(gè)體計(jì)算擁擠度并將所有個(gè)體擁擠度進(jìn)行降序排列，之后將等級(jí)大于i+1 的個(gè)體全部淘汰。對(duì)生成后的父代種群計(jì)算適應(yīng)度，fitness=θ1*T+θ2*C，其中演化開銷和運(yùn)行總時(shí)間的權(quán)重各占一半，選擇適應(yīng)度大的父代進(jìn)行交叉、變異操作生成子代種群。最后判斷代數(shù)是否等于最大進(jìn)化代數(shù)，否則就繼續(xù)執(zhí)行循環(huán)迭代。最終的演化操作規(guī)則見算法2 第15）～29）行。

3.2 業(yè)務(wù)流程部署和動(dòng)態(tài)調(diào)整算法

用戶根據(jù)自己實(shí)際的業(yè)務(wù)需求建模自己需要的業(yè)務(wù)流程，通過(guò)該部署算法計(jì)算演化操作，交由執(zhí)行器作微服務(wù)實(shí)例部署。兩個(gè)算法的策略如圖3 所示。

圖3 算法策略Fig.3 Algorithmic strategy

業(yè)務(wù)流程部署算法 本文改進(jìn)HA 提出了BpmHA，微服務(wù)實(shí)例的遷移代價(jià)、微服務(wù)與用戶的數(shù)據(jù)通信代價(jià)和微服務(wù)之間的數(shù)據(jù)流傳輸代價(jià)是影響微服務(wù)部署效率的三大因素，因此在選擇部署節(jié)點(diǎn)時(shí)綜合計(jì)算三者代價(jià)來(lái)選擇最優(yōu)的部署方案，BpmHA 經(jīng)過(guò)后期實(shí)驗(yàn)?zāi)艿玫揭粋€(gè)近似全局最優(yōu)的解，無(wú)需重復(fù)多次運(yùn)行。如果BpmHA 不滿足用戶的服務(wù)質(zhì)量（Quality of Service，QoS），系統(tǒng)會(huì)采用NSGA-Ⅱ迭代計(jì)算演化操作方案。算法的輸入是用戶提交的業(yè)務(wù)流程和各節(jié)點(diǎn)的部署狀態(tài)（所有節(jié)點(diǎn)的狀態(tài)），算法的輸出是演化方案(OP(U)，OP(I)，OP(S))。

業(yè)務(wù)流程動(dòng)態(tài)調(diào)整算法 與部署算法不同，該算法的輸入是對(duì)云邊節(jié)點(diǎn)上已有運(yùn)行的業(yè)務(wù)流程實(shí)例動(dòng)態(tài)調(diào)整后的實(shí)例；雖然已經(jīng)運(yùn)行完的流程片段不再經(jīng)過(guò)算法重新部署，但是動(dòng)態(tài)調(diào)整的部分仍會(huì)參考已部署的流程狀態(tài)進(jìn)行綜合優(yōu)化部署。動(dòng)態(tài)調(diào)整算法在遺傳算法上也作了改進(jìn)，演化系統(tǒng)記錄兩個(gè)算法已運(yùn)行計(jì)算出的一些較優(yōu)解（使本文的兩個(gè)優(yōu)化目標(biāo)效果不錯(cuò)的解集會(huì)被記錄下來(lái)），NGSA-Ⅱ不需要從最初種群開始迭代計(jì)算，可以從記錄的解集中挑選一批作為父代和子代，提高了種群的迭代速度，用戶修改業(yè)務(wù)流程后演化系統(tǒng)能及時(shí)動(dòng)態(tài)演化。

4 實(shí)驗(yàn)與結(jié)果分析

4.1 仿真平臺(tái)介紹

本文使用仿真軟件CloudSim 和WorkflowSim，其中CloudSim 提供了云計(jì)算相關(guān)的資源建模和任務(wù)調(diào)度方面的仿真；WorkflowSim 在CloudSim 基礎(chǔ)上引入了工作流級(jí)別的仿真，通過(guò)模擬真實(shí)工作流的運(yùn)行機(jī)制來(lái)調(diào)度任務(wù)。用戶可以把設(shè)計(jì)好的調(diào)度算法放到該工具上執(zhí)行，實(shí)現(xiàn)真實(shí)模擬云邊環(huán)境下的工作流調(diào)度。WorkflowSim 被廣泛應(yīng)用于工作流調(diào)度的科研學(xué)習(xí)上。

WorkflowSim 中的工作流形式通過(guò)有向無(wú)環(huán)圖（Directed Acyclic Graph，DAG）的形式表示，本文中的業(yè)務(wù)流程表示為有向無(wú)環(huán)圖，其中業(yè)務(wù)流程中的每個(gè)活動(dòng)表示為圖中的一個(gè)活動(dòng)，業(yè)務(wù)流程的控制流順序相當(dāng)于圖上的邊。

4.2 數(shù)據(jù)集準(zhǔn)備

為了驗(yàn)證本文算法在業(yè)務(wù)流程微服務(wù)部署和調(diào)整兩個(gè)階段的可行性和效率，實(shí)驗(yàn)中需要使用大量不同的工作流。由于公共的數(shù)據(jù)集有限，為了模擬現(xiàn)實(shí)生活中各種需求的業(yè)務(wù)流程，本文實(shí)驗(yàn)中業(yè)務(wù)流程表示為帶有數(shù)據(jù)流的DAG，參照文獻(xiàn)［23］中提出的DAG 構(gòu)造方法，本文設(shè)計(jì)了一種帶有數(shù)據(jù)流的DAG 生成算法，通過(guò)添加一些約束并采用編碼方式生成兩組工作流，其中一組工作流在初始的一組工作流的基礎(chǔ)上隨機(jī)修改以模擬用戶修改后的業(yè)務(wù)流程，再通過(guò)動(dòng)態(tài)調(diào)整算法重新計(jì)算部署。簡(jiǎn)而言之，一組初始的工作流用于測(cè)試業(yè)務(wù)流程部署算法的效率，隨機(jī)修改的工作流用于測(cè)試動(dòng)態(tài)調(diào)整算法的效率。通過(guò)表2 所示的自定義參數(shù)，程序自動(dòng)生成滿足實(shí)驗(yàn)條件的工作流。

表2 工作流參數(shù)設(shè)置Tab.2 Workflow parameters setting

DAG 生成算法隨機(jī)標(biāo)注DAG 的每個(gè)節(jié)點(diǎn)的模擬地理位置，目的是模擬用戶的移動(dòng)。該算法首先隨機(jī)生成節(jié)點(diǎn)與用戶之間的傳輸開銷，再生成一條最長(zhǎng)路徑的工作流，然后通過(guò)隨機(jī)的最大并行度值將剩余的任務(wù)個(gè)數(shù)加入DAG 中，接著逐層連接下層節(jié)點(diǎn)，確保形成一個(gè)連通圖。確定完DAG 所有節(jié)點(diǎn)后，該算法會(huì)在隨機(jī)節(jié)點(diǎn)之間生成有輸入輸出指向性的數(shù)據(jù)訪問(wèn)關(guān)系和具體數(shù)據(jù)值，從而模擬出節(jié)點(diǎn)之間數(shù)據(jù)流關(guān)系。

4.3 實(shí)驗(yàn)環(huán)境配置

為了驗(yàn)證本文提出的業(yè)務(wù)流程動(dòng)態(tài)演化算法的有效性，需要同其他算法進(jìn)行比較。為了減少其他因素對(duì)實(shí)驗(yàn)結(jié)果的影響，實(shí)驗(yàn)環(huán)境均保持一致。本文實(shí)驗(yàn)環(huán)境如下。

實(shí)驗(yàn)所用的服務(wù)器操作系統(tǒng)版本為Windows 10，內(nèi)存32 GB，實(shí)驗(yàn)仿真工具WorkflowSim1.0，Java 環(huán)境為JDK1.8，Python 版本3.6。WorkflowSim 模擬生成的10 個(gè)邊緣節(jié)點(diǎn)的參數(shù)：CPU 運(yùn)算法能力TOPS（Tera Operations Per Second）或者M(jìn)IPS（Million Instructions Per Second）為3 000，內(nèi)存5 GB，外存20 GB，通信帶寬10 MB/s。WorkflowSim 模擬生成的1個(gè)云節(jié)點(diǎn)的參數(shù)：CPU 運(yùn)算法能力：TOPS 或 者M(jìn)IPS 為20 000，內(nèi)存20 GB，外存100 GB，通信帶寬20 MB/s。

為了簡(jiǎn)化實(shí)驗(yàn)，把DAG 的每個(gè)頂點(diǎn)當(dāng)作WorkflowSim 工具中的一個(gè)虛擬機(jī)資源，它的大小和所需要的計(jì)算資源都一樣，具體參數(shù)為：虛擬機(jī)所需CPU 運(yùn)算能力資源TOPS 或者M(jìn)IPS 為20，虛擬機(jī)所占外存大小區(qū)間0.5～1.0 MB。

4.4 算法性能分析

4.4.1 實(shí)驗(yàn)參數(shù)設(shè)置

本文的優(yōu)化目標(biāo)主要有兩個(gè)，一個(gè)是最小化業(yè)務(wù)流程的運(yùn)行時(shí)間，另一個(gè)是最小化微服務(wù)系統(tǒng)的演化開銷。業(yè)務(wù)流程的運(yùn)行時(shí)間包括算法的執(zhí)行時(shí)間和業(yè)務(wù)流程的執(zhí)行時(shí)間。具體演化操作開銷如表3 所示。

表3 演化操作開銷Tab.3 Evolution operation cost

4.4.2 對(duì)比實(shí)驗(yàn)設(shè)置

本文實(shí)驗(yàn)對(duì)比的算法包括GA，NGSA-Ⅱ，HA+NGSA-Ⅱ的算法組合，和本文提出的算法BpmHA+NSGA-Ⅱ的算法組合，表4 是實(shí)驗(yàn)中算法的相關(guān)參數(shù)設(shè)置。

表4 遺傳算法參數(shù)設(shè)置Tab.4 Genetic algorithm parameter setting

算法1 和算法2 的輸出是3 組具體的演化操作，每一種操作的演化開銷都在表6 中具體表示。本文只需要把算法算出來(lái)的演化操作開銷進(jìn)行相加，就能計(jì)算得到總的演化開銷。

4.4.3 實(shí)驗(yàn)結(jié)果展示

DAG 生成算法隨機(jī)組成了1 000 個(gè)DAG，按照固定的順序排列仿真業(yè)務(wù)流程部署的測(cè)試。另外1 000 個(gè)DAG 在原先的DAG 基礎(chǔ)上進(jìn)行微小的改變，用作動(dòng)態(tài)修改業(yè)務(wù)流程的測(cè)試。本文通過(guò)仿真實(shí)驗(yàn)控制該調(diào)度環(huán)境中DAG 的數(shù)量規(guī)模，對(duì)比這幾個(gè)主流算法的總運(yùn)行時(shí)間（調(diào)度完所有的DAG 所用的總時(shí)間）和綜合調(diào)度開銷（調(diào)度完所有的DAG 所消耗的開銷資源）。在部署階段，部署算法（BpmHA+NSGA-Ⅱ）與HA+NSGA-Ⅱ的算法組合相比，各個(gè)規(guī)模的平均運(yùn)行時(shí)間低9.7%，演化總開銷低16.8%；在動(dòng)態(tài)調(diào)整階段，動(dòng)態(tài)調(diào)整算法（BpmHA+NSGA-Ⅱ）與HA 加NSGA-Ⅱ的算法組合相比，各個(gè)規(guī)模平均運(yùn)行時(shí)間低6.3%，演化總開銷低21.7%。

為了更好地驗(yàn)證本文算法的有效性和效率，本文設(shè)置DAG 的規(guī)模為自變量，比較本文算法和對(duì)比算法在部署階段和調(diào)整階段的運(yùn)行時(shí)間，如圖4 所示。

圖4 各算法在不同階段的運(yùn)行時(shí)間Fig.4 Running time of each algorithm in different stages

原因分析 GA 通過(guò)不斷迭代產(chǎn)生最優(yōu)解，需要一定的時(shí)間。NSGA-Ⅱ相較于GA 多了精英策略和尋找非支配解的過(guò)程，所以比GA 時(shí)間長(zhǎng)。HA 較簡(jiǎn)單，會(huì)搜尋每個(gè)節(jié)點(diǎn)已在運(yùn)行的DAG 部分活動(dòng)，只要資源足夠，就直接生成實(shí)例部署，不需要考慮綜合調(diào)度代價(jià)，所以時(shí)間短；但是在該節(jié)點(diǎn)資源臨界情況，該啟發(fā)式算法沒考慮負(fù)載均衡，導(dǎo)致執(zhí)行時(shí)間變長(zhǎng)。HA+NSGA-Ⅱ可以很好地解決這個(gè)問(wèn)題，如果HA 導(dǎo)致運(yùn)行時(shí)間變長(zhǎng)，系統(tǒng)會(huì)啟動(dòng)NSGA-Ⅱ進(jìn)行總的迭代部署，所以總運(yùn)行時(shí)間比GA 短。而BpmHA 改進(jìn)了HA，考慮到負(fù)載均衡和業(yè)務(wù)流程數(shù)據(jù)流的特性，綜合選擇最優(yōu)節(jié)點(diǎn)部署，雖然需要一定的時(shí)間代價(jià)，但是真正執(zhí)行的時(shí)間是所有算法中最短的。如果BpmHA 并沒有使兩個(gè)目標(biāo)得到很好的優(yōu)化，就會(huì)啟動(dòng)NSGA-Ⅱ進(jìn)行總體優(yōu)化，NSGA-Ⅱ不會(huì)從最初狀態(tài)開始迭代，會(huì)從HA 產(chǎn)生的局部最優(yōu)解中挑出一些作為初代，開始迭代計(jì)算，這樣大幅縮短了演化時(shí)間。另外從圖4 中可以明顯看出，調(diào)整階段的算法策略跟部署階段的效果是差不多的，調(diào)整階段在資源充足的情況下，BpmHA 的效果不錯(cuò)，因?yàn)橹皇蔷植扛膭?dòng)，無(wú)須用NSGA-Ⅱ迭代計(jì)算最優(yōu)解。如果NSGA-Ⅱ不考慮演化時(shí)間，整體的執(zhí)行時(shí)間較短。

本文仿真了在云邊環(huán)境協(xié)同下的業(yè)務(wù)流程微服務(wù)調(diào)度，相較于傳統(tǒng)的DAG，本文生成的DAG 多活動(dòng)之間會(huì)有數(shù)據(jù)傳輸，跟用戶之間也有數(shù)據(jù)的交互。部署階段和調(diào)整階段的調(diào)度總開銷如圖5 所示，可以看出本文針對(duì)業(yè)務(wù)流程和微服務(wù)特性對(duì)啟發(fā)式算法改進(jìn)的BpmHA+NSGA-Ⅱ的組合算法的演化總開銷較低，節(jié)省了資源。

圖5 各算法在不同階段上的總演化開銷Fig.5 Total evolution cost of each algorithm in different stages

原因分析 GA 需要迭代找出最優(yōu)解，不斷迭代重新部署會(huì)導(dǎo)致遷移代價(jià)較大，會(huì)帶來(lái)一定的開銷。NSGA-Ⅱ通過(guò)引入精英策略得到較好的解，因此開銷比GA 低。HA 為了追求更短的時(shí)間，遍歷找到活動(dòng)所在的節(jié)點(diǎn)直接部署，遷移代價(jià)低，但是沒有綜合考慮數(shù)據(jù)流的傳輸代價(jià)和微服務(wù)與用戶之間的傳輸代價(jià)，所以最后產(chǎn)生的演化總開銷通常較大。而HA+NSGA-Ⅱ的組合算法會(huì)在HA 無(wú)法縮短時(shí)間的時(shí)候啟動(dòng)NSGA-Ⅱ，負(fù)載均衡相關(guān)已部署節(jié)點(diǎn)，但是總開銷跟GA 和NSGA-Ⅱ差不多。而本文針對(duì)HA 改進(jìn)的BpmHA 考慮了業(yè)務(wù)流程多個(gè)節(jié)點(diǎn)存在數(shù)據(jù)流的特性和微服務(wù)的組合演化特性，綜合計(jì)算NE后選出值最小的節(jié)點(diǎn)進(jìn)行調(diào)度，確?？傉{(diào)度開銷是最小的，從而縮短運(yùn)行時(shí)間。

5 結(jié)語(yǔ)

相較于傳統(tǒng)的服務(wù)，微服務(wù)更小、更敏捷。由于微服務(wù)功能單一，需要通過(guò)傳統(tǒng)工作流、BPEL 和BPMN 等編排方式組合微服務(wù)。本文采用業(yè)務(wù)流程的方式組合微服務(wù)。本文針對(duì)云邊下的微服務(wù)組合的動(dòng)態(tài)演化的問(wèn)題，結(jié)合了實(shí)驗(yàn)室對(duì)業(yè)務(wù)流程主動(dòng)式探索和服務(wù)組合的研究上的積累和文獻(xiàn)［18］中提出的微服務(wù)演化框架和基礎(chǔ)架構(gòu)，提出了一種在云邊協(xié)同環(huán)境下基于業(yè)務(wù)流程的微服務(wù)組合的動(dòng)態(tài)演化方法。該方法包含了支持業(yè)務(wù)流程部署和調(diào)整的動(dòng)態(tài)演化算法，其中本文設(shè)計(jì)的啟發(fā)式算法BpmHA 綜合考慮微服務(wù)實(shí)例的遷移代價(jià)、微服務(wù)與用戶的數(shù)據(jù)通信代價(jià)和微服務(wù)之間的數(shù)據(jù)流傳輸代價(jià)，能得到一個(gè)近似全局最優(yōu)的解，無(wú)需多次運(yùn)行，既縮短了算法的執(zhí)行時(shí)間又提高了算法的效率。在NSGA-Ⅱ的基礎(chǔ)上，增加了把節(jié)點(diǎn)上的狀態(tài)轉(zhuǎn)化種群基因的形式，并把兩個(gè)算法已計(jì)算的較優(yōu)解作為初始種群，加速迭代計(jì)算出最優(yōu)解，及時(shí)演化滿足用戶的需求。通過(guò)實(shí)驗(yàn)驗(yàn)證了該算法在云邊環(huán)境下微服務(wù)組合動(dòng)態(tài)演化特定問(wèn)題上有不錯(cuò)的表現(xiàn)，總運(yùn)行時(shí)間和總演化開銷均有所降低。

本文還存在以下不足之處。

1）由于實(shí)驗(yàn)設(shè)備等問(wèn)題，并沒有在真實(shí)集群環(huán)境上運(yùn)行該演化框架和本文提出的演化算法，只是在仿真環(huán)境上驗(yàn)證了算法的合理性和效率。以后會(huì)逐步在真實(shí)的環(huán)境中去運(yùn)行該算法。

2）本文采用特定的DAG 簡(jiǎn)單模擬業(yè)務(wù)流程，而DAG 業(yè)務(wù)流程復(fù)雜，有許多別的元素。本文只是用DAG 的活動(dòng)表示了業(yè)務(wù)流程中的服務(wù)任務(wù)，并沒有考慮別的任務(wù)、事件等元素。在以后的真實(shí)環(huán)境中，需要把業(yè)務(wù)流程其他元素考慮進(jìn)去。