本文作者：Emma Wirt
在我的职业生涯中，我参与过 30 多次技术尽职调查，最初是在一家战略咨询公司的私募股权团队，现在则是在 Fika Ventures。这些是我反复看到会导致融资轮失败的架构选择。每一个在当时看起来都很合理，但在 18 个月后却成为了关键瓶颈。
(1) 过早采用微服务（过早优化）
我刚进入科技行业时，认为微服务是好的，单体架构是坏的；很简单，对吧？直到我的第一位主管 Michael 完全改变了我的看法。他教会我，真正的能力不是盲目崇拜或否定某种特定架构，而是理解在什么情况下哪种架构才是合理的。大多数在 A 轮阶段就采用微服务的公司，只是在不必要的复杂性上烧钱。
模式： 一个由 8 名工程师组成的团队管理着 15 个微服务。每个服务都有自己独立的部署流水线、监控和数据库。CTO 阅读了 Uber 工程博客后，决定“从第一天起就为规模化而构建”。
为什么这会扼杀交易：
- 工程开发速度下降 70% —— 每个功能都涉及 5 个服务
- 无法根据客户反馈快速迭代
- 为不到 100 位客户在 AWS 上多花了额外的 $$
- 仅基础设施就需要 3 名工程师
示例： 一家 B2B SaaS 公司，年经常性收入（ARR）为 200 万美元，却将 40% 的工程时间花在服务编排上 → 采用单体架构的竞争对手用一半的团队速度快 3 倍地交付 → 因竞争压力在融资轮中失利。
正确做法： 在 ARR 约 1000 万美元或工程师人数超过 30 人之前保持单体架构。在代码中使用服务边界（模块/命名空间），以便日后可以拆分。这不是硬性规则；请根据你公司的实际情况做决定。但请记住，Instagram 曾用 Django 单体架构扩展到 1 亿用户……
(2) 为数据模型选择了错误的数据库（无模式的诱惑）
模式： 因为“我们需要快速推进，而模式太有约束！！”所以一开始选择了 MongoDB / DynamoDB。快进到 18 个月后：你在应用层实现 ACID 事务，而你所谓“灵活”的文档在生产环境中已经有 30 种不同的结构……
为什么它会扼杀交易：
- 复杂查询需要多次往返或昂贵的聚合操作
- 财务报告需要 5 条不同的数据管道
- “最终一致性”？是的，这在涉及资金时并不总是奏效
- 你曾经喜欢的灵活性？现在你得手动迁移数百万份不一致的文档
示例 ： 一家使用 MongoDB 存储交易数据的金融科技初创公司，在其上构建了自己的交易层 → 在尽职调查期间，对账发现报告收入与数据库记录之间存在差异 → 修复需要对整个数据库层进行重构 → 也就是说，他们没有的 6 个月时间
正确做法： 让数据库与数据模型匹配！
- 关系型 + 事务处理 → PostgreSQL / MySQL
- 时间序列 → TimesaleDB / InfluxDB
- 文档存储 → MongoDB（用于真正的文档！）
- 键值存储 → Redis / DynamoDB
别误会——在产品目录、内容管理和用户会话方面，MongoDB 非常出色。但在处理财务账本、社交图谱或任何具有复杂关系的数据时，它的体验就会变得很痛苦。
(3) 构建在已弃用或即将淘汰的技术之上
这不是显而易见的吗？但你会惊讶于我看到有多少产品还在使用 Angular 前端……
模式： 核心产品建立在 Angular.js、CoffeeScript、Backbone 或其他已被弃用的框架上……“它运行得很好，很流行，也很简单，我们为什么要重写呢？”
为什么它会扼杀交易：
- 未来的招聘计划——你打算去哪里找到愿意在过时技术上工作的 10 倍工程师？
- 安全漏洞没有得到修补
- 没有生态系统——每个功能都需要从零开始构建
示例： 一家医疗公司用 Backbone.js 编写了整个前端。→ 8 个月内一直难以招聘到工程师 → 两名高级前端工程师中的一位离职 → 产品开发显著放缓。
正确做法： 将 20% 的工程时间预算用于框架升级。如果某个框架在 2 年内没有重大版本发布，就开始考虑迁移！有时候，选择那些“无聊”的框架（React、Vue 等）反而是明智之举，你的招聘经理会感谢你的 :)
(4) 从第一天起就没有 API 策略（集成噩梦）
常见模式： 一切都是通过 UI 构建的。现在你的客户想要 API！你正在为 UI 控制器临时添加 REST 端点。没有任何版本控制。到处都是破坏性变更。
为什么它会让交易告吹：
- 无法为需要集成的客户提供服务
- 移动应用正在调用持续出错的内部端点
- 没有可用的合作伙伴生态系统
- API 直接暴露内部数据模型
示例： 垂直型 SaaS 公司因集成需要“3–4 个月的定制开发”而失去 3 笔价值超过 $500k ARR 的企业交易 → 在客户电话中被揭示这是常态而非个例后，投资人选择退出。
正确做法： 从第一天起就优先构建 API。你的 UI 应该使用与提供给客户相同的 API。使用正确的版本控制（v1、v2）。用 OpenAPI / Swagger / 你偏好的服务记录所有内容。你的 API 是一个产品，而不是事后补充。
(5) 忽视多租户架构直到为时已晚（企业客户说再见）
常见模式： 每个客户都有自己独立的数据库/部署。前 10 个客户时还能运作良好。但现在你有 100 个客户，AWS 账单高达 $200k/月。企业客户现在还要求为他们的实例提供 SOC 2 合规。
为什么它会扼杀交易：
- 毛利率是20%而不是80%
- 无法发布新版本——需要更新100个部署
- 安全补丁变成耗时数月的项目
- 企业级功能（SSO、审计日志）需要重复构建一百次！
示例： 一家拥有 150 次部署的 MarTech 初创公司 → 5 人的 DevOps 团队只能勉强维持系统运行，基础设施成本严重影响单元经济效益 → 投资者难以找到盈利路径。
正确做法： 从一开始就构建多租户架构并实现逻辑隔离。在数据库中使用行级安全。如果确实需要物理隔离，优先选择每个租户一个 schema，而不是每个租户一个数据库。每个租户单独容器仅适用于有明确逻辑需求的真正企业级合同。
核心结论
事情是这样的：这些并不是糟糕的技术决策；它们只是做出的时机不对。这些架构在某个阶段都是合理的。但那些成功完成融资的创始人明白，架构应该跟随收入，而不是走在收入前面。
这是一个非常简单且适合阶段的框架：
- $0–1m ARR：单体架构、PostgreSQL、API 优先、多租户
- $1–10m ARR：增加缓存、异步任务、只读副本、监控
- 年经常性收入超过 $10m：可以考虑微服务、多语言持久化、“有趣”的技术
Michael Scott 说得最好：KISS —— “保持简单，笨蛋”
最优秀的 CTO 会优化开发速度和客户价值，而不是追求架构的纯粹性。我向你保证！你的投资人和客户都会感谢你。