羅欽凱，倪成章

(1.華中科技大學，湖北 武漢 430074；2.武漢郵電科學研究院，湖北 武漢 430074)

0 引 言

全行業(yè)大規(guī)模的“上云”需求，和以OpenStack為代表的云計算資源類型的多樣化，極大擴展了云管平臺(cloud management platform，CMP)的服務領域，亟待實現(xiàn)一種架構層面直觀反映復雜業(yè)務邏輯的、便于敏捷開發(fā)與持續(xù)集成的CMP開發(fā)方案。單體架構已不能滿足軟件即服務(software-as-a-service，SaaS)層應用在高擴展性和高可用性等方面的需要，亟待一種新的設計架構能最大限度地實現(xiàn)高擴展性。

單體架構應用開發(fā)成型迅速，但隨著線上業(yè)務需求復雜多樣化，新需求調研階段的溝通成本顯著，業(yè)務邏輯開發(fā)困難，無法滿足應用對擴展性和維護性的要求[1]，也將導致需求調研階段需求溝通的成本顯著和上線維護階段可維護性差。從開發(fā)實現(xiàn)業(yè)務邏輯的痛點出發(fā)，通過解構工作流核心設計模型，設計出工作流微服務組件結構模型，并基于Spring Cloud微服務開發(fā)框架給出組件間REST API與流程節(jié)點自由跳轉算法，以及CQRS模式數(shù)據操作等方案。

1 研究背景

工作流技術順應了信息時代“異構化、松耦合”的發(fā)展趨勢[2]。工作流相關領域的專家學者對此做了許多研究。例如，于樂等[3]設計了云工作流在商業(yè)智能業(yè)務場景下的SaaS層應用；鄧麗等[4]設計的空間科學任務協(xié)同論證平臺論證了復雜任務下的協(xié)同性與一致性；李金艷等[5]實現(xiàn)了一種面向協(xié)作的基于角色的柔性工作流訪問控制機制；陳儒等[6]研究了基于事務規(guī)則驅動的動態(tài)工作流模型；張型龍等[7]設計并實現(xiàn)了基于服務集成的工作流模型。針對工作流技術應用于傳統(tǒng)單體架構時功能與業(yè)務邏輯耦合度較高所帶來的擴展性差、可維護性差等問題，文中提出采用基于微服務的工作流技術，將面向分布式服務的工作流[8]應用于CMP，以期實現(xiàn)對分布式云計算資源的調度管理。

1.1 工作流

工作流技術沿著以數(shù)據為中心的流程建模與柔性分布式設計的方向發(fā)展[9]。業(yè)界提出旨在提供易于理解和易于標識的業(yè)務流程建模標記(business process modeling notation，BPMN)。衍生的BPMN2.0規(guī)范可以直觀和準確地描述業(yè)務流程的細節(jié)，降低在整個產品生命周期中按需開發(fā)的溝通成本；有利于業(yè)務邏輯與功能邏輯進一步解耦，降低工作流技術在復雜業(yè)務場景下持續(xù)集成新功能的實施成本[10]；它更注重語法定義的通用性和交換格式的標準化，XML格式規(guī)范便于移植在所有遵從BPMN規(guī)范的工作流引擎中解析利用。

1.2 微服務

微服務架構本質上體現(xiàn)的是解耦再封裝[11]。由多個團隊自由選擇合適技術獨立開發(fā)每個服務，只要遵守統(tǒng)一的系統(tǒng)內HTTP型無狀態(tài)通信規(guī)范API即可，降低復雜系統(tǒng)的設計門檻，適合團隊敏捷開發(fā)；每個服務均能被獨立部署和驗證，讓持續(xù)部署成為可能，可以顯著提高部署效率；只需要在特定的微服務組件中增加所需功能，而不影響整體業(yè)務和其他功能，整個微服務系統(tǒng)的可擴展性得到提升。微服務架構有別于面向服務的架構(service-oriented architecture，SOA)，微服務架構各個服務間基于端到端的訂閱方式，業(yè)務流程發(fā)生完全按照業(yè)務邏輯，當前事件的觸發(fā)只需關注前置事件即可，需求變化帶來的改變也只面向業(yè)務上下文而非功能，架構設計相當靈活。

2 工作流核心設計模型

主流的工作流引擎是jBPM5與Activiti。通用性方面，Activiti所采用寬松的Apache License 2.0開源協(xié)議不會在二次開發(fā)商用過程中引起不必要的著作權糾紛。易用性方面，微服務架構分布式的調用方式使Spring Cloud開發(fā)框架成為主流，Activiti架構繼承自jBPM4，在整合已有jBPM4項目上具有原生優(yōu)勢，這也意味著它對Spring框架的原生支持[12]，可以輕松集成基于Spring代理的事務管理以及基于業(yè)務邏輯的面向切面編程。

2.1 流程推進模型

使工作流流程推進模型首先要以滿足以下定義作為前提：

定義1(狀態(tài)轉換)：從一個給定狀態(tài)出發(fā)，只能進入有限狀態(tài)機中其他狀態(tài)的一個子集；服務隨流程實例的演進，完成調用其他服務或是某些需要手動確認觸發(fā)的業(yè)務流程，流程狀態(tài)從當前節(jié)點轉移到下一節(jié)點等待被觸發(fā)。

定義2(事務控制)：下一事件只能在BPMN流程定義模型描述的前置事件完成之后完成，不能跳過任何事務步驟，否則不滿足事務性。

定義3(定量描述)：BPMN流程定義模型對流程的定性描述還需通過對各類流程數(shù)據持久化處理使其定量化。

BPMN流程定義模型結合Petri-Net[13-14]和UML兩種建模思路實現(xiàn)Activiti工作流的流程推進模型。由起點(StartEvent)、終點(EndEvent)、任務節(jié)點(Activity)與連線(Transition)組成的有向無環(huán)圖(directed acyclic graph，DAG)即為流程定義(ProcessDefination)，實例化的流程定義即流程實例(ProcessInstance)，實例中流程執(zhí)行體(ProcessExecution)相當于指針。每個實例被加載進工作流引擎都會首先觸發(fā)activityBehaviour()事件找到起點，緊接著會觸發(fā)監(jiān)聽器(executionListener())執(zhí)行起點的end()事件并找到出方向連線事件outgoingTransition()；同樣，觸發(fā)監(jiān)聽器執(zhí)行出方向連線的take()事件找到第一個任務節(jié)點Activity；觸發(fā)監(jiān)聽器執(zhí)行當前節(jié)點的start()事件，為當前節(jié)點設置屬性、指派任務或調用API后，觸發(fā)監(jiān)聽器執(zhí)行當前節(jié)點的end()事件完成當前任務節(jié)點，并提交事務，將當前的狀態(tài)保存到數(shù)據庫里。該流程實例會暫停推進，直到外部請求再次觸發(fā)監(jiān)聽器執(zhí)行出方向連線的take()事件找到下一任務節(jié)點，流程會繼續(xù)向下一步驟推進。圖1是流程推進模型分鏡操作時序圖，每次流程推進都由一次或多次上述步驟組成。

圖1 流程推進模型分鏡操作時序

2.2 面向API調用

面向API調用是Activiti Service的設計思路。工作流引擎通過對外暴露Service API(見表1)，依據流程定義部署流程實例、配置流程參數(shù)、指派任務執(zhí)行人或代理人，實現(xiàn)審批、回退、駁回、創(chuàng)建等業(yè)務功能，完成工作流的內在功能邏輯。

工作流引擎未直接暴露的底層服務API也可以通過ProcessEngine API調用并借此完成節(jié)點自由跳轉等特性功能。

由此衍生出的概念層面三種不同粒度的API封裝模式如圖2所示。

表1 工作流引擎Service API

圖2 不同粒度的API封裝模式

外觀模式(Facade Pattern)下Service API是對功能邏輯的抽象定義，通過調用對外已經暴露的ServiceAPI或重寫的自定義ServiceAPI實現(xiàn)功能邏輯；命令模式(Command Pattern)實質上是將不同命令(Command)交由命令執(zhí)行器(CommandExecutor)統(tǒng)一執(zhí)行；攔截器模式(Interceptor Pattern)下，命令模式執(zhí)行當前某個命令的過程，對應于在當前命令執(zhí)行前后分別執(zhí)行若干前置或后置攔截器的過程，旨在實現(xiàn)最細粒度的事務控制。ProcessEngine API在外觀模式層面將工作流引擎內部作透明處理，屏蔽底層架構實現(xiàn)層面上復雜的技術細節(jié)，使得調用服務不必關心引擎事務規(guī)則和流程定義等的具體實現(xiàn)。

3 工作流微服務組件設計方案

微服務架構(見圖3)的設計理念在于，有編排功能的基于業(yè)務邏輯的架構可以減少耦合，在此基礎上所有的微服務組件可以訂閱與其業(yè)務相關的其他服務所發(fā)生的事件，進而對事件做出響應，最終通過REST服務完成功能。采用API網關機制聚合系統(tǒng)外部請求和映射系統(tǒng)內部服務，內部每個微服務組件提供REST API。請求基于HTTP協(xié)議通過API網關分發(fā)到目標服務，可以降低外部請求與具體服務的耦合度，減少通信頻次。采用去中心化的服務注冊機制，每個微服務組件的服務注冊節(jié)點之間沒有主次之分，針對注冊節(jié)點宕機問題提供自動檢測及周期恢復功能，所有組件通過引用服務發(fā)現(xiàn)客戶端，在每個組件入口類上添加服務發(fā)現(xiàn)注解后即可完成服務注冊。

圖3 CMP微服務架構示意

3.1 微服務框架與工作流結構模型

面向領域模型(domain-oriented model，DOM)可以準確反映業(yè)務語言，真正實現(xiàn)以業(yè)務邏輯實體為核心的靈活拓展；基于“Spring+Hibernate”傳統(tǒng)架構的J2EE應用關注功能邏輯過于業(yè)務邏輯，而Spring Cloud依據領域劃分微服務，以領域模型替代“功能服務+數(shù)據表”模型，以并發(fā)的業(yè)務事件驅動替代傳統(tǒng)消息總線數(shù)據驅動。基于微服務的工作流微服務組件設計延續(xù)了Spring Cloud“約定優(yōu)于配置”的契約式編程思想，bootstrap.yml配置文件依據開發(fā)環(huán)境在spring.profiles.active配置項激活目標環(huán)境；Java持久層API(Java persistence API，JPA)將數(shù)據表名和字段名按照約定映射到方法類，構造面向對象的查詢語句，以非侵入式設計靈活操作流程數(shù)據。

架構層面實現(xiàn)不同服務間功能解耦，工作流組件只需暴露API被其他服務調用，解決復雜業(yè)務邏輯的同時，在后續(xù)持續(xù)集成需求開發(fā)新業(yè)務功能時，可以在不影響業(yè)務邏輯和API原有設計前提下對工作流組件重新設計開發(fā)。工作流組件如表2所示。

表2 工作流組件概覽

工作流組件運行的具體步驟如圖4所示。

(1)流程管理器訪問BPMN定義模型庫，讀取當前流程定義進入工作流引擎；

(2)由事務規(guī)則引擎驅動過程模型的啟動和執(zhí)行，事務規(guī)則引擎負責依據XML設計規(guī)范解析執(zhí)行過程模型文件；依據事務規(guī)則庫中的事務規(guī)則子模塊對業(yè)務流轉實現(xiàn)事務控制；

(3)Service API完成當前步驟并持久化流程數(shù)據，并且通過暴露的REST API被其他微服務調用；

(4)當前步驟執(zhí)行完成后，工作流引擎處于等待狀態(tài)直到流程監(jiān)聽器相應請求被觸發(fā)。

圖4 工作流組件運行示意

3.2 REST API與流程節(jié)點自由跳轉設計

CMP中每個微服務可能是某個事件的生產者、消費者或二者兼有。當租戶客戶端提交云資源訂單申請，租戶服務端微服務組件作為當前事件的消費者向工作流組件REST API發(fā)送HTTP請求傳入流程參數(shù)；工作流組件作為當前事件的生產者，調用業(yè)務層nextStep()方法類，完成持久化和參數(shù)傳遞驅動當前流程向下推進直到完成當前事件；工作流又作為當前事件的消費者，完成當前事件過程中向OpenStack-MS微服務組件REST API發(fā)送HTTP請求；OpenStack組件以生產者身份參與當前事件，依據API參數(shù)分配云硬盤、云主機等云資源。

基于微服務架構的工作流組件將傳統(tǒng)工作流系統(tǒng)中基于每項具體業(yè)務功能設計的調用API設計為“下一步”(nextStep())、“回退”(rollback())、“開始”(startProcess())和“結束”(finishProcess())四個REST API，屏蔽每次請求的具體業(yè)務功能細節(jié)；基于Java泛型設計的動態(tài)實體類滿足無狀態(tài)JSON格式傳入參數(shù)并將其代入流程參數(shù)傳遞。如訂單審批工作流被調用startProcess()方法類的同時，會從API參數(shù)獲取到諸如訂單主題、備注、審批需求等訂單信息傳入當前流程實例的流程參數(shù)在流程中傳遞；針對特性需求，基于Java的繼承特性，使得子類繼承基類，根據事務需求靈活擴展開發(fā)。針對流程節(jié)點的自由跳轉的業(yè)務需求，預設流程輸出流程不能很好滿足，以下偽代碼實現(xiàn)了對引擎底層未暴露的Command API二次調用。

算法：rollback()兩步回退算法。

(當前節(jié)點CurrAct;當前節(jié)點出方向OutgoingTrans;當前節(jié)點出方向列表OutgoingTransList;當前節(jié)點原始出方向OriOutgoingTrans;當前節(jié)點入方向CurrTrans;當前節(jié)點入方向列表CurrTransList;上一步節(jié)點PreAct;上一步節(jié)點入方向PreTrans;上一步節(jié)點入方向列表PreTransList;上兩步節(jié)點MultiPreAct;當前節(jié)點新出方向NewTrans;當前節(jié)點新出方向列表NewTransList;)

for(OutgoingTrans：OutgoingTransList){

OriOutgoingTrans=OutgoingTrans;}

OutgoingTransList.clear();

for(CurrTrans：CurrTransList){

PreAct=CurrAct;

for(PreTrans:PreTransList){

MultiPreAct=PreAct;

NewTrans.setDestination(MultiPreAct);

NewTransList.add(NewTrans);

taskService.complete();

historyService.deleteHistoricTaskInstance;}}

NewTransList.clear();

OutgoingTransList.add(OriOutgoingTrans);

3.3 命令查詢職責分離模式數(shù)據操作

傳統(tǒng)單體架構應用采用CRUD設計模式(Create/Retrieve/Update/Delete，“增加/讀取/更新/刪除”)，持久層操作和查詢一種類型的數(shù)據通過相同的實體類。微服務架構系統(tǒng)要求業(yè)務邏輯的實現(xiàn)從數(shù)據驅動(Data-Driven)轉向任務驅動(Task-Driven)和事件驅動(Event-Driven)。工作流微服務組件采用“命令查詢職責分離”(command query responsibility segregation，CQRS)設計模式，為了使數(shù)據操作Command(會修改系統(tǒng)狀態(tài)的增刪改操作)和數(shù)據查詢Query(不會修改系統(tǒng)狀態(tài)的查詢操作)分離。圖5展示了CQRS與CRUD模式的異同。

涉及的CQRS中所有涉及到對數(shù)據庫的改變均通過發(fā)送Command異步觸發(fā)對應事務性操作，避免了CRUD中操作和查詢同時進行可能導致的事務沖突；此外面向切面編程思想，通過添加“@Transactional”注解實現(xiàn)每個方法類粒度上的事務管理，從而最大限度保證對數(shù)據庫事務操作的原子性和一致性；針對CMP資源訂單的實時流程狀態(tài)和歷史流程狀態(tài)進行列表分頁展示的需求，基于CQRS設計模式，針對實時流程數(shù)據和歷史流程數(shù)據設計獨立的服務調用REST API，被請求時根據請求參數(shù)諸如租戶ID、流程ID、執(zhí)行步驟、關鍵詞等列表分頁展示條件查詢或精確查詢結果。

圖5 CQRS與CRUD模式的異同示意

4 結束語

文中設計了CMP工作流微服務組件，發(fā)揮Activiti工作流引擎整合Spring Cloud微服務框架的原生優(yōu)勢；系統(tǒng)內API調用采用REST風格設計，最大限度上保證無狀態(tài)請求的效率最大化，降低開發(fā)難度；流程節(jié)點自由跳轉有助于有效完成工單訂單審批流程在復雜業(yè)務場景下的特性需求；CQRS數(shù)據操作方案旨在解決復雜業(yè)務場景下功能邏輯的高耦合和低效操作下可能產生的誤操作和資源浪費。CMP在OpenStack Pike版本云環(huán)境上驗證了其在云資源調度管理上的可行性。開發(fā)改進方面，可以通過容器部署微服務應用[15]，配置文件采取集約管理，以GitServer的方式按照不同開發(fā)環(huán)境依賴要求，實現(xiàn)配置文件集群部署。