什么是软件架构
软件架构的对比
分层模式
客户端-服务器模式
主从设备模式
管道-过滤器模式
代理模式
点对点模式
- 要求
- 即我们常说的P2P架构,每个节点既是客户端又是服务器,任何一个节点无法直接找到其他节点,必须依靠用户群进行信息交流。它可以减低以往网路传输中的节点,以降低资料遗失的风险。
- 常见形式
- 根据中央化程度——纯P2P、杂P2P、混合P2P
- 根据网络拓扑结构——结构P2P、无结构P2P、松散结构P2P
- 优势
- 拥有很好的并行处理能力
- 对网络通信没有很高的要求,可以大幅度提高性能
- 不用投资大量金钱在服务器的软,硬体设备
- 数据分布式存储,有利于保证数据的安全性
- 劣势
- 架设较为复杂,除了要有开发服务器端,还要有专用的客户端
- 用在大规模的网络,资源分享紊乱,管理较难,安全性较低。
- 适用情况
- 文件共享网络,如迅雷等
- 多媒体协议,如P2PTV和PDTP
- 专有多媒体应用程序
事件总线模式
- 要求
- 即我们在游戏开发和移动应用开发中经常听到的观察者模式。由4个主要组件组成,分别为事件源、事件监听器、通道和事件总线。消息源将消息发布到事件总线中的特定通道上。侦听器订阅特定的通道。当消息被发送到侦听器订阅的通道是,其就会收到通知消息
- 事件总线维护一个事件源与事件处理的映射字典
- 通过单例模式,确保事件总线的唯一入口
- 利用反射完成事件源与事件处理的初始化绑定
- 提供统一的事件注册、取消注册和触发接口
- 常见形式
- 观察者模式,或者称为发布订阅模式
- 优势
- 调度灵活,针对事件进行对应的响应
- 实现简单,并没有很复杂的架构
- 快速且轻量
- 劣势
- 因为在一个比较大型的项目中,会有很多不同的事件,如果不能对这些事件做很好的抽象,就会出现接口膨胀的状况
- 适用情况
- 安卓开发
- 游戏开发
- 通知服务
模型-视图-控制器模式
- 要求
- 我们通常称之为MVC模式,是在开发过程中,最常用也是最有效的一种开发模式。由模型、视图和控制器三个部分组成。MVC模式用一种业务逻辑、数据、界面显示分离的方法组织代码,实现了一种动态的程序设计,简化后续对程序的修改和扩展,并且使程序某一部分的重复利用成为可能
- 优势
- 低代码耦合度
- 可重用性高
- 生命周期成本低
- 部署块
- 劣势
- 增加了系统的复杂性和实现的难度
- 视图对模型数据的低效率访问
- 不适合中小型应用的开发
- 适用情况
- 基本上比较大型的项目开发工作都是利用MVC架构进行实现的
黑板模式
- 要求
- 本质上与事件总线模式类似,可以算是观察者模式的一种拓展。黑板模式允许多个消息读写者同时存在,消息的生产者和消费者完全分开,主要解决的问题是消息的生产者和消费者之间的耦合问题。
- 常见形式
- 拉模式——将数据库作为黑板
- 推模式——将消息队列作为黑板
- 优势
- 可用于非确定性问题求解
- 启发式解决过程
- 可维护性高
- 可重用性好
- 劣势
- 不能确保期望结果
- 效率低下
- 回退
- 不支持并行
- 共享空间的访问需要同步
- 适用情况
- 语音识别
- 车辆识别和跟踪
- 蛋白质结构识别
- 声纳信号的解释
解释器模式
- 要求
- 是一种在开发过程中很少用到的设计模式,主要由抽象表达式、终结符表达式、非终结符表达式、环境类四个角色。我们可以将其过程理解为定义一个语言的文法,并且建立一个解释器来解释该语言中的句子
- 优势
- 易于改变和扩展文法
- 增加新的解释表达式较为方便
- 劣势
- 对于复杂文法难以维护
- 执行效率较低
- 适用情况
- 数据库查询语言
- 计算器设计
- 用于描述通信协议的语言
总结
软件架构是一个用于指导系统实现的草图,这个草图越详细对于系统实现的指导意义越重大,贯穿于软件的整个生命周期。
软件架构是要服务于业务功能的,每种架构都有特定的架构风格,不存在一种架构适用于所有系统,所以在开发过程中所使用的软件架构要根据我们自己的实际情况而定。