容器化微服務工作流開發框架①

劉一田，劉士進

(南京南瑞信息通信科技有限公司，南京 210003)

1 引言

“互聯網+”等新的生產和經濟發展模式迫切需要企業業務流程改進和再造，業務流程作為代表企業服務水平和競爭力的核心資產，需要隨著市場變化靈活快速按需重構，亟需一種低成本、可擴展、可動態配置的柔性工作流開發框架支撐.

云技術的發展為企業信息化流程再造提供了階梯，云技術通過虛擬化技術將計算、存儲、網絡和服務變成可動態配置的資源，而容器技術因其輕量級、易部署、啟動快等優點正逐步取代傳統虛擬機成為新一代云化基礎設施，而且隨著Kubernetes (k8s)、Docker 等容器化技術的日益成熟[1]和微服務架構的廣泛應用，結合DEVOPS 的敏捷開發、持續集成、快速迭代已逐步成為保障業務交付安全及性能的主流技術發展趨勢.

目前國外已有很多比較成熟的工作流管理系統Pegasus[2]、GridFlow[3]，這些工作流引擎框架提升了流程任務的編排和管理能力，但偏向于科學計算，業務流程運行時靈活變更支持不足；在流程引擎的服務能力提升方面，文獻[4-6]研究了云環境下容器化的有限狀態機工作流彈性伸縮技術，提出了基于CPU 使用率的工作流自動伸縮模型，結合流程負荷自動伸縮流程的容器數目以提升流程引擎服務性能，但不太適用于順序工作流.因此，主流工作流框架在柔性適配流程開發和運維方面還面臨著一些問題和挑戰，主要表現在：(1)業務活動的簡單變更需要修改流程模板、流程表單及流程遷移事件，但修改無法即時生效，增加開發運維成本并影響生產效率.(2)流程活動參與者范圍篩選計算復雜，影響業務開發效率.(3)順序工作流引擎的運行時擴展柔性不足，云計算結合容器技術雖然讓資源擴縮變得方便，但依然需要人工手動操作，智能和自動化程度較低.

針對上述問題，本文提出一種容器環境下基于領域驅動設計的工作流開發框架，將企業應用根據領域模型細分后，拆分為分工明確的核心子域微服務、邊界上下文和業務微服務，通過容器作為微服務的載體，靈活集成企業工具鏈，在提高服務質量、可擴展性和可靠性的同時，降低了企業運行成本，具備以下特征：(1)支持基于領域模型驅動的在線流程表單零代碼開發、運行模型變更和屬性狀態權限控制；(2)支持動態的業務組織關鍵點設計，柔性適配活動參與者，支持流程活動腳本的運行時更新.(3)結合監控微服務的容器服務柔性伸縮策略及控制.

2 容器化柔性微服務工作流開發框架設計

本文設計的容器化柔性微服務工作流開發框架結構如圖1所示.通用服務和業務服務都以Docker 鏡像方式發布，并推送到容器鏡像倉庫，通過K8S 容器管理組件從容器鏡像倉庫拉取鏡像并部署到容器池中.數據庫不做容器化部署.框架的結構說明如下.

(1)所有微服務統一走網關路由，微服務網關采用集群方式部署，支持高可用路由和基于安全策略的最小權限訪問控制.

圖1 容器化微服務流程開發框架結構

(2) 所有服務以容器化方式啟動運行并注冊到Spring Cloud Netflix Eureka[7]中，接入監控代理，監控代理將容器及服務的監控數據發送給監控服務，實現Docker 容器及微服務的服務水平質量監控.

(3)權限微服務提供基于RBAC 的訪問控制，并支持業務組織管理、用戶管理、角色管理、菜單管理、功能管理等.

(4)工作流微服務提供基于Web 的可視化流程建模和發布、監控管理.其中工作流模型的機構模型主要描述使用者的角色、權限分配、活動狀態以及組織機構關系等，并基于權限微服務提供的組織、角色和用戶進行配置和解析.

(5)模型微服務提供基于Web 在線運行時領域對象模型建模功能，支持數據源、業務字典、編輯器模板、業務對象模型、展現模型、應用控制模型等模型的建模，其中，業務對象模型是業務表的抽象，并增加屬性編輯器模板的綁定等約束，屬性編輯器模板和業務字典綁定，支持運行時表單編輯，應用控制模型提供業務展現場景視圖基于狀態的對象和屬性訪問控制配置.

(6)監控微服務提供對包含自身在內的所有微服務的URL 鏈路服務質量監控，容器CPU、內存、線程等資源的實時監控；基于監控指標的容器伸縮策略配置，并根據服務質量狀態伸縮策略進行實時告警推送和容器伸縮控制.

3 容器化柔性微服務工作流開發框架實現

一個完整的工作流模型由3 個子模型組成：其中組織模型描述工作流執行中的組織實體，框架中基于通用權限服務配置業務組織實體以及角色、用戶等實體；信息模型描述工作流執行中的信息項，框架中基于領域建模實現；過程模型描述工作流的功能，框架中基于可視化流程建模配置及解析實現.微服務工作流子模型之間的實體關系形式化描述如圖2所示.

圖2 微服務工作流子模型的實體關系描述

結合微服務工作流子模型實體關系，容器化微服務工作流開發框架的開發流程如下：

(1)通過模型驅動微服務提供的建模視圖按業務領域建模，構建領域對象模型，并基于領域對象模型構建業務表單模型.(2)通過工作流微服務提供的流程設計器構建業務流程，設置流程啟動者和參與者，限定參與者為指定組織用戶，在流程活動模板中綁定表單模型，并允許在表單中設置流程活動狀態的表單屬性訪問控制.(3)通過可視化界面設計器[8]設計界面，支持最終用戶的業務流程操作流轉.

根據上述開發流程，需要實現3 個主要關鍵技術組件：(1)基于模型驅動微服務的零代碼流程開發套件；(2)基于通用權限微服務的流程活動組織關鍵點策略和流程腳本的熱更新機制；(3)結合監控微服務的容器彈性伸縮策略和伸縮控制.

3.1 基于領域驅動微服務流程零代碼開發

模型微服務基于多租戶模式，實現了基于領域模型驅動的在線業務對象模型建模、流程表單模型建模、和應用控制屬性狀態管理，模型關系如圖3所示.領域對象模型具體構建方式為：(1)首先基于分層架構將領域層劃分出來，領域專家劃分領域為合適的子域、邊界上下文、實體、值對象和服務；(2)研發人員基于子域分包建模，通過可視化建模視圖構建領域包、數據源、業務對象類型和類型屬性、類型關聯.表單建模是根據業務需求構建應用控制和表單模型，應用控制模型設置對業務類型和基于狀態的類型屬性的訪問控制，表單模型引用應用控制模型，在表單模型中設計表單屬性的編輯器模板，添加業務字典并和編輯器綁定以支持界面交互.最后創建流程模型，在流程活動模板中綁定表單模型并發布流程，通過界面設計器設計界面并綁定對象類型和流程參數完成零碼開發.

圖3 領域模型構建

3.2 基于通用權限微服務的流程活動關鍵點設置和活動腳本動態更新

通用權限微服務提供了多租戶的權限管理功能，并支持基于網關和安全策略的統一權限認證，實現了基于租戶的業務組織、菜單、功能等資源管理，并通過角色和資源及用戶的綁定實現權限解耦和授權，如圖4(a)所示.服務之間的認證采用輕量級JWT 認證[9].

圖4 通用權限服務的資源授權及組織關鍵點

工作流引擎微服務基于開源引擎Activiti 實現，Activiti 提供了工作流存儲、運行時、任務、身份、管理、歷史、表單等7 類流程服務接口，框架對其身份接口進行擴展，集成框架通用權限微服務，允許操作者將流程活動參與者設置為和流程啟動者或上一個活動的發送者相同的業務組織，實現了基于通用權限業務組織的活動關鍵點功能：給出業務組織列表，允許操作者將指定的業務組織設置為活動關鍵點，如圖4(b)所示.當發送流程時，當發送者隸屬于某已設置的關鍵點組織時，則將發送范圍限定為該關鍵點內具有可接受任務角色的用戶，解決了活動參與者設置業務的復雜計算等問題.框架采用JSON 描述流程定義，用關鍵字描述了圖2中子模型之間的關系，其中流程、活動、遷移線都抽象為資源對象，表單作為活動資源對象的子對象，通過遷移事件支持二次開發.如圖5所示.其中user 表示活動參與者，以角色描述，formtemplate 表示表單模型，overlay 表示組織關鍵點，stateId 表示應用控制模型狀態.event 表示事件，action 表示事件方法.

圖5 微服務流程的形式化定義

框架提供流程腳本管理界面，支持將流程腳本jar 包上傳到流程微服務內存及數據庫中，由于流程活動腳本相對獨立，利用JVM classloader 的動態代理機制，實現了流程活動腳本運行時即時熱更新，避免了需求變更升級腳本時對運行時生產流程的影響.

3.3 結合監控微服務的容器彈性伸縮策略

資源使用率通常都有峰谷期，傳統工作流框架無法根據任務量或任務到達速率進行動態伸縮來提高集群的整體資源利用率和服務質量，本文設計的框架是通過基于監控策略的監控框架對微服務容器和微服務進行監控[10]，全自動的收集Docker 容器實例、微服務實例及服務接口的信息.圖6給出了結合監控微服務的容器彈性伸縮策略控制過程.其中容器彈性伸縮策略支持配置兩種策略算法：(1)基于閾值的響應式伸縮算法實現：定義容器伸縮配置yaml 文件，作為K8S 創建容器的配置，周期性地采集微服務宿主Docker 容器的CPU、內存、網絡、IO 等指標占用率，以及服務平均響應時間等，通過與設定閾值進行比較從而動態改變集群數量，為了避免瞬時資源消耗峰谷造成的頻繁伸縮，在策略的配置上增加了伸縮延遲時間配置.(2)基于預測的伸縮算法實現：主要采用時間序列分析和機器學習兩類，其中時間序列分析主要提供了簡單移動平均法和指數平滑法兩種算法；機器學習法采用了BP 神經網絡預測模型[11]，將正確的結果和產生的結果進行比較，根據誤差逆推對神經網絡中的權重進行反饋修正，從而來完成學習的過程.

4 案例分析與評估

為了驗證本文提出的容器化微服務工作流開發框架，在一個真實的環境中進行了案例的部署和研究.案例環境由3 臺8 核32 GB 內存的浪潮服務器(SA5248L)組成，其中數據庫采用虛擬機部署，網關微服務、服務注冊微服務、工作流微服務、權限微服務、模型驅動微服務、監控微服務采用容器部署，容器副本數均默認為3.數據庫和應用服務采用某電力公司綜合停電管理系統的測試數據庫和經過領域劃分的微服務，微服務實例以K8S 部署的Docker 容器形式運行.

圖6 基于監控微服務的容器彈性伸縮

部署完成后，由兩名業務配置人員經過培訓后基于停電檢修流程所涉及的領域對象、表單和流程建模，并根據流程活動和應用控制狀態設置流程表單對象的不同字段的動態訪問控制權限.其中檢修流程活動包括方式專責初審、通信處和調度處等各部門會簽、方式處審批、網公司審批、調度執行、歸檔等活動環節，檢修流程定義的形式化描述如圖7所示.

圖7 停電檢修流程的形式化定義

在檢修活動表單授權時，每個檢修流程活動對應于一個檢修單狀態，狀態是類型屬性和屬性權限的屬性安全域，并基于角色設置屬性的訪問控制，狀態和流程活動匹配，以支持運行時獲取表單及屬性訪問控制.如圖8所示.將基于模型的表單和流程活動掛接，設置流程活動參與者及關聯組織關鍵點，組織關鍵點的定義和選擇是以省內地市供電局和電廠為關鍵點，這樣地市供電局和電廠的用戶在處理流程時，流程活動的參與者被限定為當前供電局或電廠.經評估，相同人工下較之前代碼開發方式提升開發效率35%以上.

圖8 檢修流程表單類型屬性權限授權模型

在運行時工作流等微服務性能彈性伸縮方面，通過loadrunner 模擬并發300 用戶的登錄、檢修流程創建、保存、發送、審批等流程活動，通過監控策略和容器彈性伸縮策略，即監控每3 分鐘內服務容器CPU 和內存占用率，15 分鐘后取監控周期內CPU和內存占用平均值，當CPU 或內存平均占用率達到80%時，啟動容器擴容操作，自動增加1 個指定服務的容器，當CPU 或內存平均占用率低于30%時，刪除指定服務的1 個容器服務實例，以避免因為監控數據抖動而引起頻繁的擴容或縮容操作，觀察容器化微服務流程開發框架的自動彈性伸縮能力和服務穩定性，結果見表1.

表1 檢修流程性能壓力測試

驗證結果表明，柔性微服務工作流開發框架能有效根據資源使用率的峰谷進行容器服務伸縮，保證了工作流等微服務的運行時性能、擴展能力和高可用，但也發現了一些問題，針對小規模的應用現有框架的部署架構略顯復雜，增加了運維難度，尚有提升空間.目前，柔性微服務工作流開發框架已在南網某省綜合停電管理系統中實現并應用，取得了較好的應用效果.

5 結束語

本文研究了傳統工作流框架建模、領域驅動設計、容器化微服務運行時自動伸縮等技術，在此基礎上，設計了容器化柔性微服務流程開發框架，給出了基于領域驅動設計的微服務的零代碼流程開發套件、基于通用權限微服務的流程活動組織關鍵點適配和流程腳本熱更新機制、結合監控微服務的容器彈性伸縮策略及伸縮控制等創新點，闡述了該框架的架構設計及關鍵實現技術.最后，以南方電網某省綜合停電管理系統的檢修單應用案例為背景，給出了柔性微服務工作流開發框架的應用驗證評估，驗證結果、效率評估及生產運行實踐表明，該框架提升了分布式環境下微服務工作流應用開發和管理的靈活度、效率，實現了基于容器的工作流等微服務運行時柔性伸縮能力，提高了電網應用信息系統的服務水平.后續將針對遺留問題持續改進優化該框架.