设计备选方案阶段的三种常见错误

架构设计本质上不是凭空发明，而是对已经过时间检验的成熟技术模式（高可用的主备/集群方案、高性能的负载均衡/多路复用、可扩展的分层/插件化等）进行挑选组合和调整，只有在成熟方式完全无法满足需求时才需要真正创新，而创新本身多数情况下也是建立在已有技术之上的（如NoSQL本质是把数据库索引独立成缓存系统，Hadoop的基础是集群方案+数据复制方案）。正因为可选模式和组合方式非常多，”如何设计最终方案”这一步反而是架构师最容易犯错的地方，常见错误集中在三种。第一种是执着于设计”最优秀”的方案：出于证明自己技术能力的心理，倾向于选集群方案而非主备方案、选业界领先方案而非够用方案，这违背了[[合适原则：合适优于业界领先，及其三个失败根源]]——挑选适合自身业务、团队、技术能力的方案才是好方案，否则要么浪费大量资源做出没人用得起来的系统（如TPS 50000设计目标实际只跑出500的”亿级用户平台”案例），要么方案本身根本不可能落地（如10人团队想再造一个淘宝）。第二种是只做一个方案：仅凭简单的心理评估就锁定一个方案直接进入详细设计，弊端有三层——评估过于简单，容易因为某个局部缺点就否决掉综合来看其实最好的方案；架构师个人的经验和知识天然有局限，某条评估标准本身可能就是错的或已经过时；单一方案在评审时容易演变成”过度辩护”，评审焦点从”这个方案好不好”变成”架构师能不能自圆其说”。第三种是备选方案写得过于详细：把备选方案直接当成最终方案来精雕细琢，代价是耗费大量时间精力、注意力被拖进细节导致备选数量不够或差异不明显、评审时容易被参数级的争论（比如某个定时器该设1分钟还是30秒）带偏方向。这三种错误共同指向一个正确姿势：备选阶段应该聚焦在技术选型层面的差异（如ZooKeeper主备决策和Keepalived主备决策，差异就足够大），细节留到最终方案阶段再收敛，不需要在备选阶段就纠结。

结构图：

flowchart TB
  A["设计备选方案阶段的三种常见错误"]
  A --> B["错误①追求最优秀方案<br/>违背合适原则，导致资源浪费或方案根本无法落地"]
  A --> C["错误②只做一个方案"]
  C --> C1["评估过于简单：因局部缺点否决综合最优方案"]
  C --> C2["架构师经验有局限：评估标准本身可能有误或已过时"]
  C --> C3["单方案陷入过度辩护：评审变成为方案强词夺理"]
  A --> D["错误③方案写得过于详细"]
  D --> D1["耗费大量时间精力"]
  D --> D2["注意力陷入细节，忽略整体，方案数量或差异不足"]
  D --> D3["评审被参数级争论带偏"]
  B --> E["正确姿势：备选阶段只聚焦技术选型层面的<br/>明显差异，实现细节留到最终方案阶段收敛"]
  C --> E
  D --> E