内容纲要
第一步 识别复杂度
架构设计的目的本质上是为了解决软件系统的复杂性。要解决复杂性，首先我们得知道复杂在哪里？
不了解复杂度在什么地方，可能会做的越多错的越多。
复杂度来源
系统的复杂度可能包含一个或多个点。如果同时具备这些点，架构师必须好好想想，是不是设计失误了。如果真的都需要面临这些复杂度，则架构师需要对复杂度进行排序解决。
过度设计
过度设计是指在在架构师在设计的时候，太超前的考虑了太多的业务场景（实际上可能根本不会发生，或者发生的概率很小），导致在设计架构的时候，使架构过于复杂，违背了演化原则。
后果
- 运维效率低下
- 开发效率低下
- 问题排查困难
- 换人成本极高
困境
如果接手这种项目，将面临：
- 要做的事情太多，无从下手
- 设计方案太复杂，落地遥遥无期
- 设计互相矛盾
解决之道
- 列出复杂度原因
- 给复杂度排序
- 优先解决优先级较高的复杂度问题
如何识别复杂度？
复杂度分析4 问
- 是否需要高性能？
- 分析业务，预估 TPS、QPS 量级（以峰值计算，峰值可以取平均值的 2~4 倍，⚠️具体业务具体分析）
- 是否需要高可用？
- 分析业务中断、消息丢失对系统和业务的影响
- 是否需要可扩展？
- 分析业务场景，总结系统是否需要为各场景设计可扩展性
- 是否需要安全？是否需要低成本？
- 这个不用问，安全是必不可少的，如果你不想收到勒索邮件的话；低成本得看公司缺不缺钱，设计的方案能不能符合成本预算。
第二步 设计备选方案
成熟的架构师需要熟悉很多已知的技术；对已经经过验证的架构烂熟于心；根据业务挑选合适的架构进行组合，并做调整。
新技术都是在现有的技术的基础上发展起来的，现有的技术又源于先前的技术。将技术进行功能性分组，可以大大简化设计过程，这就是“技术模块化”的首要原因。技术的“组合”和“递归”特征，将彻底改变我们对技术本质的认识。
常见错误及解决办法
- 设计最优秀的方案
- 我们都知道有很多优秀的方案，知道原理，都能做出来，但是，得先问问自己：“我们有那个条件吗？”
- 请回头好好思考：简单原则、合适原则
- 我们都知道有很多优秀的方案，知道原理，都能做出来，但是，得先问问自己：“我们有那个条件吗？”
- 只做一个方案
- 人力有穷时，很多问题，不是一下子能够想全的
- 单一方案可能出现过度辩护的情况，如：在评审、调研时，可能会默认偏向那个唯一方案，导致忽略某些重要问题，或者错过实际更优的方案
- 备选方案以 3 ~ 5 个为佳；少了可能会考虑不周全，多了需要花费太多精力
- 备选方案需要差异明显（架构上的差异）
- 备选方案的技术不要局限于已熟悉的技术；很多时候，新的技术的某些特点会更适合某些场景（毕竟新技术都是为了某些场景而诞生的）
- 备选方案过于详细
- 牵扯太多精力
- 注意力可能过于集中到细节，失去整体视野
- 评审时可能会被带到讨论细节的节奏，失去架构评审的目的
- 备选阶段重点关注技术选型，不要过度关注细节
- 技术选型的差异要明显
评估和选择备选方案
备选方案选择的困难点
- 每个方案都可行
- 没有完美的方案
- 评价标准主观性强
选方案的指导思想
- 最简派
- 选最简单的方案
- 最牛派
- 选技术最牛的方案
- 最熟派
- 选使用最熟悉的方案
- 领导派
- 让领导来选（甩锅大法）
到底这么选？
360 度环评：
- 列出需要关注的质量属性点
- 从不同质量属性维度去评估每个点
- 挑选最优的方案
常见质量属性
- 性能
- 可用性
- 硬件成本
- 项目投入
- 复杂性
- 可扩展性
- 安全性
- …
遵循“简单原则”、“合适原则”；避免贪大求全（什么都想要）；满足业务一定阶段内的发展需求（一般来说按照当前的业务规模的 2 ~ 4 倍来做预算即可）即可
常见误区
- 数量对比法
- 看哪个方案优点多就选哪个方案
- 单纯的数量无法大表真正的需求
- 看哪个方案优点多就选哪个方案
- 权重法
- 每个质量属性给一个权重
- 权重设置过于主观，很难得出真正符合实际需求的值
- 每个质量属性给一个权重
解决方案
需要根据优先级进行选择
详细方案设计
经过设计方案评审后，大体的方向已经定下来了，但项目落地还没完成，所有架构师需要继续设计详细的方案。
详细方案设计，简单来说就是将方案涉及的关键技术细节确定下来。
问题
详细方案制定时可能出现一种极端情况：在详细方案设计时才发现备选方案不可行（一般是在设计备选方案时遗漏了某些关键技术点或质量属性）
预防及解决办法
- 架构师在设计备选方案时，需要对备选方案有较深入的理解。
- 通过分步骤、分阶段、分系统等方式降低方案复杂度
- 如果无法从方案复杂度入手，就以设计团队的方式进行设计，博众取长，避免架构师出现盲点