一、微服务基础概念（大白话）
- 什么是微服务？和单体应用有什么区别？
- 单体应用：把整个系统（用户、订单、商品、支付……）全写在一个项目里，打成一个包（war/jar），部署在同一台服务器上。 问题：改一行代码要重新部署整个系统；一个模块挂了全部玩完；团队互相牵制，难以扩展。
- 微服务：按业务功能拆成多个独立的小项目。比如用户服务、订单服务、商品服务，每个服务有自己的数据库、独立部署、独立开发。 好处：一个服务挂了不影响其他；每个服务可以单独扩缩容；团队可以各管各的；技术栈也可以不一样（比如订单服务用 Java，推荐服务用 Python）。
比喻：
- 单体 = 一个巨无霸厨房，所有菜都在一个灶台上做，灶台一坏全餐厅停业。
- 微服务 = 烧烤摊、炒菜档、凉菜档分开，每个档口独立，坏了只影响一类菜。
- 微服务有哪些痛点（难点）？Spring Cloud 解决了什么？
| 痛点 | 说明 | Spring Cloud 提供的解决方案 |
| 服务那么多，怎么找到对方？ | 服务A要调用服务B，但B的IP会变（比如扩缩容、重启） | 服务注册与发现（Eureka、Nacos） |
| 调用失败怎么办？ | 网络抖动、服务B挂了，A一直等着会拖垮整个系统 | 熔断、降级、重试（Hystrix、Sentinel、Resilience4j） |
| 怎么统一请求入口？ | 前端要记几十个服务地址，太乱 | 网关（Gateway、Zuul） |
| 配置怎么管理？ | 每个服务都有自己的配置文件，改一个配置要重启几十个服务 | 配置中心（Config、Nacos、Apollo） |
| 怎么追踪一个请求的完整调用链？ | 一个请求经过 5 个服务，哪个环节慢了？ | 链路追踪（Sleuth + Zipkin/SkyWalking） |
| 分布式事务怎么搞？ | 下单要同时扣库存、减余额，跨服务怎么保证一致？ | 分布式事务（Seata、消息最终一致性） |