如果把用户需求看作是问题空间，那么架构就是解空间，架构的目标就是要设计软件系统来解决问题。架构其实就是结构设计，从抽象的角度，根据问题域，对系统进行划分，各部分之间建立交互关系，通过分工和协作，连接合并成一个整体，完成系统目标。从不同的维度看系统结构：高维度，子系统或服务的切分和交互；中维度，系统或服务内部的模块划分；低维度，代码结构，数据结构，表结构。
架构设计从两个面来考虑：1.功能需求，看架构设计是否能够满足业务需求。从需求模型转化成架构模型需要关注两个问题：如果根据需求模型构建架构模型，如何保证模型转化的可追踪性。2.非功能性需求，也是我们所关注的系统的质量属性，如高性能，高可用，可扩展，安全性，可靠性等等。
架构设计流程
1）识别系统的复杂度
我们在设计架构时，首先就是要分析系统的复杂性，只有正确分析出系统的复杂性，后续的架构方案才不会偏离方向。例如，如果一个系统的复杂度本来是业务逻辑复杂，功能耦合严重，你却设计一个TPS达到5万/每秒的高性能架构，即使这个系统的最后的性能再优秀，也没有说明意义。
软件的复杂度来源有高性能，高可用，可扩展，低成本，安全，规模等。但架构师具体判断复杂性的时候，不能随意猜测，生搬硬套，必须结合具体的场景，像高性能，高可用等质量属性，可以通过质量场景来捕获。实际上绝大部分场景下，复杂度只是其中的某一个，少数情况下包含其中两个。
架构理论上看，这里说的复杂度，很像敏感点，为了实现某一质量属性，一个或多个构件所共有的特征。
目前我们碰到的大部分都是在原有系统上进行架构，当你碰到一个很多复杂度都存在问题的系统，该怎么办。当然是一个个来解决问题，将主要的复杂度问题列出来，根据业务，技术，团队等情况进行排序，优先解决的当前面临的最主要的复杂度问题。对于同一个复杂度问题，软件系统的方案可以是多个的，总是可以挑选出性价比最高的那个。
2）设计备选方案
确定了系统主要面临的复杂度问题后，方案设计就有了明确的目标。软件技术经过几十年的发展，虽然新技术层出不穷，但经过时间的发展，被各种场景验证过的成熟技术也很多。高可用的主备方案，集群方案，高性能的负载均衡，多路复用，可扩展的分层，插件化等技术，我们可以根据已有的目标，查找现有的可选的成熟的解决方案。
基于已有的技术或架构模式进行组合，然后调整，大部分情况下就能够得到我们需要的方案，但并不意味着架构设计是一件很简单的事情。因为可选的模式有很多，组合的方案更多，往往一个问题的解决方案有很多个；如果在组合的方案上进行一些创新，那么解决方案会更多。因此，如何设计最终的方案，并不是一件容易的事情。
我们在设计方案是，一定要避免只设计一个方案。通常我们在方案设计的时候，开始心里都会有几个方案的初步设想，再简单的判断一下哪个最好，然后就选择这个自认为最好的方案进行详细设计了。这样做就非常危险了，心里评估太过于简单，考虑的还是太片面，会简单的因为某一个缺陷就否决一个方案，但这世上本就不存在完美的架构。如果自己对某一知识点的理解不够，可能原来理解就是错的，会导致方案本身就是错的。所以针对这些问题，我们在做方案设计的时候，一定设计备选方案，备选方案的数量选择3-5个，备选方案的差异性要比较明显（主备方案和集群方案都是保障高可用的）。
3）架构评估和选择方案
完成备选方案设计之后，如何挑选最终的方案也是一个很大的挑战，每个方案都是可行，每个方案都不是完美的，评价标准主观性较强。在架构评估过程中，评估人员所关注的是系统的质量属性。主要评估方法是SAAM和ATAM，通过列出我们所关注的质量属性点，然后从这些质量属性上去评估我们的方案。
SAAM —— 基于场景的架构分析方法
该方法是最早形成文档并得到广泛使用的软件架构分析方法，对描述系统属性的文档，验证基本的架构原则和假设。该方法有利于评估架构固有的风险，指导评估人员进行架构检查，发现潜在的问题点。
1）使用场景技术，把任何形式的质量属性都具体化为场景，
2）架构描述应该被所有参与评估的人所理解。功能，结构和分配作为描述架构的三个主要方面。
3）评估的5个步骤：场景开发，架构描述，单场景评估，场景交互，总体评估
这里就一个方案设计举例说明，该方案需要关注的架构质量属性：
内容来自李云华《从0开始学习架构》
通过场景开发，确定质量属性：
第一，由于背景问题是系统性能不足，因此“性能”是首要考虑的架构质量属性。由于业务快速发展，我们希望本次方案做完后，性能上至少能支撑接下来1 年内的业务发展。
第二，由于开发人员只有5 个人，因此复杂度和项目开发时间也是需要重点关注的，我们不希望一个方案需要做半年时间才能做完。
第三， 由于是创业公司， 目前还处于未盈利状态，因此方案的成本也需要考虑。
第四，业务发展很快，各种新的功能不断提出，产品经理希望我们的业务法代速度更快一些，因此系统需要能够快速扩展新的功能。
第五，用户量增长很快，系统如果故障影响比较大，因此系统的可用性也需要关注。
最终的质量属性包括性能、复杂度、成本、可扩展、可用性。我们逐一对比两个方案，扩展应用服务器的方案和系统功能拆分方案，如下表所示。
通过表格可以清楚的看到各个场景下各个方案的优劣点，但如何进行选择的，不能简单的根据哪个方案优势大就选哪个。应该根据“按优先级选择”，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。
ATAM——体系结构权衡分析法
这是在SAAM的基础上发展起来的，在系统开发前，对多个质量属性之间进行评价和折中。考虑多个相互影响的质量属性情况下，从原则上提供一种理解软件架构的能力的方法。
主要划分为4个活动领域：场景和需求收集，体系结构视图和场景实现，属性模型构造和分析，折中。
步骤：1.描述ATAM方法，2.描述业务动机，3.描述架构，4.确定架构方法，5.生成质量属性效用树，6.分析架构方法，7.讨论场景和场景分级，8.分析架构方法，9.描述评估结果
4）详细方案设计
详细设计就是将方案设计的关键技术细节确定下来。
假如我们确定使用Elasticsearch 来做全文搜索，那么就需要确定E lasticsearch 的索引是按照业务划分，还是一个大索引就可以了：副本数量是2 个、3 个还是4 个，集群节点数量是3 个还是6 个等。
假如我们确定使用MySQL 分库分表，那么就需要确定哪些表要分库分表，按照什么维度来分库分表，分库分表后联合查询怎么处理等。
假如我们确定引入Nginx 来做负载均衡，那么Ngi nx 的主备怎么做， Nginx 的负载均衡策略用哪个（权重分配？轮询？ ip hash? ）等。
架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深入的理解。避免在详细设计的时候因为某个细节推翻整个方案的情况。通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度。
架构设计原则
1）合适原则
优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起井发挥出最大功效。
业界领先的方案虽然厉害，很牛*，但如果一个只有几个人的团队，想做一个微信或淘宝那样的“亿级用户平台”，可以想象最后的结果。没有那么多人力，没有那么大的业务量，没有那么长时间的技术积累，设计的架构再优秀再领先，也是无法实现的。
没有必要为一个公司内部的OA系统设计一个百万并发性能的架构，这些都属于过度设计，架构设计只要合适就可以。
2）简单原则
软件领域的复杂性体现在以下两个方面。
a.结构的复杂性
结构复杂的系统几乎毫无例外地具备两个特点： 组成复杂系统的组件数量更多，同时这些组件之间的关系也更加复杂。
结构上的复杂性存在的问题是： 1.组件越多，就越有可能其中某个组件出现故障，从而导致系统故障。2.某个组件改动，会影响关联的所有组件，这些被影响的组件同样会继续递归影响更多的组件。3.定位一个复杂系统中的问题总是比简单系统更加困难。
b.逻辑复杂性
逻辑复杂的组件一个典型特征就是单个组件承担了太多的功能。
看到结构复杂性后，我们的第一反应可能就是“降低组件数量”，毕竟组件数量越少，系统结构越简单。最简单的结构当然就是整个系统只有一个组件，即系统本身，所有的功能和逻辑都在这一个组件中实现。
逻辑复杂性带来的维护和扩展的问题，线上出现问题后，很难定位。
无论结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单的方案和复杂的方案都可以满足需求，一定要选择简单的方案。
3）演化原则
软件架构需要根据业务发展不断变化这个本质特点。
首先，设计出来的架构要满足当时的业务需要。
其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
最后，当业务发生变化时，架构要扩展、重构、甚至重写；代码也许会重写，但有价值的经验、教训 、逻辑、设计等却可以在新架构中延续。
架构师在进行架构设计时时刻提醒自己不要贪大求全，或者盲目照搬大公司的做法，而是应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。
