微服务基础概念

概述

本文阐述微服务架构的核心定义、设计原则与常见误区，帮助建立正确的认知框架。

什么是微服务

[!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] 后续延伸

02-服务治理 — 服务间通信、负载均衡、熔断降级等治理机制

03-数据一致性 — 独立数据库架构下的分布式事务方案

04-可观测性 — 日志、指标、链路追踪三支柱

05-部署运维 — 容器化编排、灰度发布、弹性伸缩

3.8 KiB Raw Blame History Unescape Escape