03 | 架构设计流程（三）：评估和选择备选方案

李运华 2019-09-06

上一期我讲了设计备选方案，在完成备选方案设计后，如何挑选出最终的方案也是一个很大的挑战，主要原因有：
每个方案都是可行的，如果方案不可行就根本不应该作为备选方案。
没有哪个方案是完美的。例如，A 方案有性能的缺点，B 方案有成本的缺点，C 方案有新技术不成熟的风险。
评价标准主观性比较强，比如设计师说 A 方案比 B 方案复杂，但另外一个设计师可能会认为差不多，因为比较难将“复杂”一词进行量化。因此，方案评审的时候我们经常会遇到几个设计师针对某个方案或者某个技术点争论得面红耳赤。
正因为选择备选方案存在这些困难，所以实践中很多设计师或者架构师就采取了下面几种指导思想：
最简派
设计师挑选一个看起来最简单的方案。例如，我们要做全文搜索功能，方案 1 基于 MySQL，方案 2 基于 Elasticsearch。MySQL 的查询功能比较简单，而 Elasticsearch 的倒排索引设计要复杂得多，写入数据到 Elasticsearch，要设计 Elasticsearch 的索引，要设计 Elasticsearch 的分布式……全套下来复杂度很高，所以干脆就挑选 MySQL 来做吧。
最牛派
最牛派的做法和最简派正好相反，设计师会倾向于挑选技术上看起来最牛的方案。例如，性能最高的、可用性最好的、功能最强大的，或者淘宝用的、微信开源的、Google 出品的等。

取消

完成

0/1000字

划线

笔记

复制

该试读文章来自付费专栏《架构设计流程详解》，如需阅读全部文章，
请订阅文章所属专栏。

立即订阅

登录后留言

精选留言(1)

SuperSnow

如果kafka是因为用于日志，不方便用于业务，那可以用其他消息队列啊。毕竟当高访问量时，关键业务同步走数据库，非关键还是最好靠MQ来搞成异步为好。
如果用成纯RDBMS不是不可以，但是还是感觉换另外一款MQ，然后DB+MQ这样是否比较优雅一些呢。

2019-09-11

 1

 8

收起评论

1









下载
客户端

返回
顶部