关于软件架构的一切
现有软件架构方法的详细概述
软件开发可以描述为一个复杂的系统过程，需要在各个技术领域以及相关业务方面的专业知识。就像总体规划的蓝图一样，通过定义软件的体系结构，可以促进此软件开发过程的组成部分。
为什么我们需要软件架构
> Big Ball of Mud
早期的开发人员用来设计无体系结构的软件，这种软件最初看起来像是没有计划开销以及更快的原型制作的优点。但是，随着他们深入到过程中，该软件变得像泥泞的球一样变得僵化和难以管理。随着每项变更的成本越来越高，这种方法后来被称为“泥浆大球”（Big Ball of Mud）
随着时间的推移，这种项目变得难以管理，因此每次新迭代都会大大增加维护成本。这限制了软件的发展，超出了项目开始时最初定义的范围。
在软件设计的多年发展过程中，开发人员提出了一些健壮的体系结构方法，以避免出现少体系结构的软件设计问题（也称为“泥泞大球”）。以下是一些最著名的
- 分层架构
- 多层架构
- 面向服务的体系结构（SOA）
- 微服务架构
分层架构
此方法基于关注点分离的原理。软件设计分为相互重叠的一层。每一层都承担着专门的责任。架构将软件分为以下几层
- 表示层
- 业务逻辑层
- 数据链路层
表示层拥有与外界交互的用户界面。这也负责提供用户体验，因为这是暴露给最终用户交互的唯一层。
顾名思义，业务逻辑层包含软件应用程序的业务逻辑。该层将UI / UX与业务相关的计算分离开，从而提供了根据不断变化的业务需求修改逻辑的灵活性，而不会影响其他层。
数据链接层负责与数据库等持久性存储进行交互以及与域无关的杂项数据处理（即与业务无关）
数据和控制从设计的每一层流到另一层。这些层还增加了设计中的抽象度。由于稳定性在一定程度上与抽象成正比，因此也将软件的稳定性提高到一定程度。
> Layered Representation of Architecture
好处
- 与其他方法相比，实现起来更简单
- 由于各层之间的关注点分离而提供抽象
- 层之间的隔离使其他层免受一层的修改
- 由于耦合度低，软件变得更易于管理
坏处
- 没有太大的可扩展性
- 用这种方法构建的软件将倾向于具有缺乏易于修改的单体结构
- 即使没有必要从某些层传递数据，数据也必须一层一层地从另一层流出。此问题被称为“污水池问题”
多层架构
这种架构方法根据客户端服务器通信原理将软件套件分为几层。架构可以具有n层系统中的一，二层，将数据提供者和使用者之间的职责分开。
它利用请求响应模式在定义的层之间进行通信。与分层架构不同，它提供的可伸缩性可以是水平的（通过高性能节点扩展网络）或垂直的（通过提高单个性能来扩展每个节点）
单层系统
在这种方法中，单个系统既可以充当客户端又可以充当服务器，并且可以简化部署，而无需进行系统间通信（ISC）。因此，提供了很好的通信速度。
这样的系统仅适用于小规模的单用户应用程序，而不应用于多用户复杂的应用程序。
2层系统
> 2-Tiered Architecture
这样的系统由两个物理机组成，分别是服务器和客户端。它提供了数据管理操作以及数据处理和表示操作之间的隔离。
- 客户拥有表示，业务逻辑和数据链接层。
- 服务器保存数据存储，例如数据库
3层/ n层系统
> 3-Tiered Architecture
这样的体系结构在水平和垂直方向上都是高度可扩展的。通常，实施n层体系结构比较昂贵，但可以提供高性能。因此，它在大型复杂软件解决方案中是首选。
可以将其与面向服务的高级体系结构样式相结合，以生成高度复杂的模型。当软件复杂且需要性能和扩展性时，建议使用此体系结构，因为这可能是在资源和时间上更昂贵的方法。
面向服务的架构
SOA是基于服务的体系结构模型，其中组件和应用程序使用定义良好的服务进行通信。
它由5个元素组成，即
- 服务
- 服务巴士
- 服务库服务目录
- SOA安全性
- SOA治理
客户端通过网络使用标准协议和数据格式发送请求。ESB处理的此请求可以被视为SOA的核心。ESB负责编排和路由。ESB使用服务存储库将请求定向到专用服务。该专用服务可以与其他服务或数据库交互以组成响应有效负载（响应数据）。
完整的请求响应调用符合SOA治理和安全性规则，以完成确保安全性和正确性的事务。
> https://www.udemy.com/course/software-architecture-and-design-essentials/
服务通常分为两种类型
- 原子服务：提供无法进一步分解的功能
- 组合服务：多种大气服务的集合，以提供复杂的组合功能
服务种类
服务可以是以下类型，即
- 实体服务
- 域服务
- 公用事业服务
- 综合服务
- 申请服务
- 安保服务
微服务架构
根据Martin Fowler在2014年撰写的文章中提供的定义，描述了微服务架构
简而言之，微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个小型服务都在自己的进程中运行并与轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，并且可以由全自动部署机制独立部署。这些服务的集中管理几乎没有，它可以用不同的编程语言编写并使用不同的数据存储技术。
它基于服务组件化的原理。这种体系结构将软件分解为可以定义为服务的各种组件。每项服务负有单一责任，每项服务本质上都是孤立的。一种服务的更改不应影响其他服务。
> https://divante.com/blog/monolithic-architecture-vs-microservices/
微服务包括什么
能够独立扩展的隔离，简洁和细粒度微服务的体系结构组合
架构由5个部分组成，如下所示
- 服务
- 服务巴士
- 外部配置
- API网关
- 货柜
微服务的特征
微服务架构应包含以下特征
- 通过服务进行组件化
- 围绕业务能力进行组织
- 产品不是项目
- 智能端点和哑管道
- 分散治理
- 分散数据管理
- 基础设施自动化
- 失败的设计
- 进化设计
建议与不同的团队分别开发不同的微服务，并允许每个微服务随时间同时演化，就像空气中的各种气泡一样。由于数据通信是按照标准协议和数据格式进行的，因此一项服务的结构不会影响共同服务中的功能。
> Comparison of different architectures
好处
- 由于高度隔离，提供低耦合
- 增强模块化
- 一项服务中的故障不会对整个系统造成影响，因为它们是隔离的
- 提供高度的灵活性
- 提供高度的可扩展性
- 易于修改可以加快进化迭代的速度
- 可以实现更好的错误处理
- 避免层层架构和数据流仅通过有关服务的问题
缺点
- 不同服务之间进行通信时出现故障的可能性更高。
- 难以管理大量服务。
- 需要解决的问题，例如网络延迟和负载平衡以及其他类似分布式体系结构的问题
- 分布式环境下的复杂测试
- 实施需要更多时间
参考
结论
每种软件体系结构方法的设计动机都是为了解决先前体系结构中的突出问题。拥有不同方法的适当知识可以帮助您为项目设计高效的软件架构
“尽管不存在完善的软件体系结构，但是，只要满足项目的功能和非功能需求，任何体系结构方法都可以被认为是相对完美的”
(本文由闻数起舞翻译自Ronald ?ngel的文章《Everything About Software Architecture》，转载请注明出处，原文链接： https://medium.com/swlh/everything-aboutsoftware-architecture-dfd2b9351ef4)