备选方案设计的三条实操准则

避开[[设计备选方案阶段的三种常见错误]]之后，具体该设计几个方案、方案之间要差多少、从哪里找方案，有三条可操作的准则。第一，备选方案数量以3~5个为最佳：少于3个往往说明思维还不够开阔、考虑不够周全；多于5个则会耗费过多精力和时间，而且方案之间的差别常常已经不明显，边际收益很低。第二，备选方案之间的差异要落在架构层面而非细节层面：主备方案和集群方案属于架构层面的明显差异，同样是主备方案但换用ZooKeeper做主备决策还是Keepalived做主备决策，差异也足够明显；但如果都用ZooKeeper做主备决策，只是一个检测周期设1分钟、另一个设5分钟，这只是参数细节的差异，不构成两个独立备选方案，应当在最终方案里选定后再细化，而不是在备选阶段就分裂成两个方案。第三，备选方案考察的技术范围不能只局限于自己已经熟悉的技术：架构师往往出于快速完成任务、降低风险的心理，会不自觉地倾向套用自己熟练的技术去解决新问题——就像那句俗语”如果你手里有一把锤子，所有的问题在你看来都是钉子”，例如对MySQL很熟悉的架构师，遇到性能不够时第一反应往往是分库分表，而实际上引入一个Memcache缓存可能就足以解决问题。这三条准则背后有一个共同的现实约束：团队的技术背景本身会天然收窄备选方案的可选范围（比如Java背景的团队，多个备选方案往往都基于同一套Java网络库展开），成熟团队通常不会轻易切换技术栈，反而是新成立的团队更愿意尝试新技术——这本身也是”合适原则”的自然延伸，而不是缺陷。