架构设计的套路

架构设计有没有套路

大学毕业后，找工作，一般会学习一种语言，如java、然后是一种框架，如spring boot，然后就是写业务系统，不停的写，有些人会补一些算法、设计模式之类的知识，但是很少有架构的知识供我们学习，这是因为，至今为止，架构理论并没有系统化，大学里，找不到一本可以作为教材的架构课本。软件工程、编译原理、数据库的教材很多，是因为他们已经形成了理论。

没有系统的架构设计教程，但是有适应于不同人的架构设计讨论，这里，我介绍一下自己的一些套路。

架构设计的流程

废话不多说，我们来看看，

架构流程

  1. 接到设计任务: 接到任务后，调研需求。
  2. 记录需求，找到需求对应的功能中，最难的几个需求。
  3. 设计3套方案：根据需求设计多套方案，一套方案容易受主观影响，也容易受常识影响。
  4. 比较多套方案的区别，其实就是比较优缺点。优缺点是选择方案的标准，也是评审专家获取更多信息，作为判断的输入。
  5. 找朋友评审，避免一些低级错误。
  6. 思考会被问到的问题
  7. 尽快找Leader评审，原因是尽可能发现错误。
  8. 初步方案是否通过，通过后，继续喜欢方案。 没有通过，改方案。
  9. 细化方案，选择其中的一个方案做细化。
  10. 多维度评审方案。

了解详细需求阶段，找到复杂点

需求分析阶段，找对方向，找准突破点，是架构设计的第一步。

项目最开始的时候，如果是项目模块多，研发人员分不清模块与模块之间的关系，也不知道自己现在应该开发哪个模块，那么我们就需要设计模块与模块之间的关系的逻辑架构图。

这就是当前的重点，如果这时候，我们去设计性能，那么会无用下手，因为，我们不知道性能的瓶颈在哪里，有没有瓶颈，就算设计出来了。那么，系统模块与模块之间的关系仍然没有理清楚，这样，仍然对架构没有用处。

所以，最开始，需求分析阶段最重要的就是找到哪些点应该去设计。

至少要有2，3套方案

当找到了哪些点要去设计，就针对这些点设计至少3套方案。

既然选择突破点是复杂问题，那么复杂问题一定需要有多套方案。

这句话说来非常简单，例如出去烧烤，下雨不下雨，我们需要有2种方案，否则一场本来美好的烧烤聚会，会变为一次难忘失落的回忆。

  1. 下雨的时候，我们的方案是什么? 是户内、还是户外，或者干脆选择不去。 这些又会牵涉到食材的购买，门票的预定等。

  2. 如果不下雨，太阳很大，应该怎么处理。如果不大雨，阴天怎么安排。

只有把这些设计好了，才能做后面的细化设计，否则一些喜欢都没有意义，浪费时间。

很多人无法做设计，很大原因，就是不知道如何做多套方案。

程序员要突破3点： 1、要有足够的知识面、学习能力，能够找到多套方案 2、会分析多套方案的优缺点 3、重视多套方案，这一点最难做到，会因为很多原因放弃。

做一套方案可不可以

认为只做一套方案就行了的人的观点：

  1. 主观上不知道有这套方法论
  2. 只在心里评估，没有系统的用分析工具：框图、流程图、文档表达出来，从而在心里因为某一个缺点，就把一个方案给否定了。有缺点的方案，没有任何证据证明不是全局最优 的。
  3. 不做方案，就无法评审，无法评审，就不知道架构师否定某套方案的原因，很可能架构师否定方案的原因是错误的。
  4. 只设计一个方案，那么架构师在讲解的时候会竭力维护这个方案。原因是这个方案花了很久时间，认为某个细节不会影响整个方案。认为评审者是小题大做。

备选方案几套最好：3-5套，一般3套。5套，是确实这些方案是有区别的。没有区别的方案，算一套方案。

方案做到什么程度，适合评审

既然我们已经决定了要多套方案，那么方案什么时候要组织评审呢？

软件架构评审人员

不要一来就把Leader叫上。

方案要突出大方向，避免陷入细节

备选方案不是最终的方案，你的领导（经验更丰富），他们思考更全面，并不一定会选择你的方案。 如果你把某一套方案设计得太细节，那么很快他们会被你引导到细节中，而忽视了，方案本身是否正确。最后一般讨论很久，最终又回到方案的方向是否正确上。 这样做也有很多弊端：

  1. 设计细节，一个小方案就会花费很多时间
  2. 深入细节，会导致没时间设计其他备选方案，方案数目无法达到3，5个。
  3. 评审很快会深入细节。专家会被抓细节，因为这是他们没办法，必须抓的。 举例来说，甚至会陷入，为什么数据库用id，不是uuid呢？id容易暴露信息，uuid查询，排序没有优势。
. 优点 缺点
自增id 数据库自动编号，速度快，而且是增量增长，按顺序存放，对于检索非常有利；数字型，占用空间小，易排序，在程序中传递也方便；如果通过非系统增加记录时，可以不用指定该字段，不用担心主键重复问题。 因为自动增长，在手动要插入指定ID的记录时会显得麻烦，尤其是当系统与其它系统集成时，需要数据导入时，很难保证原系统的ID不发生主键冲突（前提是老系统也是数字型的）。特别是在新系统上线时，新旧系统并行存在，并且是异库异构的数据库的情况下，需要双向同步时，自增主键将是你的噩梦；在系统集成或割接时，如果新旧系统主键不同是数字型就会导致修改主键数据类型，这也会导致其它有外键关联的表的修改，后果同样很严重；若系统也是数字型的，在导入时，为了区分新老数据，可能想在老数据主键前统一加一个字符标识（例如“o”，old）来表示这是老数据，那么自动增长的数字型又面临一个挑战。
uuid 出现数据拆分、合并存储的时候，能达到全局的唯一性 影响插入速度， 并且造成硬盘使用率低。uuid之间比较大小相对数字慢不少， 影响查询速度。uuid占空间大， 如果你建的索引越多， 影响越严重

360度评审

所谓的360度评审，就是全方位的评审。

缓存架构问题

评审的表格模板如下：

比较点 方案一：使用redis一 方案二：memcache 备注
可扩展性 数据可以超过内存大小；数据类型多样；而Redis最大支持1G 可以存图片、视频等；数据不能超过内存；数据类型单一；Memcached单个key-value大小有限，一个value最大只支持1MB .
高性能 两者差不多； 两者差不多；存储大数据比存储小数据性能更高（100K以上） .
高可用 可以持久化到磁盘；可以恢复 数据可能丢失；不可恢复，可靠性相对较低 .
人力、时间等成本 团队熟悉 团队已经很久没使用memcache了 .
难易程度 从集群的搭建上，更为容易 . .

选择的标准：

错误的评审标准

  1. 根据总分投票。哪一项最重要，其分数就高，然后计算总分数

  2. 投票法：大家一起来举手投票

  3. 根据数量对比法，那个方案优点多就选择哪一个。

按重要程度比较

  1. 先比较最重要的属性
  2. 如果相同，比较第2重要的属性

永远选择最重要的属性来比较。

细化方案

设计详细方案，细化才可实现

需要深入细节，举例来说，在数据库选型的时候，用mysql好，还是postgresql好。选择哪一个，架构师必须对这2种数据库的性能、可用性、基本的原理有一定的了解，否则很容易觉得postgresql很新，然后为了突出自己的能力，不被别人笑话，就使用它。

我一直认为：架构师一定要知识面丰富，一定要有多年的编程积累才可。 经验太少，很难做出好的架构。

针对上一节课的redis和memcache的问题，我们最终选择了redis，那么就需要对redis进行详细的设计。

我们将高可用作为了最重要的标准，那么现在就需要设计redis高可用了。

关于高可用有很多细节，我们这里不展开，后面再展开。