1. 微服务架构概述

1.1 单体架构 vs 微服务架构

在讨论微服务之前，必须先理解其对立面——单体架构（Monolithic Architecture）。单体架构是将所有功能模块（用户管理、订单、支付、库存等）打包在同一个进程、同一个部署单元中的传统模式。而微服务架构（Microservices Architecture）则将应用拆分为一组独立部署、独立运行的小型服务，每个服务围绕特定业务能力构建。

1.2 微服务核心特征

微服务并非简单的“拆小”，它遵循一组明确的架构特征。根据 Martin Fowler 与 James Lewis 的定义，微服务架构具备以下核心特征：

1. 组件化与独立部署：每个服务是一个独立组件，可单独构建、测试、部署和升级，不影响其他服务。
2. 围绕业务能力组织：服务边界由业务领域（Bounded Context）决定，而非技术分层（如 DAO、Service、Controller）。
3. 产品化思维：每个服务由跨职能团队（开发+测试+运维）全生命周期负责，而非“项目制”交付。
4. 智能端点与哑管道：服务间通信采用轻量级协议（HTTP/REST 或 gRPC），避免使用 ESB 等重量级中间件。
5. 去中心化治理：每个服务可自由选择最适合的技术栈，不强制统一语言或框架。
6. 去中心化数据管理：每个服务拥有自己的数据库或存储方案，服务间通过 API 交换数据，而非共享数据库。
7. 基础设施自动化：依赖 CI/CD、容器化（Docker）、编排（Kubernetes）实现自动化部署与弹性伸缩。
8. 容错设计：服务必须内置熔断、重试、降级、限流等机制，防止故障级联扩散。
9. 演进式设计：架构允许逐步从单体演进到微服务，而非一次性“大爆炸”重构。

1.3 微服务架构的优缺点与适用场景

优点

• 独立部署与快速迭代：每个服务可独立发布，缩短交付周期，支持频繁上线。
• 技术异构性：不同服务可根据场景选择最合适的语言或框架（如 Python 做 AI 推理，Go 做高并发网关）。
• 弹性扩展：只对热点服务（如订单、支付）进行水平扩展，节省资源成本。
• 故障隔离：单个服务崩溃不会导致整个系统瘫痪，通过熔断/降级保障核心链路可用。
• 团队自治：小团队（2-8人）全权负责一个服务，减少跨团队沟通成本。

缺点

• 分布式复杂性：网络延迟、数据一致性、分布式事务、服务发现等问题显著增加。
• 运维成本高：需要容器编排、日志聚合、链路追踪、监控告警等基础设施支撑。
• 数据一致性挑战：跨服务的事务无法使用传统 ACID，必须采用 Saga、事件溯源等最终一致性方案。
• 测试复杂度上升：集成测试需要模拟多个服务，端到端测试链路长、环境搭建困难。
• 服务间通信开销：远程调用（RPC）相比本地调用有显著的延迟和序列化开销。

适用场景