Appearance
微服务架构入门全景
看在前面
一、微服务架构概述
微服务架构是一种架构模式（或架构风格）。它提倡将单一应用程序划分成一组小的服务：每个服务运行在其独立的进程中。服务之间通过轻量的通信机制（通常是 HTTP 的 RESTful API 或 RPC）互相配合。每个服务围绕具体业务构建，并且能够被独立部署到生产环境。
单体架构 微服务架构
┌──────────────────┐ ┌────────┐ ┌────────┐
│ 全部业务功能 │ │ 用户服务 │ │ 订单服务 │
│ (一个进程/一个WAR) │ => └───┬────┘ └───┬────┘
│ │ └──── REST/RPC ────┘
└────────┬─────────┘ ┌────────┐ ┌────────┐
│ │ 商品服务 │ │ 支付服务 │
一个数据库 └────────┘ └────────┘
(库随服务拆，各自独立部署)二、微服务的出现与发展
早期的软件都是单体结构：功能集中、代码集中、部署集中，小团队维护没有问题。随着业务规模扩大，单体暴露出诸多困难。任何一个小改动都要整体重新编译部署、模块间耦合越来越重。单点故障影响全局、技术栈被锁死、团队协作互相阻塞。
于是先出现了 SOA（面向服务架构）——把功能抽成服务通过 ESB 总线交互。微服务可以看作 SOA 的继承与轻量化。去掉笨重的 ESB，用更细粒度的服务 + 更轻量的协议（REST/RPC + 消息）。并引入"去中心化治理、去中心化数据管理"这类理念。伴随 Docker、Kubernetes 这类容器化与 DevOps 技术的成熟而大规模落地。
三、传统单体开发模式与微服务的区别
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 开发 | 所有模块在一个工程里 | 按业务拆成多个独立工程/团队 |
| 构建/部署 | 整体编译、整体发布 | 每个服务独立构建、独立部署 |
| 扩展 | 整体复制扩展，资源浪费 | 按需对单个服务弹性扩容 |
| 故障 | 一处崩溃全体挂掉 | 故障隔离在单个服务内 |
| 技术 | 统一技术栈 | 每个服务可按场景选型（去中心化） |
| 数据 | 共享一个数据库 | 每个服务私有数据库，接口访问 |
四、微服务的具体特征
服务组件化：组件以独立服务的形式存在，服务即组件；
按业务组织团队：康威定律的实践——团队按业务能力划分（用户团队、订单团队）。而不是按技术层（前端组、后端组、DBA 组）；
面向产品而非项目：谁开发谁运营（you build it, you run it），团队对服务全生命周期负责；
去中心化治理：每个服务可以选用最适合的技术栈和存储，不强制统一；
去中心化数据管理：每个服务管理自己的数据库，提倡每服务一库。全局一致性通过事件最终一致来达成；
基础设施自动化：CI/CD、容器化、自动化测试是微服务的前提；
容错性设计：服务会挂，必须设计超时、重试、熔断、降级；
演进式设计：无法一蹴而就，先单体后拆分，按边界逐步演进。
五、SOA 和微服务的区别
通信协议：SOA 靠重量级的 ESB（企业服务总线）做消息路由、协议转换、编排。微服务用轻量级协议（REST/RPC、MQ）点对点通信或借助简单的网关；
服务粒度：SOA 粒度较粗（服务是较大的业务组件），微服务粒度更细，一个服务只做一件事；
部署与数据：SOA 服务常共享数据库、整体交付；微服务独立部署、独立数据库；
治理：SOA 是集中式治理（企业级标准统一），微服务偏向去中心化治理。
六、怎么具体实践微服务
拆分是第一难题，常见思路：
按业务能力拆：用户、商品、订单、支付、库存、营销；
按**领域驱动设计（DDD）**的限界上下文拆分边界，保证服务高内聚低耦合；
拆分原则：单一职责、独立部署、团队可维护（两个披萨团队）；避免拆得过细导致分布式复杂度爆炸。
配套基础设施：API 网关（统一入口、鉴权、限流）、注册中心（服务发现）、配置中心（动态配置）。链路追踪（排查跨服务调用）、日志聚合（ELK）、监控告警、容器与编排（Docker/K8s）、CI/CD 流水线。
七、常见的设计模式和应用
1. 聚合器微服务设计：一个聚合服务（或网关）并行调用多个后端微服务。把结果合并后返回给客户端，适合详情页这类需要拼装多份数据的场景。
2. 代理微服务设计：聚合器的一个变体。网关只做请求转发和按需的轻量变换（如协议转换、裁剪字段），业务逻辑仍在后端各服务。适合 BFF（为前端量身定做的后端）。
3. 链式微服务设计：请求沿 A→B→C 的链条依次传递。每个服务处理一部分并可能返回中间结果，响应再逆向返回。注意链不宜过长，否则延迟累加。
4. 数据共享微服务设计：多个服务短期共享一个数据库（迁移期或读多写少的查询场景）。属于反模式的妥协用法，长期应消除共享库。
5. 异步消息微服务设计：服务之间通过消息队列（Kafka/RabbitMQ/RocketMQ）异步通信，彻底解耦。上游只管发事件，下游按需订阅，天然削峰填谷。是事件驱动架构（EDA）的基础。
八、微服务的优点和缺点
优点：
服务小、内聚，易于理解和维护；单个服务可独立开发、部署、扩容，迭代速度快；
故障隔离，局部故障不至于拖垮全站；技术栈自由，可以按场景试错新技术；
团队自治，按业务组织，沟通链路短，契合规模化研发。
缺点：
分布式系统的全部复杂度迎面而来：网络不可靠、数据最终一致、分布式事务、链路排障难；
运维成本陡增：几十上百个服务的部署、监控、告警、日志，必须有自动化基础设施兜底；
服务拆分边界如果不对，会退化为"分布式单体"：改一个需求要动多个服务，还要一起发布；
测试复杂度上升：接口契约、联调、集成测试、契约测试都不可少。
九、思考：意识的转变
微服务不只是一个技术选型，更是一种研发意识和组织方式的转变。从"大而全的集中式交付"转向"小而自治的业务单元"。用自动化的基础设施和容错设计来对冲分布式的复杂度。是否上微服务，取决于业务复杂度、团队规模和基础设施成熟度。没有这些前提，单体仍然是合理且高效的选择。架构没有银弹，适合自己的才是最好的。
内容来源：原文 · 2026-10 整理回填。