为简单架构辩护 (2022)

简单架构 vs 复杂架构

• 许多评论者支持“无聊”的技术栈（Rails/Django，或 Python+Postgres，SSR 模板 + htmx，单一 VPS），认为它们对大多数 CRUD/业务应用已经足够，尤其是 B2B 场景。
• 他们强调，简单系统更容易理解、维护、调试，也更容易配备人员；“老而可靠”往往胜过“新而炫”。
• 也有人认为，什么算“简单”本身是主观的：容器、k8s、GraphQL 或异步 I/O，对熟悉它们的人来说可能很简单，对其他人则很复杂。

单体、微服务与事件溯源

• 很多人强烈支持从单体开始，并用清晰的模块和边界来组织；不少人声称，纪律严明的单体可以扩展到很远。
• 微服务的批评者认为，它们并没有降低复杂度，只是把复杂度搬到了网络上，使一致性、事务、调试和部署都更困难。
• 支持微服务的人则主要把它们视为一种组织与协作工具：能支持独立团队、隔离故障，以及有针对性的扩展。
• 有些人把事件溯源/CQRS 提议为“做对了的微服务”，但另一些人认为它不成熟且复杂（PII 删除、重放语义、确定性）。

技术选择：Python、GraphQL、Kubernetes

• 一些人认为，文中描述的技术栈（Python 单体 + Postgres + 队列 + GraphQL + k8s + 自定义协议）并不是真的“简单”，并对其中几项选择提出质疑。
• 关于金融领域使用 Python 的争论：一些人认为静态类型对处理金钱至关重要；另一些人则认为现代 Python 工具链（mypy、C FFI、丰富的库）已经足够。
• GraphQL 既得到称赞（减少 REST 端点膨胀、共享 schema、强类型），也遭到反对（概念复杂、响应体过大、并非比 REST 更必需）。
• 有些人认为 Kubernetes 对小团队来说是不必要的开销；另一些人则说，托管的 k8s 集群可以成为运行“普通”三层应用的一种直接方式。

人和组织因素

• 许多人将复杂性归咎于简历驱动或“喜鹊式”工程：为了学习或显摆而采用 Kafka、微服务、云等，而不是为了解决真实问题。
• 也有人指出，探索本身是有价值的，但应该发生在原型、个人项目或受限场景中，而不是核心生产系统里。
• 还有几条评论强调，架构必须匹配组织现实：团队规模、经验、所有权和激励，比具体模式更重要。

规模、性能与“你用不着它”

• 一派认为，同步 I/O 和单一数据库就能轻松处理“每月数百万请求”；在引入分布式复杂性之前，先把机器做大。
• 另一派警告，阻塞 I/O 和选型不当的技术栈，即使在低流量下也可能崩掉，尤其是在下游延迟激增时。
• 大家普遍同意，过早“按 Netflix 的方式构建”已经拖垮或拖慢了许多公司，但同样，设计不足将来修复起来也可能代价高昂。

职业、激励与价值

• 有些人担心，专注于“无聊技术”会损害职业前景，因为招聘往往会按流行技术栈筛人。
• 另一些人反驳说，可量化的业务影响（“节省了 X，带来了 Y 收入”）在高级别岗位上比技术套话更有说服力。
• 还有几条评论指出激励失配：廉价资本和“不计代价增长”鼓励了浪费性的复杂化；建议把工程师更紧密地绑定到业务结果上，作为纠偏。