Java教程

软件体系复习

本文主要是介绍软件体系复习,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

Software Architecture(软件体系结构)简称SA

1993年D Garlan, M Shaw

D Garlan, M Shaw提出软件架构包括 component(组件)、connector(连接件)和constraint(约束**)三大要素

1992年元素(D E.Perry与A L.Wolf)

处理元素(processing elements)负责对数据进行加工

数 据元素(data elements)是被加工的信息

连接元素(connecting elements)把体系结构的不同部分组合连接起来

2011年ISO/IEC/IEEE标准

ISO/IEC/IEEE标准中定义软件架构是某一系统的基本组织结构, 其内容包括软件构件,构件间的联系,构件与其环境间的联系,以及指导上述内 容设计与演化的原理。

1999年Booch,Rumbaugh and Jacobson

Booch,Rumbaugh and Jacobson从另一个角度对软件架构的概 念进行了全新的诠释,认为架构是一系列重要决策的集合。

Anton, 2005软件架构是架构层次上所有 设计决策的集合体

Kruchten, 2006软件体系结构是设计决策+设计(设计决策的推理过程)

基于D Garlan, M Shaw的定义:软件体系结构 = 组件 + 连接件 + 约束

组件:具有某种功能的可重用的软件模块单元,表示了系统中主要的计算单元数据存储连接件:表示了组件之间的交互,简单的连接件有:管道(pipe)、过程调用 (procedure-call)、事件广播(event broadcast)等。复杂的连接件有:客户-服务器 (client-server)通信协议,数据库和应用之间SQL连接等。 约束:表示了组件和连接件的拓扑逻辑和约束(constraint)。

架构

架构是为了解决软件复杂性问题。

软件系统的复杂度

软件系统的复杂度的有以下来源:高性能、高可用、可扩展、安全、 规模和低成本。

单体架构

用户比较多的单体架构

面向服务的架构SOA

微服务架构

将一个大的系统拆成若干个独立的小系统,分别进行维护和部署,都运行在自己独立的进程中。它们之间可以通过轻量级的通信协议(http等)进行通信,在功能上还是一个完整的整体,这样的设计方法称之为微服务的架构。

微服务之间的通信可以有同步和异步两种方式,同步采用RPC或(RESTful),异步采用消息队列。

软件体系结构风格

[风格]  https://zhuanlan.zhihu.com/p/39784838 

preview

管道/过滤器风格的特点:(摘自:【百度百科】软件体系结构)

(1)使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;

(2)允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成

(3)支持软件重用。重要提供适合在两个过滤器之间传送的数据,任何两个过滤器都可被连接起来;

(4)系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来;旧的可以被改进的过滤器替换掉;

(5)允许对一些如吞吐量、死锁等属性的分析;

(6)支持并行执行。每个过滤器是作为一个单独的任务完成,因此可与其它任务并行执行。

img

举例(媒体播放器

preview

编译器

preview

事件系统风格

事件驱动架构:当软件系统中存在的一些事件发生,导致其他部分执行或者操作的设计方法叫事件驱动架构

一个事件驱动风格实例

事件系统风格常用实现方式: 一种是无事件管理器模式,一种是有事件管理器模式。 无事件管理器模式常见的是观察者模式。有事件管理器常见的是点对点模式和发布订阅模式。

设计模式

观察者模式:

有管理器模式模式

可应用场景

点对点模式、竞争消费者模式和发布订阅模式

微服务风格

SOA

SOA的产生背景: 企业各部门都有独立的IT系统,比如人力资源系统、销售系统等,随着企业业务的发展,更多业务需要将各部门的IT系统集成到一起工作,但是各个部门的IT系统的提供商不同、实现技术不同,有的系统用Java开发,对外提供RPC;有的系统用C#开发,对外提供SOAP协议,只能借助ESB进行格式转换了,所以SOA就诞生了。

微服务架构特征

1)组件化与服务 每个服务运行在一个独立的进程中

2)围绕业务能力进行组织

3)产品不是项目 you build,you run it

4)智能终端弱管道 通过轻量级RESTfulAPI进行通信或通过RabbitMQ通信

5)去中心化 没有ESB,各自数据库独立

6)重点是自动化部署、自动化测试、熔断等技术

SOA和微服务区别

微服务是去掉ESB后的SOA。SOA的ESB太中心化,如果它有问题,整个系统就瘫痪了。所以微服务是去中心化的,当然去中心化还体现在每个微服务有自己独立的数据库。

微服务是细粒度的SOA,且通过HttpRESTful协议或RPC协议代替ESB。

微服务应用场景是互联网级,SOA应用场景是企业级。

微服务的理念是快速交付,SOA的理念是解决兼容问题。快速交付就要求采用自动化测试、持续集成、自动化部署等。

Nacos Config中的几个概念

使用Nacos Config作为配置中心,就是将Nacos当做一个服务端,将各个微服务看 成客户端,我们将各个微服务的配置文件统一放在Nacos上,然后各个微服务从 Nacos上拉去配置即可。

命名空间(namespace):用于不同环境或用户的配置隔离 配置分组(group):用于将不同服务归类为同一个组 配置集(data id):一个微服务的配置文件就是一个配置集

降级、限流和熔断---保护你的微服务

降级:为了业务高可用,丢车保帅,停掉非业务功能,优先保证核心业务可用。例如:论坛可以降级 为只能看帖子,不能发帖子。

限流:只允许系统能够承受的用户量进来访问,超出系统访问能力的用户将被抛弃。

熔断:A服务的X功能依赖B服务的某个接口,当B服务的接口响应很慢的时候,A服务的X功能响应肯定 也会被拖慢,进一步导致A服务的线程都被卡在X功能处理上,此时A服务的其他功能都会被卡住或响应 非常慢。这时就需要熔断机制了,即A服务不再请求B服务的这个接口,A服务内部只要发现请求B服务 的这个接口就立即返回错误,从而避免A服务整个被拖慢甚至拖死。

熔断和降级是两个比较容易混淆的概念,降级的目的是应对系统自身的故障,而熔断的目的是应对 依赖的外部系统故障的情况。

自动化部署和自动化测试

容器化:Docker是容器引擎,起到应用隔离 作用。K8S是容器编排系统,用于容器管理, 容器间的负载均衡。

自动化测试框架有Junit(单元测试)、 Selenium(Web应用程序自动测试)等。

资源

统一资源接口要求使用标准的HTTP方法对资源进行操作,所以URI只应该来表示资源的名称,而不应该包括资源的操作。通俗来说,URI不应该使用动作来描述。例如:

GET /getUser/1 =>GET /user/1 获得资源

POST /createUser=>POST /user 创建资源

PUT /updateUser/1=>PUT /user/1更新资源

DELETE /deleteUser/1= >DELETE /user/1 删除资源

原来对资源进行操作的方法,不规范 =>方法名+资源名 标准且规范

客户端与服务端的交互必须是无状态的,并在每一次请求中包含处理该请求所需的一切信息。

RESTful风格

RESTful架构风格使得前后端分离了

使用RESTful风格可以克服传统架构风格的那4个缺陷:

①设计API工作量减少,因为功能需求一旦出来,需要操作的资源、操作的方式立刻就能分析出来,因此资源URL和API的使用方式(GET, POST...)都很容易得到。 ②没有了操作之间的依赖。资源之间虽然可能有关联,但是小得多。 ③对资源的操作也就那么几种(获取、新建、修改、删除),API的一致性、自我描述性很强,不需要过多解释。 ④对于GET请求,我们都可以考虑使用缓存,因为在RESTful的架构中,GET请求代表获取数据,必须是安全、幂等的。

无服务风格

无服务架构风格使得“一个函数可以是一个微服务”成为现实。

BaaS 后端即服务

IaaS 基础设施即服务

FaaS 即服务

SaaS 软件即服务

PaaS 平台即服务

视图

视图是一组架构元素及其关联关系的表示。

视图”的概念为我们提供了描述体系结构的原则: 记录相关的意见 然后添加适用于多个视图的信息 从而将观点联系在一起

架构元素–软件或硬件中存在的一组实际元素 视图–由系统相关者编写和读取的一组连贯的 架构元素的表示

但并非涵盖所有架构元素。 视图绑定了体系结构描述时感兴趣的元素类型和关系类 型,并显示了它们。

类型

分解视图–显示与“关联的子模块”关系相关联的模块

使用视图–显示与“使用”关系相关联的模块

(即,一个模块使用另一模块提供的服务) 分层视图–显示被划分为相关和连贯功能的模块组。 每个组代表整体结构中的一个层。 类/泛化视图–显示称为类的模块,这些模块通过关系的 “继承”或“实例”关联。

进程视图–显示通过通信、同步和排除操作连接的进程或线程

并发视图–显示组件和连接器,其中连接器代表“逻辑线程” 共享数据(存储库)视图–显示创建、存储和访问持久数据的组件 和连接器 客户端-服务器视图–显示协作的客户端和服务器以及它们之间的 连接器(即它们共享的协议和消息)

部署视图–显示软件元素及其对硬件和通信元素的分配 实施视图–显示开发、集成和配置控制环境中的软件元 素及其到文件结构的映射 工作分配视图–显示模块及其如何分配给负责实施和集 成它们的开发团队

4+1视图

Rational公司的Kruchten在1995年提出了用于体系结构描述的“4 + 1”模型。该模型建立在由 Perry&Wolf和Berry Boehm提出的体系结构定义的基础上。

逻辑视图:支持行为要求。 关键抽象,是对象或对象类。 过程视图:解决并发和分发。 将线程映射到对象。 开发视图:组织软件模块,库,子系统,开发单元。 物理视图:将其他元素映射到处理和通信节点。 用例视图:将其他视图映射到重要的用例(这些用例被称 作场景)上对体系结构加以说明,它们构成了第5个视图。

逻辑视图

1)支持系统的功能需求,即系统提供给最终用户的服务。 2)通常是系统职责划分 3)通常用功能模块图和分析类图表示逻辑视图。 分析类图就是抽象级别较高的类图,而设计类图更具体

开发视图

1)为开发人员准备的 ​ 2)关注程序包,不仅包括要编译的源程序还包括第三方库、框架 ​ 3)要考虑软件内部的需求,如可扩展性、可重用性、易理解性、易测试性、可移植性 ​ 4)考虑开发工具的不同而带来的局限性 ​ 5)通常用设计类图、包图、组件图表示开发视图。

类图的麻烦在于它们特别多样化,这里有一些 使用技巧: 不要使用所有可用的符号。 从简单的东西开始: 类,关联,属性,泛化和约束。 仅在需要时才引 入其他符号。 分析类图在探索业务语言时非常有用。 类之间的关系有:依赖、关联、组合、聚合、泛化和实现。

部署视图

1)关注如何安装和部署到物理机器 ​ 2)如何部署目标程序,尽量考虑高可用、高性能和高并发(三高) ​ 3)通常用部署图表示

过程视图

1)也称进程视图、并发视图 2)侧重系统的运行特性,关注运行期的非功能需求,如性能和可用性 ​ 3)强调并发性、分布式、系统集成性和容错能力 ​ 4)关注进程、线程等运行时概念,以及相关的并发、异步和通信等问题 ​ 5)通常用活动图表示

逻辑视图&开发视图&过程视图

1)逻辑视图中的一个职责可能映射开发视图多个程序包 ​ 2)逻辑视图的一个分析类可能映射开发视图的多个设计类 ​ 3)开发视图关注程序包的静态依赖关系,而过程视图关注的是这些程序包运行之后的交互关系。

用例视图

主要用用例图表示

质量属性

Quality Attributes(QA)质量属性

属于非功能性需求,并不被功能所决定 实现功能特性必须给构成系统中的各个部分(模块) 赋予正确的职责、正确的资源和正确的调度顺序 先实现功能,再谈质量属性

质量场景

质量属性场景的6个组成部分 刺激源(source):谁造成的刺激 刺激(stimulus):一个影响系统的情况 制品(artifact):系统被影响的部分 环境(environment):刺激发生时系统所处的状态 响应(response):刺激所产生的结果 响应衡量指标(response measure):如何评估响应

可用性

可用性的关注点 故障 提升可用性的策略 故障检测 故障恢复 故障避免

衡量指标: 可用(或故障)时间百分比 修复故障所需的时间 平均无故障时间

提升可用性的策略

降低故障造成的影响 方向1:故障检测 如何第一时间发现故障 方向2:故障恢复 如何恢复正确的结果 方向3:故障避免 如何主动减少故障的发生

心跳

被监控组件定期向监控组件发出心跳消息 在节点间保持周期性的心跳信号以检测各个节点的状态。若连续未收到的 心跳信号到了一定的数目,就认为相应的系统已经出现故障。

异常

抛出 + 捕获 + 处理 需要编程语言支持

主动冗余

A、B服务器完成同样的运算(A和B的状态时刻保持一致),平时只取 A算出的结果 当A出现故障时,系统可以极快地切换到B

被动冗余

A服务器完成运算后的一定时间内把自身状态告知B,B再把自身状态更 新为A的状态。 当A出现故障时,首先需要确认B的状态是最新的。 在重新上线前,都需要做状态的重新同步

内测

开发人员修正bug,并在内部进行测试,确认无误后再发布补丁

进程监控(故障避免)

检查点/回滚

定期保存,便于恢复

可修改性

衡量指标:

修改完成的时间 修改所花的人力成本 修改所花的经济成本 ……

刺激源:谁进行的修改(开发者/管理员/用户) 刺激:要进行的具体修改

提升可修改性策略

目标:降低修改的时间和成本

方向1:限制修改范围 让修改所影响的 软件范围尽可能的小 方向2:延迟绑定时间 让软件在运行期间仍可进行灵活修改

可修改性的关注点 修改的成本 提升可修改性的策略 限制修改范围 延迟绑定时间

性能

关注点: 系统响应事件的速度 和事件的数量和到达模式有关

响应衡量指标: 处理事件所花的时间 单位时间内处理事件的数目 处理的错误率/丢失率

提升性能策略

目标 在限定时间内响应事件

获取资源 + 使用资源 方向1:资源的需求 方向2:资源的管理 方向3:资源的仲裁

安全性

关注点 在保证合法用户使用系统的前提下,抵抗对系统的攻击 攻击(威胁) 试图突破系统安全性防护的尝试

响应 合法用户正常使用,拒绝非法用户的使用 对攻击有威慑

响应衡量指标 发起攻击的难度 从攻击中恢复的难度

可测试性

关注点 让软件的bug容易被测试出来 验证软件产品与它的需求规格是否匹配(存在不符或缺失) 使用最小的成本和工作量来验证软件的质量

响应 理想的响应是可以进行测试,并且可以观察到测试结果 当测试结果无法被观察到时,测试难度很大

响应衡量指标 白盒测试中的覆盖率 语句覆盖 判定覆盖/分支覆盖(判定可能是多个条件组合) 条件覆盖:覆盖判定中的每个条件 路径覆盖、判定条件覆盖、条件组合覆盖…… 未来继续发现bug的概率

提升可测试性

目标:让测试更轻松

方向1:黑盒测试 方向2:白盒测试

黑盒:记录 / 回放、把接口和实现分离开、提供专用的测试路径

白盒:内部监控、Appium(APP UI测试)、Selenium(Web UI测试)、JMeter(接口测试、性能测试)

可测试性的关注点 让bug容易被测试出来 提升可测试性的策略 黑盒 白盒

易用性

关注点:让用户使用软件的难度降低 不同方面: 如何方便用户入门? 如何提高用户使用软件的效率? 如何降低用户出错造成的影响? 如何让软件适应用户的需求? 如何提高用户的自信和舒适度?

响应: 系统响应用户的要求 响应衡量指标: 用户完成任务的时间 用户出错的次数 用户满意度 用户操作的成功率

提升易用性

目标 让用户轻松 方向1:运行时策略 方向2:设计时策略

体系结构评估

软件架构决定了系统的质量属性。可修改性、性能、可用性等随着软件架构的确定而确定。如果软件架构有问题,无论使用多么高超的实现技术,一些质量属性都无法实现。

敏感点、权衡点、风险点

敏感点是一个或多个构件(和/或构件之间的关系)的特性 权衡点是影响多个质量属性的特性,是多个质量属性的敏感点系统的体系结构涉及到很多人的利益,这些人都对体系结构施加各种影响,以保证自己的目标能够实现。

架构评估

◇ 基于调查问卷或检查表的评估方式 ◇ 基于场景的评估方式 ◇ 基于度量的评估方式

比较如下:

质量效应树

这篇关于软件体系复习的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!