2. 微服务架构基础：微服务定义、与单体架构对比、服务拆分原则

2.1 微服务架构定义

微服务架构是一种将单一应用程序划分为一组小型、自治服务的架构风格。每个服务运行在独立的进程中，围绕特定业务能力构建，并通过轻量级通信机制（通常是 HTTP/REST 或 gRPC）相互协作。

微服务的核心特征包括：

• 单一职责：每个服务只负责一个明确的业务领域或子域。
• 独立部署：服务可以独立于其他服务进行构建、测试、部署和扩展。
• 技术异构：不同服务可以使用最适合其业务场景的编程语言、数据库和中间件。
• 去中心化治理：团队拥有服务的完整所有权，包括数据模型和 API 设计。
• 弹性与容错：单个服务的故障不会导致整个系统崩溃，通过熔断、重试、限流等模式保障系统可用性。

2.2 单体架构 vs 微服务架构

理解微服务的价值，需要先看清单体架构的局限。下表从多个维度对比两种架构模式：

下图直观展示了两种架构在部署和扩展模式上的核心差异：

2.3 服务拆分原则

服务拆分是微服务架构设计中最关键也最困难的环节。拆分过细会导致“分布式单体”和运维噩梦；拆分过粗则无法获得微服务的收益。以下是业界公认的五大拆分原则：

1. 领域驱动设计（DDD）限界上下文原则
   • 以业务领域为核心，识别限界上下文（Bounded Context），每个上下文对应一个微服务。
   • 服务内部使用统一语言（Ubiquitous Language），服务间通过事件或 API 通信。
2. 单一职责原则（SRP）
3. 每个服务只负责一个明确的业务能力，如“用户服务”只管理用户注册、认证和资料。
4. 避免“万能服务”或“上帝服务”，一个服务不应承担多个不相关的职责。
5. 数据所有权原则
   • 每个服务拥有自己的数据库或数据存储，禁止跨服务直接访问数据库。
   • 服务间数据交换必须通过 API 或事件，确保数据边界清晰。
6. 团队自治原则
   • 服务拆分应与团队结构对齐，遵循康威定律（Conway's Law）。
   • 一个服务由一个全功能团队（包含开发、测试、运维角色）全权负责。
7. 变更频率与稳定性原则
   • 将变更频繁的业务逻辑与相对稳定的基础服务分离。
   • 高频变更服务可以独立迭代，不影响低频变更服务的稳定性。

下图展示了基于 DDD 限界上下文进行服务拆分的典型流程：

2.4 服务拆分决策矩阵

在实际项目中，可以借助以下决策矩阵来评估候选服务的合理性。对每个候选服务，从四个维度打分（1~5 分），总分越高越适合独立为微服务：

使用建议：对每个候选服务计算总分（满分 20 分）。总分 ≥ 14 分：强烈建议拆分为独立微服务；8~13 分：可拆分，但需进一步评估耦合风险；≤ 7 分：暂不建议拆分，保持为单体模块更经济。