描述你参与的一个教育类项目中的技术选型过程，比如从单体架构迁移到微服务架构。请说明遇到的挑战（如服务拆分、跨服务通信、数据一致性）及解决方案。
答案
1) 【一句话结论】在参与的教育类项目（假设为“智慧校园选课系统”）中，从单体架构迁移到微服务架构的核心是通过业务能力拆分服务、采用分布式数据库分库分表、gRPC优化通信、Saga模式保障数据一致性，解决了单体扩展性差的问题，最终实现服务独立扩容与系统弹性提升。
2) 【原理/概念讲解】老师口吻解释：单体架构是将用户管理、课程管理、选课等模块打包成一个应用，像“一个整体蛋糕”，部署、扩展时需整体调整，初期开发效率高但扩展性差。微服务架构则是将系统拆分为独立服务（如用户服务、课程服务、选课服务），每个服务负责单一业务能力，服务间通过API通信，像“多个独立小蛋糕”，每个小蛋糕可独立部署、扩展，但通过盘子（服务间通信）协作。关键点包括服务独立部署、技术异构（如用户服务用Java，选课服务用Go）。
3) 【对比与适用场景】
| 特性 | 单体架构 | 微服务架构 |
|---|---|---|
| 定义 | 所有功能模块部署在单一应用中 | 系统拆分为多个独立服务，每个服务负责单一业务能力 |
| 特性 | 部署简单，初期开发效率高（模块内逻辑集中） | 部署复杂，初期开发效率低（需管理多个服务） |
| 使用场景 | 小型系统（用户<1000）、业务简单 | 中大型系统（用户>1000）、业务复杂、需要高扩展性 |
| 注意点 | 扩展性差（整体扩展），维护复杂 | 服务拆分粒度难（过度拆分导致通信成本高），数据一致性难 |
4) 【示例】
假设项目是“智慧校园选课系统”，单体架构时，用户注册、课程信息、选课流程都在一个Java应用中。迁移时，拆分为：
- 用户服务（处理用户注册、登录，数据库分库分表：用户表按ID哈希到3个数据库实例，用ShardingSphere管理）
- 课程服务（管理课程信息，数据库分库分表：课程表按课程ID范围分片）
- 选课服务（处理选课流程，调用用户服务校验用户、课程服务扣减库存，数据一致性用Saga模式）
服务间通信：用户服务调用选课服务时用gRPC（配置示例：grpc-transport-http2开启HTTP/2，grpc-compress-gzip启用头部压缩）。
Saga模式补偿流程（伪代码）：
// 选课流程：用户服务创建订单 → 课程服务扣减库存 → 支付成功则更新订单状态
// 补偿事务：支付失败则回滚库存
if (paymentFailed) {
// 发送补偿消息回滚库存
sendCompensationMessage(courseId, inventory, originalInventory)
}
5) 【面试口播版答案】（约90秒）：“我参与过一个教育类项目，从单体架构迁移到微服务架构。核心是通过业务能力拆分服务，比如用户、课程、选课拆分为独立服务。遇到的主要挑战是服务拆分粒度（比如选课逻辑是否单独服务）和跨服务通信（REST延迟），还有数据一致性（选课扣库存失败后库存未回滚）。解决方案是：服务拆分遵循单一职责，用领域驱动设计划分边界；跨服务通信采用gRPC（基于HTTP/2，支持头部压缩，比REST高效）；数据一致性用Saga模式，通过消息队列异步通知，支付失败时回滚库存。迁移后，用户服务可独立扩容，响应时间从500ms减少到150ms，系统弹性提升。”
6) 【追问清单】
- 问：服务拆分时如何确定粒度？比如选课逻辑是否应该单独服务？
回答要点：遵循单一职责，按业务能力拆分，比如选课属于用户服务或单独选课服务，避免服务过大导致通信成本高。 - 问：gRPC选型时，为什么选择它而不是REST？具体的技术优势是什么？
回答要点：gRPC基于HTTP/2，支持双向流、头部压缩，比REST的HTTP请求/响应更高效，适合高并发场景，减少通信延迟。 - 问：数据迁移时，用户表如何从单体数据库拆分到分布式数据库？具体策略是什么？
回答要点：采用分库分表策略，按用户ID哈希拆分到不同数据库实例，用ShardingSphere中间件管理，确保数据一致性。 - 问：Saga模式如何处理补偿事务？比如支付失败后如何回滚库存？
回答要点：Saga通过消息队列异步通知，每个步骤完成后发送确认消息，若某步骤失败，发送补偿消息回滚前序步骤，保证最终一致性。 - 问：迁移后系统的具体性能数据有哪些？比如用户服务独立扩容后的响应时间变化？
回答要点：用户服务独立扩容后，响应时间从500ms减少到150ms，系统弹性提升，用户反馈选课流程更流畅。
7) 【常见坑/雷区】
- 坑1：过度拆分服务，导致服务间通信成本过高（比如每个请求调用多个服务，延迟增加）。避免：服务粒度不宜过细，按业务能力合理拆分，比如核心业务服务拆分，辅助服务合并。
- 坑2：忽略数据一致性，导致业务逻辑错误（比如选课扣库存失败后，库存未回滚）。避免：采用Saga、最终一致性或分布式事务方案（如两阶段提交，但成本高），根据业务场景选择。
- 坑3：服务治理缺失，导致服务不可用（如注册中心故障，服务无法发现）。避免：部署服务注册中心（如Nacos），配置负载均衡，监控服务状态。
- 坑4：技术选型不匹配，比如用REST处理高并发场景。避免：根据场景选择通信协议（高并发用gRPC，低并发用REST）。
- 坑5：缺乏服务版本管理，导致升级时影响其他服务。避免：采用API网关或服务路由，支持版本兼容，逐步升级服务。