Marketplace 微服务：什么时候必要，什么时候是多余的数百万
「一上来就微服务——好扩展。」听起来合理，直到看到报价：本可 4 个月 MVP，变成一年架构设计、三支 DevOps、发布还能带崩邻居服务。
对 marketplace 而言，微服务不是「成熟标志」，而是昂贵的工具——只在负载、变更速度、多团队等约束成立时才回本。其余情况是在为尚未赚到的复杂度买单。
为什么 marketplace 特别纠结
Marketplace 天然是多「产品」：买家前台、卖家后台、支付、搜索、审核、数据。第一天就「切服务」似乎合理。但实践中80% 新平台还没碰到微服务要解决的那些痛。
典型剧本：startup 规划 15–20 个服务、Kubernetes 和 event bus，订单还没过千。半年后团队花在协调发布和调试 RPC 上的时间，超过做 GMV 功能的时间。
微服务真正解决什么
不是「网站更快」，也不是「像淘宝那样 scale」。它解决三个管理问题：
- 独立发布——改 catalog 不必动 payment。
- 按需扩容——搜索 10 台，admin 1 台。
- 多团队并行——三个 squad 不在一个 repo 里互踩。
若只有 3–8 人、两周一发版——模块化单体 + 清晰边界 更便宜（起步常省 2–3 倍），商业模式还在变时也更易调整。
5 个信号：该把一块拆出去
- 发布要几周——改搜索也要回归整个单体
- 各块负载不同——搜索/catalog 吃 CPU，admin 闲着却一起扩容
- ≥2 个团队并行——单 repo 冲突和「排队上线」
- 一个模块挂全站——PDF 生成 bug 拖垮下单
- 有可测瓶颈——压测显示 90% 延迟在一个组件
命中两条及以上——计划只拆一个热点模块（常见：搜索、支付、通知），而不是「全部重写」。
4 个信号：现在上微服务是浪费
- 12 个月内没有 GMV 目标——在优化未来的 infra，不是当下的产品。
- 工程师 <10 人——DevOps、监控、服务契约 overhead 吃掉收益。
- 商业模式每季度变——硬边界服务比重划单体模块更贵。
- 「我们要像大厂」——大厂的微服务是单体痛过之后才有的，不是第一单之前。
粗算要花多少钱
Marketplace MVP（catalog、订单、卖家、支付、admin）估算：
| 路径 | 首单周期 | 预算量级 |
|---|---|---|
| 模块化单体 | 2–4 个月 | 从 64 万元起 |
| Day-1 微服务 | 6–12 个月 | 200–320 万元起 |
| 无准备把单体拆微服务 | 在现状上 +4–8 个月 | 常为「干净重写」的 1.5–2 倍 |
* 典型 B2B marketplace；集成与设计会移动数字
差距不仅在开发。微服务要可观测性、每服务 CI/CD、runbook 与 on-call——相对维护良好的单体，月运维多 5,000–13,000 元。
可行策略：Strangler Fig
不是「单体 vs 微服务」，而是渐进外迁——成熟团队常用：
你不是「重写京东」，而是有钱再买 scale，不是预支。
反模式：分布式单体
最差结局：12 个微服务同步互调、共库、连锁宕机——付了微服务的复杂度，却保留单体的回归与恐惧改代码。
架构 review 时 CTO 该警惕：
- 一次点击 = 5+ 同步 HTTP 跨服务
- 多服务写同一批表
- 「临时」共享业务库被所有服务引用
- 没有 per-service 指标——只有「网站慢」
与 CTO / 供应商开会清单
- 12 个月 GMV 与 RPS 目标——数字，不是「用户很多」
- 一年后并行几个工程团队
- 压测里第一个撞墙的是哪个模块
- 拆之前能否在单体里描述模块边界
- 上线后 observability 与 on-call 预算有没有
- 迁一个服务 vs 优化单体（缓存、索引、队列）哪个更便宜
- 拆分时数据归属 schema——开发开始前就要定
要点
Marketplace 微服务不是目标也不是勋章，是对可测痛点（慢发布、瓶颈、多团队）的回应。起步更常赢的是模块化单体 + 预留架构 + 分阶段外迁计划。
NineLab 设计 marketplace 的方式：先跑通销售与清晰预算，再在数字指向瓶颈处 scale——而不是在 conference 上时髦的地方 scale。
主题常见问题
流量形态与数据往往与生产不一致。需要场景、与线上一致的指标，以及可回滚的逐步加压。
常见瓶颈在数据库与执行计划、连接池、同步外部调用与队列——可作为快速排查清单。
不一定：失效、冷启动与热点键可能适得其反。缓存要按读模型与 SLO 设计。
垂直扩展与查询优化触顶，且数据增长在分片键上可预期时。