第 1 讲 软件模式架构
1.软件架构模式概念
1.1 架构是什么
定义
架构是构成一个系统的基础组织结构,包括系统的组件构成,组件间的相互关系、系统和其所在的关系、以及指导架构设计和演进的相关准则。
特性
-
架构定义系统的结构
-
架构定义系统的行为和交互
-
架构只关注影响系统的重要元素
-
架构遵循一种架构风格
-
架构需要平衡工系私的需求
-
架构受所处环境的约束,反过米也影响它的环境
-
架构不仅仅要实现最后产出,还必须保证是合理和正确的
-
大多数的架构难点都和质量参数相关,而不是功能需求
架构风格
-
定义:以结构组织模式定义的一类系统族。一种软件体系结构风格刻划了一个具有类似结构和语义的系统家族。内容包括:
-
构件
-
交互关系
-
约束条件
-
架构风格 | 风格分类 |
---|---|
数据流风格 | 批处理 |
管道/过滤器 | |
调用/返回风格 | 主程序/子程序 |
面向对象风格 | |
层次风格 | |
独立构件风格 | 进程通讯 |
事件系统 | |
虚拟机风格 | 解释器 |
基于规则的系统 | |
仓库风格 | 数据库系统 |
超文本系统 | |
黑板系统 |
遵循架构风格的好处:
-
建立共识:
-
架构遵循某种风格, 使相关人员更加理解架构,降低沟通成本
-
遵循架构风格, 可以加快架构选型
-
架构沉淀:
-
基于架构风格, 可以快速的明确架构中需要复用/沉淀的构件,形成架构框架
-
-
促进复用:
-
架构规划中遵循适合的架构风格, 可以提升效率,规避风险
-
设计中遵循架构风格,提升开发效率
-
架构与框架
框架是软件,架构不是软件。
框架的作用:
-
通过框架实现了架构的沉淀落地
-
框架的质量决定了系统整体架构的质量
-
对框架的验证,验证了整体系统架构
1.2 架构模式
什么是模式
模式其实就是模板,基于同样的一个模板,可以有很多种变种,同样的一种模板的一个框架,或者是模板的一种架构,它有很多种变种来满足我们不同的需求。
架构模式
-
架构模式是对以往系统的架构抽象而形成的模板
-
是对某个具体环境 下问题的结构性解决方案
-
内容包括:
-
提供一些事先定义好的子系统, 指定它们的责任
-
给出把它们组织在一 起的法则和指南。
-
架构风格与架构模式的异同
-
概念上,通常可以互用
-
架构风格反映了系统遵循的某种模式,是一类系统的抽象总结描述
-
架构模式,是架构风格具体化的模板,可以包含一种或多种架构风格,是为了实现某个目标,而形成的解决方案模板。
模式的构成
-
语境
-
问题
-
解决方案
模式的层次分类
-
架构模式
-
设计模式
-
代码模式
FEAF 和软件架构模式
分层架构定义:
-
组件被分成几个平行的层次。层次是具体工作的高度抽象,它们都是为了实现某种特定的业务请求
-
每层有都有特定的角色和职能,每层都代表了系统的一类功能。系统中的每个构件都在相应的层中。
-
每层组件关注点分离,本层中的组件只会处理本层的逻辑。
适用范围:
-
最常见的架构、与大多数企业的组织架构模式相似,所以用处最广。
-
适用于以交易密集、管理密集型的为主的应用
分层的要义:
-
确定层和请求流之间的关系;
-
明确各种层之间的访问限制.
层封闭:
-
请求自上而下进行调用,不能自下向上逆层调用
-
每层都是封闭的,上层请求必须逐层传递,向下层访问。
-
下层服务于上层
层隔离:
-
架构中的某一层的改变不会影响到其他层,这些变化的影响范围限于当前层次。
-
层与层之间要完全独立。
层开放原则:
如果80%的请求都是简单的穿过某层,此层没有做逻辑或数据处理,仅仅是简单传递信息,则此层应该开放。
层开放的优劣:
-
优点:层开放增加了系统的灵活性,提升了效率。
-
缺点:增加了管理复杂度,随意的开放,提升了架构大泥球化的风险。
分层架构模式评估
评估点 | 评估值 | 简述 |
---|---|---|
整体灵活性 | 低 | 分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因 |
易部署性 | 低 | 层与层之间逐级访问,每层都需要部署,才能支持一个业务。 |
可测性 | 高 | 因为组件都处于各自的层次中,可以模拟其他的层,或者说去掉层进行分层测试,所以分层模式很容易测试 |
性能 | 低 | 一次业务请求要穿越所有的架构层,层次越多效率越低。 |
伸缩性 | 低 | 分层解决”了横向隔离,没有解决水平扩展问题 |
易开发性 | 高 | 架构易于理解,开发人员认可度高。 |
2. 面向服务的架构模式
基本特征:
-
服务的封装
-
服务的重用
-
服务的互操作
-
服务是自治的功能实体
-
服务之间的松耦合度
-
服务是位置透明的
-
明确定义的接口
参考模型:
5. 基于内存空间的架构(SBA)
参考模型:
特点:
-
微内核架构可以嵌入到其他架构中
-
微内核架构很好的支持了渐进式设计和增量开发
适用场景:
-
基于核心系统的外围应用
-
基于核心版本的分支版本扩展
微内核架构模式评估:
评估点 | 评估值 | 简述 |
---|---|---|
整体灵活性 | 高 | 核心系统趋于稳定,插件模块快速适应变化 |
易部署性 | 高 | 插件可以被热插拔 |
可测性 | 高 | 每个插件独立解耦,可以单独测试 |
性能 | 高 | 核心系统内聚稳定,插件应用按需定制,使得整体系统摒弃了无谓的插件兼容内容,整体性能得到提升 |
伸缩性 | 低 | 伸缩性依赖于核心系统 |
易开发性 | 低 | 需求较强的设计规约;插件注册、插件粒度、插件连接方式是关键点。 |
2.3 六大架构总体评估
分层架构 | SOA架构 | 微服务架构 | 事件驱动架构 | 内存空间架构 | 微内核架构 | |
---|---|---|---|---|---|---|
整体灵活性 | 低 | 高 | 高 | 高 | 高 | 高 |
易于部署 | 低 | 高 | 高 | 高 | 高 | 高 |
可测试性 | 高 | 高 | 高 | 低 | 低 | 高 |
性能 | 低 | 低 | 低 | 高 | 高 | 高 |
伸缩性 | 低 | 低 | 高 | 高 | 高 | 高 |
易于开发 | 高 | 高 | 高 | 低 | 低 | 低 |
3. 架构模式的应用方法
3.1 架构模式的选择

3.2 混搭的架构模式
架构混搭的原因:
-
大型系统的业务复杂度决定了不可能采用一种架构模式构建整个系统,通常是多种架构模式的组合
-
每种架构模式都有不同特点优劣,应该根据具体情况来选择适合的架构模式,以解决实际问题
-
技术标准的约束,市场的影响,客户的决策也影响了不一-定可以采用最优的架构模式,必须基于一定的约束进行修正
-
与遗留系统的架构混搭
架构模式混搭方式:
-
域混搭:不同的子系统采用不同的模式
-
层混搭:不同的层级采用不同的模式
-
内外混搭:系统内外部采用不同的模式
-
业务混搭:不同业务采用不同的模式
-
处理混搭:不同的数据处理方式采用不同的模式
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!