一、 架构是什么
通常关于架构的第一个问题是架构是什么，很自然也很正常，本文也不能免俗。然而关于这个问题却没有一致性答案，同时也要注意到不同应用的架构实质上存在不同差异性。
(一) 架构的定义
架构，虽然人们一直在讨论它，甚至于每天都在同其工作，然而这个词并没有一个被业界广泛认可的定义。
大致而言，架构的定义分为三类：
| 类别 |
定义 |
| 结构论 |
牛津高阶词典: 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个特性，如下：
通常来讲，架构所关注的非功能需求可以分为三个角度 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. 各项的非功能性指标；
五、 小结
以如下思维导图作为本文的小结：
