---
tags: [microservice, architecture]
create time: 2026-04-29 12:30
---
# 微服务基础概念
## 概述
本文阐述微服务架构的核心定义、设计原则与常见误区，帮助建立正确的认知框架。
## 什么是微服务
> [!definition] 核心定义
> **微服务**（Microservices）是一种将单一应用拆分为一组**小服务**的架构风格。每个服务运行在独立进程中，通过轻量级通信机制协作，且**各自拥有独立的数据库**。
关键特征：
| 特征 | 说明 |
|------|------|
| 独立部署 | 每个服务可以独立构建、测试和发布 |
| 去中心化 | 数据管理、技术选型由各团队自主决策 |
| 容错性 | 服务故障不影响整个系统 |
| 组织对齐 | 按业务域划分，与 Conway 定律呼应 |
### 单体 vs 微服务
```mermaid
graph TB
subgraph Monolith["单体架构"]
UI["Web UI"]
API["API Layer"]
Biz["Business Logic"]
DB["数据库"]
UI --> API --> Biz --> DB
end
subgraph Microservices["微服务架构"]
GW["API Gateway"]
S1["Service A
+ Database"]
S2["Service B
+ Database"]
S3["Service C
+ Database"]
GW --> S1
GW --> S2
GW --> S3
S2 -.->|RPC/MQ| S1
end
```
> [!question] 思考
> 既然微服务有这么多好处，为什么不是所有公司都迁移到微服务？什么时候单体反而更合适？
**答案线索**：微服务引入的是**分布式复杂度**。网络延迟、数据一致性、运维成本全部上来了。对于小型团队或小规模应用，单体更简单高效。
## 拆分原则：DDD 与限界上下文
微服务拆分的核心思想来自 **领域驱动设计 (DDD)** —— 按 **限界上下文 (Bounded Context)** 划分。
```mermaid
graph LR
UC["用户中心"]
OS["订单服务"]
PS["支付服务"]
IS["库存服务"]
UC -->|查询/注册| OS
OS -->|创建支付| PS
OS -->|扣减库存| IS
PS -->|支付回调| OS
IS -->|库存确认| OS
```
> [!tip] 限界上下文不是代码边界，而是语义边界
> 同一个词在不同上下文中可能有完全不同的含义。比如 "商品" 在电商场景中是一套完整对象，但在物流场景中可能只是一个包裹编号。明确上下文是 DDD 的第一步。
> [!warning] 反模式
> - ❌ **按技术层拆分**：Controller 层一个服务、Service 层一个服务 — 这不是微服务，是"分布式单体"
> - ✅ **按业务域拆分**：每个服务对应一个业务能力边界
## 核心设计原则
> [!summary] SOLID + CAP 的组合拳
>
> | 原则 | 含义 | 微服务场景 |
> |------|------|-----------|
> | 单一职责 | 一个服务只做一件事 | 订单服务只管订单生命周期 |
> | 高内聚低耦合 | 内部紧密，外部松散 | 服务间通过接口通信，不共享代码 |
> | 最终一致性 | 允许短暂不一致 | 分布式环境放弃强一致性，换取可用性 |
> | 独立失败 | 故障隔离 | 单个服务宕机不影响全局 |
## 何时不应该用微服务
> [!failure] 拒绝伪需求
>
> - 团队小于 10 人，维护单个应用就够
> - 项目处于快速原型阶段，需求频繁变更
> - 团队成员缺乏分布式系统设计经验
> - 已有大型单体正在稳定运行
**记住**：架构没有银弹。微服务是为了解决**特定规模下的组织和工程问题**而生的。先问自己："我的痛点是什么？"再决定是否值得付出代价。
> [!note] 后续延伸
>
> - [[02-服务治理]] — 服务间通信、负载均衡、熔断降级等治理机制
> - [[03-数据一致性]] — 独立数据库架构下的分布式事务方案
> - [[04-可观测性]] — 日志、指标、链路追踪三支柱
> - [[05-部署运维]] — 容器化编排、灰度发布、弹性伸缩