如下内容来之https://time.geekbang.org/column/article/6463 学习笔记：

10 | 架构设计流程：识别复杂度

　　第 1 步：识别复杂度

　　是将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题。

　　“亿级用户平台”这个案例，团队就优先选择将子系统的数量降下来，后来发现子系统数量降下来后，不但开发效率提升了，

　　原来经常发生的小问题也基本消失了，于是团队再在这个基础上做了异地多活方案，也取得了非常好的效果。

　　例如，Hadoop 能够将高可用、高性能、大容量三个大数据处理的复杂度问题同时解决。

　　对于按照复杂度优先级解决的方式，存在一个普遍的担忧：如果按照优先级来解决复杂度，可能会出现解决了优先级排在前面的复杂度后，解决后续复杂度的方案需要将已经落地的方案推倒重来。

　　这个担忧理论上是可能的，但现实中几乎是不可能出现的，原因在于软件系统的可塑性和易变性。对于同一个复杂度问题，软件系统的方案可以有多个，总是可以挑出综合来看性价比最高的方案。

11 | 架构设计流程：设计备选方案

　　第 2步：设计备选方案

　　架构师的工作并不神秘，成熟的架构师需要对已经存在的技术非常熟悉，对已经经过验证的架构模式烂熟于心，然后根据自己对业务的理解，挑选合适的架构模式进行组合，再对组合后的方案进行修改和调整。

1. NoSQL：Key-Value 的存储和数据库的索引其实是类似的，
2. Memcache 只是把数据库的索引独立出来做成了一个缓存系统。
3. Hadoop 大文件存储方案，基础其实是集群方案 + 数据复制方案。
4. Docker 虚拟化，基础是 LXC（Linux Containers）。
5. LevelDB 的文件存储结构是 Skip List。

　　第一种常见的错误：设计最优秀的方案。

　　第二种常见的错误：只做一个方案。

1. 备选方案的数量以 3 ~ 5 个为最佳。
2. 备选方案的差异要比较明显。
3. 备选方案的技术不要只局限于已经熟悉的技术

　　第三种常见的错误：备选方案过于详细。

 

设计备选方案实战

　　备选方案 1：采用开源的 KafkaKafka 是成熟的开源消息队列方案，功能强大，性能非常高，而且已经比较成熟，很多大公司都在使用。

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

　　备选方案 3：集群 + 自研存储方案（参考 Kafka）

12 | 架构设计流程：评估和选择备选方案

　　正因为选择备选方案存在这些困难，所以实践中很多设计师或者架构师就采取了下面几种指导思想。

　　最简派

　　　　设计师挑选一个看起来最简单的方案。例如，我们要做全文搜索功能，方案 1 基于 MySQL，

　　　　方案 2 基于 Elasticsearch。MySQL 的查询功能比较简单，而 Elasticsearch 的倒排索引设计要复杂得多，写入数据到Elasticsearch，

　　　　要设计 Elasticsearch 的索引，要设计 Elasticsearch 的分布式……全套下来复杂度很高，所以干脆就挑选 MySQL 来做吧。

　　最牛派

　　　　最牛派的做法和最简派正好相反，设计师会倾向于挑选技术上看起来最牛的方案。例如，性能最高的、可用性最好的、功能最强大的，或者淘宝用的、微信开源的、Google 出品的等。

　　　　我们以缓存方案中的 Memcache 和 Redis 为例，假如我们要挑选一个搭配 MySQL 使用的缓存，Memcache 是纯内存缓存，支持基于一致性 hash 的集群；

　　　　而 Redis 同时支持持久化、支持数据字典、支持主备、支持集群，看起来比 Memcache 好很多啊，所以就选 Redis 好了。

　　　　最熟派设计师基于自己的过往经验，挑选自己最熟悉的方案。

　　　　我以编程语言为例，假如设计师曾经是一个 C++ 经验丰富的开发人员，现在要设计一个运维管理系统，由于对 Python 或者 Ruby on Rails 不熟悉，因此继续选择 C++ 来做运维管理系统。

　　领导派

　　　　领导派就更加聪明了，列出备选方案，设计师自己拿捏不定，然后就让领导来定夺，反正最后方案选的对那是领导厉害，方案选的不对怎么办？那也是领导“背锅”。

 

　　第 3 步：评估和选择备选方案

　　　　前面提到了那么多指导思想，真正应该选择哪种方法来评估和选择备选方案呢？我的答案就是“360 度环评”！

　　　　具体的操作方式为：列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。

　　　　常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。

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

　　  

 

　　 

13 | 架构设计流程：详细方案设计

　　第 4 步：详细方案设计简单来说，详细方案设计就是将方案涉及的关键技术细节给确定下来。

　　　　假如我们确定使用 Elasticsearch 来做全文搜索，那么就需要确定 Elasticsearch 的索引是按照业务划分，还是一个大索引就可以了；副本数量是 2 个、3 个还是 4 个，集群节点数量是 3 个还是 6 个等。

　　　　假如我们确定使用 MySQL 分库分表，那么就需要确定哪些表要分库分表，按照什么维度来分库分表，分库分表后联合查询怎么处理等。

　　　　假如我们确定引入 Nginx 来做负载均衡，那么 Nginx 的主备怎么做，Nginx 的负载均衡策略用哪个（权重分配？轮询？ip_hash？）等。

 

标签：方案,架构,架构设计,开始,复杂度,笔记,Elasticsearch,MySQL,备选
来源： https://www.cnblogs.com/dongxizhen/p/16209422.html