有什么软件架构属于单体架构_什么是软件架构？

毫无疑问，世界越来越依赖软件。 软件是无处不在的手机以及复杂的空中交通管制系统的基本要素。 实际上，我们现在想当然的许多创新（包括eBay或Amazon这样的组织）如果不用于软件，就根本不存在。 甚至在金融，零售和公共部门等传统组织中，也严重依赖软件。 在当今时代，很难找到一个不在某种程度上从事软件业务的组织。

为了使此类创新和组织得以生存，他们依赖的软件必须提供所需的功能，足够的质量，在承诺时可用并以可接受的价格提供。

所有这些特征均受软件结构（本文的主题）影响。 我的重点是“软件密集型系统”，IEEE定义如下：

软件密集型系统是指任何软件对整个系统的设计，构造，部署和发展都具有重要影响的系统。 [来自IEEE1471。请参见下面的“架构定义”部分。]

在本文中，术语“体系结构”不合格时与术语“软件体系结构”同义。 尽管本文着重于软件密集型系统，但重要的是要记住，软件密集型系统仍然需要硬件才能执行，并且某些质量（例如可靠性或性能）是通过软件和硬件的组合来实现的。 因此，不能忽略整个解决方案的硬件方面。 本文稍后将对此进行详细讨论。

架构定义

在“架构”方面不乏定义。 甚至还有维护定义集合的网站。 ^1个本文中所用的定义是从IEEE标准1472000服用，IEEE推荐的软件密集型系统中，被称为IEEE 1471的架构描述的²这一定义如下，其中关键特性粗体显示。

建筑是体现在它的组成部分 ，它们之间的相互关系的系统的基本组织 ， 环境 ，和指导原则，其设计和演变。 [IEEE 1471]

本标准还定义了与该定义有关的下列术语：

系统是组织成完成特定功能或一组功能的组件的集合。 术语“系统”包含单个应用程序，传统意义上的系统，子系统，系统系统，产品线，产品系列，整个企业以及其他感兴趣的集合。 存在一种在其环境中执行一个或多个任务的系统。 [IEEE 1471]

环境或环境决定了对该系统的发展，运营，政治和其他影响的设置和环境。 [IEEE 1471]

任务是一个或多个利益相关者旨在实现某个目标的系统的使用或操作。 [IEEE 1471]

利益相关者是对系统感兴趣或关注的个人，团队或组织（或其类）。 [IEEE 1471]

我们可以看到，在所有这些定义中都使用了术语“组件”。 但是，大多数体系结构定义都没有定义“组件”一词，IEEE 1471也不例外，因为它故意模糊地覆盖了业界的许多解释。 组件可以是逻辑或物理，独立于技术或特定于技术，大粒度或小粒度的。 出于本文的目的，我使用UML 2.0规范中组件的定义。 为了涵盖我们可能会遇到的各种架构元素，包括对象，技术组件（例如Enterprise JavaBean），服务，程序模块，遗留系统，打包的应用程序等，我使用了相当宽松的术语。 这是“组件”的UML 2.0定义：

[组件是]系统的模块化部分，它封装其内容，并且其表示形式可以在其环境中替换。 组件根据提供的接口和必需的接口定义其行为。 这样，组件就是一种类型，其一致性由这些提供的必需的接口定义（包括它们的静态和动态语义）。 ³

此处提供的定义涵盖了许多不同的概念，本文稍后将对其进行详细讨论。 尽管业界没有公认的“体系结构”定义，但是值得考虑其他一些定义，以便可以观察到它们之间的相似性。 请考虑以下定义，在这些定义中，我再次大胆强调了一些关键特征。

体系结构是关于软件系统的组织，构成系统的结构元素及其接口的选择以及在这些元素之间的协作中指定的行为 ，这些元素的组成方面的一系列重要决策的集合。逐步增大的子系统以及指导该组织的架构样式 -这些元素及其接口，协作和组成。 [克鲁奇滕] ⁴

程序或计算系统的软件体系结构是系统的一个或多个结构，包括软件元素，这些元素的外部可见属性以及它们之间的关系 。 [Bass等] ⁵

[体系结构]是系统的组织结构和相关行为。 可以将体系结构递归分解为通过接口，连接零件的关系以及组装零件的约束进行交互的零件。 通过接口进行交互的部件包括类，组件和子系统。 [UML 1.5] ⁶

系统或系统集合的软件体系结构由有关软件结构以及构成系统的那些结构之间的相互作用的所有重要设计决策组成。 设计决策支持系统要成功支持的一组期望的质量。 设计决策为系统开发，支持和维护提供了概念基础。 [麦戈文] ⁷

尽管定义有些不同，但是我们可以看到很大的共性。 例如，大多数定义都表明，架构与结构和行为都有关，仅与重大决策有关，可能符合架构风格，受其利益相关者及其环境的影响，并体现基于原理的决策。 所有这些主题以及其他主题将在下面讨论。

架构定义结构

如果您要让任何人向您描述“架构”，十分之九，他们将对结构进行一些引用。 这通常与建筑物或其他土木工程结构（例如桥梁）有关。 尽管这些项目还存在其他特征，例如行为，用途适应性甚至美观，但最熟悉，最常提及的是结构特征。

那么，如果您要求某人描述他正在开发的软件系统的体系结构，您就不会感到惊讶，您可能会得到一个显示系统结构方面的图表-这些方面是体系结构层，组件，或分发节点。 结构确实是体系结构的基本特征。 架构的结构方面以多种方式体现出来，结果，大多数架构定义都是含糊的。 结构元素可以是子系统，过程，库，数据库，计算节点，遗留系统，现成产品等。

许多体系结构定义不仅承认结构元素本身，而且也承认结构元素的组成，它们之间的关系（以及支持这些关系所需的任何连接器），它们的接口以及它们的分区。 同样，可以以各种方式提供这些元素中的每一个。 例如，连接器可以是套接字，可以是同步的或异步的，可以与特定的协议相关联，依此类推。

图1中显示了一些结构元素的示例。该图显示了一个UML类图，其中包含一些代表订单处理系统的结构元素。 在这里，我们看到三个类-OrderEntry，CustomerManagement和AccountManagement。 OrderEntry类显示为取决于CustomerManagement类以及AccountManagement类。

图1：显示结构元素的UML类图

架构定义行为

除了定义结构元素之外，体系结构还定义了这些结构元素之间的交互。 这些交互提供了所需的系统行为。 图2显示了UML序列图，该序列图显示了许多交互，这些交互共同使系统支持订单处理系统中订单的创建。 在这里，我们看到五个交互。 首先，售货员角色使用OrderEntry类的实例创建订单。 OrderEntry实例使用CustomerManagement类的实例获取客户详细信息。 然后，OrderEntry实例使用AccountManagement类的实例来创建订单，用订单项填充订单，然后下订单。

图2：显示行为元素的UML序列图

应该注意的是，图2与图1一致，因为我们可以从图2中定义的交互中得出图1中所示的依赖项。例如，OrderEntry的实例在执行过程中取决于CustomerManagement的实例，如图所示。通过图2中的交互。这种依赖性反映在相应的OrderEntry和CustomerManagement类之间的依赖性关系中，如图1所示。

架构专注于重要元素

虽然架构定义了结构和行为，但是它与定义所有结构和所有行为无关。 它仅与那些被认为是重要的元素有关。 重要的元素是具有长效和持久作用的元素，例如主要的结构元素，与基本行为相关的元素，以及解决诸如可靠性和可伸缩性等重要特征的元素。 通常，体系结构不关心这些元素的细粒度细节。 建筑意义也可以表述为经济意义，因为考虑某些要素而非其他要素的主要驱动力是创造成本和变更成本。

由于架构仅关注重要元素，因此它为我们提供了所考虑系统的特定视角-与架构师最相关的视角。 ⁸从这个意义上讲，体系结构是系统的抽象，可帮助架构师管理复杂性。

还值得注意的是，重要元素的集合不是静态的，并且会随着时间而变化。 由于需要改进需求，确定风险，构建可执行软件并汲取教训，因此，重要元素集可能会发生变化。 但是，面对变化，体系结构的相对稳定性在一定程度上是一个好的体系结构的标志，一个执行良好的架构过程的标志以及一个好的建筑师的标志。 如果由于相对较小的更改而需要不断修订体系结构，那么这不是一个好兆头。 但是，如果体系结构相对稳定，那么反之亦然。

架构平衡了利益相关者的需求

创建了一种体系结构，以最终解决一系列利益相关者的需求。 但是，通常不可能满足所有表达的需求。 例如，利益相关者可以在指定的时间范围内要求某些功能，但是这两个需求（功能和时间范围）是互斥的。 可以缩小范围以满足时间表，或者可以在延长的时间范围内提供所有功能。 同样，不同的利益相关者可能会表达相互矛盾的需求，而且必须再次达到适当的平衡。 因此，权衡是架构过程的一个基本方面，而协商则是架构师的一个基本特征。

只是为了让您对当前的任务有所了解，请考虑以下利益相关者的需求：

• 最终用户关注直观，正确的行为，性能，可靠性，可用性，可用性和安全性。
• 系统管理员关心直观的行为，管理和辅助监视的工具。
• 营销人员关注竞争特征，上市时间，与其他产品的定位以及成本。
• 客户关心成本，稳定性和进度。
• 开发人员关心明确的要求以及简单一致的设计方法。
• 项目经理关心项目的跟踪，进度，资源的有效使用和预算的可预测性。
• 维护人员关心的是一种易于理解，一致且记录在案的设计方法，以及可以轻松进行修改的方法。

从清单中可以看出，架构师面临的另一个挑战是利益相关者不仅担心系统提供所需的功能。 所列出的许多关注点本质上是不起作用的，因为它们不会对系统的功能做出贡献（例如，与成本和计划有关的关注点）。 尽管如此，这些关注仍然代表了系统的质量或约束。 就架构师而言，非功能性需求通常是最重要的需求。

架构体现了基于基本原理的决策

架构的一个重要方面不仅是最终结果，架构本身，还在于其为何如此。 因此，重要的考虑因素是确保您记录导致该体系结构的决策以及这些决策的原理。

此信息与许多利益相关者有关，尤其是那些必须维护系统的利益相关者。 当架构师需要重新审视所做出决策的基本原理时，这些信息通常对他们很有价值，从而使他们不必最终不必要地追溯步骤。 例如，在审查体系结构并且架构师需要证明已做出的决定时，将使用此信息。

建筑可能符合建筑风格

大多数体系结构派生自具有相似关注点的系统。 这种相似性可以描述为一种建筑风格，可以将其视为一种特殊的图案，尽管它通常是复杂的复合图案（将多个图案组合在一起）。 就像模式一样，建筑风格代表了经验的编纂，对于建筑师来说，寻找重用这种经验的机会是一种好习惯。 建筑风格的示例包括分布式风格，管道和过滤器风格，以数据为中心的风格，基于规则的风格等。 给定的系统可能表现出不止一种体系结构风格。 正如肖和加伦所描述的那样：

[建筑风格]根据结构组织的模式定义了一系列系统。 更具体地说，建筑风格定义了组件和连接器类型的词汇表，以及如何组合它们的一组约束。 ⁹

就UML而言：

[模式是]在给定上下文中对常见问题的通用解决方案。 ¹⁰

除了重用经验之外，应用建筑风格（或模式）还使我们作为建筑师的生活更加轻松，因为通常根据使用它的理由来记录风格（因此，要做的事情很少）以及它的结构和行为（因此，由于我们可以简单地引用样式，因此要生成的体系结构文档更少）。

架构受其环境影响

系统驻留在一个环境中，该环境影响体系结构。 有时将其称为“上下文中的体系结构”。 本质上，环境决定了系统必须在其中运行的边界，这随后会影响体系结构。 影响架构的环境因素包括架构将支持的业务任务，系统涉众，内部技术约束（例如符合组织标准的要求）以及外部技术约束（例如与外部接口的需求）系统或符合外部法规标准）。

相反，正如Bass，Clements和Kazman ¹¹雄辩地描述的那样，该体系结构也可能影响其环境。 从技术的角度来看，架构的创建不仅会改变环​​境-例如，它可能会为拥有的组织贡献可重用的资产-架构的创建也可能会改变架构中的可用环境。组织。

当涉及软件密集型系统时，必须始终考虑环境的特定方面，如本章前面所述。 为了使软件有用，必须执行该软件。 为了执行，该软件在某种硬件上运行。 因此，最终的系统是软件和硬件的组合，正是这种组合允许实现诸如可靠性和性能之类的属性。 软件不能隔离执行软件的硬件来获得这些属性。

IEEE Std 12207-1995，即“信息技术的IEEE标准-软件生命周期过程”，定义了与先前提到的IEEE 1471系统定义不同的系统（该定义侧重于软件密集型系统），但与系统工程领域：

[系统]是一个集成的复合材料，由一个或多个流程，硬件，软件，设施和人员组成，提供满足指定需求或目标的能力。 [IEEE 12207] ¹²

用于系统工程的Rational UnifiedProcess®（RUP SE）的配置包含类似的定义。

[系统]是一组提供服务的资源，企业可以使用这些资源来执行业务目的或任务。 系统组件通常由硬件，软件，数据和工作程序^13组成 。

在系统工程领域，需要在软件，硬件和人员的使用方面进行权衡。 例如，如果性能是关键，则可以决定以硬件而不是软件或人员来实现某些系统元素。 另一个示例是，为了向顾客提供可用的系统，决定提供作为人类的顾客界面，而不是提供以软件或硬件实现的界面。 更复杂的场景要求通过组合软件，硬件和人员来实现某些系统质量。 （因此，本系列文章在适当的地方引用了除软件以外的其他元素。）

有趣的是，系统工程特别关注将软件和硬件（以及人员）视为对等方，从而避免了将硬件视为软件的第二等公民并且仅是执行软件的工具的陷阱。软件，或者相对于硬件而言，软件被视为二等公民，并且仅仅是使硬件实现所需功能的手段。

架构影响团队结构

架构定义了解决给定关注点的相关元素的相关分组。 例如，用于订单处理系统的体系结构可以具有用于订单输入，帐户管理，客户管理，履行，与外部系统集成，持久性和安全性的定义的元素分组。

这些分组中的每个分组可能需要不同的技能。 因此，一旦定义了软件开发团队的结构，使其与体系结构保持一致是非常有意义的。 但是，通常情况下，体系结构受初始团队结构的影响，反之亦然。 最好避免这种陷阱，因为结果通常是不理想的体系结构。 《康威定律》指出：“如果有四个小组在编译器上工作，那么您将获得4遍编译器。” 在实践中，我们常常无意间创建了反映组织创建架构的架构。

但是，也可以说这种稍微理想化的观点并不总是可行的，因为出于纯粹务实的原因，当前的团队结构和可用的技能代表了对可能性的非常真实的约束，因此建筑师必须考虑到这一点。

每个系统中都有一个体系结构

还值得注意的是，即使没有正式记录该体系结构，或者该系统非常简单，例如由一个元素组成，每个系统都有一个体系结构。 在记录体系结构时通常具有相当大的价值。 与记录体系结构相比，记录体系结构倾向于更仔细地考虑-因此，更有效-因为记录体系结构的过程自然会引起深思熟虑的考虑。

相反，如果未记录体系结构，则很难（如果不是不可能）证明其在解决诸如可维护性，最佳实践适应等质量方面是否满足规定的要求。 未记录的架构，似乎是当今存在的大多数，往往是偶然的，而不是有意的。

架构具有特定范围

有许多种建筑，其中最著名的是与建筑物和其他土木工程结构有关的建筑。 即使在软件工程领域，我们也经常遇到不同形式的体系结构。 例如，除了软件体系结构的概念外，我们可能还会遇到诸如企业体系结构，系统体系结构，组织体系结构，信息体系结构，硬件体系结构，应用程序体系结构，基础结构体系结构等概念。 您还将听到其他术语，每个术语都定义了架构活动的特定范围。

不幸的是，业界在这些术语中的每一个的含义或它们彼此之间的关系上没有达成一致，这导致相同术语（同义）和两个或两个以上含义相同的事物（同义）的含义不同。 但是，可以从图3推断其中一些术语的范围。当您考虑该图和随后的讨论时，几乎可以肯定的是，您在组织中有不同意见或不同用法。 但这正是要点-证明这些术语确实存在于该行业中，但是在其含义上尚未达成共识。

图3：不同术语的范围

图3所示的元素是：

• 软件体系结构，这是前面定义的本文的主要重点。
• 一种硬件体系结构，考虑了CPU，内存，硬盘等元素，打印机等外围设备以及用于连接这些元素的元素。
• 组织架构，考虑与业务流程，组织结构，角色和职责以及组织的核心竞争力有关的元素。
• 信息体系结构，它考虑组织信息的结构。
• 如本章前面所述，软件体系结构，硬件体系结构，组织体系结构和信息体系结构都是整个系统体系结构的子集。
• 企业体系结构与系统体系结构相似，它也考虑了硬件，软件和人员等元素。 但是，企业体系结构与业务之间有更紧密的联系，因为它专注于实现业务目标，并关注诸如业务敏捷性和组织效率之类的项目。 企业体系结构可能会跨越公司边界。

正如人们所期望的那样，有相应形式的架构师（例如，软件架构师，硬件架构师等）和架构师（例如，软件架构师，硬件架构师等）。

现在我们已经完成了这些定义，现在有很多未解决的问题。 企业体系结构和系统体系结构之间有什么区别？ 企业是系统吗？ 信息体系结构是否与某些数据密集型软件应用程序中的数据体系结构相同？ 不幸的是，对于这些问题，没有统一的答案。

现在，您应该只知道存在这些不同的术语，但是在行业中并没有一致的定义。 因此，建议您选择与您的组织相关的术语并适当地定义它们。 然后，您至少会实现某种一致性，并减少发生沟通错误的可能性。

摘要

本文着重于定义软件体系结构的核心特征。 但是，还有许多问题没有答案。 软件架构师的作用是什么？ 架构师参与哪些关键活动？ “建筑”的好处是什么？ 这些问题和其他问题将在本系列的后续文章中得到解答。

致谢

本文的内容来自于即将出版的一本书，该书的标题为“软件架构过程”。 因此，我要感谢许多人对此内容进行了评论，这些人包括Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Holger Heuss，Kelli Houston，Luan Doan-Minh，Philippe Kruchten，Nick Rozanski ，戴夫·威廉姆斯和伊恩·伍兹。

翻译自: https://www.ibm.com/developerworks/rational/library/feb06/eeles/index.html