基于REST的云工作流引擎的架構(gòu)設(shè)計

夏懷婷, 潘金濤

(中遠海運科技股份有限公司,上海 200135)

0 引 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1 Activiti

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

2.2.2 RESTful

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

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

2.2.3 Spring Boot

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

2.2.4 Spring Cloud

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以Repository的API為例，對各資源的具體操作類型作簡要說明。

1) /repository/models

GET：獲取所有模型

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

2) /repository/deployments

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

POST：部署一個流程

3) /repository/deployments/{deploymentId}

GET：獲取某個部署信息

DELETE：刪除某個部署信息

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

GET：獲取某個部署下的資源列表

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

GET：獲取某個部署下的某個資源信息

3 架構(gòu)部署

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

圖7 架構(gòu)部署

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 結(jié) 語

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