夏懷婷, 潘金濤

(中遠(yuǎn)海運(yùn)科技股份有限公司,上海 200135)

0 引 言

工作流引擎是企業(yè)將其分散的應(yīng)用連接起來(lái)整合成一個(gè)完整的流程應(yīng)用的調(diào)度工作。在傳統(tǒng)的工作流引擎系統(tǒng)方案中，企業(yè)內(nèi)所有需使用工作流引擎的應(yīng)用系統(tǒng)都必須購(gòu)買(mǎi)并集成工作流引擎系統(tǒng)，導(dǎo)致應(yīng)用過(guò)于復(fù)雜，且耦合度較高，不利于云端的部署，難以與不同結(jié)構(gòu)的應(yīng)用服務(wù)交互;同時(shí),只能以流程為單位存儲(chǔ)工作流要素，無(wú)法以流程節(jié)點(diǎn)的層次提供工作流要素給客戶復(fù)用，難以滿足客戶對(duì)細(xì)節(jié)定制的需求。

隨著企業(yè)內(nèi)的業(yè)務(wù)系統(tǒng)開(kāi)始向云(尤其是私有云)中遷移，提供基于私有云的工作流引擎成為必然。在私有云中，可提供基于云的流程建模、流程執(zhí)行、流程監(jiān)控分析、流程管理和業(yè)務(wù)調(diào)用?；赗EST的工作流引擎在云中具有一定的優(yōu)勢(shì)，通過(guò)對(duì)云中的服務(wù)進(jìn)行編制或編排，滿足企業(yè)內(nèi)各業(yè)務(wù)協(xié)作的需要。

在云環(huán)境中搭建工作流引擎服務(wù)通常有2種方式:

1) 結(jié)合云環(huán)境的特點(diǎn),運(yùn)用工作流技術(shù)實(shí)現(xiàn)云工作流引擎建模、執(zhí)行、管理和監(jiān)控等功能；

2) 將現(xiàn)有的開(kāi)源工作流引擎移植到云環(huán)境中。

當(dāng)前的云工作流引擎系統(tǒng)大多采用第1種方式，這將帶來(lái)一些不必要的開(kāi)銷(xiāo)。因此,本文采用第2種方式，即將開(kāi)源工作流引擎移植到云環(huán)境中，在Activiti的基礎(chǔ)上設(shè)計(jì)基于REST(Representational State Transfer)的工作流引擎，使其適應(yīng)云端部署環(huán)境，根據(jù)RESTful服務(wù)中每個(gè)資源結(jié)點(diǎn)都可發(fā)布并接受訪問(wèn)的特性，將流程、活動(dòng)和實(shí)例等所有工作流要素都封裝為REST的資源，從而以流程節(jié)點(diǎn)的層次提供可復(fù)用的工作流要素。

1 設(shè)計(jì)目標(biāo)

云工作流引擎的設(shè)計(jì)目標(biāo)主要是將工作流引擎從應(yīng)用系統(tǒng)中解耦出來(lái)，形成一個(gè)獨(dú)立的服務(wù)，從而降低系統(tǒng)的耦合性，提供更加靈活的服務(wù)支持，實(shí)現(xiàn)復(fù)雜度可控、獨(dú)立部署、技術(shù)選型靈活、服務(wù)容錯(cuò)和按需獨(dú)立擴(kuò)展等目標(biāo)。

1) 復(fù)雜度可控：將整體應(yīng)用分解為一組服務(wù)，功能總量沒(méi)有變化，但應(yīng)用程序已被分為體積小、復(fù)雜度低和可管理的微服務(wù)。每個(gè)服務(wù)專(zhuān)注于單一功能，由專(zhuān)注于該服務(wù)的團(tuán)隊(duì)獨(dú)立開(kāi)發(fā)，可大大提高開(kāi)發(fā)效率。

2) 獨(dú)立部署：微服務(wù)架構(gòu)模式可實(shí)現(xiàn)每個(gè)微服務(wù)獨(dú)立部署，開(kāi)發(fā)人員無(wú)需協(xié)調(diào)部署本地變更到服務(wù)，這些變更經(jīng)過(guò)測(cè)試之后即可立即部署。同時(shí),每個(gè)微服務(wù)在啟動(dòng)方面比大型整體應(yīng)用快得多，使得發(fā)布更為高效，且會(huì)加速部署。

3) 技術(shù)選型靈活：在微服務(wù)架構(gòu)模式下，技術(shù)選型是去中心化的。開(kāi)發(fā)者可自由選擇任何符合服務(wù)API契約的技術(shù)。此外，由于服務(wù)較小，采用當(dāng)前的技術(shù)重寫(xiě)舊服務(wù)將變得更為可行。

4) 服務(wù)容錯(cuò)：當(dāng)某一服務(wù)發(fā)生故障時(shí)，在單一整體應(yīng)用的傳統(tǒng)架構(gòu)模式下，故障很可能在整個(gè)應(yīng)用內(nèi)擴(kuò)散，形成全局性的不可用;而在微服務(wù)架構(gòu)模式下，故障會(huì)被隔離在單個(gè)服務(wù)中，可通過(guò)超時(shí)重試、限流、降級(jí)和熔斷等機(jī)制實(shí)現(xiàn)服務(wù)的容錯(cuò)。

5) 按需獨(dú)立擴(kuò)展：傳統(tǒng)單體應(yīng)用架構(gòu)必須以應(yīng)用為單位進(jìn)行橫向擴(kuò)展，在資源需求有沖突時(shí)會(huì)變得比較困難。引擎微服務(wù)化之后,可獨(dú)立于應(yīng)用服務(wù),使用負(fù)載均衡器進(jìn)行自由擴(kuò)展。此外，引擎服務(wù)可部署到最適合其資源需求的硬件上，而整體架構(gòu)中具有嚴(yán)重資源需求差異的組件(如CPU密集和內(nèi)存密集)必須部署在一起。

2 架構(gòu)設(shè)計(jì)

2.1 總體技術(shù)架構(gòu)設(shè)計(jì)

整個(gè)云工作流引擎架構(gòu)基于云計(jì)算平臺(tái)開(kāi)發(fā)部署，并由微服務(wù)、容器和BPM(Business Process Management)等若干技術(shù)組件構(gòu)成,其中:微服務(wù)分解BPM應(yīng)用系統(tǒng)，將應(yīng)用與引擎微服務(wù)化;容器采用Docker技術(shù)實(shí)現(xiàn)微服務(wù)鏡像化;BPM組件實(shí)現(xiàn)BPM建模、執(zhí)行、管理和監(jiān)控等功能，這些功能必須基于“用戶權(quán)限隔離”底層機(jī)制，實(shí)現(xiàn)BPM云引擎多租戶隔離和交互要求。

當(dāng)然,服務(wù)的平穩(wěn)運(yùn)行離不開(kāi)架構(gòu)的整體監(jiān)控和治理，包括服務(wù)注冊(cè)與發(fā)現(xiàn)、服務(wù)容器管理、服務(wù)編排、配置中心、安全管理和日志收集等。該工作流引擎的總體技術(shù)架構(gòu)見(jiàn)圖1。

圖1 基于REST的云工作流引擎總體技術(shù)架構(gòu)

2.2 關(guān)鍵開(kāi)發(fā)技術(shù)

2.2.1 Activiti

Activiti是一個(gè)開(kāi)源的工作流引擎，實(shí)現(xiàn)了BPMN 2.0規(guī)范，可發(fā)布設(shè)計(jì)好的流程定義，并通過(guò)API(Application Programming Interface)進(jìn)行流程調(diào)度。Activiti采用流程虛擬機(jī)(Process Virtual Machine, PVM)，支持BPMN2.0規(guī)范以外的流程格式，具有與外部服務(wù)良好集成的能力，服務(wù)接口清晰，已實(shí)現(xiàn)部分RESTful接口。

2.2.2 RESTful

圖2 面向資源的REST服務(wù)訪問(wèn)

圖2為面向資源的REST服務(wù)訪問(wèn)。REST架構(gòu)風(fēng)格將一切都看作是資源，客戶端通過(guò)GET、PUT、POST和DELETE等4種操作實(shí)現(xiàn)與資源的交互。因此，在BPM私有云引擎的設(shè)計(jì)中,遵循該原理設(shè)計(jì)BPM引擎的API，并提供基于REST的API。

2.2.3 Spring Boot

Spring Boot用來(lái)簡(jiǎn)化新Spring應(yīng)用的初始搭建和開(kāi)發(fā)過(guò)程。該框架采用特定的方式配置，從而使開(kāi)發(fā)人員不必定義樣板化的配置,可專(zhuān)注于應(yīng)用程序的邏輯。

2.2.4 Spring Cloud

Spring Cloud是一系列框架的有序集合,利用Spring Boot的開(kāi)發(fā)便利性巧妙地簡(jiǎn)化分布式系統(tǒng)基礎(chǔ)設(shè)施的開(kāi)發(fā)，服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器和數(shù)據(jù)監(jiān)控等都可用Spring Boot的開(kāi)發(fā)風(fēng)格做到一鍵式啟動(dòng)和部署。

2.3 SAAS服務(wù)關(guān)鍵功能實(shí)現(xiàn)方式設(shè)計(jì)

2.3.1 用戶權(quán)限隔離

SAAS服務(wù)的主要特性是支持多租戶應(yīng)用，其關(guān)鍵實(shí)現(xiàn)方式是數(shù)據(jù)隔離(包括組織內(nèi)的部門(mén)用戶數(shù)據(jù)和流程數(shù)據(jù))和客戶自服務(wù)(包括個(gè)性定制和管理隔離)。該設(shè)計(jì)通過(guò)租戶識(shí)別碼對(duì)多租戶進(jìn)行數(shù)據(jù)管理，即將多個(gè)租戶存入同一個(gè)數(shù)據(jù)庫(kù)中，使用同一個(gè)Schema(即將數(shù)據(jù)保存在一個(gè)表格中，通過(guò)租戶的識(shí)別碼來(lái)區(qū)分)。

圖3為用戶權(quán)限隔離的ER圖，組織的各個(gè)表中都有一個(gè)租戶識(shí)別碼，根據(jù)該識(shí)別碼實(shí)現(xiàn)組織內(nèi)用戶的隔離，不同租戶對(duì)各自的組織數(shù)據(jù)進(jìn)行維護(hù)。在模型表和流程定義表中添加“租戶識(shí)別碼”，通過(guò)“租戶識(shí)別碼”字段實(shí)現(xiàn)對(duì)不同租戶流程定義的隔離，該“租戶識(shí)別碼”與組織表中的租戶識(shí)別碼相關(guān)聯(lián)。在流程實(shí)例表中添加字段“租戶識(shí)別碼”，活動(dòng)實(shí)例表、工作任務(wù)表、流程轉(zhuǎn)移表和流程變量表等都通過(guò)“流程實(shí)例ID”與流程實(shí)例表相關(guān)聯(lián)，因此無(wú)需添加租戶識(shí)別碼字段。

圖3 用戶權(quán)限隔離的ER圖

2.3.2 用戶數(shù)據(jù)同步

每個(gè)涉及到用戶的系統(tǒng)都有一套用戶權(quán)限管理平臺(tái)或模塊，用來(lái)維護(hù)用戶在系統(tǒng)內(nèi)的功能、數(shù)據(jù)權(quán)限。采用的Activiti工作流引擎配套設(shè)計(jì)包括User和Group的Identify模塊，針對(duì)Activiti Identify用戶數(shù)據(jù)的同步,通過(guò)調(diào)用IdentifyService接口完成同步，即通過(guò)數(shù)據(jù)推送的方式將數(shù)據(jù)同步到Activiti的身份表中。

Activiti的Identify模塊由用戶、用戶組和用戶與組關(guān)系組成(見(jiàn)圖4)，因此接口內(nèi)容應(yīng)包括同步用戶信息、同步組信息和同步用戶與組關(guān)系信息等。

圖4 Activiti用戶組關(guān)系圖

用于用戶、用戶組及用戶組關(guān)系同步的，需開(kāi)發(fā)的REST API為：

1) POST/identity/user/{userId}：同步某個(gè)用戶數(shù)據(jù)；

2) POST/identity/group/{groupId}：同步某個(gè)組數(shù)據(jù)；

3) POST/identity/membership/{membershipId}：同步某個(gè)用戶組關(guān)系數(shù)據(jù)；

4) DELETE/identity/user/{userId}：刪除某個(gè)用戶數(shù)據(jù)；

5) DELETE/identity/group/{groupId}：刪除某個(gè)組數(shù)據(jù)；

6) DELETE/identity/membership/{membershipId}：刪除某個(gè)用戶組關(guān)系數(shù)據(jù)。

2.3.3 REST API設(shè)計(jì)與實(shí)現(xiàn)方式

圖5為Activiti引擎的系統(tǒng)服務(wù)結(jié)構(gòu)圖，給出了引擎提供的所有功能組件。ProcessEngineConfiguration是配置管理類(lèi)，管理的對(duì)象包括ProcessEngine、XXservice和數(shù)據(jù)庫(kù)session等。對(duì)于ProcessEngineConfiguration的配置，Activiti默認(rèn)從activiti.cfg.xml中讀取，也可從Spring的配置文件中讀取。ProcessEngine提供有很多工作流方法的服務(wù)，都是線程安全的，下面對(duì)各服務(wù)的功能進(jìn)行介紹。

圖5 Activiti引擎的系統(tǒng)服務(wù)結(jié)構(gòu)圖

1) RepositoryService：提供對(duì)Repository(BPMN2.0 XML文件、表單定義文件和流程定義圖像文件等)的存取服務(wù)。

2) RuntimeService：提供啟動(dòng)流程、查詢流程實(shí)例和設(shè)置獲取流程實(shí)例變量等功能。此外,提供對(duì)流程部署、流程定義和流程實(shí)例的存取服務(wù)。

3) TaskService：提供對(duì)用戶Task和Form的相關(guān)操作及運(yùn)行時(shí)任務(wù)查詢、領(lǐng)取、完成、刪除和變量設(shè)置等功能。

4) IdentityService：提供對(duì)Activiti系統(tǒng)中用戶和用戶組的管理功能。

5) ManagementService：提供對(duì)Activiti流程引擎的管理和維護(hù)功能，這些功能不在工作流驅(qū)動(dòng)的應(yīng)用程序中使用，主要用于Activiti系統(tǒng)的日常維護(hù)。

6) HistoryService:用于獲取正在運(yùn)行或已完成流程實(shí)例的信息，與 RuntimeService中獲取的流程信息不同，歷史信息包含已持久化存儲(chǔ)的永久信息，并已被針對(duì)查詢優(yōu)化。

7) FormService:可存取啟動(dòng)和完成任務(wù)所需的表單數(shù)據(jù)并根據(jù)需要渲染表單。

按照RESTful風(fēng)格將上述服務(wù)提供的接口和訪問(wèn)方法發(fā)布為Web資源，各服務(wù)對(duì)應(yīng)的REST API見(jiàn)圖6。

圖6 各服務(wù)對(duì)應(yīng)的REST API

以Repository的API為例，對(duì)各資源的具體操作類(lèi)型作簡(jiǎn)要說(shuō)明。

1) /repository/models

GET：獲取所有模型

POST：創(chuàng)建一個(gè)模型

2) /repository/deployments

GET：獲取所有已部署的流程

POST：部署一個(gè)流程

3) /repository/deployments/{deploymentId}

GET：獲取某個(gè)部署信息

DELETE：刪除某個(gè)部署信息

4) /repository/deployments/{deploymentId}/resources

GET：獲取某個(gè)部署下的資源列表

5) /repository/deployments/{deploymentId}/resources/{resourceId}

GET：獲取某個(gè)部署下的某個(gè)資源信息

3 架構(gòu)部署

云工作流引擎平臺(tái)的架構(gòu)部署包含注冊(cè)中心、配置中心、調(diào)用中心、部署中心、日志中心、監(jiān)控中心、追蹤中心和消息中心等8部分(見(jiàn)圖7)。

圖7 架構(gòu)部署

1) 注冊(cè)中心：用于注冊(cè)微服務(wù)相關(guān)配置信息的中心，實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和服務(wù)注冊(cè)，選用Eureka實(shí)現(xiàn)。

2) 配置中心：用于管理微服務(wù)應(yīng)用程序所需的配置參數(shù)，選用Spring Cloud Config實(shí)現(xiàn)，通過(guò)Spring Cloud Bus實(shí)現(xiàn)動(dòng)態(tài)的配置更新。

3) 調(diào)用中心：即API網(wǎng)關(guān)，用于提供給前端調(diào)用的統(tǒng)一入口，選用Zuul實(shí)現(xiàn)。

4) 部署中心：用于編譯、打包微服務(wù)源碼并將其部署到Docker引擎中，選用Jenkins實(shí)現(xiàn)。

5) 日志中心：用于收集和管理微服務(wù)應(yīng)用程序中產(chǎn)生的日志，選用ELK實(shí)現(xiàn)。

6) 監(jiān)控中心：用于監(jiān)控微服務(wù)的實(shí)時(shí)運(yùn)行狀況，選用zipkin實(shí)現(xiàn)。

7) 追蹤中心：用于最終調(diào)用微服務(wù)的軌跡，選用sleuth實(shí)現(xiàn)。

8) 消息中心：用于解耦微服務(wù)之間的調(diào)用關(guān)系，同步調(diào)用選用REST實(shí)現(xiàn)，異步調(diào)用選用kafka實(shí)現(xiàn)。

在實(shí)現(xiàn)工作流引擎的所有接口之后，由部署中心執(zhí)行編譯和打包操作，構(gòu)建成Docker鏡像，最后將其上傳到鏡像倉(cāng)庫(kù)，以便后續(xù)從鏡像倉(cāng)庫(kù)中下載指定的鏡像，運(yùn)行相應(yīng)的Docker容器。

在Docker鏡像上傳到鏡像倉(cāng)庫(kù)之后，部署中心可在不同的運(yùn)行環(huán)境下根據(jù)特定的鏡像啟動(dòng)相應(yīng)的Docker容器。為便于描述，將該容器稱為“服務(wù)容器”，包含承載微服務(wù)的應(yīng)用程序及其配置文件。

在服務(wù)容器啟動(dòng)之后，自動(dòng)從配置中心讀取相應(yīng)的配置信息并將其網(wǎng)絡(luò)地址等信息寫(xiě)入注冊(cè)中心，該過(guò)程稱為“服務(wù)注冊(cè)”。服務(wù)容器與注冊(cè)中心通過(guò)一定的機(jī)制(例如心跳)通信，注冊(cè)中心若長(zhǎng)時(shí)間無(wú)法與某服務(wù)容器通信，會(huì)注銷(xiāo)該實(shí)例，服務(wù)網(wǎng)絡(luò)地址變更時(shí)會(huì)重新寫(xiě)入注冊(cè)中心。

服務(wù)容器相互調(diào)用時(shí)，若鏈路的某個(gè)服務(wù)容器不可用或響應(yīng)時(shí)間太長(zhǎng)，則調(diào)用該服務(wù)的鏈路會(huì)產(chǎn)生大量積壓，導(dǎo)致積壓蔓延，稱之為“雪崩效應(yīng)”。為防止雪崩，當(dāng)調(diào)用某個(gè)服務(wù)之后發(fā)現(xiàn)無(wú)法完成時(shí)，主動(dòng)撤銷(xiāo)連接，返回fallback的響應(yīng)信息，防止雪崩，該過(guò)程稱為“服務(wù)熔斷”。當(dāng)系統(tǒng)壓力過(guò)大時(shí)，進(jìn)行限流或關(guān)停不重要的業(yè)務(wù)，為主要業(yè)務(wù)讓出資源，該過(guò)程稱為“服務(wù)降級(jí)”。

用戶在通過(guò)瀏覽器或移動(dòng)端訪問(wèn)引擎系統(tǒng)時(shí)，請(qǐng)求首先通過(guò)負(fù)載均衡進(jìn)入服務(wù)網(wǎng)關(guān)，因?yàn)槠涫撬姓?qǐng)求調(diào)用的中心、系統(tǒng)的唯一入口，也稱其為“調(diào)用中心”。調(diào)用中心雖然是不帶任何業(yè)務(wù)的中心，但需確保其所做的事情足夠少，使其不會(huì)成為整個(gè)應(yīng)用系統(tǒng)調(diào)用的瓶頸，客戶端的認(rèn)證、訪問(wèn)控制、監(jiān)控和緩存等公共邏輯可抽象到網(wǎng)關(guān)中實(shí)現(xiàn)。

調(diào)用中心隨后連接注冊(cè)中心，并通過(guò)服務(wù)名稱從注冊(cè)中心獲取服務(wù)所在的IP地址和端口號(hào)(即服務(wù)地址)，該過(guò)程稱為“服務(wù)發(fā)現(xiàn)”。由此，調(diào)用中心可根據(jù)服務(wù)地址，以反向代理的方式調(diào)用具體的服務(wù)容器，該過(guò)程稱為“服務(wù)調(diào)用”。

在服務(wù)容器中可能會(huì)觸發(fā)一些事件，這些事件將以消息的方式寫(xiě)入消息中心，以便其他服務(wù)對(duì)消息中心進(jìn)行監(jiān)聽(tīng)并從中獲取相應(yīng)的消息。該方案可解決服務(wù)之間的耦合問(wèn)題，同時(shí)能將同步調(diào)用轉(zhuǎn)為異步調(diào)用，提高整個(gè)應(yīng)用系統(tǒng)的吞吐率。

服務(wù)容器在運(yùn)行時(shí)會(huì)產(chǎn)生大量的日志，可將這些日志統(tǒng)一寫(xiě)入日志中心，并能在日志中心提供的控制臺(tái)上查詢具體的日志信息。此外，日志中心能幫助快速定位和分析系統(tǒng)出現(xiàn)的異常情況。

為判斷服務(wù)容器的運(yùn)行是否正常，可借助監(jiān)控中心輸出的圖形化數(shù)據(jù)來(lái)實(shí)現(xiàn)。監(jiān)控中心不斷地收集服務(wù)容器的運(yùn)行狀態(tài)，包括CPU、內(nèi)存、硬盤(pán)、網(wǎng)絡(luò)及應(yīng)用程序的JVM內(nèi)存使用情況等。

由于微服務(wù)很難切得干凈,除了向外部提供以外，微服務(wù)之間難免會(huì)出現(xiàn)少量的調(diào)用關(guān)系，可將每次調(diào)用產(chǎn)生的相關(guān)信息寫(xiě)入追蹤中心，通過(guò)追蹤中心提供的圖形化界面查看服務(wù)之間的調(diào)用軌跡和產(chǎn)生的調(diào)用延時(shí)，從而分析出服務(wù)調(diào)用產(chǎn)生的性能瓶頸。

4 架構(gòu)應(yīng)用

簡(jiǎn)單搭建1個(gè)Eureka服務(wù)(服務(wù)注冊(cè)中心)、2個(gè)應(yīng)用服務(wù)(OA Service)、2個(gè)工作流引擎服務(wù)(Workflow Service)和1個(gè)API網(wǎng)關(guān)(Zuul Server)，驗(yàn)證上述架構(gòu)設(shè)計(jì)的可行性(見(jiàn)圖8)。所有服務(wù)都需注冊(cè)到Eureka服務(wù)上，以便服務(wù)間調(diào)用。API網(wǎng)關(guān)是系統(tǒng)唯一的入口，主要實(shí)現(xiàn)服務(wù)請(qǐng)求路由、負(fù)載均衡和服務(wù)熔斷等功能。這里與/oa相關(guān)的請(qǐng)求全部轉(zhuǎn)發(fā)到OA Service上，與/workflow相關(guān)的請(qǐng)求全部轉(zhuǎn)發(fā)到Workflow Service上，并選擇其中一臺(tái)服務(wù)(Server A或Server B)進(jìn)行轉(zhuǎn)發(fā)，實(shí)現(xiàn)服務(wù)的負(fù)載均衡。同時(shí),OA Service與Workflow Service之間也可通過(guò)REST方式調(diào)用對(duì)方的API，如應(yīng)用服務(wù)可調(diào)用引擎服務(wù)的用戶數(shù)據(jù)同步接口實(shí)現(xiàn)用戶信息同步，應(yīng)用服務(wù)的用戶待辦數(shù)據(jù)可調(diào)用引擎服務(wù)獲取用戶任務(wù)的接口，應(yīng)用服務(wù)的流程跟蹤可調(diào)用引擎流程跟蹤接口等。

單體架構(gòu)應(yīng)用(見(jiàn)圖9)就是將所有功能(OA接口和工作流引擎接口)集成到一起組成一個(gè)整體應(yīng)用，進(jìn)行集中式管理，簡(jiǎn)單直接，基本上不會(huì)重復(fù)開(kāi)發(fā)，但會(huì)帶來(lái)開(kāi)發(fā)效率低、代碼維護(hù)難、部署不靈活、穩(wěn)定性不高和可擴(kuò)展性不強(qiáng)等問(wèn)題。

圖8 微服務(wù)架構(gòu)應(yīng)用

圖9 單體架構(gòu)應(yīng)用

由2種應(yīng)用的對(duì)比可知，微服務(wù)架構(gòu)應(yīng)用將工作流引擎從應(yīng)用系統(tǒng)中成功地分離出來(lái)，由原來(lái)的1個(gè)完整服務(wù)(Application Server)拆分為2個(gè)服務(wù)(OA Service和Workflow Service)， OA Service只需實(shí)現(xiàn)業(yè)務(wù)相關(guān)功能接口，工作流引擎相關(guān)接口交由Workflow Service完成，從而實(shí)現(xiàn)2個(gè)服務(wù)的獨(dú)立部署和擴(kuò)展。

5 結(jié) 語(yǔ)

隨著云計(jì)算的發(fā)展和企業(yè)集約化、一體化、集中化的發(fā)展，云工作流引擎成為企業(yè)建立私有云工作流引擎的發(fā)展必然，給企業(yè)帶來(lái)更多的經(jīng)濟(jì)效益，包括硬件的成本得以降低、硬件資源的使用率大幅提升、平臺(tái)維護(hù)人員大幅減少、數(shù)據(jù)的管理和管控更加集中；同時(shí)，云工作流引擎可帶來(lái)系統(tǒng)的高可用、可擴(kuò)展性和自動(dòng)伸縮等能力。但是，云工作流引擎是分布式系統(tǒng)，會(huì)提高部署和管理的復(fù)雜性，從而對(duì)開(kāi)發(fā)者提出更高的要求。