共计 4116 个字符，预计需要花费 11 分钟才能阅读完成。
大家好，我是易安！
在实现备选方案设计后，如何筛选最终的计划是一个很大的挑战，因为每个备选计划都是可行的。然而，没有哪个备选计划是完满的，因为每个计划都存在一些毛病或危险。此外，评估备选计划的规范也具备肯定的主观性，可能会导致设计师之间产生争执。
因而，在实践中，许多设计师或架构师采取了上面几种指导思想来抉择备选计划：
- 简略派
设计师筛选一个看起来最简略、最容易实现的计划。例如，如果要做全文搜寻性能，MySQL 的查问性能比较简单，而 Elasticsearch 的倒排索引设计要简单得多，所以可能会抉择 MySQL。
- 最牛派
最牛派的做法与最简派正好相同，设计师会偏向于抉择技术上看起来最牛的计划。例如，如果要抉择一个搭配 MySQL 应用的缓存，可能会抉择 Redis，因为它反对长久化、数据字典、主备、集群等性能。
- 最熟派
设计师基于本人的过往教训，抉择本人最相熟的计划。例如，如果设计师已经是一个 C ++ 经验丰富的开发人员，当初要设计一个运维管理系统，因为对 Python 或 Ruby on Rails 不相熟，可能会持续抉择 C ++ 来做运维管理系统。
- 领导派
领导派将备选计划列出，而后让领导来决定最终计划。这种做法可能会让设计师本人拿捏不定，但最终的责任会由领导来承当。
不同的做法自身并不存在相对的正确或者相对的谬误，要害是要依据不同的场景抉择不同的形式。有时候要抉择最简略的计划，有时候要抉择最优良的计划，有时候要抉择最相熟的计划，甚至有时候须要领导来拍板。因而，关键问题是如何判断何时采纳这些不同的抉择形式。在架构设计流程的第 3 步：评估和抉择备选计划中，抉择备选计划的办法应该依据具体场景和理论状况进行评估和决策。
计划评估
在评估和抉择备选计划时，咱们应该采纳全方位评估的办法。具体来说，咱们须要列出咱们须要关注的品质属性点，并从这些品质属性的维度去评估每个备选计划，再综合筛选适宜过后状况的最优计划。
常见的计划品质属性点包含性能、可用性、硬件老本、我的项目投入、复杂度、安全性、可扩展性等。在评估这些品质属性时，须要遵循架构设计准则 1“适合准则”和准则 2“简略准则”，防止贪大求全，基本上某个品质属性可能满足肯定期间内业务倒退就能够了。
例如，在设计一个购物网站时，如果咱们预期 1 年内可能倒退到 TPS 2000（业务一年翻倍曾经是很好的状况了），在评估计划的性能时，只有能超过 2000 的都是适合的计划，而不是依照淘宝的规范要实现 TPS 10 万。
在评估将来业务倒退的规模时，须要思考架构设计准则 3“演变准则”，防止适度设计、一步到位的想法。即便呈现业务迅猛发展，也要遵循这个准则，尽可能让零碎可能简略地扩容来跟上业务的倒退。
通常状况下，如果某个品质属性评估和业务倒退有关系（例如，性能、硬件老本等），能够通过将以后的业务规模乘以 2 ~4 来评估将来的业务倒退规模。例如，当初的 TPS 是 1000，则依照 TPS 4000 来设计方案；如果当初 TPS 是 10000，则依照 TPS 20000 来设计方案。
实现计划的 360 度环评后，咱们能够基于评估后果整顿出 360 度环评表，高深莫测地看到各个备选计划的优劣点。然而 360 度环评表也只能帮忙咱们剖析各个备选计划，还是没有通知咱们具体选哪个计划。因为没有哪个计划是完满的，不同备选计划之间的差别要比拟显著，差别显著的备选计划不可能所有的优缺点都是一样的。
如何抉择备选计划
面临多个备选计划的抉择时，咱们应该依照优先级抉择备选计划。即综合以后的业务倒退状况、团队人员规模和技能、业务倒退预测等因素，依照优先级抉择，即架构师综合以后的业务倒退状况、团队人员规模和技能、业务倒退预测等因素，将品质属性依照优先级排序，首先筛选满足第一优先级的，如果计划都满足，那就再看第二优先级，以此类推。
有时候会呈现两个或者多个计划，每个品质属性的优缺点都一样的状况。实践上是可能的，但实际上不太可能。因为在备选方案设计时，不同的备选计划之间的差别要比拟显著，差别显著的备选计划不可能所有的优缺点都是一样的。
实战
还是以之前咱们讲过的微博零碎设计，针对提出的 3 个备选计划，架构师组织了备选计划评审会议，加入的人有研发、测试、运维、还有几个外围业务的主管。
1. 备选计划 1：采纳开源 Kafka 计划
- 业务主管偏向于采纳 Kafka 计划，因为 Kafka 曾经比拟成熟，各个业务团队或多或少都理解过 Kafka。
- 中间件团队局部研发人员也反对应用 Kafka，因为应用 Kafka 能节俭大量的开发投入；但局部人员认为 Kafka 可能并不适宜咱们的业务场景，因为 Kafka 的设计目标是为了撑持大容量的日志音讯传输，而咱们的音讯队列是为了业务数据的牢靠传输。
- 运维代表提出了强烈的拥护意见：首先，Kafka 是 Scala 语言编写的，运维团队没有保护 Scala 语言开发的零碎的教训，出问题后很难疾速解决；其次，目前运维团队曾经有一套成熟的运维体系，包含部署、监控、应急等，应用 Kafka 无奈融入这套体系，须要独自投入运维人力。
- 测试代表也偏向于引入 Kafka，因为 Kafka 比拟成熟，毋庸太多测试投入。
2. 备选计划 2：集群 + MySQL 存储
- 中间件团队的研发人员认为这个计划比较简单，但局部研发人员对于这个计划的性能持狐疑态度，毕竟应用 MySQL 来存储音讯数据，性能必定不如应用文件系统；并且有的研发人员放心做这样的计划是否会影响中间件团队的技术名誉，毕竟用 MySQL 来做音讯队列，看起来比拟“土”、比拟另类。
- 运维代表同意这个计划，因为这个计划能够融入到现有的运维体系中，而且应用 MySQL 存储数据，可靠性有保障，运维团队也有丰盛的 MySQL 运维教训；但运维团队认为这个计划的老本比拟高，一个数据分组就须要 4 台机器（2 台服务器 + 2 台数据库）。
- 测试代表认为这个计划测试人力投入较大，包含功能测试、性能测试、可靠性测试等都须要大量地投入人力。
- 业务主管对这个计划既不必定也不否定，因为反正都不是业务团队来投入人力来开发，系统维护也是中间件团队负责，对业务团队来说，只有保障音讯队列零碎稳固和牢靠即可。
3. 备选计划 3：集群 + 自研存储系统
- 中间件团队局部研发人员认为这是一个很好的计划，既可能展示中间件团队的技术实力，性能上相比 MySQL 也要高；但另外的研发人员认为这个计划复杂度太高，依照目前的团队人力和技术实力，要做到稳固牢靠的存储系统，须要耗时较长的迭代，这个过程中音讯队列零碎可能因为存储呈现重大问题，例如文件损坏导致失落大量数据。
- 运维代表不太赞成这个计划，因为运维之前遇到过几次相似的存储系统故障导致数据失落的问题，损失惨重。例如，MongoDB 丢数据、Tokyo Tyrant 丢数据无奈复原等。运维团队并不置信目前的中间件团队的技术实力足以撑持本人研发一个存储系统（这让中间件团队的人员感觉有点不爽）。
- 测试代表同意运维代表的意见，并且自研存储系统的测试难度也很高，投入也很大。
- 业务主管对自研存储系统也持保留意见，因为从历史教训来看，新零碎上线必定有 bug，而存储系统出 bug 是最重大的，一旦出 bug 导致大量音讯失落，对系统的影响会重大。
针对 3 个备选计划的探讨初步实现后，架构师列出了 3 个计划的全方位评估表：
列出这个表格后，无奈一眼看出具体哪个计划更适合，于是大家都把眼光投向架构师，决策的压力当初集中在架构师身上了。
架构师通过思考后，给出了最终抉择备选计划 2，起因有：
- 排除备选计划 1 的次要起因是可运维性，因为再成熟的零碎，上线后都可能出问题，如果出问题无奈疾速解决，则无奈满足业务的需要；并且 Kafka 的次要设计指标是高性能日志传输，而咱们的音讯队列设计的次要指标是业务音讯的牢靠传输。
- 排除备选计划 3 的次要起因是复杂度，目前团队技术实力和人员规模（总共 6 人，还有其余中间件零碎须要开发和保护）无奈撑持自研存储系统（参考架构设计准则 2：简略准则）。
- 备选计划 2 的长处就是复杂度不高，也能够很好地融入现有运维体系，可靠性也有保障。
针对备选计划 2 的毛病，架构师解释是：
- 备选计划 2 的第一个毛病是性能，业务目前须要的性能并不是十分高，计划 2 可能满足，即便前面性能需求减少，计划 2 的数据分组计划也可能平行扩大进行撑持（参考架构设计准则 3：演变准则）。
- 备选计划 2 的第二个毛病是老本，一个分组就须要 4 台机器，撑持目前的业务需要可能须要 12 台服务器，但实际上备机（包含服务器和数据库）次要用作备份，能够和其余零碎并行部署在同一台机器上。
- 备选计划 2 的第三个毛病是技术上看起来并不很优越，但咱们的设计目标不是为了证实本人（参考架构设计准则 1：适合准则），而是更快更好地满足业务需要。
最初，大家针对一些细节再次探讨后，确定了抉择备选计划 2。
通过微博这个案例咱们能够看出，备选计划的抉择和很多因素相干，并不单单思考性能高下、技术是否优越这些纯技术因素。业务的需要特点、运维团队的教训、已有的技术体系、团队人员的技术水平都会影响备选计划的抉择。因而，同样是上述 3 个备选计划，有的团队会抉择引入 Kafka（例如，很多守业公司的初创团队，人手不够，须要疾速上线撑持业务），有的会抉择自研存储系统（例如，阿里开发了 RocketMQ，人多力量大，业务简单是次要起因）。
总结
备选计划评估和抉择是架构师工作的一个重要方面。架构师须要依据以后业务的理论状况，对备选计划进行全方位的评估，从各个品质属性的维度去评估每个计划，再综合筛选适宜过后状况的最优计划。在评估备选计划时，须要遵循架构设计准则 1“适合准则”和准则 2“简略准则”，防止贪大求全，基本上某个品质属性可能满足肯定期间内业务倒退就能够了。同时也要遵循原则 3“演变准则”，防止适度设计，一步到位的想法。最初，在抉择备选计划时，须要依照品质属性的优先级排序，一一抉择最适宜的计划。
总之，备选计划评估和抉择是一个全方位的过程，须要综合思考多方面的因素。只有在评估和抉择过程中遵循适合准则、简略准则和演变准则，并依照优先级一一抉择最适宜的计划，能力设计出高质量、可扩大、易保护、高性能的零碎架构。
如果本文对你有帮忙的话，欢送点赞分享，这对我持续分享 & 创作优质文章十分重要。感激！
本文由 mdnice 多平台公布
