3.8 KiB
3.8 KiB
tags, create time
| tags | create time | ||
|---|---|---|---|
|
2026-04-29 12:30 |
微服务基础概念
概述
本文阐述微服务架构的核心定义、设计原则与常见误区，帮助建立正确的认知框架。
什么是微服务
[!definition] 核心定义 微服务（Microservices）是一种将单一应用拆分为一组小服务的架构风格。每个服务运行在独立进程中，通过轻量级通信机制协作，且各自拥有独立的数据库。
关键特征：
| 特征 | 说明 |
|---|---|
| 独立部署 | 每个服务可以独立构建、测试和发布 |
| 去中心化 | 数据管理、技术选型由各团队自主决策 |
| 容错性 | 服务故障不影响整个系统 |
| 组织对齐 | 按业务域划分，与 Conway 定律呼应 |
单体 vs 微服务
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<br/>+ Database"]
S2["Service B<br/>+ Database"]
S3["Service C<br/>+ Database"]
GW --> S1
GW --> S2
GW --> S3
S2 -.->|RPC/MQ| S1
end
[!question] 思考 既然微服务有这么多好处，为什么不是所有公司都迁移到微服务？什么时候单体反而更合适？
答案线索：微服务引入的是分布式复杂度。网络延迟、数据一致性、运维成本全部上来了。对于小型团队或小规模应用，单体更简单高效。
拆分原则：DDD 与限界上下文
微服务拆分的核心思想来自 领域驱动设计 (DDD) —— 按 限界上下文 (Bounded Context) 划分。
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] 后续延伸