S17-B01 · 微服务是什么、带来哪些挑战

适用读者：准备拆服务、或已经在多服务里迷失的人。本系列第一篇。
前置：S15-A02（部署与 CI/CD）。
覆盖旧文：908(80) 909(104) 2621(293) 2643(426) + 2 张全景卡 = 2,116 点。
覆盖扩展：E-S17-001（拆分后的四个新问题）、E-S17-002（康威定律）。
下一篇：S17-B02 · 服务注册与发现。

1. 一句话结论

微服务不是"把代码拆小"，而是"把原来一次进程内调用，变成一次可能失败的网络调用"——所以所有新问题都来自"网络"和"多实例"。

2. 拆分后多出的四个问题（E-S17-001）

问题	单体里不存在，拆分后必须解决
发现	对方实例地址在变
调用可靠性	网络会超时/失败/重试
数据一致性	一次业务跨多个库
排障	一次请求跨 N 个服务

这四件事就是本系列的四条主线：注册发现（B02）、消息与重试（J01–J03）、分布式事务（J04）、链路追踪（A02）。

3. 什么时候不该拆

信号	说明
团队 < 10 人、业务未稳定	拆了只会增加运维成本
没有自动化部署	手动部署 N 个服务等于灾难
没有可观测性	出问题无从定位
强事务需求集中	拆分后要写分布式事务

判据："我的部署、监控、日志能支撑 N 个服务吗？" 不能 → 先补 S15-A02/A01 的能力，再拆。

4. 边界怎么划（E-S17-002）

康威定律：系统的结构会反映组织的沟通结构。

划法	说明
按业务能力（推荐）	订单/支付/库存各自独立
按技术分层	❌ 会导致每次改动跨多个服务
按团队边界	现实中最常见（与康威定律一致）

判据："这个服务能由一个团队独立负责、独立发布吗？" 不能 → 边界划错了。

5. 五个误区

误区	真相
"微服务=性能更好"	多一次网络往返，通常更慢
"服务越细越好"	运维成本指数上升
"拆了就不需要事务"	反而要分布式事务
"Spring Cloud 就是微服务"	只是工具集
"先拆再补可观测性"	会陷入无法排障

6. 自检

拆分后多出的四个问题？
什么条件下不该拆？
康威定律说的是什么？
按技术分层拆为什么不好？
微服务为什么常常"更慢"？

7. 下一篇

S17-B02 · 服务注册与发现

挑战讲完，下一篇解决第一个：实例地址总在变，调用方怎么找到它。

本篇属于系列《S17 · 分布式与消息队列》。旧文来源：A-908/909/2621/2643 + 2 张全景卡；扩展点 E-S17-001/002。