1. Nacos、Sentinel、Seata 与 RocketMQ 组合使用时，配置、注册和事务故障应由哪些独立降级策略处理
问题
当 Nacos、Sentinel、Seata 与 RocketMQ 这四个中间件组合使用时，配置中心故障、注册中心故障和事务协调器故障分别应当由哪些相互独立的降级策略来处理？
考察点
- 各中间件故障时对业务的影响面与降级手段
- 配置中心、注册中心、事务协调器各自的"降级语义"差异
- 降级策略设计时的独立性原则（避免耦合失效）
答案
四个组件职责不同，降级策略必须相互独立。Nacos（配置+注册）故障时，配置侧可利用客户端本地快照与进程内缓存继续服务，注册侧放弃动态推送、依赖本地缓存的上次实例列表；Sentinel 故障时降级为本地规则的默认兜底（如最宽松或最严格流控），确保不给系统带来额外依赖点；Seata 事务协调器故障时，@GlobalTransactional 应降级为本地事务提交并记录告警，避免全局事务悬挂导致数据不一致；RocketMQ 故障时应切换为本地消息表或同步调用兜底，保证消息不丢。降级策略之间不能互相依赖，例如配置中心故障不应阻止注册中心降级，事务降级不应等待消息降级，否则局部故障会演变成级联故障。
解析
设计原则是"故障隔离、局部降级、可观测"。每个中间件都在客户端维护快照或降级开关，故障时只影响该组件能力，其他组件照常工作。这也是分布式系统"组件自治"思想的体现。
示例代码
@Configuration
public class DegradePolicyConfig {
@Bean
public SeataFailureHandler seataFailureHandler() {
// Seata 故障时降级为本地事务，并记录告警
return () -> {
log.warn("Seata TC 不可用，降级为本地事务");
return TxResult.LOCAL_COMMIT;
};
}
}