一句话总结
微服务是将单体应用拆分为一组独立部署、独立开发、独立扩展的小服务。每个服务围绕业务能力构建，拥有独立数据库，通过轻量级通信机制（HTTP/RPC）协作。Spring Cloud 提供一站式解决方案：注册中心（Nacos/Eureka）、配置中心（Nacos Config）、网关（Gateway）、远程调用（Feign）、熔断降级（Sentinel）、链路追踪（Sleuth）。核心挑战：服务发现、配置管理、分布式事务、链路追踪。
初级理解
单体 vs 微服务
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 部署 | 整体打包部署 | 每个服务独立部署 |
| 扩展 | 整体扩展（资源浪费） | 按需扩展（精准） |
| 开发 | 统一技术栈 | 每个服务可不同技术栈 |
| 数据库 | 共享数据库 | 每个服务独立数据库 |
| 故障隔离 | 一个模块故障影响全局 | 故障隔离，不影响其他服务 |
| 复杂度 | 开发简单，运维简单 | 分布式系统复杂度 |
中级深入
服务拆分原则
# 拆分原则
# 1. 单一职责：一个服务只做一件事
# 2. 高内聚低耦合：服务内部紧密，服务间松散
# 3. 按业务领域拆分（DDD 限界上下文）
# 4. 数据独立：每个服务有自己的数据库
# 5. 团队对齐：一个团队负责一个/多个服务
# 拆分示例（电商系统）
# 用户服务（user-service）：注册、登录、用户信息
# 商品服务（product-service）：商品管理、分类、库存
# 订单服务（order-service）：下单、订单管理
# 支付服务（pay-service）：支付、退款
# 物流服务（logistics-service）：发货、物流跟踪
# 拆分粒度
# 太小：服务太多，运维复杂，调用链长
# 太大：退化为单体，失去微服务优势
# 原则：先粗后细，逐步拆分
Spring Cloud 核心组件
| 组件 | 作用 | Spring Cloud 实现 |
|---|---|---|
| 注册中心 | 服务注册与发现 | Nacos、Eureka、Consul |
| 配置中心 | 集中配置管理 | Nacos Config、Spring Cloud Config |
| 网关 | 统一入口、路由转发 | Gateway、Zuul |
| 远程调用 | 服务间通信 | Feign/OpenFeign、RestTemplate |
| 负载均衡 | 请求分发 | Ribbon、LoadBalancer |
| 熔断降级 | 故障容错 | Sentinel、Hystrix |
| 链路追踪 | 调用链分析 | Sleuth + Zipkin |
高级拓展
CAP 理论在微服务中的体现
# CAP 理论
# C（Consistency）：一致性，所有节点同一时刻数据相同
# A（Availability）：可用性，每个请求都能得到响应
# P（Partition Tolerance）：分区容错性，网络分区时系统仍能工作
# 微服务中 P 是必须的（网络不可靠）
# 所以只能在 C 和 A 之间权衡
# 注册中心的选择
# Eureka：AP（优先可用性）
# - 节点平等，网络分区时仍可注册和查询
# - 可能拿到旧数据（最终一致性）
# Zookeeper：CP（优先一致性）
# - Leader 选举期间不可用
# Nacos：AP/CP 可切换
# - 默认 AP，可配置为 CP
服务间通信方式
# 同步通信（HTTP/RPC）
# REST API（Feign）：简单、跨语言、调试方便
# Dubbo（RPC）：高性能、长连接、二进制协议
# gRPC：高性能、Protocol Buffers、双向流
# 异步通信（消息队列）
# 场景：下单后发短信、扣库存
# 优点：解耦、削峰、最终一致性
# 缺点：延迟、复杂度增加
# 选择建议
# 查询类：同步 REST
# 命令类（需要即时结果）：同步 REST
# 通知类（不需要即时结果）：异步 MQ
实战场景
场景：微服务项目结构
# 典型微服务项目结构
mall-project/
├── mall-gateway/ # 网关服务
├── mall-common/ # 公共模块（工具类、统一返回）
├── mall-user/ # 用户服务
│ ├── user-api/ # Feign 接口定义
│ └── user-service/ # 服务实现
├── mall-product/ # 商品服务
├── mall-order/ # 订单服务
└── mall-pay/ # 支付服务
# 每个服务独立数据库
# mall_user、mall_product、mall_order、mall_pay
面试模拟
面试官：微服务和单体架构有什么区别？
你：单体是整体打包部署，微服务是独立部署的小服务。微服务优势：独立扩展、故障隔离、技术栈灵活；挑战：分布式复杂度、数据一致性、运维成本高。不是所有项目都需要微服务，小项目用单体更合适。
面试官：服务拆分的原则是什么？
你：单一职责、高内聚低耦合、按业务领域拆分（DDD）、数据独立。拆分粒度要适中，先粗后细逐步演进。拆分过细会导致服务爆炸和调用链过长。