107 lines
3.8 KiB
Markdown
107 lines
3.8 KiB
Markdown
|
---
|
|||
|
|
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<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)** 划分。
|
|||
|
|
|
|||
|
|
```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-部署运维]] — 容器化编排、灰度发布、弹性伸缩
|