实施一个新的软件系统的第一步是架构图。随着软件系统和网络应用变得越来越复杂，设计良好的系统架构图已经成为与其他开发者和利益相关者沟通的关键。软件架构图是一种重要的文档实践，它可以帮助你计划和实施网络中的变化，将战略举措可视化，并保持在你的组织需求之前。
一个软件的架构是任何成功的软件系统的基础，并将在整个系统的生命周期内影响到从可维护性、可扩展性、稳定性和安全性等一切。你希望你的图表能够快速地将软件系统的基本组成和行为传达给技术和非技术的受众。这些图将帮助其他人理解所使用的软件架构，以及不同组件在该系统中的交互方式。
今天，我们将集中讨论如何绘制图表，一些流行的软件架构模式的例子，以及寻找参考架构的地方，以作为各种用例的起点。我们还将讨论一个好的架构图应该达到什么目的，以及为什么你应该花时间来创建一个架构图。
让我们直接开始吧!
什么是软件架构？
软件架构描述了一个系统在其环境、关系、设计原则等方面的基本概念和属性。软件架构包含了软件系统的组织、结构元素、行为元素以及这些元素组成的更大的子系统。软件系统通常可以包含多个架构。
"没有整体架构或设计的编程就像只用手电筒探索一个洞穴。你不知道你去过哪里，你不知道你要去哪里，你也不知道你在哪里"。
丹尼-索普
拥有一个伟大的架构为你将来如何处理性能、容错性、可扩展性和可靠性奠定了基础。为你的软件选择正确的架构，将导致你在扩大规模时在压力条件下的性能更加稳定。
即使你没有预计到用户的增加，思考你的项目的大局，以及你如何向其他人传达这个愿景，可以帮助你和你的团队根据这些决定对你的整体架构的影响来做出战略决策。
推广Danny Thorpe的洞穴比喻，如果你的洞穴旅行出了问题，而你又在等待救援人员来找你，那么有一个彻底的洞穴系统可以带来巨大的变化。
同样地，彻底的软件架构可以帮助你的工程师快速定位和修复错误。
我们是否需要记录软件架构？
你是否应该记录你的软件架构，取决于你所从事的项目类型。对于记录软件架构是否真的值得花时间，或者是否会拖慢一切速度，有一些争论。实际情况是介于两者之间。
一些开发人员不需要为每个项目都绘制好软件架构。如果你是单独工作，或者使用固有的适应性强的开发方法，专注于像敏捷这样的持续改进，那就很难记录每一个变化。
"不正确的文档往往比没有文档更糟糕"。
Bertrand Meyer
在其他时候，在一个复杂的系统中，对软件架构的重要部分记录不足，会导致重大问题或促成技术债务。作为一般规则，一旦你的项目扩展到包括一个以上的人，你就应该开始记录产品的软件架构。
你需要记录什么？
你必须确保每个新员工都能得到核心组件和高层架构。在很多情况下，软件架构和它的文档会比产品的最初创造者更久。在产品上工作的人可能会改变，使用的编程语言可能会改变，但软件架构几乎总是会保留。
这就是为什么记录你的软件架构是如此重要。它允许从事项目工作的人查看你的产品如何变化和发展的记录。
虽然你可能不想记录每一个代码变化或架构变化，但你肯定想记录重大的变化，同样重要的是，为什么会有这些变化。
好的架构图能实现什么？
好的软件架构图是真理和清晰的来源。如果做得好的话，高水平的架构图和彻底的文档可以成为沟通系统或应用内部状态的有效工具。在你开始编码之前做图和在你的代码写完之后做图也会带来不同的好处。
- 前瞻性设计需要在你或你的团队开始编码之前创建你的图表。这样做的好处是可以帮助你的开发人员更好地可视化他们所要创建的系统。
- 后向设计是指在代码编写完成后再绘制图表。这可以帮助开发人员看到项目是如何发展的，并记录该工作流程，以便日后改进。
"在编程领域，没有什么比没有文档的程序更可鄙的了。"
Edward Yourdon
你也希望你的图尽可能的不言自明，这样任何人看了都能立即看到你的软件系统中的关系、约束和限制，而不需要问你什么意思。
一个好的架构图会：
- 描绘出核心组件
- 突出关键的系统相互作用和关系
- 易于访问和分享
- 保持一致的风格
- 更容易识别软件架构中的潜在缺陷或需要改进的地方。
图解的基础知识：流程图、C4和UML 2.5
现在我们已经谈完了记录软件架构可以给你带来什么好处，让我们来看看一些制作图表的常用方法。
流程图
流程图是你可以制作的最基本的图表类型之一。它们的简单性使它们成为在你开始编码之前将一个算法或程序的逻辑可视化的有效工具。
这里是一个流程图关键的例子，包含了一些图中常用的符号。
在一个技术图表中，每个形状通常包括以下内容：
- 被代表的元素的名称
- 该元素在系统中的作用
- 该元素的技术
图中的每个元件都会有箭头将其与其他元件连接起来，并描述它们之间的相互作用。
C4模型
C4模型是一个软件系统的架构文件标准，它将一个软件系统分解为四个层次：
- 上下文（第1层）：上下文图是对你的系统做什么、解决什么问题、参与的人以及与之交互的任何外部系统的高层次、概念性的描述。这些图有助于提供一个大局观。
- 容器（第2级）：容器图更深入一层，描述构成你的系统的应用程序或服务之间的高层次互动。容器可以代表API、数据库、文件系统、微服务等。
- 组件（第3层）：组件图看的是容器内的不同代码体。这些图有助于可视化你的代码库的抽象。
- 代码（第4级）：顾名思义，代码图看的是映射到代码的架构元素，如类、接口、对象和函数。
作为最低限度，大多数团队应该为他们的软件系统创建和维护上下文图和容器图。
如果组件图能增加价值，也可以创建，但你要找到一种方法来自动更新这些图，以达到长期记录的目的。
大多数IDE（或UML建模工具）可以按需生成代码图，所以这个层次的文档是可选的。如果一个组件特别重要或复杂，那么第4级图会有帮助，但大多数情况下，你不需要这么深入。
UML 2.5
统一建模语言（UML）是软件工程中最常用的，用于创建记录第4级架构元素的图。
有14种UML图，主要分为两类：
- 结构图显示了建模系统中的哪些对象。
- 行为图显示这些对象是如何相互作用的。
| 结构图 | 行为图 |
|---|---|
| 类图 | 活动图 |
| 组件图 | 通信图 |
| 部署图 | 交互图 |
| 对象图 | 状态机图 |
| 包装图 | 序列图 |
| 外形图 | 时序图 |
| 复合结构图 | 用例图 |
在这篇文章中，我们将主要关注第1和第2级图，所以我们不会在这里讨论太多细节。
然而，如果你想生成第4级图，研究UML可以是一个坚实的起点。
例子：发票系统
你正在建立一个网络应用，数字艺术家可以用它来管理和发送发票给客户。这方面的上下文图应该是什么样子的？
至少，你的图应该包括以下内容：
- 数据库
- 业务逻辑组件
- 用户界面
首先，从你的软件系统的表示开始。
接下来，你要记录谁是行动者。行为者是任何将使用该软件系统的人。
在这个方案中，我们的演员是：
- 数字艺术家
- 客户
现在你知道了谁是你的行动者，记录任何与软件系统交互的外部系统。
如果你想更深入一步，你可以创建一个容器图。容器图将专注于构成特定容器的应用程序。
6种软件架构模式
有许多软件架构风格，了解流行的风格可以为你节省一些时间。下面是对六种不同类型的架构模式的基本介绍（但希望是全面的）。
1.分层（N层）架构
分层架构模式，也被称为N层架构模式，是大多数Java EE应用程序使用的标准架构。分层架构风格将组件（或应用程序）划分为水平的、逻辑的层。
每一层在系统中都有一个独特的角色。一个层可能负责处理业务逻辑，而另一个层则负责处理表现逻辑。这展示了一个被称为关注点分离（SoC）的概念。一个层的组件将只处理该层内的逻辑。像这样的分离层也使得测试和开发软件更加容易，因为这种模式本身并不复杂。缺点是，这并不是最有效的模式，而且很难扩大规模。
大多数分层架构将由四个封闭的层组成：
- 表现形式
- 业务
- 持久性
- 数据库
偶尔，业务层和持久化层被合并为一个单一的层，特别是当持久化逻辑（如SQL）被包含在业务层的组件中时。较小的应用程序可以只有三层，而较复杂的应用程序可以包含五层或更多。
封闭层要求请求通过目标层之前的层。例如，如果你想向数据库层发送一个请求，该请求必须先经过表现层、业务层和持久层。
但有时，让一个请求穿过每一层并没有意义。对于这样的情况，你可以打开某些层，使请求可以跳过它们，直接进入下面的层。
分层架构模式对于大多数应用来说是一个很好的通用模式，特别是当你不确定要使用哪种架构模式的时候。
注意：层和层都是指一个软件系统的功能划分。然而，层指的是运行在与其他部门分离的基础设施上的软件。因此，如果所有层都在同一设备上运行，一个具有多层的应用程序只能有一个层。
2.客户机-服务器架构
在客户-服务器架构中，有多个节点或客户通过网络或互联网连接，他们与中央服务器通信。
有两种主要类型的组件：
- 发送请求的服务请求者（又称客户）
- 响应请求的服务提供者
在这种架构中，服务器托管、管理并提供客户要求的大部分资源和服务。这也被称为 "请求-响应 "的消息传递模式。
具有客户-服务器架构的应用程序的几个经典例子是万维网和电子邮件。
3.事件驱动的架构
事件驱动架构模式是分布式异步架构模式，具有高度的适应性。这种模式最适合于小型到大型的应用程序，具有很高的可扩展性。由于在这种模式中，事件处理器组件是相互隔离的，因此可以在不影响其他组件性能的情况下对组件进行改变。
这种模式有两种主要的拓扑结构：调解器和经纪人拓扑结构。
调解器拓扑结构有四种主要类型的组件：
- 事件队列
- 事件调解器
- 事件通道
- 事件处理器
当一个事件有多个步骤，需要通过中央调解器进行某种程度的协调来处理时，就会使用调解器拓扑结构。
当用户向事件队列发送初始事件时，初始事件就会被引导到事件调解器。
收到初始事件后，提示事件调解器发布并发送处理事件到事件通道，告诉它们开始执行每个处理步骤。从事件通道接收处理事件的事件处理器包含业务逻辑组件，执行处理初始事件所需的所有步骤。
一般来说，事件处理器组件应该只执行单一的业务任务，而不依赖其他事件处理器。这是因为你希望你的事件处理器能够与其他事件处理器同时运行步骤。
经纪人拓扑结构用于进程流，在这种情况下，事件不需要一个中央调解人来分配或协调事件。
经纪人拓扑结构有两种主要类型的组件：
- 经纪人
- 事件处理者
经纪人组件包含该事件流的所有事件通道。这些事件通道可以是消息队列、消息主题，或两者的组合。
在经纪人拓扑结构中，事件处理器组件直接接收事件，并负责处理和发布新的事件，以表明一个事件已经被处理。
事件不断地流经处理器组件的链条，直到没有更多的事件被发布为最初的事件。
这种进程的分布允许事件驱动的架构以最小的资源消耗运行大量的并发连接。
4.微内核架构
微内核架构（也被称为插件架构）通常用于实现可以作为第三方产品下载的应用程序。这种架构也常见于内部商业应用中。
这种架构的一个有趣之处在于，你实际上可以把它嵌入到其他模式中，比如分层架构。
在你典型的微内核架构中，有两类架构组件：核心系统和插件模块。
核心系统包含了使软件系统运行所需的最小业务逻辑。你可以通过连接插件组件来扩展软件系统的功能，增加更多的功能。
这有点像给你的汽车添加一个冷空气进气口，以提高其扭矩和马力。
插件组件可以使用开放服务网关倡议（OSGi）、消息传递、网络服务或对象实例化进行连接。实现的方法由你决定。
注意：插件组件是独立的组件，旨在扩展或增强核心系统的功能，不应该与其他组件形成依赖关系。
如果你正在制作一个基于产品的应用程序（如Eclipse IDE），微内核架构模式应该是你的首选，因为它允许你随着时间的推移轻松添加额外的功能。
5.微服务架构
微服务架构是目前最流行的软件趋势之一，其原因之一可以归结为开发的易扩展性。当微服务不能再被维护时，它们可以被重写或替换。
对于**"微服务 "这个术语，没有一个普遍接受的定义。**在本文中，我们将把微服务定义为一个可独立部署的模块。
微服务架构由一组小型的、独立的、自成一体的服务组成，其代码基础较小。与使用分层架构模式的单体应用不同，保持小的、独立的代码库可以将依赖关系的数量降到最低。
微服务架构的每个组件都作为一个单独的单元被部署。单元的单独部署简化了交付管道，使部署速度大大加快。开发团队可以用较小的单元轻松地建立起持续交付管道。测试也变得更容易，因为你只需要测试单个微服务的功能。
注意：微服务架构只有在部署自动化时才能发挥作用，因为微服务大大增加了可部署单元的数量。
微服务架构的另一个关键概念是服务组件。服务组件的复杂程度可以从单个模块到应用程序的大部分。微服务架构被认为是一种分布式模式，因为其服务组件之间是完全解耦的。
微服务也有利于持续交付，这有助于使软件开发更加灵活。
像亚马逊、Netflix和Spotify这样的大公司都可以发现实施这种架构。
实现微服务架构的方式有很多，但最常见的拓扑结构是基于API REST、基于应用REST和集中式消息传递。
6.基于空间的架构
当你想到典型的网络应用程序时，它们中的大多数通常以相同的方式处理来自客户端的请求。客户端从网络浏览器发送请求，请求被发送到网络服务器，然后是应用服务器，最后是数据库服务器。当这种数据流处理大量并发运行的请求时，你通常最终会出现瓶颈问题。这就是基于空间的架构（SBA）模式出现的地方。SBA模式是专门为最大限度地减少可扩展性和并发性相关的问题而设计的，它取消了中央数据库，而是使用复制的内存数据网格。
SBA模式，也被称为云架构模式，用于分布式计算系统，其中组件之间的互动是通过一个或多个共享空间来调解的。
在这个共享空间中，各组件交换图元和条目。这给我们带来了元组空间的概念，或分布式共享内存的想法。
元组空间提供了一个可以并发访问的元组存储库。应用数据被保存在内存中，并在活跃的处理单元之间进行复制。
这种架构模式中的两种主要类型的组件是：
- 处理单元
- 虚拟中间件
处理单元通常包含：
- 应用模块
- 一个内存数据网格
- 用于故障转移的可选异步持久性存储
- 一个数据复制引擎
数据复制引擎是虚拟中间件用来将一个处理单元中的数据变化复制到所有其他活动的处理单元中。
虚拟化中间件管理请求、会话、数据复制、分布式请求处理和处理单元部署。
虚拟化中间件将包含四个主要组件：
- 信息传递网格
- 数据网格
- 处理网格
- 部署管理器
信息传递网格是管理输入请求和会话信息的组件。
数据网格是虚拟中间件中最重要的组件，与每个处理单元中的数据复制引擎进行交互。
部署管理器是根据负载条件管理处理单元的启动和关闭的组件。它将在用户负载增加时启动新的处理单元，在用户负载减少时关闭处理单元。这种对不断变化的环境的动态响应使基于空间的应用能够轻松地扩大规模。
处理网格是一个可选的组件，当多个处理单元处理一部分应用时，它管理分布式请求处理。
这种类型的软件架构最适合于社交网站或任何需要处理大规模流量高峰的系统。
3个用于架构应用程序的公共云平台
参考架构是很好的资源，可以作为你的图表的基础。一个软件参考架构就像一个结构和元素的模板，被安排为一个特定领域或软件系统家族提供解决方案。
因此，如果你知道你要绘制一个分层的架构图，你可以看看现有的使用这种风格的参考架构。
这里有三个公共云平台，可以免费访问数百个基于云的参考架构图，还有制图工具
1.亚马逊网络服务（AWS）
亚马逊网络服务是目前使用最广泛的云计算平台。AWS提供了基础设施（IaaS）、平台（PaaS）和打包的软件即服务（SaaS）的组合，因此它有丰富的资源，如Workload Discovery[2]和AWS CloudFormation Designer[2] ，用于创建、审查和绘制应用程序的架构图。
下面是一个数据组件的AWS架构图的例子：
AWS数据组件
2.微软Azure
微软Azure平台是第二受欢迎的云计算解决方案，如果你已经在使用微软的产品，它是一个很好的选择。对于数百种解决方案，你可以浏览参考架构的目录。
这里有一个参考架构的例子，描述了一个解决方案如何使用机器学习来自动和大规模地创建电影推荐。
Azure参考架构图
微软Azure架构附带了数据流的细分，对各个组件的解释，以及潜在的使用案例。每个架构还包括基于微软Azure良好架构框架的五个支柱的性能分析：
- 可靠性：一个系统从故障中恢复并继续运行的能力
- 安全性：保护应用程序和数据免受威胁
- 成本优化：管理成本以实现价值最大化
- 卓越运营：保持系统在生产中运行的操作流程
- 性能效率：一个系统适应负载变化的能力
3.谷歌云平台（GCP）
谷歌云平台是一个云计算服务的集合，也是第三大IaaS供应商。GCP提供了一个快速绘制图表的绝佳资源：谷歌云架构图表工具。
在Google Cloud Architecture Diagramming Tool中，你可以直接将预先构建的参考架构拖放到画布上。当你在图解工具中，导航到图解部分，你会看到超过10个常见用例的参考架构。
下面是一个简单的容器化应用的参考架构的例子：
GCP简单的容器化应用
总结和下一步工作
了解软件架构是任何软件开发人员需要培养的一项重要技能。学习如何有效地绘制这些模式的图表，可以帮助别人理解你们一起工作的架构，这是一个很好的方法。
此外，如果你打算成为一名系统设计师、云计算架构师或解决方案架构师，绘制图表是你需要培养的一项技能。在与非技术（和技术）受众交流时，能够说明产品的软件架构的清晰愿景是至关重要的。你要对你的软件系统的不同元素如何工作有一个清晰的概念，并将其传递给加入你项目的人。如果你决定离开一个项目，你可以放心地知道，当你离开时，事情不会崩溃。
如果你喜欢学习软件架构模式和图解，我们鼓励你继续学习系统设计对于那些喜欢解决抽象问题和思考大局的人来说，系统设计是一个伟大的领域。
学习愉快!
