第 1 讲 软件模式架构
1.软件架构模式概念
1.1 架构是什么
定义
架构是构成一个系统的基础组织结构,包括系统的组件构成,组件间的相互关系、系统和其所在的关系、以及指导架构设计和演进的相关准则。
特性
-
架构定义系统的结构
-
架构定义系统的行为和交互
-
架构只关注影响系统的重要元素
-
架构遵循一种架构风格
-
架构需要平衡工系私的需求
-
架构受所处环境的约束,反过米也影响它的环境
-
架构不仅仅要实现最后产出,还必须保证是合理和正确的
-
大多数的架构难点都和质量参数相关,而不是功能需求
架构风格
-
定义:以结构组织模式定义的一类系统族。一种软件体系结构风格刻划了一个具有类似结构和语义的系统家族。内容包括:
-
构件
-
交互关系
-
约束条件
-
架构风格 | 风格分类 |
---|---|
数据流风格 | 批处理 |
管道/过滤器 | |
调用/返回风格 | 主程序/子程序 |
面向对象风格 | |
层次风格 | |
独立构件风格 | 进程通讯 |
事件系统 | |
虚拟机风格 | 解释器 |
基于规则的系统 | |
仓库风格 | 数据库系统 |
超文本系统 | |
黑板系统 |
遵循架构风格的好处:
-
建立共识:
-
架构遵循某种风格, 使相关人员更加理解架构,降低沟通成本
-
遵循架构风格, 可以加快架构选型
-
架构沉淀:
-
基于架构风格, 可以快速的明确架构中需要复用/沉淀的构件,形成架构框架
-
-
促进复用:
-
架构规划中遵循适合的架构风格, 可以提升效率,规避风险
-
设计中遵循架构风格,提升开发效率
-
架构与框架
框架是软件,架构不是软件。
框架的作用:
-
通过框架实现了架构的沉淀落地
-
框架的质量决定了系统整体架构的质量
-
对框架的验证,验证了整体系统架构
1.2 架构模式
什么是模式
模式其实就是模板,基于同样的一个模板,可以有很多种变种,同样的一种模板的一个框架,或者是模板的一种架构,它有很多种变种来满足我们不同的需求。
架构模式
-
架构模式是对以往系统的架构抽象而形成的模板
-
是对某个具体环境 下问题的结构性解决方案
-
内容包括:
-
提供一些事先定义好的子系统, 指定它们的责任
-
给出把它们组织在一 起的法则和指南。
-
架构风格与架构模式的异同
-
概念上,通常可以互用
-
架构风格反映了系统遵循的某种模式,是一类系统的抽象总结描述
-
架构模式,是架构风格具体化的模板,可以包含一种或多种架构风格,是为了实现某个目标,而形成的解决方案模板。
模式的构成
-
语境
-
问题
-
解决方案
模式的层次分类
-
架构模式
-
设计模式
-
代码模式
FEAF 和软件架构模式
2. 常见的架构模式
2.1 常见的错误架构演进
架构大泥球
定义: 一大片随意构造,杂乱无章,凌乱,任意拼接,毫无头绪的代码丛林。这些代码模块,没有组织性,缺乏明确的规则、职责和同其他模块之间的关联。
产生的原因:缺乏架构设计
-
缺少前期设计
-
应对需求变化过晚
-
应对架构变化过晚
-
碎片式增长-乱打补丁
常态存在的原因:只看眼前、快、省
-
前期时间成本少,交付快
-
用户只关心结果,不关心实现
-
新增需求通过补丁的方式实现简单
如何避免架构大泥球
选择合适的架构模式
2.2 六种常见的架构模式
1. 分层架构模式
分层架构定义:
-
组件被分成几个平行的层次。层次是具体工作的高度抽象,它们都是为了实现某种特定的业务请求
-
每层有都有特定的角色和职能,每层都代表了系统的一类功能。系统中的每个构件都在相应的层中。
-
每层组件关注点分离,本层中的组件只会处理本层的逻辑。
适用范围:
-
最常见的架构、与大多数企业的组织架构模式相似,所以用处最广。
-
适用于以交易密集、管理密集型的为主的应用
分层的要义:
-
确定层和请求流之间的关系;
-
明确各种层之间的访问限制.
层封闭:
-
请求自上而下进行调用,不能自下向上逆层调用
-
每层都是封闭的,上层请求必须逐层传递,向下层访问。
-
下层服务于上层
层隔离:
-
架构中的某一层的改变不会影响到其他层,这些变化的影响范围限于当前层次。
-
层与层之间要完全独立。
层开放原则:
如果80%的请求都是简单的穿过某层,此层没有做逻辑或数据处理,仅仅是简单传递信息,则此层应该开放。
层开放的优劣:
-
优点:层开放增加了系统的灵活性,提升了效率。
-
缺点:增加了管理复杂度,随意的开放,提升了架构大泥球化的风险。
分层架构模式评估
评估点 | 评估值 | 简述 |
---|---|---|
整体灵活性 | 低 | 分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因 |
易部署性 | 低 | 层与层之间逐级访问,每层都需要部署,才能支持一个业务。 |
可测性 | 高 | 因为组件都处于各自的层次中,可以模拟其他的层,或者说去掉层进行分层测试,所以分层模式很容易测试 |
性能 | 低 | 一次业务请求要穿越所有的架构层,层次越多效率越低。 |
伸缩性 | 低 | 分层解决”了横向隔离,没有解决水平扩展问题 |
易开发性 | 高 | 架构易于理解,开发人员认可度高。 |
2. 面向服务的架构模式
基本特征:
-
服务的封装
-
服务的重用
-
服务的互操作
-
服务是自治的功能实体
-
服务之间的松耦合度
-
服务是位置透明的
-
明确定义的接口
参考模型:
-
企业服务总线 提供消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能
-
各类业务服务:
-
从功能分类:交互服务、流程服务、信息服务、合作伙伴服务、(原)企业应用服务、接入服务等
-
服务形态分类:原子服务、复合服务、流程服务等
-
SOA架构模式评估
评估点 | 评估值 | 简述 |
---|---|---|
整体灵活性 | 高 | 各个服务相对解耦,针对需求变化可以根据服务进行迭代交付。 |
易部署性 | 高 | 统一的ESB总线独立部署,其他异构服务可以分别独立部署。 |
可测性 | 高 | 可以分服务进行测试 |
性能 | 低 | 服务请求需要通过esb总线进行传输,效率偏低。 |
伸缩性 | 低 | ESB的集中式架构,对伸缩性方面没有特别的优势 |
易开发性 | 高 | 通过定义服务标准化协议,系统各层、各服务可以分别开发。 |
3. 微服务架构模式
参考模型:
微服务架构来源分析:
特征:
-
通过服务实现组件
-
基于业务功能搭建团队
-
做产品而非项目
-
智能化服务端点和哑管道
-
分/去中心化的数据管理
-
离散式治理
拓扑结构:
-
客户端直接访问
-
客户端直接访问各个微服务暴漏的rest API
-
一般用于简单应用或实验性应用,实际商用应用较少采用。
-
主要问题:客户端需要链接不同的微服务API地址,客户端逻辑复杂
-
-
基于REST API
-
一般用于暴漏出小的独立的微服务,该结构由很细粒度的服务组件组成。
-
这些细粒度的服务组件可使用基于REST的接口访问,通常部署为独立的的基于Web的API层 API GateWay层
-
通常为简单的接口处理,采用轻量级web服务器,如nginx
-
-
基于REST应用
-
一般用于暴漏出粗粒度的微服务
-
用户交互层,为web应用或富客户端,有一-定的交互逻辑,采用web应用服务器,如weblogic/tomcat等
-
此种结构与Rest API结构的区别就在于,rest api结构层比较薄,仅有接口逻辑,没有交互处理逻辑。
-
-
基于消息的结构
-
适用于用于应用或UI层与服务组件之间的传输层需要复杂控制的参加。
-
采用使用轻量级的集中消息代理组件代替REST进行远程访问,可以称为小型SOA架构。
-
比起SOA架构,消息代理组件不做编排、转换或复杂的路由,它只是向服务组件远程传递消息。
-
微服务架构模式评估
评估点 | 评估值 | 简述 |
---|---|---|
整体灵活性 | 高 | 微服务可以单独部署单元的概念,变化隔离成单独的服务;松耦合的。 |
易部署性 | 高 | 每个微服务都可以独立部署发布 |
可测性 | 高 | 每个微服务都业务内聚的,带有完整的业务逻辑、业务数据,可以单独进行功能测试、压力测试。 |
性能 | 低 | 对单业务来讲,微服务化后会经历多次交互,性能相应下降。 |
伸缩性 | 高 | 每个微服务都是独立的进程,可以分别进行弹性伸缩 |
易开发性 | 高 | 由于功能被分隔成不同的服务组件,由于开发范围更小且被隔离,开发变得更简单 |
4. 事件驱动架构
-
中介拓扑结构
-
代理拓扑结构
5. 基于内存空间的架构(SBA)
参考模型:
适用范围:
-
解决高性能、高并发的伸缩性需求用于有大量不可预测并发用户的应用。
-
适合使用传统的大规模关系数据库的应用
SBA架构模式评估:
评估点 | 评估值 | 简述 |
---|---|---|
整体灵活性 | 高 | Pu之间相对独立,可以分别部署和启停。应用需求变化可以分Pu进行修改,应对业务变化,可以分Pu进行弹性伸缩。 |
易部署性 | 高 | 每个PU都可以独立部署发布 |
可测性 | 低 | 基于内存的测试难度较高 |
性能 | 高 | 基于内存处理,性能很高 |
伸缩性 | 高 | 没有集中的数据存储层,Pu可以完全线性扩展。 |
易开发性 | 低 | 基于内存的开发,需要较高的门槛。 |
6. 微内核架构
参考模型:
特点:
-
微内核架构可以嵌入到其他架构中
-
微内核架构很好的支持了渐进式设计和增量开发
适用场景:
-
基于核心系统的外围应用
-
基于核心版本的分支版本扩展
微内核架构模式评估:
评估点 | 评估值 | 简述 |
---|---|---|
整体灵活性 | 高 | 核心系统趋于稳定,插件模块快速适应变化 |
易部署性 | 高 | 插件可以被热插拔 |
可测性 | 高 | 每个插件独立解耦,可以单独测试 |
性能 | 高 | 核心系统内聚稳定,插件应用按需定制,使得整体系统摒弃了无谓的插件兼容内容,整体性能得到提升 |
伸缩性 | 低 | 伸缩性依赖于核心系统 |
易开发性 | 低 | 需求较强的设计规约;插件注册、插件粒度、插件连接方式是关键点。 |
2.3 六大架构总体评估
分层架构 | SOA架构 | 微服务架构 | 事件驱动架构 | 内存空间架构 | 微内核架构 | |
---|---|---|---|---|---|---|
整体灵活性 | 低 | 高 | 高 | 高 | 高 | 高 |
易于部署 | 低 | 高 | 高 | 高 | 高 | 高 |
可测试性 | 高 | 高 | 高 | 低 | 低 | 高 |
性能 | 低 | 低 | 低 | 高 | 高 | 高 |
伸缩性 | 低 | 低 | 高 | 高 | 高 | 高 |
易于开发 | 高 | 高 | 高 | 低 | 低 | 低 |
3. 架构模式的应用方法
3.1 架构模式的选择
3.2 混搭的架构模式
架构混搭的原因:
-
大型系统的业务复杂度决定了不可能采用一种架构模式构建整个系统,通常是多种架构模式的组合
-
每种架构模式都有不同特点优劣,应该根据具体情况来选择适合的架构模式,以解决实际问题
-
技术标准的约束,市场的影响,客户的决策也影响了不一-定可以采用最优的架构模式,必须基于一定的约束进行修正
-
与遗留系统的架构混搭
架构模式混搭方式:
-
域混搭:不同的子系统采用不同的模式
-
层混搭:不同的层级采用不同的模式
-
内外混搭:系统内外部采用不同的模式
-
业务混搭:不同业务采用不同的模式
-
处理混搭:不同的数据处理方式采用不同的模式