面试题：微服务架构下熔断与降级对分布式事务及系统一致性的影响及应对

Question

在存在熔断与降级的微服务架构中，分布式事务的执行可能会受到影响，进而影响系统的一致性。请分析熔断与降级操作是如何干扰分布式事务流程以及系统一致性的，并提出有效的应对方案，包括但不限于使用何种一致性协议、如何进行补偿操作等。

Answer 1

熔断与降级对分布式事务流程及系统一致性的干扰分析

1. 熔断干扰
   • 事务中断：当某个微服务熔断时，依赖该服务的分布式事务操作会被立即中断。例如，在一个电商下单的分布式事务中，订单服务依赖库存服务，如果库存服务熔断，订单服务无法完成库存扣减操作，导致整个下单事务无法正常推进。
   • 数据不一致风险：由于熔断，部分已完成的事务分支可能无法回滚。假设订单已创建成功，但库存扣减因熔断未执行，就会出现订单存在但库存未减少的不一致情况。
2. 降级干扰
   • 简化业务逻辑：降级操作可能简化了某些微服务的业务逻辑，以保证系统基本可用。例如，在支付微服务降级时，可能只记录支付请求而不真正进行支付处理。这会导致分布式事务中的支付环节与预期不符，影响整个事务的完整性和系统一致性。
   • 补偿困难：降级后的简化操作可能使得后续的补偿操作难以实施。因为降级后的状态与正常业务流程下的状态不同，按照常规补偿逻辑可能无法恢复到事务开始前的状态。

应对方案

1. 一致性协议
   • 使用TCC（Try - Confirm - Cancel）协议：
     • Try阶段：各个微服务尝试预留资源，比如订单服务尝试锁定库存资源，而不是直接扣减库存。这样在熔断或降级发生时，不会真正修改资源状态，避免数据不一致。
     • Confirm阶段：当所有微服务的Try阶段都成功后，再正式提交事务，执行真正的资源修改操作，如订单服务确认扣减库存。
     • Cancel阶段：如果在Try阶段或Confirm阶段有任何服务失败（包括熔断或降级导致的失败），则调用Cancel操作回滚之前Try阶段预留的资源。
   • 引入Saga模式：
     • 将一个长事务分解为多个本地短事务。每个微服务执行本地事务，并记录操作日志。例如，在电商系统中，订单创建、库存扣减、支付等都作为独立的本地事务。
     • 当出现熔断或降级导致某个事务失败时，根据日志按照相反顺序执行补偿事务。如订单创建成功但库存扣减因熔断失败，就执行订单取消的补偿事务。
2. 补偿操作
   • 基于消息队列的补偿：在分布式事务执行过程中，将每个事务操作记录发送到消息队列。如果出现熔断或降级导致事务失败，通过消息队列重新触发相关操作或补偿操作。例如，库存扣减因熔断失败，消息队列可以重新发送库存扣减消息，待库存服务恢复正常后再次尝试。
   • 人工介入补偿：对于一些复杂且无法自动处理的情况，提供人工介入的接口。管理员可以根据系统记录的事务状态，手动执行补偿操作，确保系统一致性。比如在支付降级后，人工核对支付记录并手动处理支付确认等操作。