软件架构是任何成功软件系统的基础，并且会影响整个系统生命周期中的可维护性、可扩展性、稳定性和安全性等方方面面。实施新软件系统的第一步是架构图.
随着软件系统和 Web 应用程序变得越来越复杂，精心设计的系统架构图对于与其他开发人员和利益相关者进行交流变得至关重要。软件架构图是一种重要的文档实践，可帮助您规划和实施网络变更、可视化战略计划并领先于组织的需求。
今天，我们将重点介绍如何绘制图表、流行软件架构模式的一些示例，以及找到参考架构的地方，以用作各种用例的起点。我们还将讨论一个好的架构图应该完成什么，以及为什么你应该花时间来创建一个。
我们将介绍：
- 什么是软件架构
- 图表基础：流程图、C4 和 UML 2.5
- 6 种软件架构模式
- 3 个用于构建应用程序的公共云平台
- 总结和后续步骤
什么是软件架构？
软件架构描述了系统在其环境、关系、设计原则等上下文中的基本概念和属性。软件架构包括软件系统的组织、结构元素、行为元素以及将这些元素组合成更大的子系统。软件系统通常可以包含多种架构。
“没有整体架构或设计的编程就像只用手电筒探索洞穴：你不知道你去过哪里，你不知道你要去哪里，你也不知道到底在哪里你是。”丹尼·索普
拥有出色的架构为您将来如何处理性能、容错性、可扩展性和可靠性奠定了基础。为您的软件选择正确的架构将在您扩大规模时在压力条件下保持稳定的性能。
即使您预计用户数量不会增加，考虑您的项目的大局以及如何将这一愿景传达给其他人也可以帮助您和您的团队根据这些决策对您整体的影响做出战略决策建筑学。
完善的软件架构可以帮助您的工程师快速定位和修复错误。
我们需要记录软件架构吗？
您是否应该记录您的软件架构取决于您正在处理的项目类型。关于记录软件架构是否真的值得花时间，或者它是否会减慢一切，存在一些争议。现实在中间的某个地方。
一些开发人员并不需要为每个项目设计一个映射良好的软件架构。如果您是单独工作或使用像敏捷这样专注于持续改进的固有适应性开发方法，则可能很难记录每一次更改。
“不正确的文档通常比没有文档更糟糕。”伯特兰·迈耶
在其他时候，对复杂系统中软件架构的重要部分的记录不足可能会导致重大问题或导致技术债务。作为一般规则，一旦您的项目扩展至多人，您就应该开始记录产品的软件架构。
你需要记录什么？
您必须确保核心组件和高级架构可供每位员工使用。在许多情况下，软件架构及其文档将比产品的最初创建者更持久。从事产品工作的人可能会改变，使用的编程语言可能会改变，但软件架构几乎总是会保持不变。
这就是为什么记录您的软件架构如此重要的原因。它允许从事该项目的人员查看您的产品如何更改和发展的记录。
虽然您可能不想记录每个代码更改或架构更改，但您肯定希望记录重大更改，同样重要的是，记录进行这些更改的原因。
好的架构图能完成什么？
好的软件架构图是真实和清晰的来源。您希望您的图表能够快速向技术和非技术受众传达软件系统的基本组成和行为。
如果做得好，高级架构图和详尽的文档可以成为传达系统或应用程序内部状态的有效工具。
在开始编码之前绘制图表和在编写代码之后绘制图表也会带来不同的好处。
- 正向设计需要在您或您的团队开始编码之前创建图表。这有助于帮助您的开发人员更好地可视化他们正在尝试创建的系统。
- 后向设计涉及在编写代码后绘制图表。这可以帮助开发人员了解项目是如何开发的，并记录该工作流程以供以后改进。
您还希望您的图表尽可能不言自明，以便任何查看它的人都可以立即看到您的软件系统中的关系、约束和限制，而无需询问您的含义。
一个好的架构图将：
- 图表核心组件
- 突出关键系统交互和关系
- 易于访问和共享
- 保持一致的风格
- 更容易识别软件架构中的潜在缺陷或需要改进的领域
图表基础：流程图、C4 和 UML 2.5
既然我们已经讨论完了记录软件架构如何使您受益，那么让我们看看一些用于制作图表的常用方法。
流程图
流程图是您可以制作的最基本的图表类型之一。它们的简单性使它们成为在开始编码之前可视化算法或程序逻辑的有效工具。
以下是流程图键的示例，其中包含图表中使用的一些常见符号。
在技术图表中，每个形状通常包括以下内容：
- 被表示的元素的名称
- 该元素在系统中的作用
- 那个元素的技术
图表的每个组件都有将其连接到其他组件并描述它们之间的交互的箭头。
C4 型号
C4 模型是软件系统的体系结构文档标准，它将软件系统分为四个级别：
- 上下文（第 1 级）：上下文图是对系统做什么、它解决什么问题、涉及的人员以及与之交互的任何外部系统的高级概念描述。这些图表有助于提供全局概览。
- 容器（第 2 级）：容器图更深入地描述构成系统的应用程序或服务之间的高级交互。容器可以代表 API、数据库、文件系统、微服务等。
- 组件（第 3 级）：组件图查看容器内的不同代码体。这些图表有助于可视化代码库的抽象。
- 代码（4 级）：顾名思义，代码图着眼于映射到代码的架构元素，例如类、接口、对象和函数。
作为最低要求，大多数团队应该为他们的软件系统创建和维护上下文和容器图。
如果组件图增加了价值，则可以创建它们，但您需要找到一种方法来自动更新这些图以用于长期文档目的。
大多数 IDE（或 UML 建模工具）可以按需生成代码图，因此这种详细程度的文档更容易检索而不是维护。如果一个组件特别重要或复杂，那么手头有 4 级图表可能会有所帮助，但在大多数情况下，您可以等到需要这些图表时再生成它们。
UML 2.5
统一建模语言 (UML) 最常用于软件工程，以创建用于记录 4 级架构元素的图表。
有 14 种类型的 UML 图分为两大类：
- 结构图显示了建模系统中的对象。
- 行为图显示了这些对象如何相互交互。
在本文中，我们将主要关注 C4 模型的第 1 级和第 2 级图，因此我们不会在此详细介绍。
但是，如果您想生成第 4 级图表，那么研究 UML 可能是一个不错的起点。
示例：发票系统
您正在构建一个 Web 应用程序，数字艺术家可以使用它来管理和向客户发送发票。这个的上下文图会是什么样子？
您的图表至少应包括：
- 数据库
- 业务逻辑组件
- 用户界面
首先，从您的软件系统的表示开始。
接下来，您要记录演员是谁。演员是任何将使用该软件系统的人。
在这种情况下，我们的演员是：
- 数字艺术家
- 客户
既然您知道您的参与者是谁，请记录与软件系统交互的任何外部系统。
如果你想更深入，你可以创建一个容器图。容器图将关注构成特定容器的应用程序。
6 种软件架构模式
有许多软件架构风格，了解流行的风格可以为您节省一些时间。这是对六种不同类型的架构模式的基本（但希望是全面的）介绍。
1.分层（N层）架构
分层架构模式，也称为 N 层架构模式，是大多数 Java 企业应用程序使用的标准架构。分层架构风格将组件（或应用程序）划分为水平的逻辑层。
每一层在系统中都有不同的作用。一层可能负责处理业务逻辑，而另一层负责处理表示逻辑。这展示了一个称为关注点分离 (SoC) 的概念。层的组件将仅处理该层内的逻辑。像这样分离层也使测试和开发软件更容易，因为模式本身并不太复杂。缺点是这不是最有效的使用模式，而且很难扩大规模。
大多数分层架构将由四个封闭层组成：
- 表现层
- 业务
- 持久性
- 数据库
有时，业务层和持久层会合并为一个单独的层，尤其是当持久性逻辑（例如，SQL）包含在业务层的组件中时。较小的应用程序可以只有三层，而更复杂的应用程序可以包含五个或更多。
如果您尝试向数据库层发送请求，则该请求必须首先通过表示层、业务层和持久层。
但有时，让请求通过每一层是没有意义的。对于这种情况，您可以打开某些层，以便请求可以跳过它们并直接转到它们下面的层。
对于大多数应用程序来说，分层架构模式是一种很好的通用模式，尤其是当您不确定要使用哪种架构模式时。
注意：层和层都是指软件系统的功能划分。但是，层是指在与其他部门分开的基础架构上运行的软件。因此，如果所有层都在同一设备上运行，则具有多个层的应用程序只能具有一层。
2.客户端-服务器架构
在客户端-服务器架构中，有多个节点或客户端通过网络或 Internet 连接与中央服务器通信。
有两种主要类型的组件：
- 发送请求的服务请求者（又名客户端）
- 响应请求的服务提供商
在这种架构中，服务器托管、管理和交付客户端请求的大部分资源和服务。这也称为请求-响应消息传递模式。
具有客户端-服务器架构的应用程序的两个经典示例是万维网和电子邮件。
3. 事件驱动架构
事件驱动架构模式是具有高度适应性的分布式异步架构模式。这种模式最适合具有高可扩展性的小型到大型应用程序。由于在此模式中事件处理器组件彼此隔离，因此可以对组件进行更改而不会影响其他组件的性能。
这种模式有两种主要的拓扑：中介和代理拓扑。
中介拓扑有四种主要类型的组件：
- 事件队列
- 事件中介
- 事件通道
- 事件处理器
当事件具有多个步骤，需要通过中央调解器进行某种程度的协调以进行处理时，使用调解器拓扑。
当用户将初始事件发送到事件队列时，初始事件将被定向到事件中介。
接收到初始事件提示事件中介者发布和发送处理事件到事件通道，告诉他们开始执行每个流程步骤。从事件通道接收处理事件的事件处理器包含执行处理初始事件所需的所有步骤的业务逻辑组件。
一般来说，事件处理器组件应该只执行单个业务任务，而不依赖于其他事件处理器。这是因为您希望您的事件处理器能够与其他事件处理器同时运行步骤。
代理拓扑用于事件不需要中央调解器来分发或协调事件的流程。
代理拓扑有两种主要类型的组件：
- 经纪人
- 事件处理器
代理组件包含此事件流的所有事件通道。这些事件通道可以是消息队列、消息主题或两者的组合。
在代理拓扑中，事件处理器组件直接接收事件并负责处理和发布新事件以指示事件已被处理。
事件不断地流经处理器组件链，直到不再为初始事件发布事件。
这种进程分布允许事件驱动架构以最少的资源消耗运行大量并发连接。
4.微内核架构
微内核架构（也称为插件架构）通常用于实现可作为第三方产品下载的应用程序。这种架构也常见于内部业务应用程序中。
这种架构的一个有趣之处在于，您实际上可以将其嵌入到其他模式中，例如分层架构。
在典型的微内核架构中有两种架构组件：核心系统和插件模块。
核心系统包含使软件系统运行所需的最小业务逻辑。您可以通过连接插件组件来扩展软件系统的功能以添加更多功能。
这有点像为您的汽车添加冷空气进气口以提高其扭矩和马力。
可以使用开放服务网关倡议 (OSGi)、消息传递、Web 服务或对象实例化来连接插件组件。实施方法由您决定。
注意：插件组件是独立的组件，旨在扩展或增强核心系统的功能，不应与其他组件形成依赖关系。
5.微服务架构
微服务架构是目前最流行的软件趋势之一，其中一个原因可以归因于开发的易于扩展性。当微服务无法再维护时，可以重写或替换它们。
术语“微服务”没有普遍接受的定义。在本文中，我们将微服务定义为可独立部署的模块。
微服务架构由具有小型代码库的小型、独立、自包含服务组组成。与使用分层架构模式的单体应用程序不同，保持小的、独立的代码库可以最大限度地减少依赖项的数量。
微服务架构的每个组件都部署为一个单独的单元。单独部署单元简化了交付管道并使部署速度更快。开发团队可以轻松地建立具有较小单元的持续交付管道。测试也变得更容易，因为您只需要测试单个微服务的功能。
注意：微服务架构仅在部署自动化时才有效，因为微服务显着增加了可部署单元的数量。
微服务架构的另一个关键概念是服务组件。服务组件的复杂程度可以从单个模块到应用程序的大部分。微服务架构被认为是一种分布式模式，因为它们的服务组件彼此完全解耦。
微服务还有助于持续交付，这有助于使软件开发更加灵活。
亚马逊、Netflix 和 Spotify 等大公司都在实施这种架构。
6. 云原生架构
当您考虑典型的 Web 应用程序时，它们中的大多数通常以相同的方式处理来自客户端的请求。客户端从 Web 浏览器发送请求，该请求被发送到 Web 服务器，然后是应用程序服务器，最后是数据库服务器。当这种数据流处理大量并发运行的请求时，您通常会遇到瓶颈问题。这就是云原生架构模式的用武之地。云原生模式旨在通过删除中央数据库并改用复制的内存数据网格来最大限度地减少与可伸缩性和并发性相关的问题。
云原生架构主要用于分布式计算系统，其中组件之间的交互通过一个或多个共享空间进行调解。
在这个共享空间中，组件交换元组和条目。这给我们带来了元组空间的概念，或分布式共享内存的概念。
元组空间提供可以同时访问的元组存储库。应用程序数据保存在内存中，并在活动处理单元之间复制。
此架构模式中的两种主要组件类型是：
- 处理单元
- 虚拟中间件
处理单元通常包含：
- 应用模块
- 内存数据网格
- 用于故障转移的可选异步持久存储
- 数据复制引擎
数据复制引擎是虚拟中间件用来将在一个处理单元中所做的数据更改复制到所有其他活动处理单元的工具。
虚拟化中间件管理请求、会话、数据复制、分布式请求处理和流程单元部署。
虚拟化中间件将包含四个主要组件：
- 消息传递网格
- 数据网格
- 处理网格
- 部署经理
消息传递网格是管理输入请求和会话信息的组件。
数据网格是虚拟中间件中最重要的组件，它与每个处理单元中的数据复制引擎进行交互。
部署管理器是根据负载条件管理处理单元的启动和关闭的组件。当用户负载增加时，它将启动新的处理单元，当用户负载减少时，它将关闭处理单元。这种对不断变化的环境的动态响应允许基于空间的应用程序轻松扩展。
处理网格是一个可选组件，当多个处理单元处理应用程序的一部分时，它管理分布式请求处理。
这种类型的软件架构最适合社交网站或任何需要处理大量流量峰值的系统。