第4章 分布式系统设计与微服务架构

🎯 考察点： 领域驱动设计（DDD）实践能力、业务抽象思维、对高内聚低耦合的理解。

📋 回答框架： 先强调“业务领域驱动”，推荐使用DDD限界上下文划分 → 举例用户、订单、支付三个服务 → 附带数据独立性原则（每个服务拥有自己的数据库） → 补充拆分后如何通过API网关对外暴露。

🔍 简短示例回答： “我采用DDD限界上下文来划分服务边界。例如电商项目中，将订单与支付拆分，因为两者变更频率不同且业务语义独立。每个服务拥有独立数据库，通过gRPC通信，确保高内聚低耦合。同时引入API网关统一入口，减少客户端耦合。”

❓ 可能追问： 如果业务边界模糊怎么办？拆分后如何保证数据一致性？

🎯 考察点： 对主流RPC（gRPC/Thrift/Dubbo）和注册中心（Nacos/Consul/Eureka）原理的掌握、生产环境选型权衡。

📋 回答框架： 对比序列化效率（Protobuf vs JSON） → 语言生态（Python优先选gRPC） → 注册中心对比CP/AP模型（Consul偏CP，Nacos可切换） → 实践经验：健康检查机制、客户端缓存降级。

🔍 简短示例回答： “我选择gRPC作为RPC，因为Protobuf序列化性能高且跨语言。注册中心选用Nacos，因为它支持CP/AP模式切换，满足不同场景需求。曾遇到注册中心网络分区导致服务列表不一致，最终采用短连接健康检查+本地缓存降级解决。”

❓ 可能追问： gRPC连接池如何管理？注册中心挂了如何处理？

🎯 考察点： 分布式事务理论（CAP/BASE）、实际方案选型（2PC/TCC/Saga/消息表）、异常处理经验。

📋 回答框架： 先分析业务场景（强一致性 vs 最终一致性） → 举例TCC（预留→确认/取消）或异步消息（可靠消息+本地事件表） → 强调幂等性设计和补偿机制 → 结合Seata或自研实现。

🔍 简短示例回答： “在订单支付场景，我们采用TCC模式。Try阶段冻结库存和账户资金，Confirm阶段实际扣减，Cancel阶段回滚。使用Seata AT模式减少侵入性。另外对消息型事务，使用本地消息表+定时轮询确保最终一致性，配合对账系统兜底。”

❓ 可能追问： TCC空回滚如何处理？事务日志清理策略？