運用BPMN流程建模語言　可視化加速微服務設計

先前文章提到微服務設計在編排技術和工具未出現前，導入微服務架構伴隨著業務面以外的額外開發問題，並提高維運成本和監控困難度，尤其是業務流程一致性問題，讓人們重新思考在業務流程中使用ACID和Two-Phase Commit（2PC）的必要性，而透過BPMN可視化建模工具，可以清楚了解如何重構流程，加速業務系統開發並解耦微服務之間的相依性。

從現實流程反思系統設計

在2005年，EIP大師Gregor Hohpe曾發表過一篇「Your coffee shop doesn't use two-phase commit」的文章（https://ieeexplore.ieee.org/document/1407829），談到以星巴克咖啡來思考鬆散耦合系統之間的交互設計。

從顧客排隊跟收銀員點咖啡，到拿到咖啡後，如果是同步高耦合的流程，將是收銀員結帳後，直接去製作咖啡，顧客在櫃檯前等待直到咖啡完成，這種作業流程方式將導致排隊時間越來越長，進門顧客看到排隊人龍就掉頭離開，導致生意下滑營收減少。

但是如果增加人手不改流程，又會增加營業成本，兩位員工，兩台收銀機，兩台咖啡機，但排隊等待時間問題依然沒有解決，所以餐飲業會分成前台人員跟後台人員，收銀員（Cashier）與咖啡師（Barista）不同職責，先完成點單結帳（同步）留住顧客，再利用紙杯排隊處理訂單（非同步），製作完成再叫名取餐，點餐結帳與咖啡製作解耦；且咖啡製作耗時，採Event通知讓顧戶可先離開無須在櫃台耗時等待，減少客訴；若店內生意持續成長再擴展咖啡師和咖啡機的數量（Scaling），縮短最耗時的製作時間。

解說完這咖啡流程優化，是否感覺似曾相識，這與微服務DDD（Domain-driven Design）設計方法幾乎一致。而這整個點餐到取餐的流程，用BPMM建模的流程圖如圖1所示，並可動態模擬確認流程正確性（影片連結：https://youtu.be/CFixLeDd2rg），大幅提高業務流程設計的便利性，這在過去的舊式BPM流程引擎是無法做到。

BPMN簡介

BPMN（Business Process Model and Notation）是一種標準的流程建模語言，由Object Management Group（OMG）制定，而軟體工程常用的UML（Unified Modeling Language）也是由OMG制定管理。BPMN多用於描述業務流程，它由一系列圖形元素所組成，可以直觀地表示流程中的邏輯、任務、責任範圍和訊息流，並且可以用於描述任何規模的業務流程，從簡單的個人流程到複雜的跨部門流程，BPMN有許多優點，包括：

‧可視化：協助使用者視覺化、圖形化業務流程，有助於更好地理解流程並發現流程中的潛在問題。

‧溝通：圖形化有利於跟業務單位溝通對焦系統的業務流程，有助於更好地協調流程並確保流程的正確性。

‧自動化：整合流程引擎工具可用於業務流程自動化，有效提高工作效率並降低企業成本。

‧分析：當工作流程數位化後，便可分析整體流程，更輕鬆了解工作流程的瓶頸，進而改進業務流程。

BPMN是一套強大的設計工具，除了用於改進企業內部的業務流程，也可應用在微服務系統設計，尤其是討論領域邊界及如何拆解成微服務的Command和Event、同步與非同步通訊方式，這在領域驅動設計DDD是非常重要的議題，正如Bernd Rücker（Camunda共同創辦人）在Real-Life BPMN一書的第二章開頭說到，「如果你無法完全理解，就無法充分欣賞它」，所以如果正在尋找一項方法用來可視化、溝通討論、自動化和分析自身的業務流程，那麼BPMN是最佳的選擇。以下是BPMN的組成元素：

1. 事件（Event）：表示流程的開始、間隔或結束，分為開始、中間和結束三種，見圖2左上方。

2. 閘道（Gateway）：表示流程的分支與合併，見圖2右上方。

3. 活動（Activity）：表示流程中的工作，可以是任務或子流程，見圖2左下方。

4. 連接（Connections）：連接元素，表示流程的順序關係，見圖2右下方。

5. 泳道（Pool）：表示流程參與者，可以是組織、角色或系統，如圖1所示的收銀員和咖啡師。

6. 標註物件（Annotation）：註解說明④，包括資料儲存①、資料來源②和群組關係③，如圖3所示。

BPMN圖形簡潔易讀，適用於業務流程建模，繪圖工具也可執行模擬流程，新型流程引擎支援匯入實際執行，現已廣泛應用於流程管理領域，但用於微服務領域目前才正在發展中。

BPMN與系統整合設計

在大型企業的資訊架構中，Enterprise Application Integration（EAI）是專門討論異質服務組合的技術或整合框架，這些技術和產品服務稱為中間層（Middleware）或「中間層框架」，用來實現整個企業內系統和應用程式的整合，而SOA架構中ESB（Enterprise Service Bus）是常用的解決方案和產品，當然也包括先前文章提到的2PC和Saga技術，而詳細說明企業系統整合的書籍，企業整合設計模式（Enterprise Integration Patterns，EIP）是著名架構師Gregor Hohpe的巨作，其中談到Message的傳遞、繞送和轉換，隨著微服務與事件驅動架構出現後，Message和Event有清楚的定義。

Message

過去在系統解耦設計或非同步傳輸通常都會用Message Queue來確保最少一次（at-least-once）、最多一次（at-most-once）送達或恰好一次（exactly-once）送達，這Queue可充當緩衝提高系統可用性，並且可增加Worker或Cosumer來提高處理效能，避免使用同步傳輸導致超過伺服器可負載量造成系統服務中斷，甚至服務重啟也無法消耗，持續惡性循環，亦可透過Request-Reply（https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html）達到回傳結果的要求。

Command

在分散式架構或事件驅動架構的定義，Command是發送給接收者以完成某些操作的訊息（Message），Command的發送者通常是有目的，並且期望收到接收者的回應結果，所以傳送的內容通常綁定兩個服務之間的特定格式或特定資料，通常是一對一傳輸，如同步的REST-API或是非同步的AJAX，Command示意圖如圖4所示。

Event

Event是已經發生的事實記錄，事件的發送者並不在乎Event會如何被處理（fire & forget），只是通知有發生這樣的訊息，最常見的使用情境是用來做訊息通知，如手機推播或Email發送，對於服務之間是徹底的解耦，彼此並沒有特定格式的相依性，可以是一對多或多對多傳輸，且採用事件架構更具備可擴展性與靈活性，但這取決於業務流程需要區分出Command和Event的訊息定義，如交易紀錄就是已發生的事實，Event Sourcing模式（https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing）就常見於銀行存款流水帳，記錄著每一筆存提款，一旦有金額異動可觸發手機或LINE推播，避免詐騙，Event示意圖如圖5所示。

由上可知，Command和Event是由Message轉變而來，區分成需要回應結果的Command和不需要回應的Event，正如先前文章談到，在過去由於技術和工具的限制，大多使用資料庫ACID特性來控制一致性，大多數訊息傳輸皆採用同步API方式，為了系統整合、服務解耦或效能問題，才會採用非同步MQ方式。

當業務流程採用BPMN視覺化方式設計時，可清楚明白如何將流程拆解成同步和非同步，Command和Event確保流程沒有業務邏輯面的錯誤，並可正確順利執行，而且在業務流程設計時，就可加入數據收集的活動，以免系統實作完成之後，才去業務資料庫擷取資料，重複著反正規化的ETL過程，直接取得業務流程的特徵值，可避免無謂的資料清洗過程，以Event-driven方式傳送到數據架構進行後續分析，這也是Streaming Data Architecture設計理念，而圖6就用BPMN設計來展示這整個過程：

1. 系統整合：採用Task + Message Event設計Command與Event風格的整合方式。

2. 通訊方式：避免使用阻塞的同步方式，透過流程設計思維，拆解成非同步傳輸。

3. 數據收集：傳統數據收集多從業務資料庫，將資料收集放入流程中，可減少ETL工作。

看完以上說明，再回到咖啡店的BPMN流程，從圖1中，就包括了Customer的「Queue and order coffee」和「Choose payment method」都是同步式Command，尤其是Checkout payment是強一致性，等待結帳完成才會進行「Write customer name on cup」，而Barista的「Making coffee notified」是訊息通知，製作完成後再通知顧客取咖啡，使用Message Event圖示屬於一對一非同步式Command，而Event則是用BPMN Signal Event圖示，具備一對多傳送特性。

藉由上述說明可感受到BPMN圖形化也可協助分析微服務和事件驅動流程設計，在「您可能沒有想到的5個工作流程自動案例」一文也提到BPMN應用在分散式系統通訊上（https://blog.bernd-ruecker.com/5-workflow-automation-use-cases-you-might-not-have-thought-of-9bdeb0e71996）。

結語

經過此文說明BPMN如何設計業務流程，並應用到微服務流程設計，讓業務分析或系統分析人員專注在設計流程，開發人員只須實作每項活動的細部服務實作和資料處理，避免業務流程不確定性造成不斷重複修改程式的惡夢。BPMN流程經確認完成後，就可分頭進行前端對應流程的表單設計，和每項活動所對應的後端服務實作。隨著流程越來越多，範圍越來越廣，就可使用Message queue或Event bus來做系統整合，正如圖7所示，更詳細的微服務與BPM設計方法，可參考Camunda Microservices and BPM文件（https://reurl.cc/lDraAQ）。後續將介紹BPMN如何匯入到流程引擎，以實際案例來說明微服務實作，並部署到K8s容器平台。

＜本文作者：鄭淳尹，Docker.Taipei社群共同發起人，國泰金控技術架構師，曾任台北富邦銀行雲端系統部架構師、微軟MVP、momo購物網架構師、臺北榮民總醫院資訊工程師、玉山銀行資訊處專員、宏碁eDC維運工程師。開源技術愛好者，曾在多間大學資工系擔任Docker容器技術講師，並翻譯審閱多本容器技術書籍。＞