备考软考系统架构师的时候，微服务是绕不开的大题。但说实话，大多数教程要么太浅（就告诉你"拆服务"三个字），要么太深（一上来就是分布式事务的六种实现）。

今天用一篇长文，把微服务从「拆」到「治」全链路讲透。每个知识点都带落地案例和软考论文素材。

一、为什么要微服务——先搞清楚动机

单体架构的痛点

想象一个电商系统，用户模块、订单模块、商品模块全塞在一个 war 包里。某天商品模块出了个死循环，整个系统一起挂。你想扩容？对不起，整个系统一起扩，明明只有订单模块扛不住，却要多部署 10 台全量服务。

这就是单体的三个核心问题：

1. 可用性耦合：一个模块挂，全家挂
2. 扩展粒度粗：不能按模块独立扩缩容
3. 技术栈锁定：想用 Go 写个高性能服务？不行，全部 Java

微服务怎么解决

微服务的本质就一句话：按业务边界把系统拆成一组独立部署、独立演进的服务。

每个服务有自己的代码仓库、自己的数据库、自己的部署流水线。商品服务挂了，用户还能登录、还能看订单——这叫"故障隔离"。

软考论文素材：质量属性场景——"高可用"需求的战术实现 = 服务隔离 + 熔断降级 + 冗余部署。

二、怎么拆——服务拆分原则

不是拆得越细越好。见过一个团队把用户模块拆成"注册服务"和"登录服务"，注册掉线后登录也挂了——这不叫微服务，叫微灾难。

三个核心原则

1. 按业务领域拆分（DDD 限界上下文）

用户上下文：注册、登录、会员等级、积分
订单上下文：下单、支付、退款、物流追踪
商品上下文：发布、上下架、库存、类目

每个上下文一个服务，内部高内聚，对外暴露 API。

2. 按变更频率拆分

用户基础信息很少变，但营销活动每周换。高频变更的部分单独抽出来，避免"改个活动规则要重新部署整个用户服务"。

3. 按数据主权拆分

这是最关键的：每个服务拥有自己的数据库，其他服务只能通过 API 访问数据。

用户服务 ── MySQL(用户库)
订单服务 ── MySQL(订单库)  
商品服务 ── MySQL(商品库) + Elasticsearch(搜索)

共享数据库是微服务最大的反模式——表面上是微服务，骨子里还是单体。

软考论文素材：数据库架构模式——Database per Service vs Shared Database 的 trade-off 分析。

三、怎么通——服务间通信

拆完之后，服务之间怎么说话？两大流派。

同步通信：REST / gRPC

REST：HTTP + JSON，简单通用，适合对外 API 和跨团队调用。
gRPC：基于 HTTP/2 + Protobuf，性能更好，适合内部高性能场景。

什么时候用同步？

• 查询操作（查用户信息、查商品详情）
• 需要即时响应的场景（下单前校验库存）

异步通信：消息队列

RabbitMQ / Kafka / RocketMQ：发消息就走，不用等回复。

什么时候用异步？

• 通知类操作（下单后发短信、发推送）
• 数据同步（订单状态变更后更新 ES 索引）
• 削峰填谷（秒杀请求先扔队列）

通信选型决策表

场景	方式	工具
查询用户信息	同步 REST	Feign / RestTemplate
下单减库存	同步，加分布式锁	Redisson
下单后发通知	异步 MQ	RabbitMQ
订单状态同步到 ES	异步 MQ	RocketMQ
服务间高性能调用	同步 gRPC	gRPC

软考论文素材：集成策略——同步(REST)与异步(MQ)混合架构的优缺点对比。

四、怎么管——服务治理三板斧

微服务数量一多，魔鬼就藏在细节里。

第一板斧：服务发现（Nacos / Eureka / Consul）

100 个服务实例，IP 天天变，怎么知道调到哪？需要一个注册中心。

流程：服务启动 → 向 Nacos 注册（ip:port）→ 调用方从 Nacos 拉取实例列表 → 负载均衡调用。

Nacos 额外提供配置中心功能——所有服务的配置文件统一管理，改配置不用重启。

第二板斧：API 网关（Spring Cloud Gateway / Kong）

所有外部请求统一从网关进，网关负责：

• 路由：根据 URL 前缀转发到对应服务
• 鉴权：JWT 校验，没登录直接挡
• 限流：配合 Sentinel 做网关层限流
• 日志：统一记录请求日志

网关是系统的"守门员"，也是软考论文里必画的组件。

第三板斧：熔断降级限流（Sentinel / Hystrix）

熔断：订单服务挂了，商品服务调用订单服务的线程不再傻等，直接熔断，返回兜底数据。

降级：秒杀时商品详情页不显示推荐算法结果，只显示基本信息——优先保证核心流程。

限流：每秒最多 1000 个请求进入系统，多了直接拒绝——保护系统不被打垮。

三者区别：

• 熔断 = 下游挂了，我不调了
• 降级 = 系统扛不住，暂时关掉非核心功能
• 限流 = 请求太多，排队或者拒绝

软考论文素材：质量属性战术——可用性战术（故障检测+恢复）、性能战术（资源调度）、安全战术（认证授权）。

五、数据怎么管——分布式数据挑战

分布式事务

单体一个 @Transactional 搞定，微服务跨多个数据库怎么办？

方案一：Seata AT 模式
自动回滚，对业务代码零侵入，但性能损耗较大。

方案二：TCC（Try-Confirm-Cancel）
手动编补偿逻辑，性能好但开发量大。适合金融场景。

方案三：SAGA 模式
每个步骤有对应的补偿操作，最终一致性。适合长流程。

方案四：本地消息表 + 定时任务
简单可靠，适合对实时性要求不高的场景。

CQRS（命令查询职责分离）

读写分离的经典模式：

• Command 端：处理写操作（下单、支付），只写数据库
• Query 端：处理读操作（查订单列表、商品搜索），读 ES 或者 Redis

好处：读写互不影响，各自独立扩容。

Event Sourcing（事件溯源）

不存当前状态，存所有变更事件。订单状态不是"已支付"，而是一串事件：创建→支付→发货→签收。任何时间点都能回溯。

软考论文素材：架构模式选择——CQRS + Event Sourcing 在电商系统中的落地实践。

六、链路追踪与可观测性

微服务一大坑：一个请求经过 5 个服务，哪个环节慢了？

SkyWalking / Jaeger / Zipkin：分布式链路追踪，每个请求带一个 TraceId，贯穿所有服务。配合日志聚合（ELK），出问题秒定位。

核心三件套：

1. 日志（Logging）：ELK 集中收集
2. 指标（Metrics）：Prometheus + Grafana 监控面板
3. 追踪（Tracing）：SkyWalking 链路追踪

软考论文素材：运维与质量属性——可测试性、可修改性的架构决策。

七、容器化部署（Kubernetes）

微服务 + K8s = 天生一对：

• Pod：最小部署单元，一个 Pod 跑一个服务实例
• Service：Pod 的负载均衡器，对外暴露固定 IP
• Ingress：K8s 的网关，对应微服务里的 API Gateway
• ConfigMap / Secret：配置管理，替代 Nacos 的配置中心功能

K8s 替微服务解决了：自动扩缩容（HPA）、滚动发布、健康检查、服务发现。

八、软考论文速成框架

系统架构师论文必用的微服务万能模板：

1. 项目背景（是什么系统，为什么选微服务）
2. 架构风格选择（微服务 vs SOA vs 分层，简述理由）
3. 架构设计（画图！分层画：网关→服务→数据→基础设施）
4. 关键技术决策：
   - 服务拆分策略（DDD）
   - 通信方式（REST + MQ 混合）
   - 服务治理（注册发现 + 熔断 + 网关）
   - 数据方案（Database per Service + CQRS）
5. 质量属性分析（可用性/性能/安全性如何保证）
6. 总结与展望

写在最后

微服务不是银弹。如果你的团队只有 3 个人、系统日活不过千，老老实实用单体——微服务的运维成本会吃光你所有的开发时间。

但如果你在备考软考、或者在面试架构师岗位，微服务这套东西你必须能讲清楚：为什么要拆、怎么拆、拆完怎么治、数据怎么管。

下一篇准备画六边形架构（端口适配器模式）的全景图，同样是软考高频考点。你们最想了解微服务的哪个方面？评论区等你。

文中涉及的微服务架构全景图，可在我上篇文章查看：一张图讲清微服务架构