复杂性流行病

软件行业有一个复杂性问题。不是我们所解决问题的固有复杂性——那是不可避免的。我说的是我们自己制造的复杂性：偶然复杂性。

一个拥有 10,000 用户的 CRUD 项目，部署在 Kubernetes 上，配备了 Istio、Prometheus、Grafana、ArgoCD、一个 Kafka 事件总线、12 个微服务、3 个不同的数据库和一个服务网格。为什么？因为 Netflix 是这么做的。因为在 2025 年这很"酷"。

结果是：一个 5 人开发团队花在管理基础设施上的时间比开发功能还多。

架构演进

软件架构的历史是一个复杂性不断增加的故事：单体、SOA、微服务、EDA。每一步都增加了复杂性。而在每一步，行业都将新架构呈现为通用解决方案。剧透：没有任何架构是通用的。

KISS 原则

Keep It Simple, Stupid（保持简单，笨蛋）。这个原则并不是说"保持简单，因为你能力不行。"它说的是：复杂性有成本，这个成本必须被证明是合理的。

每增加一个组件就多了一个需要维护的对象、一个潜在故障点、一项必需的技能、一笔基础设施费用、一分钟调试时间。

Kubernetes：完美案例

Kubernetes 在 Google/Netflix 规模上编排数百个容器时表现卓越。但对于部署一个拥有 5,000 用户的 MariaDB / MySQL + PHP/Node.js 应用？这是用大炮打蚊子。一台专用服务器上的 Docker Compose 可以以极小的成本完成同样的工作。

企业开始回归

Basecamp 将工作负载从云端迁回专用服务器，节省了数百万美元。Amazon Prime Video 将一个服务从微服务架构迁移到单体，成本降低了 90%。

根本问题

在选择任何技术之前，问自己：我要解决什么问题？不是"什么是流行的"或"什么能让我的简历更亮眼"。如果"为什么选择 Kubernetes？"的答案是"因为现在是 2025 年"，那么你有的是决策问题，而不是技术问题。

何时复杂性是合理的

1000 万用户，50 倍的负载峰值？Kubernetes 是合理的。200 名开发人员在一个产品上？微服务可以实现团队自治。每秒 100,000 个事件？Kafka 是正确答案。但这些案例是例外。90% 的 Web 应用没有这些约束。

我的简洁宣言

从单体开始——当单体的痛苦超过分布式的痛苦时再拆分
使用你熟悉的技术——精通的技术栈胜过流行但不熟悉的技术栈
数一数你的组件——组件数量超过开发人员数量是一个警示信号
衡量总成本——基础设施 + 开发 + 调试 + 培训时间
问"为什么？"——对于每个组件，如果答案是"以防万一"，就删除它

总结

最好的架构是能解决问题的最简单架构。不是最令人印象深刻的、不是最流行的、不是最完备的。而是最简单的。

拥抱简洁。你的团队、预算和用户都会感谢你。

本文最初发表于 Medium。

拥抱简洁