系統設計 - 應用、微服務、流程、規則編排

文 | 少個分號 （轉載請註明出處）

公衆號：DDD 和微服務

知乎：少個分號

微信號：shaogefenhao

網站：shaogefenhao.com

在架構設計中，經常會聽到人講編排這個概念。但實際上，在不同場景下他們說的可能不是一回事。

這期的系統設計，我們討論幾個和編排相關的場景：

在現代企業應用中，上述編排需求已經非常常見，下面介紹一些開源框架或者工具實現上述訴求，以便在遇到類似的場景時，能選擇合適的方案。

應用編排

在多數場景下應用編排，往往說的是部署單元和服務器資源管理，通常屬於 Devops 領域。

一些中小型公司通常使用 Linux 的 SSH 登錄，配合自己編寫的部署腳本就可以完成部署和資源管理。但是對於大公司的運維人員來說，管理成千上萬的服務器就顯得喫力。

早期比較流行的服務器部署編排的工具有 Puppet、Ansible，在雲平臺興起後出現了 Terraform 也非常好用，這些工具均可以操作虛擬服務器並自動完成批量自動化操作。

在部署方面這些工具都可以看做應用編排工具。

所以在很多文章中，應用編排的定義是跨多個計算環境自動化的協調複雜應用軟件應用程序的部署、配置和管理。

在容器和微服務興起後，基於代碼即基礎設施的編排理念出現了，通過定義應用程序和基礎設施的狀態來管理基礎設施和應用，從而保證了一致性、快速複製能力、拓展性。

常見的工具有：

在 2023 年，瞭解學習 Docker Swarm + Kubernetes 可以應付大部分應用編排的場景和帶來更多工作機會。

微服務編排

微服務編排往往說的是微服務之間的調用方式，以及如何給客戶端提供友好的 API。這個話題我們在之前的文章：系統設計 | "胖瘦" BFF：常見的兩種微服務形態 中討論過。

簡而言之通常有兩種微服務集成方式：

流程編排

流程編排往往和工作流引擎有關。

流程是一組用戶活動按照一定順序組成的序列流，順序可能是串行、並行，在流程中可能存在准入準出機制、觸發機制等。

所以工作流引擎編排的對象往往是一個系統完備的 API，一個活動也可以看做一個用例，這點需要和下面的業務規則編排區分開。

在 IT 系統中，流程引擎往往適用於下面這兩種場景：

甚至工作流管理聯盟（WfMC）在 1993 年對工作流引擎進行了規範化，使其能定義統一的接口，將各個應用接入到工作流體系中來。其模型概念如下圖所示：

參與到流程體系中的組件需要遵守一套規範，這樣就可以流程互通。發展到現在，流程引擎的主流規範是 BPMN2.0。

主流的的流程編排引擎都支持 BPMN2.0，例如：Camunda、Activiti、Flowable 等。

BPMN 和 UML 一樣是一套精確的圖形化表示方法也被 OMG 組織管理，名稱爲”Business Process Modeling Notation”，即 “業務流程建模標記法”。因此可以在前端靈活的拖拽設計生成 BPMN 文件，輸出標準文件後，即可在流程引擎中動態加載和使用。

對於大型企業來說，流程引擎可以將不同的應用集成起來，並參與到企業的流程管理工作中來。

規則編排

規則編排和流程編排則顯得不一樣，規則引擎往往用管理業務規則，基於預定義的規則，當有業務輸入時，根據輸入獲得不同的結果或者觸發不同的行爲。

例如，電商系統中對於不同積分和等級的會員獲得的折扣可能不一樣，這樣就可以使用規則引擎靈活處理此類場景。

通過規則引擎可以讓用戶也能在一定範圍進行配置，對業務結果和行爲進行干預。

規則引擎的開源方案並不多，目前可以使用的有：Drools、Liteflow（國產開源框架）。Drools 是一個標準的規則引擎框架，Liteflow 偏向代碼組件級別的流程編排多一些。

和 BPMN 標準類似，在規則引擎領域也有一個 DMN 規範，即 Decision Model and Notation。從名字上就能清晰地區分 BPMN 和 DMN 的關係。

Drools 完整支持 DMN 在很多業務規則，對於業務規則複雜的場景是一個非常不錯的選擇。快速瞭解 DMN 可以參考：learn-dmn-in-15-minutes.com。

總結

應用編排和微服務編排爲大多數人熟悉，但是對於流程引擎和規則引擎來說，瞭解的人可能不是很多。

實際上一些系統大量在使用流程引擎和規則引擎，通過剝離流程和規則，對於複雜應用系統來說大大增強其靈活性，這一點對架構師非常有幫助。

參考資料

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/p08Th2FCcTJZXH8hUigsRQ

猜你喜歡