# 五微服务三工程师：问题不在完美，在未经验证的假设

**Summary:** Var0 区分了完美与过度设计。我认同其诊断，但任何架构仍需用证据和运营成本来证明其假设的合理性。

- Canonical: https://markhuang.ai/zh/news/five-microservices-three-engineers
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-07-20
- Section: News
- Tags: 软件架构, 微服务, 工程管理, 产品工程
- Source: [var0.xyz](https://var0.xyz/posts/perfection-is-not-over-engineering.html)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![Mark 将紧凑的软件设计与五台纠缠的服务机器进行对比，一个小团队正在权衡其中的利弊](https://cdn.markhuang.ai/news/five-microservices-three-engineers/hero.webp)

*团队还没证明问题属于自己，就先把未来问题的架构搭好了——这笔账迟早要付。*

Var0 在 2026 年 7 月 19 日发了篇文章《[完美不等于过度设计](https://var0.xyz/posts/perfection-is-not-over-engineering.html)》，开头就甩出一个尖锐的例子：三个人维护五个共享数据的微服务。独立部署是拿到了，但数据库外键原本能直接保证的关系，现在变成了网络调用、松散的 ID 引用，以及数据悄悄漂移的更多可能。

这个论点有用的一半我买账。注重质量不等于过度设计。但我卡在了另一个说法上：只要需求足够清晰，就能推出唯一完美的方案。架构很少这么听话。需求互相打架，证据总是迟到，今天的约束搞不好就是下个季度的坑。我宁愿要一个能说清楚为什么这么设计、把赌注白纸黑字写下来的方案。

## 快速问答

| 问题       | 我的看法                                          |
| -------- | --------------------------------------------- |
| 源文在论证什么？ | 过度设计是指解决团队尚未面临的问题，而针对清晰约束的细致工作可以产生正确的解决方案。    |
| 哪部分有说服力？ | 架构成本应与真实的产品或运营需求挂钩，而非跟风或假设的规模。                |
| 哪部分言过其实？ | 清晰的需求并不总能导向唯一答案。成本、速度、可靠性、团队技能和可逆性仍可支持多种合理设计。 |
| 我会怎么做？   | 写下问题、证据、被否决的更简单方案，以及证明增加复杂性合理的条件。             |

## 五服务测试

这个微服务的例子之所以有说服力，是因为代价算得出来。同一个数据库里，外键就能把关系锁死；数据一旦拆到不同服务，这层保证就没了，得靠人去兜底——故障怎么处理、引用过期了怎么办、部署顺序怎么排、监控怎么做、出了问题怎么修，全要自己想清楚。

微服务是有前提的。Martin Fowler 2014 年就写过[微服务的前提条件](https://martinfowler.com/bliki/MicroservicePrerequisites.html)：快速开通环境、基本监控、快速部署、开发和运维紧密协作——这些能力得先有。独立部署确实有价值，但前提是组织规模或扩展压力真的需要它。如果压力不存在、能力也没到位，团队就是在独立部署回本之前先白扛了一堆额外工作。

![Mark 利用时间、团队、安全、性能和预算等约束，将众多软件路径收窄为一个简洁的设计](https://cdn.markhuang.ai/news/five-microservices-three-engineers/requirements.webp)

*约束的好处在于帮你砍掉诱人的选项。但如果你把对未来的猜测写成了需求，约束就会反过来害你。*

## 需求需要证据

Var0 说得最到位的地方，是把库、API、内部工具当产品看——有用户，有场景。这一转，工程师就不得不想：谁在用？用它干什么？微软的设计指南也从用户那边讲了同样的道理：[为大概率场景设计，别为所有可能性设计](https://learn.microsoft.com/en-us/windows/win32/uxguide/how-to-design-desktop-ux)。再小众的功能，只要摆在界面上，每个用户都得为它付出认知成本。

不过需求写下来不等于成立。“必须全球扩展”可能只是拍脑袋的预测。“团队需要独立部署”背后可能藏着所有权扯不清的问题。“我们需要灵活性”可能只是没人敢拍板。这些话如果不附上证据和时间窗口，几乎可以替任何抽象设计背书。

这里我想比 Var0 再往前走一步。即使问题是真实的，时机和规模都还没摸清就砸重金下去，同样算过度设计。高标准没毛病，但真正该被拎出来晒的是那些没人检验过的假设。

> **Info:**
>
> 加架构边界之前，我得先拿到四个答案：它挡住了哪种真实发生过的故障？简单方案到底差在哪？这条边界上线后要持续付什么代价？出现什么证据我们会把它拆掉？

## 算算接手的人要付多少代价

Google 的 Site Reliability Workbook 把简洁性当成端到端的系统属性，而不是代码风格偏好。它的[简洁性章节](https://sre.google/workbook/simplicity/)列了几个接地气的衡量指标：新人上手要多久、给别人讲明白要多久、运维要维护多少种不同的东西、线上跑着多少套配置。我喜欢这些指标，因为它们把架构图里藏起来的成本摆到了台面上。

一个设计，画的人觉得漂亮，运维的人可能叫苦连天。新人花几周才搞清楚服务拓扑，每个组件的部署流程都不一样——系统已经在吃团队的血了。这种消耗应该跟吞吐量、延迟一样，白纸黑字写进需求里。

社区里的讨论也能说明问题：光贴标签没用。Reddit 上有个 [ExperiencedDevs 帖子在讨论一个可疑的微服务设计](https://www.reddit.com/r/ExperiencedDevs/comments/utol87)，评论者追问：到底是哪条具体约束逼着你拆服务？也有人指出隔离确实有用的场景——资源需求差异大、合规边界要分开。这种回应才有价值：把拆分的理由摆出来。

![Mark 和两位同事在一个分布式系统中追踪故障，同时将其与一台紧凑的模块化机器进行比较](https://cdn.markhuang.ai/news/five-microservices-three-engineers/operational-cost.webp)

*监控、部署、故障响应、数据修复——这些账没算清楚之前，架构评审就不算完。*

## 完美需要保质期

Var0 的雄心我想留着，但终点得换一下。好的工程应该精准、避开意外冒出来的复杂性、把内部工具当产品认真做。但给设计贴上“完美”的标签，仍然可能遮住一个尴尬的事实：我们可能在一组经不起用户检验的假设上，做出了还不错的选择。

我会选能满足眼前证据的最小设计，然后记下是哪条约束让它胜出的。团队需要一条改得动的路，也需要一个理由——当使用量、人手、故障模式发生变化时，回去重新看当初的决定。如果五个微服务过了这一关仍然站得住脚，那就好好建。如果站不住，那问题从来不是完美主义，而是那张从来就没有证据支撑的复杂性账单。