架构11：评估备选方案

前言

设计备选方案是架构设计中最具创造性的阶段，它考验的是架构师的想象力与技术积淀。然而，创造力只是起点，真正的挑战在于抉择。当我们手握三到五个各具特色的备选方案时，如何拨开迷雾，选择那条最适合当前业务发展的道路？这不是一道简单的算术题，而是一场关于权衡与取舍的艺术之旅。

为何评估和选择备选方案如此困难？因为每个方案都是可行的——如果不可行就根本不应该作为备选方案；没有哪个方案是完美的，A 方案有性能的缺点，B 方案有成本的缺点，C 方案有新技术不成熟的风险；评价标准的主观性较强，容易陷入无谓的争论。

最简派：设计师挑选一个看起来最简单的方案。例如，做全文搜索功能，MySQL 的查询功能比较简单，而 Elasticsearch 的倒排索引设计要复杂得多，所以干脆就挑选 MySQL 来做吧。这种做法忽略了长期的技术债务和未来的扩展需求。

最牛派：设计师会倾向于挑选技术上看起来最牛的方案。性能最高的、可用性最好的、功能最强大的，或者淘宝用的、微信开源的、Google 出品的。这种做法可能导致"杀鸡用牛刀"的浪费，或者引入团队无法驾驭的复杂技术。

最熟派：设计师基于自己的过往经验，挑选自己最熟悉的方案。这种做法虽然降低了风险，但也可能错失更优的解决方案。

领导派：列出备选方案后让领导来定夺。这种做法虽然规避了决策风险，但也失去了架构师应有的专业判断。

真正应该选择哪种方法来评估和选择备选方案？答案就是"360 度环评"！具体的操作方式为：列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。

常见的方案质量属性点有：

在评估这些质量属性时，需要遵循架构设计原则中的"合适原则"和"简单原则"，避免贪大求全。某个质量属性能够满足一定时期内业务发展就可以了。

例如，如果我们做一个购物网站，现在的 TPS 是 1000，如果我们预期 1 年内能够发展到 TPS 2000，在评估方案的性能时，只要能超过 2000 的都是合适的方案，而不是说淘宝的网站 TPS 是每秒 10 万，我们的购物网站就要按照淘宝的标准也实现 TPS 10 万。

完成方案的 360 度环评后，我们可以基于评估结果整理出环评表，一目了然地看到各个方案的优劣点。但 360 度环评表也只能帮助我们分析各个备选方案，还是没有告诉我们具体选哪个方案。

面临选择上的困难，有几种看似正确但实际错误的做法：

数量对比法：简单地看哪个方案的优点多就选哪个。这种方案主要的问题在于把所有质量属性的重要性等同，而没有考虑质量属性的优先级。

加权法：每个质量属性给一个权重，然后将每个方案的权重得分加起来。这种方案主要的问题是无法客观地给出每个质量属性的权重得分。

正确的做法是按优先级选择：架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。

回到"前浪微博"的场景。针对上期提出的 3 个备选方案，架构师组织了备选方案评审会议。

备选方案 1：采用开源 Kafka 方案

业务主管：倾向于采用 Kafka 方案，因为 Kafka 已经比较成熟
研发人员：部分支持使用 Kafka 能节省大量的开发投入；但部分人员认为 Kafka 可能并不适合我们的业务场景，因为 Kafka 的设计目的是为了支撑大容量的日志消息传输
运维代表：强烈反对！运维团队没有维护 Scala 语言开发的系统的经验，而且使用 Kafka 无法融入现有的运维体系
测试代表：倾向于引入 Kafka，因为 Kafka 比较成熟，无须太多测试投入

备选方案 2：集群 + MySQL 存储

备选方案 3：集群 + 自研存储系统

架构师经过思考后，给出了最终选择备选方案 2，原因有：

排除备选方案 1 的主要原因是可运维性，因为再成熟的系统，上线后都可能出问题，如果出问题无法快速解决，则无法满足业务的需求；并且 Kafka 的主要设计目标是高性能日志传输，而我们的消息队列设计的主要目标是业务消息的可靠传输
排除备选方案 3 的主要原因是复杂度，目前团队技术实力和人员规模无法支撑自研存储系统
备选方案 2 的优点就是复杂度不高，也可以很好地融入现有运维体系，可靠性也有保障

针对备选方案 2 的缺点，架构师解释是：