面试题：Node.js微服务架构的故障容错与分布式事务处理

Question

当Node.js微服务架构中某个服务出现故障时，如何设计有效的容错机制，确保整个系统的可用性？同时，在涉及多个微服务的业务操作中，如何实现分布式事务处理，保证数据的一致性，谈谈你的设计思路和可能用到的技术。

Answer 1

容错机制设计思路

1. 服务熔断
   • 当某个微服务调用失败次数达到一定阈值时，触发熔断机制。例如，使用Hystrix库，它可以统计服务调用的失败率、错误数等指标。当失败率超过预设值（如50%）且在一定时间窗口（如10秒）内调用次数达到一定数量（如20次），就会熔断该服务调用，后续请求不再实际调用该故障服务，而是直接返回一个预设的fallback响应，避免大量无效请求堆积，影响系统整体性能。
2. 服务降级
   • 当系统资源紧张或某个微服务出现故障时，对非核心业务功能进行降级处理。比如，在电商系统中，商品详情页的一些非关键信息（如商品的历史销量图表等）依赖的微服务出现故障，可以暂时不显示这些信息，优先保证核心商品信息展示、下单等功能正常运行。可以通过配置中心来动态调整降级策略，根据不同的故障情况和业务场景，决定哪些服务或功能进行降级。
3. 服务重试
   • 对于一些临时性的故障（如网络抖动导致的服务调用失败），可以设置重试机制。在Node.js中，可以使用async - retry库。在调用微服务失败后，按照一定的策略（如固定时间间隔重试，或指数退避重试，即每次重试间隔时间逐渐增大）进行重试。例如，第一次重试间隔1秒，第二次间隔2秒，第三次间隔4秒等，最多重试3次，避免无限重试占用过多资源。同时，要根据具体业务场景和故障类型判断是否适合重试，对于一些幂等性操作（如查询操作）适合重试，而对于非幂等性操作（如创建订单）则需要谨慎处理重试逻辑。
4. 负载均衡与健康检查
   • 使用负载均衡器（如Nginx、HAProxy等）将请求均匀分配到多个微服务实例上。同时，负载均衡器定期对后端微服务进行健康检查，例如通过发送心跳请求或简单的健康检查接口调用，若某个实例连续多次健康检查失败，则标记为不健康，不再将新的请求发送到该实例，直到它恢复健康。在Node.js中，可以结合Cluster模块实现多进程负载均衡，同时使用第三方健康检查中间件（如express - health - checker用于Express框架的微服务）来增强健康检查功能。

分布式事务处理设计思路及技术

1. 两阶段提交（2PC）
   • 协调者与参与者：引入一个协调者（可以是独立的服务或某个微服务兼任）和多个参与者（各个涉及的微服务）。
   • 第一阶段（准备阶段）：协调者向所有参与者发送事务预提交请求，参与者检查自身资源是否满足事务要求，若满足则锁定资源并向协调者返回“准备就绪”响应，否则返回“失败”响应。
   • 第二阶段（提交/回滚阶段）：如果协调者收到所有参与者的“准备就绪”响应，就向所有参与者发送提交请求，参与者执行事务提交操作；若有任何一个参与者返回“失败”响应，协调者向所有参与者发送回滚请求，参与者回滚事务。在Node.js中，可以通过自定义消息队列（如使用RabbitMQ作为消息中间件）来实现协调者与参与者之间的消息传递和事务状态跟踪。
2. 三阶段提交（3PC）
   • 引入预询问阶段：在2PC的基础上增加一个预询问阶段。协调者先向参与者发送预询问请求，参与者检查自身资源和状态，判断是否可以执行事务，然后向协调者返回响应。如果所有参与者都返回可以执行事务的响应，进入准备阶段，后续流程与2PC类似。3PC解决了2PC中协调者单点故障导致的阻塞问题，因为在预询问阶段，参与者就对自身状态进行了检查和确认，减少了协调者故障后参与者不确定事务状态的情况。
3. TCC（Try - Confirm - Cancel）模式
   • Try阶段：各个微服务尝试执行业务操作，对资源进行预留（如冻结账户金额等），但不真正提交事务。
   • Confirm阶段：如果所有微服务的Try阶段都成功，那么依次调用各个微服务的Confirm操作，完成资源的真正提交（如解冻账户金额并完成支付）。
   • Cancel阶段：如果任何一个微服务的Try阶段失败，就依次调用各个微服务的Cancel操作，释放预留的资源（如解冻被冻结的账户金额）。在Node.js中，可以通过在每个微服务中实现Try、Confirm和Cancel接口方法，然后通过分布式事务框架（如Seata等，Seata支持TCC模式，虽然Seata更多基于Java，但也有一些Node.js社区在探索相关适配）来协调各个微服务之间的事务流程。
4. 本地消息表
   • 消息表设计：每个微服务维护一个本地消息表，当业务操作发生时，先将事务相关消息写入本地消息表，并标记为“待发送”状态。
   • 消息发送与处理：通过定时任务或异步线程不断扫描本地消息表，将“待发送”状态的消息发送到消息队列（如Kafka、RabbitMQ等）。其他微服务从消息队列消费消息，并根据消息执行相应的业务操作。如果消息处理成功，更新本地消息表的消息状态为“已处理”；如果处理失败，根据具体情况进行重试或回滚操作。在Node.js中，可以使用MySQL、PostgreSQL等数据库来实现本地消息表，结合Node.js的数据库操作库（如mysql2、pg等）以及消息队列客户端库（如amqplib for RabbitMQ，kafka - node for Kafka）来完成整个流程。