软件架构五大模式详解
本文包含软件架构的重要性、定义及其常见模式，架构对系统成功的影响，五种主要的架构模式及其最佳应用场景，评估优秀架构的关键质量属性。
关注TechLead，复旦博士，分享云服务领域全维度开发技术。拥有10+年互联网服务架构、AI产品研发经验、团队管理经验，复旦机器人智能实验室成员，国家级大学生赛事评审专家，发表多篇SCI核心期刊学术论文，阿里云认证的资深架构师，上亿营收AI产品研发负责人。
一个坚实的软件架构基础，是开发创新且复杂的软件的关键，这些软件不仅要符合市场需求，还要为用户解决实际问题。你是否曾参与过一些项目，这些项目在最初的几轮开发后似乎就无法继续迭代了？这正是软件架构发挥作用的地方，它的重要性显而易见。
在软件行业中，当人们谈论“软件”时，他们通常指的是软件系统内部设计中最关键的部分。然而，这一基础的构建取决于多个因素，如软件架构师与设计师之间的相互理解、正确的设计决策以及易于理解的代码。
什么是软件架构？
从使用智能手机到发送电子邮件，我们日常生活中的许多方面都严重依赖于我们使用的系统的软件架构。没有它，我们所使用和了解的许多事物将根本无法实现。软件架构带来了组织的创新。
定义
软件架构（Software Architecture）的定义长期以来一直存在争议。对某些人来说，它是基本组件的连接方式，或系统的基础组织结构。在这方面，伊利诺伊大学副教授 Ralph Johnson 提出的抽象概念值得注意：
** “架构是关于重要的事情，无论那是什么。”
乍一听，这可能显得平淡无奇，但它实际上蕴含了丰富的内涵。软件架构是指软件系统的最高级别框架，即系统骨架。它是系统基础的最初选择之一，这一选择会显著影响工作流程、代码质量、维护、部署和开发的难易度。
软件架构主要基于一系列与软件开发相关的关键决策。这些决策对最终产品的整体成功和性能有重大影响。这些决策包括：
- 选择结构组件及其接口
- 组件之间的协作行为
- 将这些结构和行为组件配置为一个实质性的子系统
- 基于业务需求做出架构决策
软件架构与软件系统设计是否相同？
尽管大多数人认为软件架构和软件设计不同，但从根本上讲，它们是一样的。这一区别源于软件系统设计被认为是低级别的细节，而软件架构是高级别的细节。
没有高级别细节的知识，开发人员可能仍能处理低级别细节，但反之则不行。系统架构师需要完全了解他们的高级决策如何影响低级别的细节。
此外，软件设计是软件开发周期（SDLC）的初始阶段之一，它为开发人员提供了详细的数据以实现兼容的软件。
另一方面，软件架构是一个计划，约束了软件系统设计以避免常见的错误。它为组织实现技术和业务战略。
简而言之，如何构建是软件设计，而构建什么则是软件架构。
为什么软件架构如此重要？
软件架构是为特定的目标而设计的——它的全部意义在于识别那些直接关系到系统成败的组件，并构建一个服务和保护这些重要组件的系统。一个有组织的系统架构设计有助于保持内部质量，从而进一步改善软件。
以 ** Netflix ** 为例，它的 ** 微服务架构 ** 使他们能够管理可用性，而在** Salesforce ** 或** Google ** 中，则是** 领域驱动设计 ** 帮助他们处理 领域逻辑的复杂性。
让我们通过以下例子来理解这一点。
假设有两个类似的产品在一个月的时间差内发布。三个月后，它们都需要新增功能。
现在有两种情境。
- 发布——5月31日：代码混乱且纠结。用户对此没有意见，但追踪变更范围并加以整合变得非常困难。
- 发布——6月30日：代码完美有序。用户对此也没有意见，但软件开发团队可以轻松处理并实施变更。
在这种情况下，软件开发公司会怎么选择？
通常，即便代码混乱，团队也会选择提前发布，因为在当时最重要的是尽快上线——越早发布，越有机会占领市场。
然而，在第二种情境中，由于质量性能和代码质量被同等重视，变更需要更多时间，这将不利于市场投放时间。
但一个设计良好的微服务架构将有助于更轻松地进行维护。这样不仅能节省时间，还能通过快速且定期的更新满足用户需求。
** 混乱的代码可能使产品更早进入市场，但在包含新变更时会要求付出更多代价。相反，有序的代码可能导致发布延期，但最终会提供准确且及时的更新。
软件架构模式
在设计一个在线购物应用的软件开发项目时，最重要的是定义其编程架构和设计。这些是构建应用的基础。例如，产品推荐的算法将如何工作？购物车将如何运作？这一系列问题不断延伸。
软件架构模式可以被定义为解决主流和重复出现的软件工程问题的方案。接下来，我们将介绍五种常见的软件架构模式：
1. 分层架构模式
这种模式因其易于开发和维护的特点而被广泛使用。它采用分层的方法，将代码按层次组织。典型的信息系统中，最常见的四个层次为：
- 表现层或 UI 层
- 应用层或服务层
- 业务逻辑层或领域层
- 数据访问层或持久层
最佳使用场景
- 需要超过 CRUD 操作的常规业务应用
- 需要快速开发的标准应用
- 对测试和维护有严格标准的应用
2. 微内核架构模式
这种模式适用于需要适应不断变化的系统需求的应用。它分为扩展功能（插件Plugins）和最小功能核心。核心系统包括标准的业务逻辑，而插件则是独立的组件，通过自定义代码为核心系统提供特定的处理功能。
插件由独立的组件组成，通过自定义代码提供特定的处理功能来支持核心系统。微内核就像一个插座，用于连接这些插件，从而增强其潜力和功能。
最佳使用场景
- 任务和作业调度应用
- 工作流应用
- 集成来自多个源数据并将其传输到不同目的地的应用
3. 微服务架构模式
这种模式通过构建多个小型且独立的应用来构成一个完整的系统。每个应用（或微服务）各自负责不同的任务，彼此之间只需进行通信。
作为单体架构模式的可行替代方案，微服务架构已获得广泛关注和重要性。它由多个松散耦合的服务组成，在使用微服务时，需要确保它们之间的消息交换保持向后兼容。
最佳使用场景
- 快速发展的 Web 和业务应用
- 具有明确边界的企业数据中心
- 由分布在全球各地的开发团队维护的网站
4. 基于事件的架构模式
这种模式用于开发高度可扩展的系统，其异步架构方式以处理定义的“事件”，如滚动条的移动、按钮点击等。基于事件的模式包含单一用途的事件处理元素，这些元素构建了一个中央单元。中央单元接收所有数据，并将其分配给处理特定类型的独立模块。
最佳使用场景
- 用户界面
- 具有异步数据流的应用
- 需要无缝数据流且最终会扩展的复杂应用
5. 基于空间的架构模式
这种模式特别用于解决并发性和可扩展性问题，消除了中央数据库的约束，并使用复制的内存数据网格。
这种模式通过将存储和处理分布在多个服务器之间来减少高负载下功能崩溃的风险。
最佳使用场景
- 社交网络
- 高流量数据如用户日志和点击流
- 低价值数据
如何评估一个好的软件架构？
一个高效的软件架构应具有以下质量属性：
- 功能性 Functionality：软件可以提供满足用户需求的功能。
- 可用性 Usability：软件使用的便利性。
- 可靠性 Reliability：在特定情况下提供所需功能的能力。
- 可迁移性/支持性 Supportability：开发者将软件迁移到不同平台的难易度。
- 性能 Performance：考虑资源利用、处理速度、响应时间、生产力和吞吐量的近似值。
- 独立性 Self-Reliance：即使某些部分出现问题，仍能保持最佳性能的能力。
总结
综上所述，软件架构是高效软件的根基，它有助于在整个生命周期内保持产品的质量和易于管理。最终，它在长期内证明是有利且必要的，因为它更易于修改，节省了开发人员的时间和精力。
本文由博客一文多发平台 OpenWrite 发布！
