[架构之路-86]：《程序员必读之软件架构》-1-什么是软件架构

Posted 2023-01-25 文火冰糖的硅基工坊

第1章　什么是架构

1.1 盲人摸象

在不同的人眼里“架构”一词的意思大相径庭，互联网上对架构的定义也多如牛毛。过去几年里我问过上百人同一个问题，在他们看来“架构”意味着什么。得到的答案概括如下（排名不分先后）：

• 每件事都有“架构”；

• 模块、连接、依赖和接口；

• 系统、子系统、交互和接口；

• 结构单元；

• 结构（组件和交互）；

• 接口而非实现；

• 改变成本很高的事情；

• 难以改变的事情；

• 更加兼顾全局的设计；

• 整个系统；

• 非功能需求/质量属性；

• 必要的约束；

• 一定程度的严格和可靠性；

• 概念模型；

• 蓝图；

• 战略和愿景；

• 指导原则；

• 技术方向；

• 标准和准则；

• 战略决策的产出；

• 从需求到最终产品的道路；

• 实现目标的过程；

• 计划；

• 管理；

• 工具和方法；

• 大局观；

• 技术领导力；

• 沟通能力（抽象、语言、词汇）；

• 审美（比如：艺术般的整洁代码）；

解读：
上面的内容无非从如下几个方向阐述了架构以及与架构相关的架构师的特征：
（1）目标系统的 静态架构特征（名称）
（2）架构目标系统的 行为特征（动词）
（3）架构目标系统的 架构师的特征（人）
盲人摸象就是从不同的层面阐述了架构的不同侧面的特征。

1.2 架构的全面理解

（1）架构作为名词

表示的是目标产品的静态组件与他们之间的动态交互、以及整个系统与外部的动态交互。

架构作为名词来解释时，概括起来都与结构有关：将产品分解为一系列组件、模块和交互。这需要考虑整个产品，包括处理（建筑物的）供电、供水、空调，或处理（软件的）安全、配置、错误处理等横切关注点的基础设施服务。

（2）架构作为动词（容易比忽略）

对目标系统的架构，是人的行为，是架构师的行为，因此架构师的内在特质和外部的行为特征提出了一些要求。

架构作为动词来解释时，包括了理解你需要构建目标系统的行为、设定愿景以便于进行构建和做出恰当的设计决策。

架构的关键在于，架构是关于愿景的交流以及技术的领导力，这样参与构建产品的每个人都能理解这个愿景，并为产品的成功做出积极贡献。因此，

所有这些都要以需求为基础，因为需求驱动架构。

（3）补充：架构师内在的特征

架构师必须具备一些技能才能完成上述目标

（1）业务技能：不同业务应用，需要不同的业务技能

（2）软件技能：编程、软件工程、计算机原理

（3）架构技能：常见架构方法与常见的架构（本系列的重点）

（4）软技能：（本系列的重点）

• 领导力

• 沟通能力

• 影响力

• 情商

• 等等

第2章　架构的种类

2.1 盲人摸象

单是IT行业就有很多不同种类的架构和架构师。下面列出了人们在被问及该问题时给出的最普遍回答（排名不分先后）：

• 硬件；

• 软件；

• 基础设施；

• 网络；

• 数据；

• 数据库；

• 应用程序；

• 安全；

• 系统；

• 技术；

• 解决方案；

• 集成；

• IT；

• 信息系统；

• 流程；

• 商务；

• 企业；

备注：
可以看出，架构无处不在：从嵌入式系统的硬件、软件、产品、应用程序、企业管理与运营，业务流程每一个地方都有架构

2.2 它们的共同点：架构的本质是结构与愿景

那么，所有这些词有什么共同点呢？除了都以“架构”或“架构师”结尾之外，所有架构类型都具有结构和愿景。

以“基础设施架构”为例，想象你要在两个办公室之间建立网络连接，而这两个办公室远隔千里。

一种做法是找一卷最长的网线，然后从一个办公室直接连接到另一个办公室。假设你有足够的线缆，这可能行得通，但现实中为了达到这个目标，你要考虑很多环境约束和非功能特性。这就是架构的过程以及设定实现目标愿景的重要之处。采用一条很长的线缆是一种方法，但由于现实世界的约束，这个方法并不可行。因为这个原因，网络往往要复杂得多，需要一组协同工作的组件来满足目标。那么从基础设施的角度出发，我们谈论结构时你期望看到的是这一领域内的通用组件，比如路由器、防火墙、包整形器、交换机等。

不管你是构建软件系统、网络还是数据库，任何成功的方案都需要你理解问题，并设定一个愿景可以和每个参与构建最终产品的人沟通。不论何种领域的架构，其实主要就是结构和愿景。

第3章　软件架构是什么

乍一看，“软件架构”似乎很容易定义。它就是讲软件的架构，对吧？没错，但它并不局限于软件。

3.1 应用程序软件架构

对于我们软件开发者来说，最熟悉的软件架构应该是应用程序软件架构，特别是通常由单一技术编写的“应用程序”（比如Java网络应用程序、Windows桌面应用程序，等等）。

应用程序架构的关注点是应用程序，通常包括将应用程序解构为类和组件，确保设计模式的正确应用，构建或使用框架，等等。本质上，应用程序架构谈论的是软件设计的低级别切面，通常只考虑单一的技术栈（比如Java、微软.NET等）。

• 结构单元主要以软件为基础，包括编程语言和结构、类库、框架、API等。它由类、组件、模块、函数、设计模式等加以描述。

• 应用程序架构着重考虑软件和代码组织。

3.2 软件架构

软件架构从代码结构和基础到将代码成功部署到生产环境，与一个软件系统重要元素相关的所有东西就是软件架构。

从开发者的角度考虑软件开发，关注点多数会放在代码上。在这里，我们考虑的是有助于构架

更好软件的东西，比如面向对象的原则、类、接口、控制反转、重构、自动化单元测试、代码整洁和其他不胜枚举的技术实践。

如果你团队里的人都只考虑这些，那么谁来考虑其他事情？

• 异常：比如登录和异常处理；

• 非功能性特征：性能、可伸缩性、可用性和其他质量属性；

• 约束条件：客观环境的约束；

• 互操作性：与其他软件系统的集成；

• 可维护性：结构和整个代码库解决问题、实现特性的方法的一致性；

• 安全性：包括认证、授权和敏感数据保密；

• 监管：审计及其他监管需求；

• 运营、支持和维护的需求；

• 产品交付：评估正在构建的系统是否有助于交付能够按计划进行。

• 业务愿景：与业务愿景一致而非背道而驰。

有时，你需要退一步，远离代码和你的开发工具。这并不意味着低层次的细节不重要，因为可用的软件最终还是要靠交付可运行的代码。细节同样重要，但就大局而言，对软件的整体视角可以确保你的代码符合整体。

上述问题都是架构和架构师师要考虑的问题。

3.3 系统架构

把系统架构看作是更大规模的应用程序架构。

大多数软件系统实际上是由横跨不同层次和技术的多个应用程序组成。

举个例子，你可能有这样一个软件系统，Java EE中间层消费Oracle数据库提供的数据，同

时向.NET Silverlight客户端提供Web服务。每个部分都有自己的应用程序架构。

要让整个软件系统工作起来，就要思考如何组合这些单独的应用程序。

换句话说，要有端到端软件系统在较高层次上的整体结构。

另外，大多数软件系统都不是孤立的，因此系统架构还关注互操作性和与环境中其他系统的集成。

结构单元就是各种软硬件，从编程语言和软件框架到服务器和基础设施。

跟应用程序架构相比，系统架构描述为从组件和服务到子系统等更高层次的抽象。

系统架构的定义大多数都包括了软件和硬件。毕竟，一个成功的软件系统离不开硬件，即使是云上的虚拟硬件。

3.4 企业架构：战略而非代码

企业架构一般是指整个组织的中心工作，着眼于如何组织与利用人员、流程和技术来使企业有效和高效地工作。

换句话说，它是关于企业如何分成组或部门（静态），业务流程（动态）如何在上层运作，以及技术如何支撑这一切。

这跟软件架构形成了强烈对比，因为企业架构没有必要关注技术细节。相反，企业架构可能看重的是如何在整个组织中最好地利用技术，而无需实际介入这些技术的工作原理。

有些开发者和软件架构师把企业架构看作职业发展的下一站，然而大多数人却并非如此。从事企业架构工作所需要的思维方式和软件架构大相径庭，对于技术及其在组织中的应用，视角很不一样。企业架构需要更高层次的抽象。这关乎广度而非深度，关乎战略而非代码。

第4章　敏捷开发与敏捷的软件架构

4.1 敏捷开发

“敏捷”一词指代的往往不止一件事情。

首当其冲就是软件开发的敏捷方法：快速行动，拥抱变化，持续交付，接收反馈，不一而足。

与敏捷思维模式相关的第二个意思是，人们如何在敏捷环境中一起工作，通常包括了团队动态、系统思维、心理学以及其他可能会跟创建高效团队联系在一起的事情。

4.2 敏捷的架构

给软件架构打上“敏捷”的标签就意味着它能够应对所处环境中的变化，适应人们提出

的不断变化的需求。

这跟敏捷团队创建的软件架构不尽相同。以敏捷方式交付软件并不能保证得到的软件架构是敏捷的。

事实上，以我的经验，发生相反的事情通常是因为敏捷团队更关注交付功能，而非架构。

4.3 好的架构带来敏捷（追求的目标）

产生这个讨论的动力是好的软件架构能带来敏捷。

尽管面向服务的架构（SOA5）因为过于复杂、臃肿，但软件系统由小型微服务构成仍呈一种增长趋势，每个服务只专注做好一件事。

一个微服务通常需要较少的代码。如果需要改变，服务可以用另一种语言重新编写。这种架构风格以多种方式提供了敏捷。

小型、松耦合的组件和服务可以孤立地构建、修改和测试，甚至根据需求变化移除和替换。因为能够加入新组件、服务并在需要时扩展，这种架构风格也很适合非常灵活和可适配的部署模型。

4.4 不同的软件架构提供不同层次的敏捷

然而，天上不会掉馅饼。构建一个这样的软件系统需要时间、精力和准则。

很多人也不需要这种水平的适应性和敏捷性，这就是为什么你看到那么多团队构建的软件系统实际上整体感强得多，各部分捆绑在一起并以单一单元部署。

尽管更易于构建，然而这种架构风格在面对变化的需求时通常要花费更多精力去适配，因为功能往往交织在代码库中。

在我看来，两种架构风格各有优缺点，应该在权衡利弊之后，再决定是构架一个整体系统还是几个微系统。和IT行业中所有的事情一样，在这两者之间也有中间地带。抱着实用主义的想法，你总能选择构建一个由很多定义好的小组件构成，但仍作为单一单元部署的软件系统。这也让你有可能在将来轻松地迁移到微服务架构。

理解组织或业务变化的速度很重要，因为这能帮助你决定采用何种架构风格，可能是整体架构、微服务架构或者介于两者之间。要理解这种权衡并做出相应的选择。

敏捷不是白来的，要得到后期的敏捷，需要前期大量的付出和系统的支撑！！！

4.5 所有软件项目都需要软件架构吗

我不会给出“看情况”这种典型的咨询式回答，相反我会说答案毫无疑问是肯定的，并提醒每个软件项目都应该考虑多种因素，以评估必需多少软件架构的思考。

这些包括了项目/产品的大小、项目/产品的复杂性、团队的大小和团队的经验。对于多少是“刚刚好”，将在其他部分探讨。

也就是说，任何系统都需要架构设计，不同的系统，架构设计所投入的时间和精力、复杂性不同而已。

有些简单的系统，几页纸、几张图或许就可以了。

而有些复杂的系统，需要大量的描述，从不同角度的描述。

第5章　架构 VS 设计

如果架构是关于结构和愿景的，那设计又是什么？

如果你在创建一个解决问题的方案，这不就是设计吗？如果确实如此，那设计和架构有什么区别？

在现实世界中，架构和设计的区别并不明显。

所有架构都是设计，但并非所有设计都是架构。这就是架构与设计的区别 。

• 架构更多的关注的是宏观、整体、系统层次的设计，而设计关注的是局部的、微观、组件内部的设计。

• 架构关注业务目标的实现，设计关注软件代码的实现。

如下都是架构，而不是设计要考虑的问题：

• 系统的形态（例如，客户端-服务器、基于Web、原生移动客户端、分布式、异步，等等）；

• 软件系统的结构（例如，组件、层、交互，等等）；

• 编程技术选择（即编程语言、部署平台，等等）；

• 程序框架选择（例如，Web MVC2框架、持久性/ORM3框架，等等）；

• 设计方法/模式选择（例如，针对性能、可伸缩性、可用性等的方法）。

第6章　软件架构的重要性

6.1 软件架构有助于交付高质量的产品

软件架构是关于结构和愿景的，不思考软件架构（以及“大局”）会导致团队经常遭遇一些常见问题。

• 你的软件系统有良好定义的结构吗？

• 团队里每个人都以一致的方式实现特性吗？

• 代码库的质量水平一致吗？

• 对于如何构建软件，团队有共同的愿景吗？

• 团队里每个人都得到了足够的技术指导吗？

• 有适当的技术领导力吗

如果上面某些问题的答案是“不”，那就需要很好的团队和很好的运气才可能成功地交付一个软件项目。如果没人思考软件架构，最终结果往往看起来像一团乱麻（big ball of mud）。

当然，软件代码自身会有一个结构，但不是你想要的！

其他副作用还包括：

软件系统太慢、不安全、脆弱、不稳定、难以部署、难以维护、难以改变、难以扩展，等等。

备注：
这与项目管理有与曲同工之妙：
没有软件架构设计的目标系统，就好没有项目管理的一群人是协同实施一个大项目，很容易陷入混乱和无序状态 。
项目管理是为了满足项目的的需求，对未来项目执行过程过程中的各种人、财、物、时间等资源进行规划和设计。
软件架构是为了以满足客户的需求，对未来目标系统运行过程中的各种组件、组件之间的关系、各种软硬件资源进行规划和设计。

6.2 软件架构的好处

思考软件架构能带来哪些好处？

总结如下：

• 让团队跟随一个清晰的愿景和路线图，无论这个愿景是一人所有还是整个团队共有；

• 技术领导力和更好的协调；

• 与人交流的刺激因素，以便回答与重要决策、非功能需求、限制和其他关注点相关的问题；

• 识别和减轻风险的框架；

• 方法和标准的一致性，随之而来的结构良好的代码库；

• 正在构建的产品的坚实基础；

• 对不同的听众，以不同层次的抽象来交流解决方案的结构。

总之：
软件架构设计能够确保未来运行的目标系统不会陷入混乱和无序，
软件架构设计能够确保未来运行的目标系统有章法、有步骤地实施。