BPM平臺在各行業的IT架構中都是重要的基礎支撐平臺，十二五期間，企業級BPM作為SOA體系下的關鍵元件，經歷了一個加速建設的過程。我們也有幸參與了一些行業的流程平臺建設，今天與大家分享我們在流程引擎架構演進過程中的一些經驗與思考。

首先對過去這些年的架構發展歷程進行回顧和總結，

然後談談目前單體型BPM遇到的問題與微服務改造的思路，

第三部分介紹流程平臺向微服務架構演化的一些思考與規劃。

過去：企業級BPM十年架構演化回顧

自上世紀60年代起，企業運營中的管理需求不斷推動著流程管理思想以及流程技術的發展，首先是資訊科技驅動的流程自動化思想出現，然後職能部門的組織模式問題促使BPR業務流程再造的出現，來到21世紀初，以業務流程為中心組織企業整體運營的思想逐漸被接受成為主流，推動了BPM技術的發展。

工作流時代，主要在單個業務系統內部實現流程的自動化與靈活變更，解決較小的企業和組織的流程自動化需求。而BPM技術是在完整的思想與方法論體系下誕生，站在全域性視角關注企業的戰略落地、職能打通、敏捷響應，是涵蓋業務流程建模、執行、監控、優化的全生命週期解決方案。

如果您於十幾年前就開始接觸流程領域，這一定是您記憶中深刻而又古老的一張圖，大多數早期的工作流廠商均是參考該模型制定了自己的產品架構。無論技術趨勢如何演變、功能需求如何疊加，流程平臺的總體概念架構並沒有脫離這個參考模型。

該模型的核心是流程引擎，以及由其提供的5類介面，流程引擎實現了核心的流程排程機制，支撐著流程模型及其組成活動的定義、載入、解析、校驗、執行、監聽的整體執行過程。本次分享主要針對流程引擎的架構演化來展開。

本章節對過去這些年流程平臺的架構演進歷程進行回顧，從兩個緯度分成兩條演進路線來講述。

第一條線是功能性架構，從最初只能支援單個業務系統的內部工作流，到打破部門牆支援端到端流程，再到SOA體系架構下全面支撐企業的流程建模、實施與監控，從支援WfMC-XPDL到支援BPMN規範，最後對大型企業的多領域業務系統進行集中納管。

第二條線是非功能架構，利用叢集、快取、非同步、分散式等多種架構模式，不斷追求著高效能、高可用、可伸縮性等質量屬性。

十多年前，工作流的應用剛剛在國內興起，一些開源的工作流引擎諸如jbpm2.0、osworkflow開始被廣泛使用，那時大多是嵌入式架構，即流程元件與業務系統部署在一個應用中，只做本地呼叫，共享一個數據庫，只能實現該業務系統內的工作流自動化。

隨著流程領域的深入發展，流程平臺開始作為一種中介軟體進行獨立的部署和運維，業務系統通過遠端呼叫的方式獲得流程服務，依賴單獨的流程資料庫，流程管理控制檯也被當做一個前端應用分離出來。這種部署架構顯然是更加複雜了，但卻是從工作流走向BPM的關鍵一步。

因為BPM的目標是將多個業務系統間的流程連在一起，將多個業務應用中的流程集中管理，其所服務的物件也不僅僅是開發人員而是面向企業管理。定位的不同，帶來架構與功能的諸多不同，BPM所要解決的問題要求其必然是獨立部署的。

SOA是面向企業架構的一套方法論，BPM與ESB都是其體系下的重要支撐平臺。ESB是系統間服務介面互動的匯流排，可以做服務路由、協議轉換、報文轉換、邏輯編排，但它處於技術層面的互聯互通。

BPM則是站在全域性業務管理的視角實現一個更高緯度的整合，在這一架構下基於SDO/SCA技術的BPM可以實現動態web服務，並且更加方便的接入ESB上的服務，在端到端業務流程整合方面的支撐力度更強。

十二五IT建設期間，許多大型的國企央企都提出了企業級BPM或統一流程平臺的概念，藉此契機，流程引擎開始向著多租戶架構發展。

企業級BPM是指在公司總部及各省（市）公司構建集中的“BPM流程服務資源池”，將原來由各應用使用的BPM元件統一收歸至總部及各省公司集中部署與運維，集中納管各系統流程模型及流程執行例項，體現出“統一流程標準、統一流程服務、統一流程運維”的特徵。

每個應用的流程獨立流轉互不干擾，支援表級資料隔離、資料來源級隔離，支援租戶的組織機構服務、任務推送服務等十幾項個性化配置。

PVM即流程虛擬機器大概是在2009年開始在流程領域出現的一種技術，是一種優秀的程式可擴充套件性架構。PVM本質上是要將流程引擎與流程語言解耦，為此，PVM提供了一套獨立的流程定義模型、外掛環境及外掛擴充套件點。

流程模型與任何流程標準或規範無關，直接決定了PVM對流程的描述建模能力，也是支援多流程語言的關鍵。從PVM的擴充套件機制可以看到，模型是保持不變的，能擴充套件的只是節點的執行期行為。

PVM提供了一套外掛環境以及外掛擴充套件點，把流程與活動在執行期的關鍵行為抽象出來，與流程的其他模組解耦合。最後，PVM還提供了一套排程框架或稱持續推進機制，使流程可以持續執行或從任意一個點重新切入。

在高併發、大吞吐量的應用場景中，需要能夠水平擴充套件的叢集架構，負載均衡將來自業務系統的請求分發到叢集中的某個流程引擎，每個引擎保持著自己的狀態資料（如流程例項等），在多個引擎的本地快取間需要同步狀態，在引擎內部以及叢集的多個引擎之間需要對併發請求進行排隊，這種分散式快取的方式也是redis和memcache等集中式快取沒有在企業應用中被廣泛使用之前的主流選擇。

對於叢集架構的支援除了快取資料的狀態同步，還需要全域性鎖機制、叢集通知機制、統一主鍵生成機制、業務資源同步機制、任務爭搶機制等，系統的每個模組在設計和研發中都不能忘記自己是在一個叢集中執行的。

隨著流程平臺逐漸應用於電信、電力等行業的關鍵生產系統中，對於效能和可用性的要求迅速提高，基於SEDA理念的三段式框架應運而生。

SEDA是為了支援大規模併發處理、降低響應時間、處理請求積壓以及隔離外部系統不穩定性而出現的一種架構模型。其核心思想是把一個請求處理過程分成幾個Stage，不同資源消耗的Stage使用不同數量的執行緒池來支撐，Stage間使用事件驅動的非同步通訊模式。

流程平臺基於自身的應用特點可以將引擎分為三段：接入段、引擎段、接出段，在支援原有的request-response同步呼叫方式之外，接入段與引擎段支援One-way方式，引擎段與接出段間支援request-callback方式。

平臺的非同步api介面、ServiceTask/SendTask圖元、非同步觸發事件等功能模組都可以基於三段式框架來實現。

分散式SEDA架構則是通過非阻塞的HTTP呼叫來組合多個SEDA架構的JVM，這些JVM可以在一臺機器上，也可以分散在多臺機器上。

對於一個請求的處理被分為6個Stage：接入層（正常響應Stage／異常響應Stage），流程引擎層（請求Stage／正常響應Stage／異常響應Stage），接出層（請求Stage）。 接入層根據請求中的流程例項ID和叢集節點數的餘數進行路由（PID%NODE_NUM,限任務提交等非統計查詢類操作），可以傳遞給本地JVM流程引擎或是遠端JVM流程引擎，待處理完成後，將真實的業務資料響應返回。

現在：單體型BPM的問題與改造方案

架構的演進是在眾多行業客戶的需求推動下對功能性以及質量屬性的不斷追求。在功能性方面，工作流自動化、端到端流程打通、多系統集中納管；在質量屬性方面，為獲得更低的延遲、更高的吞吐量，採用並行化、非同步化、批量化、快取化、去中心化等架構模式，無單點的可用性設計，伺服器、快取、儲存各個層面的可伸縮性，不斷的服務分層、模組分割構造出程式面的可擴充套件性。

然而，對於一個發展了十餘年的單體巨石型平臺系統，龐大的程式碼量和眾多的公共模組，導致迴歸測試工作量激增、版本釋出週期長、新同事接手難、產品質量難以保障。

不同模組有著截然不同的計算特點，有cpu密集型、記憶體密集型、IO密集型，有主體核心的功能，也有繁雜的衍生功能，垂直架構下這些模組均部署在同一程序中，相互影響的矛盾似乎難以調和。

而企業級BPM統一流程執行服務的功能需求對於彈性伸縮、高可用、熱部署等能力需要在對等叢集架構下也遇到了技術瓶頸。圖中對BPM在研發運維中經常遇到的問題進行了舉例，後續章節將嘗試通過微服務架構改造來解決。

網際網路經濟深刻改變了我們身邊的商業環境，消費者的生活方式日益數字化。企業也在運用多種技術手段發揮數字化潛力，促進企業業務模式的轉型。這要求IT架構更快速的響應客戶的個性化需求，更加彈性的應對無時不在的客戶請求。

架構規定了軟體的高層劃分及各部分間的互動。太多問題矯揉在一起會造成解決方案的複雜度陡增，所以架構設計很重要的一點就是能把難以處理的大問題分解成便於管理的小問題。架構是為管理服務的，能夠把軟體拆分成穩定的細粒度模組的架構就是好的架構。

在企業架構上使用SOA支撐業務，而在應用技術架構上使用微服務架構，是一個合適的選擇。

服務化的思想一直是軟體架構的標準正規化，微服務則是這一思想的最新實踐，它會給我們帶來哪些啟示呢。圖中列舉了微服務架構的9個特徵（Martin Fowler），以及對微服務可能帶來的價值進行了舉例。一直關注我們微信群的朋友應該不會陌生。諸如每個微服務獨立開發、獨立伸縮、故障隔離等也是企業級BPM所急需的。

經過微服務架構改造的系統會變得更加複雜，這種複雜性體現在一個軟體的全生命週期的所有環節，業界大師Martin Fowler建議微服務要基於一個基礎平臺最好是一個PaaS平臺。

其實不僅是PaaS，這個平臺需要涵蓋DevOps、容器雲、微服務框架三個領域，DevOps平臺用於支撐微服務的全生命週期數字化協作，容器以其不可變性和自給自足的特點成為微服務部署與運維的最佳選擇，微服務之間通過分散式呼叫框架所提供的服務註冊發現機制、服務路由、叢集容錯等特性以去中心化的方式進行協同。

改造過程中會參考雲原生應用的12準則，後文的微服務拆分中有所體現。後續概念圖中可能會出現基礎平臺的一些元件，我們基於重基礎架構（平臺）、輕應用架構（服務）的理念以求最大限度的遮蔽微服務架構帶來的問題。

我們從業務能力、技術服務、資料實體三個層面對BPM平臺進行詳細的梳理，並對三個層面間的支撐關係進行整理，根據梳理的成果以及對系統長期的研發與運維積累下來的經驗，識別出可以拆分出來的且拆分後可以帶來價值的微服務。下圖簡要展現了梳理的內容。

根據業界前輩Chris Richardson對微服務模式的介紹，我們可以根據動詞或名詞進行微服務拆分，動詞用於服務劃分，名詞用於資源劃分，負責特定資料實體的一系列全量操作。從動詞和名詞的角度考慮三個層面的梳理，前兩個層面多是動詞，資料實體則偏向名詞。

這裡還想再提一點，在過去的十年裡，我們的BPM平臺經歷了幾次程式碼重構與架構優化，層次清晰、內部技術服務間的邊界很穩定，前後端也實現了分離，這些都是微服務改造的良好基礎。如果您的系統是一個新的系統、正在快速變化的系統，需求變動與程式碼重構都可能會使模組間的關係很不穩定，做微服務化的難度會加大。

Œ未來：企業級BPM的微服務架構演進

第三部分講述我們對企業級BPM進行微服務架構改造的一些規劃和思考。

微服務的劃分原則有著不同的實踐，可以從不同的視角、不同的關注點去分析，而它們有時又是交叉的，該圖展示了我們在思考微服務拆分時的幾個維度。

名詞/動詞視角，例如可以將工作項（參見WfMC-XPDL流程定義元模型之workitem）這個名詞及其相關的全量操作分離出來，這也相當於把PVM的一個圖元外掛的實現拆分了出來，也可以將自由流轉到目標節點這個動作分離出來，自由流是典型的中國特色流程需求，其主要目的是打破流程圖的原有定義，更加靈活的動態流轉。

業務能力/技術服務視角，對於一個業務系統而言，這相當於縱向拆分和橫向拆分。站在流程平臺這個系統的角度去看，自由流、指派後繼活動參與者等直接以對外api方式體現的能力相當於業務能力，而業務規則引擎、主鍵生成服務、定時器服務等都屬於後臺的技術服務。

主體功能/衍生功能視角，例如PVM的流程排程/流程持續推進能力是平臺的主體功能，而任務推送、轉歷史等都屬於衍生功能，沒有這些能力並不影響正常的流程推進，然而事實上它們在執行中的不確定性會極大影響PVM的效能。

我們一直在思考BPM該如何更有效的向微服務架構演化，結合BPM產品自身的特點與一些業內經驗，我們暫且列出這些原則，後續拆分示例中會有所體現。

此處先簡單說明幾點：

叢集化是指由過去的對等叢集架構演化為所有微服務都可以動態伸縮，這可能涉及到負載均衡由前端單點轉移至呼叫方；

去中心化涉及到服務的協同方式不再走集中式的ESB而是選擇釋出訂閱模式，包括註冊中心本身也要去中心；

配置化包括服務的依賴關係解耦，對應用透明無侵入；

版本化指在服務升級或線上bug修復等場景下所需要的多版本管理，服務的提供者與消費者在釋出引用時須指定版本號。

雲原生應用12準則之一是將應用作為無狀態的程序來執行，無狀態才能保證應用可以隨時啟動和關閉，可以根據壓力動態伸縮。壓力監控與伸縮漂移等能力都由基礎平臺提供。

無狀態並不是真的沒有狀態，而是將資料狀態儲存在基礎平臺的快取服務中，對於業務系統而言狀態可能是session，對於流程平臺而言則是流程例項快取等。這也涉及到雲原生應用準則的“後端支撐服務”，將資料庫、快取、訊息佇列等這些後臺支撐服務當做可掛載的資源，對應用透明。

BPM現有的分散式快取機制是使用JVM本地記憶體並通過叢集通知或全域性鎖機制處理快取的變更。如果不走無狀態改造這一關鍵步驟，上雲後在功能方面可能會出錯、在效能上也達不到伸縮的效果。

除了流程例項快取，還有流程定義快取、代理關係快取、業務資源快取、業務規則快取、多租戶快取等所有需要叢集同步的資料都需要放在基礎平臺的集中式快取服務中。各類快取的原介面保持不變，實現類則改為呼叫基礎平臺快取服務的SDK獲取各類資料。

組織機構服務在工作項處理等模組中會被頻繁使用，BPM提供介面供業務系統接入時實現，比如在國家電網的實現是統一許可權系統ISC。考慮到該介面十分重要且依賴外部系統的穩定性，出現問題時不容易釐清原因，並且有熱更新的需求，可以將組織機構服務拆分出來。

圖中演示了使用藍綠髮布來實現熱部署的過程，主要是三個步驟：部署新版本，匯入測試請求，切換流量將生產負載路由到新版本，客戶端負載的路由可由基礎平臺的微服務框架提供。

任務推送表是工作項處理模組與任務變更推送模組之間的共享模型，該模型對於工作項模組是頻繁的實時的修改，對於推送模組是定時的批量的處理，鑑於當前的處理方式可以不對該表做遷移，只把推送服務遷移到獨立程序中。

推送的技術實現是租戶即業務系統的個性化配置，也就是說這個模組受外部系統的影響很大，當它執行起來但遠端推送過程中出現不穩定狀況時將影響PVM主體的效能，因此將作為衍生功能的任務推送模組拆分為微服務可以起到隔離外部故障的作用。故障隔離不使整個系統陷入癱瘓也是微服務架構的價值之一。

業務規則引擎是BPM平臺的一項基礎服務，PVM做流程排程時基於它計算分支，工作項模組生成人工任務時基於它計算參與者。

業務規則引擎由規則快取、規則編譯、規則執行三個主要的部分構成，可以整合拆分為一個微服務，對外提供的介面直接返回規則執行後的結果，可能是一些參與者也可能是布林值。規則編譯所依賴的庫表可以不拆分，規則快取如上文所述需要轉移到基礎平臺的快取服務中。

自由流、順序工作項、指派後繼活動參與者三個功能模組均由流程例項屬性表所支撐，其中自由流和指派後繼活動參與者都是可以獨立接收業務系統api呼叫的。

可以把流程例項屬性表及快取連同這幾個功能單獨拿出來，表也可以放在原庫。該模組內部呼叫關係比較簡單易於拆分，但這幾類api的呼叫量比較低，拆出來的價值還需要評估。

從這個例子可以看到，在沒有拆分微服務之前，因為程式碼都放在一起，很難意識到把不同的關注點放在了一起，現在可以將某些資料分離為單獨的表，或把某些表分離為單獨的庫。這引出了微服務架構所帶來的資料一致性問題，這個問題首先是儘量避免出現，在其他同事的分享中提供過幾種解決方案。

本例在一個事務中可能會同時更新流程例項表和流程屬性表，我們可以採取重試+補償的策略：如果更新流程屬性表失敗，嘗試一定的次數，仍不可用則在主體程式中丟擲異常（該模組也可以熔斷或降級，當判定其不可用時，流程引擎的主體能力不受影響），如果流程屬性表成功，流程例項表的事務失敗，補償流程屬性回退到操作前的狀態。

工作項是一種重要的資料模型，按照名詞做資源劃分可以將其以及相關的全量操作分離出來，對於主體PVM而言只是人工任務這個圖元外掛的主要實現程式被拆了出來。

工作項微服務既可以直接提供api服務（負載的路由問題可以由API Gateway支撐，這也是一種常見的微服務模式），也可以為PVM提供內部服務，而且finishworkitem這個操作有可能回撥PVM主體，用於在工作項完成時觸發流程推進，所以二者是雙向呼叫的關係。

非同步化是常用的效能優化方式，在合適的場景下，非同步化可以帶來更大的吞吐量、更短的響應時間，而且還具備隔離外部不穩定性的作用。此處觸發事件以及ServiceTask/SendTask等功能都可以基於SEDA元件進行非同步化呼叫。

BPM引擎對外API以及內部伺服器之間的呼叫，都統一使用RESTFul，可以方便的進行服務mock以及監控分析。

基礎平臺的API Gateway元件以及服務註冊中心用於將客戶端的請求路由至微服務架構中的可用服務例項。這種模式可以確保客戶端察覺不到應用程式已經被拆分為多個微服務。

由平臺提供的基於註冊發現機制的分散式呼叫框架將確保客戶端不受服務例項位置的影響，即當某個微服務做了伸縮、漂移、熔斷、降級等操作之後不影響客戶端對其定址。

本次分享針對企業級BPM平臺做了一次微服務架構演進的思考，每個領域的it系統它的執行方式、計算特點、架構風格都是不同的，深入理解自己的系統，才能選擇最合適的方式進行微服務架構探索。

普元公眾號：