Ayahunter

微服务首先改变的是边界#

单体和微服务最直观的区别是部署单元数量，但真正重要的变化是所有权边界。

在结构良好的模块化单体中，订单、库存、支付可以是三个边界清楚的模块，但它们仍然随同一个应用一起构建和发布。微服务进一步把部分模块变成可独立部署的服务，并要求每个服务拥有自己的业务职责、接口和数据。

“服务拥有数据”不等于每个服务必须立即购买一套独立数据库。重点是写入权和模型的归属清楚：库存服务不能绕过订单服务直接修改订单表，订单服务也不应通过跨库 JOIN 依赖库存表的内部结构。物理隔离可以随风险和规模逐步推进，逻辑所有权则应从设计开始就明确。

什么时候值得从单体拆出去#

微服务常见的有效动机包括：

• 不同业务能力的发布节奏明显不同，整体发布已经频繁互相阻塞；
• 某个模块需要独立扩容，而整体扩容浪费资源；
• 一个代码库的变化耦合和责任边界持续失控，已经影响交付；
• 多个团队需要围绕稳定的业务边界独立负责开发、运行和演进；
• 某个能力对可用性、安全或技术栈有明显不同的要求。

反过来，如果系统规模不大、业务边界仍在快速变化、团队只有几个人，或者连自动化测试和部署都不稳定，拆成微服务通常会放大问题。此时更合适的起点是模块化单体：先把代码依赖、数据访问和模块接口管住，再根据实际瓶颈提取服务。

如何划定服务边界#

服务边界通常从业务能力开始，而不是从技术分层开始。user-service、order-service 可能是业务边界；controller-service、database-service 通常只是把同一个业务请求拆成更多网络跳数。

可以用以下四个问题检查候选边界：

1. 它负责什么业务结果？ 服务应该能用业务语言描述职责，而不是只描述技术动作。
2. 哪些数据由它决定？ 服务应拥有写入规则和状态迁移，其他服务通过接口或事件读取结果。
3. 它为什么发生变化？ 经常一起修改、一起发布的功能通常不适合强行拆开。
4. 失败时能否独立处理？ 如果两个服务必须同时成功、同时扩容、同时发布，边界很可能还不稳定。

边界不会一次设计到永久正确。更可靠的做法是从较粗的边界开始，通过调用频率、变更记录和故障数据观察耦合，再决定合并或继续拆分。过早拆得太细会产生大量“分布式内部方法调用”，接口数量和运维成本上升，却没有获得独立演进的收益。

一次微服务请求经过哪些组件#

以下是一条简化的下单链路。实线表示业务流量，虚线表示注册、发现、配置和遥测等控制关系。

flowchart LR
  C[客户端] --> G[API Gateway]
  G --> O[订单服务]
  O --> I[库存服务]
  O --> P[支付服务]
  O --> ODB[(订单数据)]
  I --> IDB[(库存数据)]
  P --> PDB[(支付数据)]
  O --> MQ[(消息系统)]
  MQ --> N[通知服务]
  O -. 注册与发现 .-> R[服务注册中心]
  I -. 注册与发现 .-> R
  P -. 注册与发现 .-> R
  G -. 路由与发现 .-> R
  O -. 配置 .-> CF[配置中心]
  I -. 配置 .-> CF
  G -. 日志 指标 Trace .-> OBS[可观测平台]
  O -. 日志 指标 Trace .-> OBS
  I -. 日志 指标 Trace .-> OBS
  P -. 日志 指标 Trace .-> OBS

这张图里的组件不是每套系统都必须单独部署。例如，在 Kubernetes 中，Service 和集群 DNS 可以为一组会动态变化的 Pod 提供稳定名称和访问入口；应用未必需要自己实现一套客户端注册发现。选择组件前，先确认运行平台已经解决了什么问题。

同步调用和异步消息怎么选#

服务之间最常见的通信方式可以归为同步请求和异步消息。

选择的关键不是哪个协议更“先进”，而是业务是否需要立即得到结果。例如查询库存通常需要同步响应；订单创建后发送通知不应阻塞主请求，更适合由事件异步触发。

无论使用哪种方式，都要把接口当成长期契约：

• 新增字段尽量保持向后兼容，不让调用方和提供方必须同时发布；
• 明确超时、错误码和重试语义，而不只定义成功响应；
• 写操作提供幂等键或业务唯一约束，避免重试产生重复副作用；
• 消息事件描述已经发生的事实，例如 OrderCreated，并携带稳定的事件 ID、业务 ID 和版本。

一个简化的事件可以是：

1
{
2
  "eventId": "evt_01J...",
3
  "eventType": "OrderCreated",
4
  "version": 1,
5
  "occurredAt": "2026-09-12T10:30:00+08:00",
6
  "orderId": "order_123",
7
  "customerId": "customer_456"
8
}

消费者应先根据 eventId 或业务唯一键判断是否已经处理。即使消息基础设施提供某种 exactly-once 能力，数据库写入、外部支付和通知等端到端副作用仍需要业务幂等保护。

服务治理的目标是限制故障扩散#

单体中的方法调用通常要么返回，要么抛出异常；远程调用还会遇到超时、连接中断、实例重启、响应丢失和部分成功。最危险的不是某个服务失败，而是调用方持续等待和重试，耗尽线程、连接和队列，最终形成级联故障。

治理策略应从最基本的时间和资源边界开始：

跨服务数据如何保持一致#

服务拆分后，原本一个本地事务中的操作可能变成：创建订单、预占库存、发起支付。直接让多个服务共享一个数据库事务，会破坏独立性并引入可用性和性能成本；完全不设计一致性，则会留下已付款但未创建订单等业务错误。

更实用的思路是先按业务要求区分一致性等级：

• 余额扣减、库存预占等关键不变量，要在拥有该数据的服务内部用本地事务和唯一约束保证；
• 跨服务状态通过事件和明确的状态机逐步推进，接受可观测、可恢复的中间状态；
• 对必须撤销的步骤设计补偿动作，而不是假设所有系统都能一起回滚。

1
本地事务：
2
  1. INSERT orders (..., status = 'PENDING')
3
  2. INSERT outbox_events (..., event_type = 'OrderCreated')
4

5
提交后：
6
  3. 发布器读取未发送事件并投递
7
  4. 消费者幂等处理
8
  5. 发布器标记已发送或等待下一次重试

可观测性让分布式问题能够被解释#

当一次请求跨过网关、订单、库存和支付服务，仅按时间搜索多份日志很难还原因果关系。生产系统至少需要把以下三类信号关联起来：

• Logs：记录离散事件和诊断上下文；
• Metrics：观察请求量、错误率、延迟分位数和资源饱和度；
• Traces：用 trace 和 span 还原请求经过的服务及每一段耗时。

Trace context 应随同步请求和异步消息传播，日志中记录 trace_id、service.name、环境和业务关联 ID。业务 ID 方便查询某个订单，trace ID 方便还原某次调用，两者用途不同，不能互相替代。

只有采集信号还不够，还需要围绕用户可感知的目标建立告警。例如订单接口的成功率和延迟比“某台机器 CPU 超过 80%”更接近真实服务质量；CPU 告警仍有价值，但它是诊断信号，不一定代表用户请求已经失败。

微服务依赖工程能力，而不只依赖框架#

微服务把一次整体发布变成多个服务的持续交付，因此下面这些能力不是锦上添花：

• 自动化测试以及接口契约的兼容性检查；
• 可重复的构建、部署、回滚和数据库变更流程；
• 统一的日志、指标、Trace 和告警规范；
• 服务清单、负责人、依赖关系和运行手册；
• 配置、Secret、证书和权限的生命周期管理；
• 容量评估、限流、故障演练和事故复盘。

容器和 Kubernetes 可以提供标准化部署、服务发现、滚动更新和弹性能力，但它们不会自动修复错误的服务边界、缺失的幂等设计或不可回滚的数据库变更。基础设施解决运行问题，业务一致性仍由应用架构负责。

更稳妥的迁移路线#

从现有单体迁移时，可以按以下顺序降低风险：

1. 建立模块边界：禁止跨模块随意访问内部实现和数据表；
2. 补齐观测和自动化：先知道系统如何运行，再增加部署单元；
3. 选择一个有明确收益的边界：例如独立扩容需求强、变化频繁且数据职责清楚的模块；
4. 先定义契约和失败语义：包含超时、幂等、兼容和回滚策略；
5. 渐进切流：保留回退路径，通过指标比较迁移前后的交付和运行效果；
6. 根据证据继续或停止：没有获得预期收益时，不要为了“架构统一”继续拆分。

这种路径常被称为 Strangler Fig：在旧系统旁逐步建立新能力并迁移流量，而不是一次性重写全部系统。它不会消除迁移成本，但能把不可逆的大爆炸式改造变成多个可验证步骤。

设计评审清单#

准备拆分一个服务时，可以逐项回答：

• 它解决了哪个已经存在的交付、扩容、可靠性或团队协作问题？
• 如果保持模块化单体，具体会产生什么不可接受的后果？
• 服务的业务职责、数据所有权和负责人是否明确？
• 上下游契约能否独立演进，还是必须同时发布？
• 每个远程调用的超时、重试、幂等和降级语义是什么？
• 跨服务业务有哪些中间状态、补偿操作和人工恢复入口？
• 日志、指标和 Trace 能否还原一次失败请求？
• 能否独立构建、部署、回滚，并处理数据库兼容？
• 新增的基础设施和运维成本由谁长期负责？
• 用什么指标证明拆分之后确实更好？

如果这些问题大多没有答案，最优选择通常不是先引入更多组件，而是保持或改进模块化单体，继续收集边界和瓶颈的证据。

总结#

微服务的核心不是注册中心、网关或某个框架，而是把系统划分成能够独立负责、独立交付和独立运行的业务边界。拆分带来的网络、故障和数据一致性问题不会因为使用框架而消失，只会通过明确的契约、时间与资源边界、幂等和补偿设计、自动化交付以及可观测性得到控制。

判断是否采用微服务时，应把两个问题分开：系统当前的问题是否真的需要解决，以及拆成服务是否是成本最低的解决方案。对于多数仍在快速变化的小型系统，结构清晰的模块化单体是更稳妥的起点；当独立交付和扩缩容的收益已经被事实证明，再渐进拆分通常更容易成功。

参考资料#

• Spring Cloud Commons：服务发现与通用抽象
• Spring Cloud LoadBalancer
• Spring Cloud Gateway
• Nacos：Service Discovery Overview
• Kubernetes：Service
• Microsoft Azure Architecture Center：Circuit Breaker
• Microsoft Azure Architecture Center：Saga
• Microsoft Azure Architecture Center：Transient Fault Handling
• OpenTelemetry：Signals