假设投放系统从单体架构迁移到微服务架构，如何设计服务拆分、API网关、服务治理，以及如何处理数据一致性（如订单与支付的一致性）？

1) 【一句话结论】
服务拆分遵循业务能力边界，通过API网关实现统一入口与路由，服务治理保障服务间通信稳定，数据一致性结合业务场景采用最终一致性（如补偿机制）或强一致性（如分布式事务），确保订单与支付状态同步。

2) 【原理/概念讲解】
老师口吻，解释核心概念：

• 服务拆分：微服务架构下，将单体应用按业务能力拆分为独立服务（如投放系统拆为“订单服务”“支付服务”“用户服务”“广告服务”）。类比：大型超市拆为“生鲜部”“家电部”“收银部”，每个部门独立运营但协同完成购物流程，避免单体中“一个服务做太多事”的问题。
• API网关：作为系统入口，负责请求路由（如请求/api/order/...转发到订单服务）、认证授权（验证用户token）、限流熔断（防止服务过载）、协议转换（如HTTP转gRPC）。类比：超市“总接待处”，所有顾客先到接待处，接待处根据需求引导到对应部门，同时检查会员卡有效性（认证）。
• 服务治理：保障服务间通信的稳定性，包含服务注册发现（服务启动时注册到注册中心，调用时从注册中心获取地址）、熔断降级（服务故障时快速失败，避免级联）、负载均衡（多个实例分发请求）。类比：超市各部门的协调机制，如生鲜部与收银部通过“订单传递单”协同，当生鲜部忙不过来时，收银部可暂时不接收新订单（熔断）。
• 数据一致性：确保订单与支付的状态同步（如“订单已创建但支付未到账”或“支付成功但订单未确认”的情况）。方案包括：最终一致性（如订单服务先创建订单，通过消息队列通知支付服务扣款，支付成功则更新订单状态，失败则补偿取消订单，适合高并发场景）；强一致性（如使用分布式事务确保原子执行，适合对一致性要求极高的场景）。

3) 【对比与适用场景】

对比维度	定义/特性	使用场景	注意点
服务拆分策略	- 领域驱动：按业务领域拆分（如订单、支付属于“交易领域”），服务边界与业务领域强关联，逻辑清晰。<br>- 数据驱动：按数据模型拆分（如订单表、支付表属于不同服务），服务与数据表强绑定，数据访问高效。<br>- 按业务流程拆分：按业务流程拆分（如下单、支付、发货属于不同服务），服务与业务流程强关联，流程逻辑清晰。	- 领域驱动：业务复杂度高、领域边界明确的系统（如金融、电商）。<br>- 数据驱动：数据模型复杂、需独立管理不同数据集的场景。<br>- 按业务流程拆分：业务流程清晰、步骤明确的场景（如电商“下单-支付-发货”流程）。	- 避免拆分过细（如逻辑简单服务拆分导致调用链过长）；避免拆分过粗（如服务职责模糊）。
数据一致性方案	- 最终一致性：通过异步消息、补偿机制保证数据最终同步，系统扩展性好，性能高。<br>- 强一致性：通过分布式事务（如Seata）保证数据原子执行，数据一致性高，但性能受限于事务开销。	- 最终一致性：对实时性要求不高、高并发场景（如订单状态最终同步，允许短暂不一致）。<br>- 强一致性：对数据一致性要求极高（如金融支付，不允许不一致）。	- 最终一致性需设计补偿机制（如支付失败时取消订单）；强一致性需权衡性能与一致性。

4) 【示例】

• 服务拆分示例：投放系统拆分为“投放订单服务”（处理投放订单创建、状态管理）、“支付服务”（处理投放订单的支付扣款）、“用户服务”（用户信息与权限管理）、“广告服务”（广告资源管理）。
• API网关示例：客户端请求/api/dsp/order/create时，API网关验证请求头中的token（用户认证），检查用户权限（是否允许创建投放订单），然后路由到“投放订单服务”的createOrder接口，并将响应返回给客户端。
• 数据一致性示例：订单服务创建投放订单后，通过消息队列（如Kafka）发送“订单创建”消息到支付服务；支付服务收到消息后，执行扣款操作，若扣款成功则发送“支付成功”消息到订单服务，订单服务更新订单状态为“已支付”；若扣款失败，则发送“支付失败”消息到订单服务，订单服务补偿取消订单（删除订单并通知用户）。

5) 【面试口播版答案】
“面试官您好，关于从单体架构迁移到微服务架构的设计，核心思路是按业务能力拆分服务，通过API网关统一入口，服务治理保障通信稳定，数据一致性结合业务场景选择方案。首先服务拆分，我会按业务领域拆分，比如投放系统拆成订单服务、支付服务、用户服务、广告服务，每个服务负责独立业务逻辑，避免单体中“一个服务做太多事”的问题。然后API网关，作为系统入口，负责请求路由（比如请求/api/order/...转发到订单服务）、认证授权（验证用户token）、限流熔断（防止服务过载），相当于系统的‘总接待处’。接着服务治理，用服务注册发现（服务启动时注册到注册中心，调用时从注册中心获取地址）、熔断降级（服务故障时快速失败，避免级联）、负载均衡（多个实例分发请求），保障服务间通信稳定。最后数据一致性，比如订单与支付的一致性，我会采用最终一致性方案：订单服务先创建订单，通过消息队列通知支付服务扣款，支付成功则更新订单状态，失败则补偿取消订单，这样既保证高并发性能，又确保最终数据一致。总结来说，服务拆分要遵循业务边界，API网关负责统一入口与治理，服务治理保障通信，数据一致性结合业务场景选择方案，确保系统稳定与数据正确。”

6) 【追问清单】

• 问题1：服务拆分的粒度如何确定？
  回答要点：根据业务复杂度、团队规模、调用频率，避免拆分过细（如逻辑简单服务拆分导致调用链过长）或过粗（如服务职责模糊）。
• 问题2：API网关的负载均衡策略如何选择？
  回答要点：根据服务实例数量和负载，常用策略有轮询（简单均衡）、加权轮询（性能加权）、随机（随机选择）、一致性哈希（会话保持）。
• 问题3：数据一致性的方案中，最终一致性和强一致性的权衡？
  回答要点：最终一致性适合高并发、对实时性要求不高的场景（如订单状态最终同步，允许短暂不一致）；强一致性适合对一致性要求极高的场景（如金融支付），但需权衡性能。
• 问题4：服务治理中的服务注册发现如何实现？
  回答要点：通过注册中心（如Nacos、Eureka），服务启动时注册自身地址和端口，调用时从注册中心获取服务列表。
• 问题5：如何处理服务间的调用超时问题？
  回答要点：设置合理超时时间（如3秒），超时后返回错误，配合熔断降级防止级联故障。

7) 【常见坑/雷区】

• 坑1：服务拆分过细导致调用链过长，影响性能。
  雷区：将逻辑简单的服务拆分（如“订单服务”拆成“下单”“支付”子服务，但逻辑简单，合并后调用次数减少）。
• 坑2：API网关的认证授权配置错误，导致安全漏洞。
  雷区：未有效验证请求头（如token过期、权限不足），导致未授权用户访问敏感接口。
• 坑3：数据一致性方案选择不当，导致业务问题。
  雷区：对实时性要求高的场景（如支付成功后立即返回用户），选择最终一致性，导致用户看到“支付成功”但实际未扣款。
• 坑4：服务治理中的熔断降级配置不合理，导致服务可用性下降。
  雷区：熔断阈值过低（如10次失败就熔断，误判正常服务）或过高（如100次失败才熔断，故障服务长时间影响其他服务）。
• 坑5：忽略灰度发布，直接全量上线微服务，导致系统不稳定。
  雷区：未分阶段上线新服务或新版本，全量上线后出现未知问题，影响用户体验。