03 - 微服务解决了什么，又带来了什么
上一章我们把电商拆成了四个独立的服务。这一章先看它治好了第 01 章的哪些病，再泼一盆冷水，看它又添了哪些新麻烦。
先看好处：第 01 章的五个痛点，一一化解
| 单体的痛点 | 微服务怎么解决 |
|---|---|
| 改一行就要整体重新部署 | 改商品服务只重部署商品服务，独立部署，其他不动 |
| 一处崩全体崩 | 支付服务挂了，用户还能登录、还能逛商品，故障被隔离 |
| 扩容不精准、烧钱 | 订单忙就只给订单服务加机器，按需精准扩容 |
| 几十人挤一个代码库 | 每个团队负责一个服务，各自开发发布，团队解耦 |
| 技术栈焊死 | 推荐服务可以用 Go，AI 服务可以用别的语言，各服务自选技术栈 |
看起来很美好。但——
泼盆冷水：微服务不是银弹
有句话必须记住：
微服务没有消灭复杂度，它只是把”代码复杂度”变成了”分布式系统复杂度”。
单体里，四个模块在同一个进程里，互相调用就是普通的函数调用——稳、快、简单。一旦拆成四个跑在不同机器上的服务，它们之间就隔了一层网络。而网络，是会出问题的。
微服务带来的四个新麻烦
麻烦 1：调用会失败（网络不可靠）
单体里调个函数几乎不可能”失败”。但微服务里，订单服务通过网络去问用户服务，可能：
- 网络抖动，超时了
- 用户服务刚好在重启，连不上
你必须处理”对方没回应怎么办”——重试？降级？这些在单体里根本不用操心。
麻烦 2：数据一致性变难
单体里，“扣库存 + 创建订单”可以放在一个数据库事务里，要么全成、要么全滚，很省心。
拆开后，库存在商品库、订单在订单库，是两个数据库。没法用一个事务包住了。万一订单创建成功、扣库存却失败了，数据就乱了。（第 05 章细讲怎么应对。）
麻烦 3：运维和排查变复杂
- 原来 1 个应用，现在 10 个服务，都要部署、监控、看日志
- 一个请求跨了好几个服务，出错了，到底是哪一环挂的？光翻日志能翻晕
服务越多，运维成本越高。这也是为什么微服务几乎总是和 Docker、K8s 绑在一起（第 07 章）。
麻烦 4：本地开发调试变麻烦
原来 python main.py 一下，整个系统就起来了。现在你想在本地跑通一个”下单”流程，得同时把用户、商品、订单、支付四个服务都启动才行。
关键判断：到底该不该上微服务？
这是本章最重要的一句话：
微服务是用来解决”规模变大”带来的问题的。如果你还没大到那个份上，硬上微服务只会自找苦吃。
给一个简单的判断参考：
该老老实实用单体 👇 该考虑微服务 👇
───────────────────── ─────────────────────
• 团队就几个人 • 几十上百人，多个团队
• 业务还在快速试错、常变 • 业务已稳定，边界清晰
• 用户量不大，一台机器扛得住 • 流量大，不同模块负载差异大
• 想快速上线、快速迭代 • 单体已经大到改不动、发布互相拖累初创团队、个人项目，先用单体。等真的被单体的痛点折磨到了，再拆也不迟。过早微服务化，是新手最常见的坑。
小结
- 微服务确实解决了单体的五大痛点：独立部署、故障隔离、精准扩容、团队解耦、技术自由。
- 但代价是：把代码复杂度换成了分布式复杂度——调用会失败、数据一致性难、运维排查复杂、本地调试麻烦。
- 微服务不是越先进越好，只在”规模足够大”时才划算。小团队请先用单体。
上一章 ← 02 - 微服务到底是什么 ｜ 下一章 → 04 - 服务之间怎么”说话” ｜ 回到 README 目录