在我们上次讨论完备选方案的设计后，接下来的一大挑战是从这些方案中选出最合适的一个。挑选过程困难，主要是因为：

每个提出的方案本身应该是可行的，否则它不应该成为备选方案。

没有一个方案是完全无缺的。比如，方案A可能在性能上有劣势，方案B可能成本较高，方案C可能涉及到尚未成熟的技术风险。

评价标准往往很主观，不同的设计师对同一方案的复杂性评估可能大相径庭，因为“复杂”这个词本身很难量化。因此，在方案评审中，设计师们经常因为对某个技术点的看法不同而争论激烈。

正因为这些选择困难，设计师或架构师通常会采取以下几种思路来指导选择：

最简派

设计师倾向于选择看起来最简单的方案。例如，如果要实现全文搜索功能，方案1是基于MySQL，而方案2是基于Elasticsearch。MySQL的查询功能简单直接，而Elasticsearch的倒排索引设计则复杂得多，涉及到设计索引、配置分布式等多个步骤，所以选择MySQL似乎是更简单的选择。

最牛派

与最简派正相反，一些设计师更倾向于选择技术上最先进的方案。他们可能会选择性能最优、功能最全或者是由著名公司使用或开源的技术。比如在选择缓存技术时，虽然Memcache是简单的纯内存缓存解决方案，但Redis提供了持久化、数据结构支持、主备复制和集群等功能，显得更加强大。

最熟派

根据自己的经验，设计师会选择他们最熟悉的方案。例如，一个有丰富C++经验的设计师在需要开发一个运维管理系统时，即使Python或Ruby on Rails可能更适合，他们也可能继续选择使用C++。

领导派

在这种方式中，设计师列出所有备选方案，但难以自己做出决定，于是让领导作出最终决策。这样，成功的话可以归功于领导的决策，失败了也可以让领导“背锅”。

这些方法没有绝对的对错，关键在于要根据不同的情况选择合适的方法。换句话说，有时候我们需要选择最简单的方案，有时候需要选择最优秀的方案，有时候应该选择最熟悉的方案，有时甚至需要领导来决定。问题的关键在于如何判断“有时候”应该如何选择？今天，我们将探讨架构设计流程的第三步：评估和选择备选方案。

这些选择方法并没有绝对的正确或错误，关键在于根据不同情景选择合适的策略。这就引入了“360度环评”方法来评估和选择备选方案：列出所有关键的质量属性点，如性能、可用性、成本、项目投入、复杂度、安全性和可扩展性等，并从这些维度评估每个方案，从而选择最适合当前情况的方案。

例如，对于一个目前TPS为1000的购物网站，预期一年内增长至TPS 2000，那么在性能评估时，任何能支持超过2000 TPS的方案都是可行的。如果担心业务突飞猛进，增长到10000 TPS，虽然可能性低，但考虑这种极端情况会导致过度设计。这时候，应遵循“演化原则”，即使真的需要，也应该接受重新设计的成本，因为业务的大幅增长通常意味着更多的资源和投入。

通常，如果质量属性与业务发展密切相关，可以简单地将当前业务规模扩大2至4倍来进行评估。例如，当前TPS为1000，可以考虑按TPS 4000设计；如果TPS已经是10000，那么按TPS 20000来设计可能更合适。

最理想的是设计一个方案，能够通过简单扩容来适应业务增长，如TPS从2000增至20000只需增加机器数量即可。但实际情况通常复杂，量的增加可能带来质的变化。例如，团队从5人增至20人时，可能需要系统拆分和架构升级。

通过360度环评，我们可以整理出一张表格，清晰展示各方案的优劣。尽管这帮助我们进行了全面分析，但通常不会有一个方案在所有维度上都是最优的。因此，选择合适的方案仍需要综合考虑，比如开源方案虽然简化了工作量，但可运维性和可扩展性可能较差；自研方案工作量大，但更加可控等。这些考量都需要在选择过程中权衡。

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

数量优势法：这种方法通过简单比较各方案的优点数量来决定选择哪个方案。例如，在5个比较的质量属性中，如果方案A在3个属性上占优，而方案B在2个属性上占优，则选择方案A。

这种方法的主要问题在于它将所有质量属性视为等同重要，忽略了各属性之间的优先级区别。比如对于像BAT这样的大型企业，方案的成本通常不是主要考虑因素，可用性和可扩展性的重要性远超成本；然而对于初创企业，成本可能是一个非常重要的考虑因素。

此外，这种方法可能遇到两个方案在优点数量上相等的情况。假设比较6个质量属性，两个方案可能各有3个优点。在这种情况下，选择就变得困难；如果为了打破平衡而强行增加一个质量属性进行比较，这个后加的不那么重要的属性可能会不合理地成为决定性因素，这也反映出了没有适当区分质量属性优先级的问题。

加权评分法：这种方法是为每个质量属性分配一个权重，例如，将性能的高、中、低三个等级分别评为10分、5分和3分；成本的高、中、低则分别评为5分、3分和1分。接着，计算每个方案根据这些权重得到的总分，最终选择分数最高的方案。

这种方法的主要问题是难以客观地确定每个质量属性的权重。比如为什么性能的权重要设为10分、5分和3分而不是5分、3分和1分，或者100分、80分和60分？这些分数的设定没有一个固定的标准，而且可能因设计师的主观意愿而调整权重，使方案的选择成为了一场数字游戏。

更合适的做法是基于优先级进行选择。架构师应考虑当前业务的发展状况、团队的规模和技能水平、业务的预期增长等因素，按照这些质量属性的优先级进行排序。优先选择满足最高优先级需求的方案，如果有多个方案均满足首要条件，则考虑次一级的优先条件，依此类推。那么，是否可能存在两个或多个方案在每个质量属性上的优缺点完全相同呢？理论上是有这种可能，但实际上几乎不会发生。正如之前所述，在设计备选方案时，应确保不同方案之间存在明显的差异，这样明显的差异保证了不同方案的优缺点不会完全一样。

评估和选择备选方案实战

在最近的“前浪微博”项目方案评审会议上，有来自研发、测试、运维以及核心业务部门的主管参加。讨论了三种不同的解决方案，以下是会议的主要内容和反馈：

1. 使用开源 Kafka 解决方案：

• 业务部门的负责人偏好采用 Kafka，因其技术成熟且大部分团队有相关经验。

• 部分中间件团队研发支持使用 Kafka，以减少开发成本。然而，其他一些研发人员担心 Kafka 可能不适合我们的具体业务需求，因其主要设计用途是处理大量日志消息，而非高可靠性的业务数据传输。

• 运维团队强烈反对，理由是他们缺乏维护用 Scala 编写的系统的经验，且 Kafka 难以融入现有运维体系。

• 测试团队倾向于采用 Kafka，因其成熟稳定，减少了测试工作量。

• 部分中间件研发人员认为该方案简单直接，但也有人担心使用 MySQL 存储消息可能会导致性能不足。

• 运维团队赞成此方案，因为它可以整合进现有的运维体系，而且他们有丰富的 MySQL 维护经验。但他们也指出成本较高，因为每个数据组需要四台机器。

• 测试团队认为此方案需要较大的测试投入，包括功能、性能和可靠性测试。

• 业务主管对此方案持中立态度，他们关心的是消息队列系统的稳定性和可靠性。

• 部分研发人员看好这个方案，认为能展示团队的技术实力，性能也优于 MySQL 方案。但也有人担心由于团队资源和技术限制，开发一个稳定可靠的存储系统可能需要较长时间，期间可能出现严重的存储问题。

• 运维团队不支持自研方案，因为他们过去遇到过自研存储系统导致的数据丢失问题。

• 测试团队认为自研系统的测试难度大，需要大量的资源投入。

• 业务主管持保留意见，担心新系统可能存在的bug会导致严重的消息丢失，影响系统稳定性。

针对 3 个备选方案的讨论初步完成后，架构师列出了 3 个方案的 360 度环评表：

列出这个表格后，无法一眼看出具体哪个方案更合适，于是大家都把目光投向架构师，决策的压力现在集中在架构师身上了。

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

排除备选方案 1 主要是因为其可运维性问题。尽管 Kafka 系统本身非常成熟，但其主要用途是高性能的日志传输，并不完全符合我们对业务消息可靠传输的需求。此外，运维团队缺乏维护用 Scala 编写的系统的经验，这可能导致一旦系统出现问题，难以快速解决，从而无法满足业务的连续性和稳定性需求。

排除备选方案 3 的主要理由是方案的高复杂度。鉴于目前中间件团队只有六名成员，同时还需负责其他中间件系统的开发和维护，团队的技术能力和人力资源不足以支撑开发和维护一个全新的自研存储系统。这违反了架构设计的简单原则。

备选方案 2 的主要优点是其较低的复杂度和良好的可融合性。该方案能够顺利整合进现有的运维体系中，并且由于使用了 MySQL 存储数据，其可靠性得到了保证。

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

备选方案 2 首要面临的挑战是性能，虽然目前的业务性能需求不高，并且该方案能满足这些需求。即使未来业务对性能的要求增长，方案 2 的数据分组结构也支持水平扩展，以应对更高的性能需求，符合架构设计的演化原则。

第二个挑战是成本问题，方案 2 需要为每个分组配备四台机器，这对当前的业务需求来说可能意味着需要12台服务器。然而，备用服务器和数据库主要用于数据备份，有潜力与其他系统共享同一硬件资源。

第三个挑战在于，技术上这个方案可能看起来不够先进，但我们的目标不在于展示技术能力，而是要迅速且有效地满足业务需求，这符合架构设计的合适原则。

最后，大家针对一些细节再次讨论后，确定了选择备选方案 2。

通过分析“前浪微博”案例，我们可以明白，选择备选方案并非仅仅基于性能或技术优势等技术性指标。业务需求的具体特点、运维团队的技能和经验、现有的技术架构以及团队的技术能力，都是决定方案选择的重要因素。因此，对于同样的三个备选方案，不同的团队可能会做出不同的选择。例如，资源有限且追求快速部署的初创企业团队可能倾向于选择 Kafka；而像阿里这样资源充足、业务复杂且技术团队庞大的公司，则可能选择开发像 RocketMQ 这样的自研存储系统。