架构漫谈二

架构的定义

架构（Architecture）一词源于建筑领域，其本身就是建筑的意思，也是体系结构的意思。维基百科英文版里对 Architecture 的解释是：规划、设计和建造建筑物的过程及产物。

鉴于软件工程与建筑工程一样是一项系统的工程性工作，引入到计算机领域后，软件架构就成为了描述软件规划设计技术的专有名词。

特别地，软件架构师一词在英文里，和建筑师也是同一个词（Architect）。

维基百科里对软件架构的定义：

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。软件架构是一个系统的草图。

软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

比较公认的软件架构定义是在 2000 年的 ANSI/IEEE 1471 标准中定义的：

1. 架构过程：在系统整个生命周期中构思、定义、表达、记录、交流，验证合适实现，维护和改进架构的过程，也就是设计过程。

2. 架构：一个系统体现在其环境中的元素、关系的基本概念或属性，以及其设计和进化原则。

3. 架构描述：表达一个架构的工作产出物（通常指的是各种架构图和设计文档）。

4. 架构视图：通过系统的某些关注点的视角，表达一个系统的工作产出物（例如部署视图、开发视图等）。

5. 系统：包含了一个或多个进程、硬件、软件、工具与可以满足需求的人的集合。

6. 环境：决定了开发、操作、策略和其他影响系统的设置和条件。

在 UML 中，架构则被认为是系统的组织结构和相关行为。架构可被分解为通过接口互联部分的关系，以及相互作用。

通过接口相互作用的部分包括类、组件和子系统。这样就可以通过 UML 的各种架构图来描述这些对象和关系，从而表达清楚一个系统的架构。

总结 

软件架构是一个用于指导系统实现的草图，这个草图越详细对于系统实现的指导意义越重大，贯穿于软件的整个生命周期。

在建筑领域，大楼尚未建造前，就已经存在于建筑师的脑海里；同样地，系统开始编写第一行代码之前，就已经存在于软件架构师的心里。

几个相关概念

模式（Pattern）

UML 中给出的解释更通俗易懂：模式是对于普遍问题的普遍解决方案。

我们可以把一类问题的共性抽象出来，这样就可以用同样的处理办法去解决这些问题，从而形成模式，所以模式是一些经验的总结。

类库（Library）

类库是一组可复用的功能或工具的集合，应用系统通过调用它们从而达到复用功能的目的。

例如，Windows 应用开发里的各种静态或动态链接库 DLL 文件，Java 开发中项目里依赖的或者 Maven 中央库里的各种 jar 包，都是 Library，比如 Apache Commons IO、HttpClient，Log4j 等。

框架（Framework）

框架是基于一组类库或工具，在特定领域里根据一定的规则组合成的、开放性的应用骨架。

比如 SSM/SSH 框架，更大范围来说 Dotnet Framework、JDK 都算是一种框架。

关于框架与架构的关系，Vasyl Boroviak 曾在 Stack Overflow 网站上通过两张图做了形象的对比，如下所示。

• 框架：

• 架构：

模块（Module）

模块是业务或系统的安装特定维度的一种切分，同时也可以看做是各种功能按照某种分类聚合的一种形式。

例如我们的一个电商系统，可以从业务上划分为用户模块、商品模块、订单模块、支付模块、物流模块、售后模块等。

另一方面，我们也可以说用户模块聚合了用户注册、用户验证等业务功能。

组件（Component）

组件是一组可以复用的业务功能的集合，包含一些对象及其行为。

组件可以直接被用做业务系统的组成部分，粒度一般小于模块，也是一种功能的聚合形式。比如日志组件、权限组件等。

服务（Service）

服务是一组对外提供业务处理能力的功能，服务需要使用明确的接口方式（比如 WebService 或 Rest 等）。

服务描述里应该包括约束和策略（比如参数、返回值，使用什么通讯协议和数据格式等）。

平台（Platform）

平台一般来说，是一个领域或方向上的生态系统，是很多解决方案的集大成者，提供了很多的服务、接口、规范、标准、功能、工具等。

例如 J2EE 平台，包含了企业级应用开发里的各种基于 Java 语言和 JVM 虚拟机运行时的技术能力。

知乎社区编程领域优秀问题回答者 ze ran 说：

库是工具箱。

框架是一套通用的解决方案。

架构是高度抽象的需求，是系统中的不变量。

平台是所有可能做的事的集合。

从软件的生命周期看架构设计

设计期

在设计期，软件作为一个成品还不存在，所以我们可以称之为概念形态。

此时架构师、产品经理或需求分析师等人员利用自己的经验能力，对系统的业务需求进行分析、拆解、抽象，形成业务文档和技术文档，以及技术验证代码等。

这个阶段，架构设计工作是重中之重，其中包括：

• 系统分拆：如何把系统拆解为不同的子系统、模块、业务单元；

• 技术选型：使用什么样的基础技术框架或脚手架；

• 技术验证：确定核心技术难点如何解决，检验能否满足期望指标；

• 接口规范：系统的内部不同部分以何种形式确定接口契约和数据通信；

• 集成方式：系统与外部其他业务系统如何进行集成；

• 技术规范：如何规范开发、测试、部署和运维的技术标准性；

• 部署方案：系统如何进行物理部署，需要多少机器、什么配置，对网络有什么要求；

• 运维方案：系统如何进行技术性运维，如何日常监控、预警报警；

• ……

这个阶段总结一下就是：业务为要，架构先行（包括业务架构和技术架构）。

实现期

这个阶段主要是编码与测试，准备部署上线，是软件从代码到最终的生产系统的过程，我们可以称之为代码形态。此阶段需要考虑的技术类工作包括：

• 确保各项技术规范和技术指标的执行落地，保障高质量的代码；

• 指导研发人员和解决各类技术问题，提升研发团队效率；

• 制定测试的技术性方案和基准，自动化、性能、安全等；

• 配合准备部署环境，运维实施方案落地等。

运行期

这个阶段系统上线、验收通过，已经初步稳定，然后进入维护阶段，成为了设计期架构设计草图的一个可用实例，我们可以称之为实例形态。此时需要考虑：

• 发布上线相关基础性工作，包括是否使用持续集成（CI)、自动化发布等技术；

• 运维基础性工作，自动化运维，监控等相关技术。

架构的形式与特点

设计文档和代码

我们一般说的架构既包括架构的设计过程，也包括设计的产出物，一般可以包括各类设计文档、设计图，也可以包括一些技术验证代码、Demo 或者其他相关程序。

文档的目的在于准确记录我们的思维产物，在软件尚未实现时，作为指导蓝图，尽量精确的描述清楚软件。

在软件的实现过程中，可能随时随着我们的深入研究，根据具体情况对文档做出局部的一些调整和修改。

文档作为结项或交接的一部分，也是整个软件项目的产出物的一部分，成为公司 IT 资产的有机组成部分。

架构服务于业务

正如 19 世纪的伟大建筑师路易斯•沙利文（Louis Sullivan）倡导的建筑设计著名格言：“功能决定形式（Form follows function）”。

软件架构首先是要服务于业务功能的。

架构影响研发团队的组织形式

业务拆分的方法和技术框架的选择必然会影响到研发团队的组织形式。

业务拆分的越细致，越有利于我们更好的对项目的各项指标量化计算，更精确的估计工时和成本，从而指导我们每个小组应该分配多少资源，使用什么样的协同和任务确认形式。

并且随着项目的推进，计划与实际情况之间的匹配程度也随时可以进一步精确调整，进而影响到我们应该对每一块任务的投入资源进行动态调整。

架构存在于每一个系统

每一个已经实现并运行的系统，都是特定架构设计的载体。

有些系统对应的架构，有详细的设计文档来描述；有些系统的设计文档，残缺不全，甚至还因为在系统的发展变化的同时，文档没有更新，导致设计文档与实际系统不符。

有些系统干脆就没有设计文档。

但是这些系统，都是基于一定的架构来创建的。

每种架构都有特定的架构风格

每种架构方式，每个具体系统内所体现的架构设计，都是可以被工程师们理解，进而提炼出来一些架构思想和设计原则，这些思想和原则就是这种架构方式的风格。依据这些风格，我们可以将各种架构方式，进行分门别类，从而进一步讨论每种架构风格的特点。

架构需要不断的发展演进

随着计算机软硬件的不断发展，软件架构思想也在不断的发展变化。

另一方面，软件为其提供业务处理和服务能力的每个具体行业领域也在不断发展变化，业务处理流程、参与角色、业务形式不断的推陈出新。

这就要求我们在系统架构设计时，保持终身学习的精神，持续吸收新思想新知识，保持贴近一线业务群体，随时因地制宜，调整架构设计，采取最适合当下场景的解决方案。

附录:

转载于：https://blog.csdn.net/csdnnews/article/details/79441488