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

這期的系統(tǒng)設計，我們討論幾個和編排相關(guān)的場景：

• 應用編排(Application Orchestration)：將應用程序通過腳本或者配置文件統(tǒng)一部署到目標服務器環(huán)境，例如虛擬機、容器云平臺等。
• 微服務編排(Micro-service Orchestration)：將原子化的微服務整合起來提供調(diào)用者更友好的 API，一般面向于多渠道、多種用戶群的系統(tǒng)。
• 流程編排(Flow Orchestration)：使用流程引擎，將不同的系統(tǒng)或者服務組織起來，提供統(tǒng)一的流程控制、中心化審批等能力。
• 規(guī)則編排(Rule Orchestration)：在服務內(nèi)對于多個決策任務進行編排執(zhí)行，提高執(zhí)行效率，簡化業(yè)務規(guī)則。

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

應用編排

在多數(shù)場景下應用編排，往往說的是部署單元和服務器資源管理，通常屬于 Devops 領(lǐng)域。

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

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

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

所以在很多文章中，應用編排的定義是跨多個計算環(huán)境自動化的協(xié)調(diào)復雜應用軟件應用程序的部署、配置和管理。

在容器和微服務興起后，基于代碼即基礎設施的編排理念出現(xiàn)了，通過定義應用程序和基礎設施的狀態(tài)來管理基礎設施和應用，從而保證了一致性、快速復制能力、拓展性。

常見的工具有：

• Kubernetes：當前主流的容器云編排工具，屬于程序員必知必會的知識。
• Docker Swarm：Docker 原生的容器編排工具，目前在小型集群、私有化環(huán)境下非常有優(yōu)勢。
• Red Hat OpenShift：商業(yè)化的編排服務，適合成熟的大型企業(yè)。
• Apache Mesos + Marathon：早期的分布式集群管理工具和應用容器管理編排框架。

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

微服務編排

微服務編排往往說的是微服務之間的調(diào)用方式，以及如何給客戶端提供友好的 API。

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

• 編排（orchestration）：由 BFF 或稱應用網(wǎng)關(guān)，調(diào)用后端領(lǐng)域服務，領(lǐng)域服務盡可能少互相調(diào)用。
• 編舞（choreography）：BFF 或 應用網(wǎng)關(guān)盡可能做轉(zhuǎn)發(fā)，后端領(lǐng)域服務之間自行相互調(diào)用。

流程編排

流程編排往往和工作流引擎有關(guān)。

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

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

在 IT 系統(tǒng)中，流程引擎往往適用于下面這兩種場景：

• 跨應用編排邏輯和能力。例如，企業(yè) CRM 下了采購單后需要觸發(fā)供應鏈相關(guān)的活動啟動。當然，調(diào)用供應鏈的活動可以由 CRM 程序發(fā)起，但是由專門的工作流平臺管理會變得更靈活和彈性。
• 需要邏輯控制和審核控制的場景。在企業(yè)應用中，審批流是一個使用非常廣泛的工作流。

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

圖片

參與到流程體系中的組件需要遵守一套規(guī)范，這樣就可以流程互通。發(fā)展到現(xiàn)在，流程引擎的主流規(guī)范是 BPMN2.0。

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

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

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

規(guī)則編排

規(guī)則編排和流程編排則顯得不一樣，規(guī)則引擎往往用管理業(yè)務規(guī)則，基于預定義的規(guī)則，當有業(yè)務輸入時，根據(jù)輸入獲得不同的結(jié)果或者觸發(fā)不同的行為。

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

通過規(guī)則引擎可以讓用戶也能在一定范圍進行配置，對業(yè)務結(jié)果和行為進行干預。

圖片

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

和 BPMN 標準類似，在規(guī)則引擎領(lǐng)域也有一個 DMN 規(guī)范，即 Decision Model and Notation。從名字上就能清晰地區(qū)分 BPMN 和 DMN 的關(guān)系。

Drools 完整支持 DMN 在很多業(yè)務規(guī)則，對于業(yè)務規(guī)則復雜的場景是一個非常不錯的選擇。快速了解 DMN 可以參考：learn-dmn-in-15-minutes.com。

總結(jié)

應用編排和微服務編排為大多數(shù)人熟悉，但是對于流程引擎和規(guī)則引擎來說，了解的人可能不是很多。

實際上一些系統(tǒng)大量在使用流程引擎和規(guī)則引擎，通過剝離流程和規(guī)則，對于復雜應用系統(tǒng)來說大大增強其靈活性，這一點對架構(gòu)師非常有幫助。

參考資料

• https://www.xenonstack.com/insights/application-orchestration-tools
• https://medium.com/trueengineering/a-review-of-microservice-orchestration-frameworks-d22797b34ea5
• https://github.com/dromara/liteflow
• https://drools.org/
• https://airflow.apache.org
• https://www.puppet.com/docs/puppet/6/puppet_overview.html
• https://www.architect.io/blog/2022-06-30/microservices-orchestration-primer/
• https://xie.infoq.cn/article/201c0ac6772e07f81c31cbe07
• https://learn-dmn-in-15-minutes.com/learn/introduction