架构演进：单体 vs 分布式 vs 微服务
软件架构随着业务复杂度的提升而不断演进。没有最好的架构，只有最适合业务场景的架构。
一、单体架构 (Monolithic)
单体架构是大多数初创项目的起点。
1. 特点
- All-in-One：整个系统打包成一个应用（通常一个 WAR/JAR 包）。
- 统一技术栈：所有功能模块（用户、订单、商品、支付…）都在一个工程里，共享同一个数据库。
2. 优缺点对比
| 优点 | 缺点 |
|---|---|
| 开发简单：上手快，适合小团队。 | 耦合度高：一个模块出问题（如内存溢出）可能搞挂整个系统。 |
| 部署方便：只需要部署一个包。 | 扩展困难：无法针对热点模块（如秒杀）单独扩展，只能整体扩容。 |
| 测试容易：无需模拟远程调用。 | 代码维护难：随着业务增长，代码库变得臃肿，编译慢，IDE 卡顿。 |
二、分布式架构 (Distributed)
随着用户量增加，单台服务器无法支撑，我们开始进行垂直拆分。
1. 特点
- 垂直拆分：将单体应用拆分为多个独立的服务（如拆分为用户系统、订单系统），服务之间通过 RPC/HTTP 通信。
- 数据库拆分：不同服务往往使用不同的数据库。
2. 优缺点对比
| 优点 | 缺点 |
|---|---|
| 降低耦合：模块间解耦，职责清晰。 | 复杂度增加：需要解决分布式事务、分布式锁等问题。 |
| 弹性扩展：可针对瓶颈服务单独扩容。 | 运维成本高：需要维护多个服务节点。 |
三、微服务架构 (Microservices)
微服务是分布式架构的一种极致实践，强调服务粒度更细和去中心化。
1. 核心特征
- 单一职责：一个服务只做一件事。
- 独立部署：每个服务独立开发、测试、部署，互不影响。
- 技术异构：可以使用不同的语言和数据库（如订单用 Java + MySQL，推荐用 Go + Redis）。
2. 微服务生态组件
| 组件类型 | 作用 | 常见选型 |
|---|---|---|
| 注册中心 | 服务的自动发现与注册 | Nacos, Eureka, Consul |
| 配置中心 | 动态管理配置，无需重启 | Nacos, Apollo, Spring Cloud Config |
| API 网关 | 统一入口，路由转发，鉴权限流 | Spring Cloud Gateway, Zuul, APISIX |
| 熔断限流 | 保护服务，防止雪崩 | Sentinel, Hystrix, Resilience4j |
| 链路追踪 | 监控调用链，排查故障 | SkyWalking, Zipkin, Jaeger |
| 分布式事务 | 保证跨服务数据一致性 | Seata, TCC, RocketMQ 事务消息 |
3. 微服务拆分原则 (DDD)
- 高内聚，低耦合：紧密相关的业务逻辑放在一起。
- 服务粒度适中：过细会导致调用链过长，过粗则退化为单体。
- 以业务领域为边界：参考领域驱动设计 (DDD) 的 Bounded Context (限界上下文)。
四、Service Mesh (服务网格)
微服务的下一代演进方向（Sidecar 模式）。
- 核心思想：将服务治理（熔断、限流、监控）从业务代码中剥离，下沉到基础设施层（Sidecar 代理）。
- 代表产品：Istio, Linkerd。
- 优点：业务代码纯粹，跨语言支持好。