软件架构

关注的内容

• 多个软件实体之间如何组织起来？
• 软件和硬件之间的关系如何？

体系结构 = 构件 + 连接体 + 拓扑结构 + 约束 + 质量

对于大规模的复杂软件系统来说，对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择已经变得明显重要得多

构件

具有某种功能的可复用的软件结构单元

• 构件 = 接口 + 功能

连接

构件间建立和维护行为关联与信息传递的途径

• 连接件
  • 管道
  • 过程调用
  • 事件广播
  • 客户机-服务器
  • 数据库连接SQL

基本模式

分层

C/S、B/S、多层，数据、计算与显示的分离（MVC）

• 一个模块做很多事情 $\rightarrow$ 各负其责，分工明确
• 牺牲了效率，提升了可维护性

异步

事件、消息

• 请求之后等待结果（同步）$\rightarrow$ 请求之后继续执行，后续等待结果（异步）
• 性能提高，但实时性变差

缓存

页面缓存、数据缓存、消息缓存

• 直接到源头去取 $\rightarrow$ 预取
• 提高了效率，但牺牲了准确性

并发（分布式）

集群、负载均衡、分布式数据库

• 原本一个模块处理很多请求 $\rightarrow$ 多个模块共同处理这些请求
• 提高了吞吐量、响应事件、可靠性，但需要考虑同步等复杂问题

架构风格

• 调用-返回风格
  • 将大系统分解为若干模块，主程序调用这些模块实现完整的系统功能
  • 不考虑分层，主要遵循同步调用方式
• 面向对象风格
  • 对象之间通过函数调用、消息传递实现交互
• 以数据为中心的风格
  • 数据的持久化存储被分离出去，形成两层结构
• 数据流风格
  • 把系统分解为几个序贯的处理步骤，这些步骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入
  • 每个处理步骤由一个过滤器构件实现
  • 处理步骤之间的数据传输由管道负责
• 层次风格
  • 除了数据被分离出去，软件系统的其他各部分进一步分离，形成更复杂的层次结构
• C/S结构（客户机-服务器体系结构）
  • 一个应用系统被分为两个逻辑上分离的部分，每一部分充当不同的角色、完成不同的功能，多台计算机共同完成统一的任务
    • 客户机：业务逻辑、与服务器通讯的接口
      • 胖客户端：客户端执行大部分的数据处理操作
      • 瘦客户端：客户端具有很少或没有业务逻辑
    • 服务器：与客户机通讯的接口、业务逻辑、数据管理
• B/S结构（浏览器/服务器）
• M/C结构（移动端/云端结构）

MVC（模型-视图-控制器）

用户界面需要频繁地修改，它是“不稳定“的 所以业务逻辑与用户界面之间应避免少的直接通信

将应用程序的数据模型/业务逻辑、用户界面分别放在独立的构件中，从而对用户界面的修改不会对数据模型/业务逻辑造成很大影响

• 模型：用于管理应用系统的行为和数据，并响应为获取其状态信息而发出的请求，还会响应更改状态的指令
• 视图：用于管理数据的显示
• 控制器：用于解释用户的鼠标和键盘输入，以通知模型和视图进行相应的更改