1、先识别复杂度

架构设计的本质目的是为了解决软件系统的复杂性，所以在我们设计架构时，首先就要分
析系统的复杂性，只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向；否则如果对系统的复杂性进行了错误的判断，即使后续的架构设计方案再完美再先进，都是南辗北辙，做得越好，错得越多、越离谱。

比如，一个系统明明是因为耦合太严重，想要增加可扩展性导致的复杂度非得要去做集群，做缓存进行对性能的提高，这种就是偏离了方向，就算你提高了性能再多，我业务量上不来也没有意义。

2、设计备选方案

• 第一种常见的错误：设计最优秀的方案！
• 第二种常见的错误：只做一个方案！
• 第三种常见的错误：备选方案过于详细！

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

3、评估和选择备选方案

我们可以通过相关质量属性点来对备选方案进行360度的评估。

常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩
展性等。在评估这些质量属性时，需要遵循架构设计原则“合适原则”和“简单原则”，避免贪大求全，基本上某个质量属性能够满足定时期内业务发展就可以了。

评估备选方案质量属性的时候，“按优先级选择”，即设计师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推，那会不会出现两个或多个方案，每个质量属性的优缺点都一样的情况呢？理论上是可能的，实际上是不可能的，前面我们提到，在做备选方案设计时，不同的备选方案之间的差异要比较明显，差异明显的备选方案不可能所有的优缺点都是一样的。

4、详细方案设计

完成备选方案的设计和选择后，我们终于可以长出一口气，因为整个架构设计最难的己经完成了，但整体方案尚未完成，架构师还需继续努力接下来我们需要再接再厉，将最终确定的备选方案进行细化，使得备选方案变成个可以落地的设计方案简单来说，详细方案设计就是将方案涉及的关键技术细节给确定下来。

比方说，如果选择Nginx 那么nginx的负载均衡策略的选择是要用轮询、加权轮询、ip_hash还是url_hash等关键技术细节。