一、 架构是什么
通常关于架构的第一个问题是架构是什么，很自然也很正常，本文也不能免俗。然而关于这个问题却没有一致性答案，同时也要注意到不同应用的架构实质上存在不同差异性。
(一) 架构的定义
架构，虽然人们一直在讨论它，甚至于每天都在同其工作，然而这个词并没有一个被业界广泛认可的定义。
大致而言，架构的定义分为三类：
|
类别 |
定义 |
|
结构论 |
牛津高阶词典: The design an structure of a computer system |
|
韦氏大辞典: The way in which the parts of a computer are organized |
|
|
IEEE: The fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment,and the principle guiding its design and evolution |
|
|
关键论 |
架构是系统中最关键的20%，关注在系统非功能性需求 |
|
文化论 |
架构是关于系统一些的决策 |
(二) 架构的分类
架构由于应用的不同而存在不同。大体而言，我们可以将当前的应用分为如下四种：互联网应用、企业应用、桌面/移动应用和游戏。
需要一提的是，虽然几种应用的存在一定的模糊性，某种技术为多种应用所共用，例如很多的企业应用基于互联网技术SaaS，以及移动设备的支持。但依然存在很大的不同。
特别的，对于企业架构，大体存在如下几种流派：
1. TOGAF， OpenGroup组织提出，围绕业务、应用、技术和数据四个方面描述架构；
2. DoDAF/MoDAF，美国和英国国防部提出的架构方案；
3. Zachman Framework， 根据不同角色的5W1H来审视架构；
4. 4+1视图，由Philippe Kruchten提出，并被RUP采纳；
(三) 架构的关键非功能指标
通常来讲，架构所关注的非功能需求可以分为三个角度5个特性，如下：
|
角度 |
特性 |
说明 |
|
运营角度 |
伸缩性 |
主要为水平扩展能力 |
|
可靠性 |
包括容错性、可用性和安全性等； |
|
|
开发角度 |
维护性 |
|
|
扩展性 |
能否快速应对业务的变化 |
|
|
应用角度 |
易用性 |
对最终用户是否友好 |
非功能性指标当然不止这些，如下是一些参考：
1. ISO 9126提出的质量特性：
2. 或者通过如下三个视图来进行：
i. 业务视角
Time To Market、Cost and Benefits、Projected life time、Targeted Market、Integration with Legacy System、Roll back Schedule
ii. 最终用户视角
Performance、Availability、Usability、Security
iii. 开发视角
Maintainability、Portability、Reusability、Testability
3. 也可以通过诸如：简洁性、清晰和一致性等指标。
不同类型的应用关注点会有很大不同，例如：互联网应用由于面临大量的最终用户，会特别关注于伸缩性、可靠性和易用性，这并不是说互联网应用不关注维护性和扩展性，只是会更加强调另外三个特性；而企业应用由于关注于数据、流程以及业务的适应性，会更多得强调维护性和扩展性，而其他特性如易用性相对弱化（面对内部用户，强制使用），伸缩性（内部用户访问量少，大部分情况下通过现有硬件即可支持）。同时，企业应用对数据一致性和准确性要求非常高，而互联网应用相对可以容忍一定的不一致性和错误。因此，一个企业应用的架构师可能无法设计互联网应用的架构。
二、 架构有什么
架构有什么，通常会来一张或者一堆好看的图画。既然本篇不讨论具体应用，故而也拿不出啥图了，也不想讨论这些。因为不同的应用存在的差异，非本文所能涵盖。这里就想讨论下形形色色架构图的背后的内容，以及隶属架构但未在架构图表达的内容。
《易经·系辞》有云：“形而上者谓之道，形而下者谓之器”，将架构分为“形而上”和“形而下”两个部分，如下图：
(一) 形而上
形而上体系中，除去前置内容，分为文化和支撑两大块。
其中，文化部分里最重要的就是原则和方法论，例如：关注点分离原则（SoC），面向对象分析设计和领域驱动设计等等。在此之下，就是架构模式和算法，常见架构模式为：结构化（分层、管道流、黑板）、分布式（代理和管道流）、交互系统（MVC和PAC）和适配系统（微内核、元数据）。当然还有更低一层次的设计模式（创建、结构和行为）。
(二) 形而下
形而下分为三个部分，运行时、工具和文档。
其中，运行时的内容按照重要性依次为：语言、平台/中间件、框架、类库和工具，具体在企业应用中就是：Java/C#、Windows/Linux、Application Server/Database、Spring/Hibernate等等。
如果说运行时决定最终能力，则工具就事关效率。工具中最常见的是集成开发环境了，此外还有配置、部署和测试工具。
文档部分是另一个重要的内容，应包括：视图（从不同角色出发，可以参考4+1），范例和各种指导参考文档。
三、 架构如何设计
如果把“形而下”当成架构设计的产出，那么架构设计往前追溯，就有输入和加工过程。
(一) 架构的输入
架构的输入包括三个部分：目标、需求和相应约束。其中：目标是大方向内容，需求关注在细节，而约束对目标的达成提供了限定。特别的，关注在非功能性指标上。
(二) 架构的设计过程
架构的设计从需求分析开始，结合参考模型或者已有架构体系，结合原则、方法论等等作料。其主要活动有：技术选型、脚手架/框架/平台搭建等等。
关于具体过程的描述，可见《如何定义和建立架构》。
四、 架构如何评估
架构设计出后一个重要的工作是对架构（形而下部分）进行评估，进行架构评估的必要性在：使得架构设计工作形成闭环，确保当前架构是合适和正确的。
大体上，架构评估有三种方法：
· ATAM: Architecture Tradeoff Analysis Method
· SAAM: Software Architecture Analysis Method
· ARID: Active Reviews for Intermediate Designs
在进行架构评估工作时，首先要确定架构评估的参与人，包括相应的干系人和独立的评估队伍；然后是确定评估的时机：早期（在架构设计期间就参与评估）和晚期（传动的，在架构设计完成后）。
评估内容包括如下：
1. 首先是要满足其输入：目标、需求和约束；
2. 各项的非功能性指标；
五、 小结
以如下思维导图作为本文的小结：
