[论文阅读]架构风格与基于网络的软件架构 第二章

---

2022年10月21日
原文：Architectural Styles and the Design of Network-based Software Architectures
目的：记个笔记；快速熟悉网络架构中的一些关键的设计风格，便于对架构整体进行优化。
说明：翻译质量并不太好，其中掺杂少量个人浅薄的理解，希望所述对您有用，同时欢迎指正。

---

第二章：基于网络的应用架构

这一章节继续介绍背景材料，主要包括介绍基于网络的应用架构以及架构风格如何被用于指导架构的设计。

2.1 范围

架构是被建立在软件系统的多个层级之上。本文研究了软件体系结构中的最高抽象级别，其组件之间的交互能够在网络通信中实现。本文的讨论仅局限于基于网络的应用程序的架构风格，以减少所研究的架构风格之间的差异。

2.1.1 基于网络 vs. 分布式(略)

2.1.2 应用软件 vs. 网络软件(略)

2.2 评估应用架构的设计(略)

2.3 重点关注的架构风格/属性

2.3.1 性能(略)

2.3.1.1 网络性能（略）

2.3.1.2 用户感知性能/用户体验（略）

2.3.1.3 网络有效性

2.3.2 可伸缩性（Scalability）

• 定义：指架构在现行配置中，支持大量组件或组件之间交互的能力。可伸缩性好表现为：通过很少的改动甚至只是硬件设备的添置，就能实现整个系统处理能力的线性增长，实现高吞吐量和低延迟高性能。
• 如何提升可可伸缩性？
  • 简化组件
  • 跨多个组件（去中心）分发服务
  • 通过监控去控制交互和配置
• 影响因素：
  • 应用或程序所处的状态
  • 分布的范围
  • 组件的耦合程度
  • 交互的频率
  • 组件的加载是否随时间均匀分布，还是在峰值上？
  • 交互是否要确保交付？
  • 是否涉及到了异步或同步处理？
  • 部署环境是否可控？

2.3.3 简单性（Simplicity）

• 定义：指的是在组件里，对其中的功能模块应用分离原则（类似单一原则），如果将这些组件分为一些不复杂的功能模块，使得这些组件更加容易理解和实现（更加简单）。这种分离原则简化了整体架构的理解。这里将复杂性、可理解性和可验证性合在一起归为简单性，是因为在网络架构中他们是相辅相成的。
• 如何提升简单性？
  • 应用分离原则
  • 将一些通用原则应用于架构中因为会提高简单性，原因在于这样会减少架构中变化。by the way，这些通用的东西会形成中间件。

2.3.4 可修改性（Modifiability）

• 定义：指对应用程序架构进行更改的容易程度。可修改性可以被细分为可演化性、可扩展性、可定制性、可配置性和可重用性。
  • 基于网络的系统需要特别关注的是动态可修改性，这里的动态指的是部署应用的时候不用重启所有系统。尽管开发一个软件系统可能能满足用户的所有需求，但是这些要求会随着时间的推移而改变，就像社会会随着时间而改变一样。由于参与基于网络的应用程序的组件可能分布在多个组织边界上，因此系统必须为渐进和零散的变化做好准备，在这种情况下，新旧实施共存，而不会阻止新实施使用其扩展功能。
• 如何提升可修改性？
  • 为渐进和零散的变化做好准备，可以通过它的细分属性（可演化性、可扩展性、可定制性、可配置性和可重用性）的角度考虑。

2.3.4.1 可演化性（Evolvability）

• 定义：可演化性表示组件实现可以在不影响其他组件的情况下进行更改的程度。
  • 组件的静态演化通常取决于实现对架构抽象的执行程度，因此对于任何特定的架构风格来说都不是唯一的。
  • 动态演化包括对应用程序状态的维护和位置的约束，则它会受到样式的影响。一些在分布式系统中的出现部分故障时，采用的恢复技术，就可用于支持动态演化。
• 如何提升可演化性？
  • 静态演化：通常取决于实现对架构抽象的执行程度，因此对于任何特定的架构风格来说都不是唯一的。比如：应用一些设计原则（高内聚低耦合），设计模型或者软件设计模式等。
  • 动态演化：在一些分布式系统中的出现部分故障时，采用的恢复技术，就可用于支持动态演化。

2.3.4.2 可扩展性（Extensibility）

• 定义：可扩展性指的就是向系统中添加功能的能力。动态扩展性意味着可以将功能添加到已部署的系统中，而不会影响系统的其余部分。在架构风格中，可扩展性是通过减少组件之间的耦合程度而产生的，比如，通过基于事件的集成方式。
• 如何提升可扩展性？
  • 减少组件之间的耦合程度
  • 比如：基于事件的集成方式

2.3.4.3 可定制性（Customizability）

• 定义：可定制性指的是暂时定制化架构元素行为的能力，以便它可以执行一些定制化的服务。如果组件可以由该组件服务的一个客户端扩展，而不会对该组件的其他客户端产生不利影响，则该组件是可定制的。这个风格可以提升架构的简单性、可伸缩性，原因在于它实现了最频繁的服务，并允许客户端定义不频繁的服务，这样可以减少服务组件的大小和复杂性。可定制性是由远程评估和按需代码的风格所产生的一种属性。
• 如何提升可定制型？
  • 实现了最频繁的服务，并允许客户端定义不频繁的服务（个人理解）

2.3.4.4 可配置性（Configurability）

• 定义：可配置性与可扩展性和可重用性相关，因为它指的是组件在部署后可修改或者可配置，以便能够使用新的服务或数据元素类型。
• 如何提升可配置性?
  • 管道-过滤器
  • 按需代码

2.3.4.5 可复用性（Reusability）

• 定义：那么可重用性是应用程序体系结构的一个属性，就比如说：应用程序架构的组件、连接器或数据元素可以在其他应用程序中重复使用，而无需修改。
• 如何提升可复用性？
  • 减少组件之间的耦合
  • 提升接口的通用性
  • 统一的管道和过滤器样式

2.3.5 可见性（Visibility）

• 定义：一个组件监视或仲裁两个其他组件之间交互的能力。这里的可见性指的是产品而非开发过程
• 影响因素？
  • 接口的通用性，
  • 访问授权
• 如何提升可见性？以及提升可见性的好处？
  • 通过共享交互中的缓存提高性能
  • 通过分层服务提升可扩展性
  • 通过反射监控实现可靠性
  • 通过中介（防火墙）检查交互实现安全性
  • 移动代理风格就是一个缺乏可见性的导致安全问题的例子。

2.3.6 可移植性（Portability）

• 定义：如果软件需要在不同环境中运行就需要可移植性。可移植性指的就是将代码与待处理的数据移植，比如虚拟机、移动代理这种风格，以及将数据元素约束为一组标准化格式的风格。

2.3.7 可靠性（Reliability）

• 定义：从应用程序结构的角度来看，可靠性可以被视为在组件、连接器或者数据存在部分故障时，应用程序引起系统级故障的可能性。
• 如何提升可靠性？
  • 避免单点故障
  • 启用冗余
  • 允许监控
  • 将故障缩小为可恢复操作的范围

2.4 总结(略)

ref：

• 关于架构风格的解释以及优化思路，详见原文：https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3
• https://zhuanlan.zhihu.com/p/362496728
• 设计模式的6个原则：https://blog.csdn.net/u010212101/article/details/73522188
• https://blog.csdn.net/mlynb/article/details/117199288

其他

1.可交付性：有轻量级部署方案，且配套完善的工具和文档
2.可继承性：具备二次开发能力，能够快速扩展功能
3.可服务性：能够低成本持续运营，尽量减少人工介入
4.可伸缩性：系统架构能根据业务规模弹性伸缩（能伸，能缩）

未完，待续>>>