架构一个系统在其所处环境中所具备的各种基本概念和属性，具体体现为其所包含的各个元素、他们之间的关系以及架构的设计和演进原则之中。
架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。
架构师在宣讲时往往会先说自己任职和设计过的大型公司的架构，这是因为当系统的规模达到一定程度后，复杂度会发生质的变化，即所谓量变引起质变。
这个量，体现在访问量、功能数量及数据量上。
访问量映射到对高性能的要求。功能数量需要视具体业务会带来不同的复杂度。而数据量带来的收集、加工、存储、分析方面的挑战，现有的方案基本都是基于 Google 的三篇大数据论文的理论：
Google File System 是大数据文件存储的技术理论。
Google Bigtable 是列式数据存储的技术理论。
Google MapReduce 是大数据运算的技术理论。
复杂度来源很多，想要一一应对，似乎会得到一个复杂无比的架构，但对于架构设计来说，其实刚开始设计时越简单越好，只要能解决问题，就可以从简单开始再慢慢去演化，对应的是下面三条原则：
合适原则：不需要一开始就挑选业界领先的架构，它也许优秀，但可能不那么适合自己，比如有很多目前用不到的能力或者大大超出诉求从而增加很多成本。其实更需要考虑的是合理地将资源整合在一起发挥出最大功效，并能够快速落地。
简单原则：有时候为了显示出自身的能力，往往会在一开始就将系统设计得非常复杂，复杂可能代表着先进，但更可能代表着“问题”，组件越多，就越可能出故障，越可能影响关联着的组件，定位问题也更加困难。其实只要能够解决诉求即可。
演化原则：不要妄想一步到位，没有人可以准确预测未来所有发展，软件不像建筑，变化才是主题。架构的设计应该先满足业务需求，适当的预留扩展性，然后在未来的业务发展中再不断地迭代，保留有限的设计，修复缺陷，改正错误，去除无用部分。这也是重构、重写的价值所在。
即使是 QQ、淘宝这种如今已经非常复杂的系统，刚开始时也只是一个简单的系统，甚至淘宝都是直接买来的系统，随着业务发展也只是先加服务器、引入一些组件解决性能问题，直到达到瓶颈才去重构重写，重新在新的复杂度要求下设计新的架构。
明确了设计原则后，当面对一个具体的业务，我们可以按照如下步骤进行架构设计：
识别复杂度：无论是新设计一个系统还是接手一个混乱的系统，第一步都是先将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题。复杂度的主要来源上文已经说过，可以按照经验或者排查法进行分析。
方案对比：先看看业界是否有类似的业务，了解他们是怎么解决问题的，然后提出3~5个备选方案，不要只考虑做一个最优秀的方案，一个人的认知范围常常是有限的，逼自己多思考几个方案可以有效规避因为思维狭隘导致的局限性，当然也不要过多，不用给出非常详细的方案，太消耗精力。备选方案的差异要比较明显，才有扩宽思路和对比的价值。
设计详细方案：当多个方案对比得出最终选择后，就可以对目标方案进行详细的设计，关键细节需要比较深入，如果方案本身很复杂，也可以采取分步骤、分阶段、分系统的实现方式来降低实现复杂度。当方案非常庞大的时候，可以汇集一个团队的智慧和经验来共同设计，防止因架构师的思维盲区导致问题。
