Ambassador模式与Orchestrator（编排器）服务的核心差异

这两个模式本质上解决的是完全不同领域的问题，看似相似的“服务间交互”只是表象，核心差异体现在以下几个维度：

核心定位与解决问题 #

• Ambassador模式：属于服务辅助/代理模式，核心目标是剥离单应用的非核心通信能力，降低主应用复杂度。比如把重试、熔断、服务发现、日志监控这些和业务无关的通信逻辑，从主应用中抽离到一个与主应用共存的代理服务中。
• Saga编排器模式：属于分布式事务协调模式，核心目标是解决跨服务的事务一致性问题。当业务流程需要多个独立服务协作完成（比如下单→扣库存→支付），无法用传统ACID事务时，通过编排器协调各个服务的本地事务，失败时执行补偿操作保证最终一致性。

部署与运行形态 #

• Ambassador：与宿主应用同部署单元（比如作为sidecar容器和主应用容器一起部署，或同进程内的代理），对主应用完全透明。主应用通过本地调用（比如localhost端口）使用Ambassador的能力，不需要感知外部服务的存在。
• Saga编排器：是独立的中心化服务（或嵌入在核心业务服务中，但本质是跨服务协调），和各个业务服务分离部署。它需要全局感知整个事务流程的状态，负责触发各个服务的操作或补偿动作。

职责范围 #

• Ambassador：只关注通信层的技术细节，不涉及任何业务逻辑。比如处理请求的超时、重试、负载均衡、TLS加密等，是主应用和外部服务之间的“通信代理人”。
• Saga编排器：需要深度理解业务流程的逻辑，负责编排整个事务的步骤顺序，以及失败时的补偿逻辑。比如知道下单成功后必须扣库存，支付失败时要回滚库存和订单状态，是业务流程的“指挥者”。

交互方式 #

• Ambassador：主应用与Ambassador是同步调用关系。主应用发起请求给Ambassador，Ambassador转发请求到外部服务，再把结果返回给主应用，整个过程对主应用来说和直接调用外部服务无异，只是多了一层代理。
• Saga编排器：通常是异步或半异步协调。要么是各个服务完成本地事务后发送事件，编排器监听事件触发下一步；要么是编排器主动调用各个服务的接口，根据返回结果决定继续执行还是触发补偿。

实际场景示例 #

• Ambassador场景：一个Python应用需要调用第三方支付API，把重试、超时、请求日志这些逻辑放到Ambassador sidecar中。Python应用只需要调用localhost:9000/pay，Ambassador会自动处理和第三方API的通信细节，失败时自动重试3次。
• Saga编排器场景：电商下单流程，编排器执行以下步骤：
  1. 调用订单服务创建订单（本地事务）
  2. 订单创建成功后，调用库存服务扣减库存（本地事务）
  3. 库存扣减成功后，调用支付服务完成支付（本地事务）
  4. 如果支付失败，编排器依次调用库存服务加回库存、订单服务取消订单，完成补偿。

内容的提问来源于stack exchange，提问作者sy-huss