编舞模式与编排模式
对比事件编舞（每个服务独立响应）与编排（由中央协调器指挥服务），并为您的架构选择合适的模式
编舞模式与编排模式 是 CoddyKit 上的免费 Cloud & IT Cert Prep 课时。 这是第 4 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Cloud & IT Cert Prep 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Cloud & IT Cert Prep 课程共包含 4 节课。
微服务协调的两种方法
当微服务需要协同完成业务流程时，有两种基本的协调模式。Orchestration 使用一个中央协调器（例如 Step Functions），明确命令各个服务执行操作。Choreography 没有中央协调器，服务监听事件并独立做出响应。理解应使用哪种模式以及何时组合使用它们，是 SAA-C03 考试考查的一项重要架构技能。
Orchestration 模式详解
在 orchestration 中，中央服务（orchestrator）控制操作顺序。它调用服务 A，等待响应，然后调用服务 B，依此类推。orchestrator 可以全面了解流程状态，处理错误和重试，并根据中间结果做出决策。在 AWS 上，Step Functions 是典型的 orchestrator：它将整个工作流定义为状态机，并驱动每个步骤。
# Orchestration: Step Functions state machine drives order processing
# StepFunctions -> ValidateOrder Lambda -> ChargePayment Lambda -> NotifyShipping Lambda
# Each arrow is an explicit command from the orchestrator
# If ChargePayment fails, Step Functions catches the error and routes to NotifyFailure
# The orchestrator (Step Functions) knows the full state of the order at every momentChoreography 模式详解
在 choreography 中，服务通过事件进行通信，而不需要中央协调器。服务 A 完成任务后，会将事件（例如 OrderValidated）发布到事件总线或主题。服务 B 监听 OrderValidated 事件并处理付款，然后发布 PaymentCharged。服务 C 监听 PaymentCharged 并发货。每个服务都是自治且解耦的，只了解自己消费和生成的事件，而不了解其他服务。
# Choreography: EventBridge bus connects services without central coordinator
# OrderService -> publishes 'OrderPlaced' to EventBridge
# PaymentService -> listens for 'OrderPlaced', charges card, publishes 'PaymentCharged'
# ShippingService -> listens for 'PaymentCharged', creates shipment, publishes 'OrderShipped'
# NotificationService -> listens for 'OrderShipped', sends email
# No service calls another service directly — all communication is via events两种模式对应的 AWS 服务
在 AWS 上，Step Functions 是主要的 orchestration 工具。对于 choreography，主要工具包括 Amazon EventBridge（用于在服务之间根据内容筛选路由事件）、Amazon SNS（用于简单的扇出）和Amazon SQS（用于服务之间的点对点消息传递）。您可以混合使用这两种模式：使用 EventBridge 在有界上下文之间实现跨域 choreography，并使用 Step Functions 编排单个域内的步骤。
权衡：可观测性
Orchestration 提供集中式可见性：Step Functions 的执行历史会准确显示工作流当前所处的位置、每个步骤耗时多久以及哪里发生了失败。调试过程较为直接。Choreography 会将可见性分散到多个服务和事件总线中；要跟踪单个业务事务，必须关联多个服务之间的日志和事件。因此，choreography 系统会高度依赖关联 ID和分布式跟踪（AWS X-Ray）来实现端到端可见性。
# Correlation ID pattern for choreography observability
# Every event includes a correlationId that flows through the entire chain
{
'source': 'com.myapp.orders',
'detail-type': 'OrderPlaced',
'detail': {
'orderId': 'ORD-123',
'correlationId': 'CORR-abc-456', # propagated to every downstream event
'customerId': 'CUST-789',
'total': 99.99
}
}权衡：耦合
Choreography 提供更松的耦合：添加一个监听现有事件的新服务时，无需修改现有服务。例如，添加一个监听 OrderPlaced 事件的分析服务，不会对订单或支付服务产生任何影响。Orchestration 会在 orchestrator 与其调用的所有服务之间引入更紧的耦合：添加新步骤需要修改状态机定义，不过各个服务本身仍保持隔离。
权衡：错误处理
Orchestration 使错误处理明确化：Step Functions 的 Catch 块为每种错误类型定义回退状态，整个工作流历史会显示失败上下文。在 choreography 中，错误处理是分散的：每个服务都必须处理自身的失败，并可以选择发布失败事件，供其他服务做出响应。实现 sagas（当某个步骤失败时用于撤销已完成工作的补偿事务）在 choreography 中比在 orchestration 中复杂得多。
# Saga pattern in choreography: compensating events
# Happy path:
# OrderPlaced -> PaymentCharged -> InventoryReserved -> OrderShipped
#
# Failure path (InventoryReservation fails):
# InventoryReservationFailed event published
# PaymentService listens -> issues refund -> publishes PaymentRefunded
# OrderService listens -> cancels order -> publishes OrderCancelled
#
# In orchestration (Step Functions), the compensating logic is in explicit Catch states何时选择 Orchestration
在以下情况下，优先选择 orchestration：业务流程具有清晰的线性或分支顺序，并且有明确的成功或失败结果；您需要集中查看流程状态，以满足运维或合规要求；错误处理涉及复杂的补偿逻辑；或者工作流运行时间较长，必须能够经受服务重启。示例包括订单履行、患者入院流程和保险理赔处理，这些工作流都具有明确的开始、结束和审计要求。
何时选择 Choreography
在以下情况下，优先选择 choreography：服务由不同团队负责，不应进行紧密协调；系统应允许新服务扩展，而无需修改现有服务；事件表示事实而不是命令（例如“OrderShipped”，而不是“ShipOrder”）；或者您希望获得最大的可扩展性，因为系统不存在中央瓶颈。示例包括分析数据摄取、通知扇出和审计记录，这些场景都允许多个独立消费者对同一事件做出响应。
混合架构
大多数现实世界中的 AWS 架构会在不同粒度层级上同时采用这两种模式。一种常见的混合方式是：使用 EventBridge 编舞来解耦限界上下文（例如，Order 域发出事件；Inventory、Payment 和 Shipping 域分别独立响应），而在 Payment 域内部，使用 Step Functions 编排来协调内部支付工作流步骤（扣款、欺诈检查、授权、结算）。这样既能实现域之间的松耦合，又能保持内部流程清晰。
# Hybrid: EventBridge for inter-domain + Step Functions for intra-domain
#
# EventBridge bus (choreography):
# Order domain publishes 'OrderPlaced'
# Payment domain receives it, starts Step Functions execution
#
# Step Functions (orchestration inside Payment domain):
# ValidateCard -> FraudCheck -> AuthorisePayment -> SettlePayment
# On success: PaymentDomain publishes 'PaymentCharged' to EventBridge bus
# On failure: Step Functions Catch -> publishes 'PaymentFailed' eventSAA-C03 考试信号
在考试中，请留意以下信号。编舞关键词：'松耦合'、'服务对事件作出反应'、'团队拥有彼此独立的服务'、'向多个使用者扇出'、'添加新服务而无需修改现有服务'。编排关键词：'按顺序协调步骤'、'跟踪工作流状态'、'通过补偿处理部分失败'、'人工审批步骤'、'带错误处理的长时间运行流程'。如果题目描述了一个由中央协调器指挥其他服务的场景，那一定属于编排。
快速检查
请测试您对本课 AWS Solutions Architect（SAA-C03）概念的理解。
课程回顾
本课您学到了：编排使用中央协调器（Step Functions）来实现明确且可见的工作流控制，编舞使用事件（EventBridge）来实现松耦合和可扩展性，并且大多数生产架构会在不同粒度层级上结合使用这两种模式。接下来，我们将学习 SAA-C03 的考试形式以及基于域权重制定学习策略的方法。
常见问题解答
「编舞模式与编排模式」课时是免费的吗？
是的 — 「编舞模式与编排模式」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Cloud & IT Cert Prep 课程的其余内容，请升级到 CoddyKit PRO。 Cloud & IT Cert Prep 课程共包含 4 节课。
「编舞模式与编排模式」这节课中我会学到什么？
对比事件编舞（每个服务独立响应）与编排（由中央协调器指挥服务），并为您的架构选择合适的模式 你通过在浏览器中直接运行的动手代码来练习 Cloud & IT Cert Prep，全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Cloud & IT Cert Prep 需要有经验吗？
无需任何先前经验。CoddyKit 上的 Cloud & IT Cert Prep 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 4 节课，共 4 节。
「编舞模式与编排模式」课时需要多长时间？
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。
我能在这节 Cloud & IT Cert Prep 课中编写并运行代码吗？
能。每节 Cloud & IT Cert Prep 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。