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

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

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

快速问答

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

五服务测试

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

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

需求需要证据

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

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

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

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

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

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

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

完美需要保质期

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

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