事件驱动型工作流 vs 引擎型工作流

事件驱动型

此工作流实际上产生于事件驱动软件架构，

将软件系统切分为若干独立运行的子系统（进程），

每个子系统同时具有发送和接受事件消息的能力。

工作流定义依赖各个子系统发送和接受事件的定义， 分散在各个子系统中。

 

对于工作流管理流管理

优点：

松散耦合，扩展性好。

缺点：

工作流的总体拓扑没有总体控制组件，不便于管理。

 

http://www.ruanyifeng.com/blog/2016/09/software-architecture.html

对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

优点

• 分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好
• 适用性广，各种类型的项目都可以用
• 性能较好，因为事件的异步本质，软件不易产生堵塞
• 事件处理器可以独立地加载和卸载，容易部署

缺点

• 涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂
• 难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚
• 分布式和异步特性导致这个架构较难测试

 

引擎型工作流

工作流引擎，将工作流的拓扑集中管理，监控。可以解决事件型工作流的缺点。

 

https://en.wikipedia.org/wiki/Workflow_engine

A workflow engine is a software application that manages business processes. It is a key component in workflow technology and typically makes use of a database server.

A workflow engine manages and monitors the state of activities in a workflow, such as the processing and approval of a loan application form, and determines which new activity to transition to according to defined processes (workflows).^[1] The actions may be anything from saving an application form in a document management system to sending a reminder e-mail to users or escalating overdue items to management. A workflow engine facilitates the flow of information, tasks, and events. Workflow engines may also be referred to as Workflow Orchestration Engines.^[2]

 

https://towardsdatascience.com/scaling-apache-airflow-for-machine-learning-workflows-f2446257e495

 

 

Scaling Apache Airflow with Executors

Apache Airflow has a multi-node architecture based on a scheduler, worker nodes, a metadata database, a web server and a queue service.

 

Example Airflow architecture.

One of the first choices when using Airflow is the type of executor. The executor communicates with the scheduler to allocate resources for each task as they’re queued. The difference between executors comes down to the resources they’ve available.

 

分布式事务

https://microservices.io/patterns/data/saga.html

https://learn.microsoft.com/en-us/azure/architecture/patterns/saga

Saga implementation approaches

The two typical saga implementation approaches are choreography and orchestration. Each approach has its own set of challenges and technologies to coordinate the workflow.

Choreography

In the choreography approach, services exchange events without a centralized controller. With choreography, each local transaction publishes domain events that trigger local transactions in other services.

 

Benefits of choreography	Drawbacks of choreography
Good for simple workflows that have few services and don't need a coordination logic.	Workflow can be confusing when you add new steps. It's difficult to track which commands each saga participant responds to.
No other service is required for coordination.	There's a risk of cyclic dependency between saga participants because they have to consume each other's commands.
Doesn't introduce a single point of failure because the responsibilities are distributed across the saga participants.	Integration testing is difficult because all services must run to simulate a transaction.

Orchestration

In orchestration, a centralized controller, or orchestrator, handles all the transactions and tells the participants which operation to perform based on events. The orchestrator performs saga requests, stores and interprets the states of each task, and handles failure recovery by using compensating transactions.

 

Benefits of orchestration	Drawbacks of orchestration
Better suited for complex workflows or when you add new services.	Other design complexity requires an implementation of a coordination logic.
Avoids cyclic dependencies because the orchestrator manages the flow.	Introduces a point of failure because the orchestrator manages the complete workflow.
Clear separation of responsibilities simplifies service logic.

 

在分布式系统（如微服务架构）中，Saga 模式主要用于解决跨服务的长事务一致性问题。其核心思想是将长事务拆分为一系列连续的本地事务，若某一步骤失败，则通过执行补偿事务来撤销已完成的操作，从而保证数据的最终一致性。

目前，Saga 模式的实现方式主要分为以下两种：

1. 编排式（Orchestration）

在这种模式下，会引入一个中心化的协调器（Orchestrator）。协调器负责统一定义流程顺序，依次向各个参与者（微服务）发送指令执行本地事务，并监听执行结果。如果流程中发生失败，协调器会按反向顺序触发补偿事务。

• 优点：流程逻辑集中，职责分离，易于维护和监控；能够有效避免服务之间的循环依赖，非常适合复杂的业务流程。
• 缺点：协调器存在单点故障风险，需要对其进行高可用设计。
• 常见框架：Apache Seata（基于状态机引擎实现）、MassTransit Courier 等。

2. 协同式 / 编舞式（Choreography）

在这种模式下，没有中心化的协调器。各个服务之间通过消息队列或事件驱动机制相互通信。每个服务在完成本地事务后，会发布一个事件来触发下一个服务；如果失败，则发布补偿事件通知前置服务进行回滚。

• 优点：去中心化设计，无单点故障风险；服务之间高度解耦，适用于参与者较少、逻辑简单的场景。
• 缺点：流程逻辑分散在各个服务中，难以进行全局追踪和调试；随着服务增多，容易出现循环依赖的问题。

在实际的工程落地中，Saga 模式需要重点解决幂等性（防止网络重试导致数据异常）、补偿事务设计（精准撤销正向事务的影响）以及状态管理等关键问题。开发团队通常会根据业务流程的复杂度和参与者的数量，灵活选择或混合使用这两种策略。

---

你当前在用的微服务架构是哪种技术栈？我可以帮你推荐更合适的实现框架和落地方案。