当前位置:   article > 正文

软考高级-系统架构师-案例分析-架构设计_系统架构师 案例

系统架构师 案例

考点分析

架构设计在案例分析题中每年必考的知识点,主要考点如下:

在这里插入图片描述

一.软件架构风格

1.基本概念
  • 什么是架构风格

软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式,惯用模式则反映众多系统共有的结构和语义。

  • 常用架构风格(需要能够从题目中分析出来使用了什么架构风格)
架构风格种类
数据流风格批处理序列,管道过滤器
调用/返回风格主程序/子程序,面向对象,层次结构
独立构件风格进程通信,事件驱动系统
虚拟机风格解释器
仓库风格数据库系统,黑板系统,超文本系统
其他风格消息总线/面向服务架构,过程控制,C2

具体架构风格的解释:

架构风格描述
批处理序列构件为一系列固定顺序的计算单元,构件之间只通过数据传递交互。每个处理步骤是一个独立的程序,每一步必须在其前一步结束后才能开始,数据必须是完整的,以整体的方式传递。传统编译器就是采用此种架构风格 。
管道-过滤器每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。这个过程通常是通过对输入数据流的变换或计算来完成的,包括通过计算和增加信息以丰富数据、通过浓缩和删除以精简数据、通过改变记录方式以转化数据和递增地转化数据等。这里的构件称为过滤器,连接件就是数据流传输的管道,将一个过滤器的输出传到另一个过滤器的输入。
主程序/子程序单线程控制,把问题划分为若千个处理步骤,构件即为主程序和子程序,子程序通常可合成为模块。过程调用作为交互机制,即充当连接件的角色。调用关系具有层次性,其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性
面向对象构件是对象,对象是抽象数据类型的实例。在抽象数据类型中,数据的表示和它们的相应操作被封装起来,对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式,对象是通过函数和过程的调用来交互的
层次结构构件组织成一个层次结构,连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务,使用下一层的服务,只能见到与自己邻接的层。通过层次结构,可以将大的问题分解为若干个渐进的小问题逐步解决,可以隐藏问题的复杂度。修改某一层,最多影响其相邻的两层(通常只能影响上层)
进程通信构件是独立的过程,连接件是消息传递。构件通常是命名过程,消息传递的方式可以是点对点、异步或同步方式,以及远程过程(方法)调用等。
时间驱动系统(隐式调用)构件不直接调用一个过程,而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册,当某个事件被触发时,系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程,它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持,为构件的维护和演化带来了方便;其缺点是构件放弃了对系统计算的控制。
解释器解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构,以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机,可以仿真硬件的执行过程和一些关键应用,其缺点是执行效率比较低。
基于规则的系统基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存,一般用在人工智能领域和DSS中。
黑板系统包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元,提供解决问题的知识。知识源响应黑板的变化,也只修改黑板﹔黑板是一个全局数据库,包含问题域解空间的全部状态,是知识源相互作用的唯一媒介;知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。
超文本系统构件以网状链接方式相互连接,用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法,它以结点为基本单位,链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。
2.真题案例分析

案例题练习:

在这里插入图片描述

案例问题:

在这里插入图片描述
案例问题1参考答案:

从集成开发环境与用户交互方式,集成开发环境的扩展性,集成开发环境的数据管理三个方面进行分析,为什么采用李工的方案。文中提到采用了李工的方案,说明李工在这三个方面上来说至少有二个方面的性能上要优于王工,并且优于的方面正好是系统需要的,从系统核心需求进行分析,核心需求(1)适合采用以数据存储为中心的架构风格,核心需求(2)适合采用解释器风格,核心需求(3)适合采用隐式调用的风格。所以在问答这个问题的时候我们可以结合系统核心需求(1)进行作答。核心需求(1)中用户通常采用交互式的方式对脚本进行编辑,语法检测,解释执行和调试。说明以数据为中心的架构风格在交互方式上要优于管道过滤器才行。并要实现各种功能的灵活组合、配置与替换。说明系统需要较好的可扩展性,所以以数据为中心的架构风格在可扩展性上需要优于管道过滤器。最后从集成开发环境的数据管理方面来看,可以从数据类型和数据转换的角度进行作答,数据类型从核心需求1中可知系统需要支持脚本语言,语法树(用于检测语法错误)的数据类型,核心需求2可知系统需要支持可视化模型的数据类型,核心需求3可知系统需要支持调试信息的数据类型,从数据类型的转换上来看,既然存在这么多种数据类型,肯定需要支持数据类型的转换才行。所以以数据为中心的软件架构风格在数据管理方面需要优于管道过滤器。

在这里插入图片描述

案例问题2参考答案:

这道题考查的就是从题目中分析出来使用了什么架构风格,解释器风格重点在于能够自动生成新的环境(拖到控件生成新的界面代码,是在自动生成新的环境),隐式调用风格重点在于当某个事件被触发后调用某个方法(自动定位是当触发断点在调试过程中命中这一事件,后执行定位方法进行定位操作)。

在这里插入图片描述

二.质量属性与架构评估

1.基本概念

质量属性主要考查四种质量属性性能,可用性,安全性和可修改性(潜在的考试bug),并且能够从文中分析出是哪一个质量属性。

在这里插入图片描述

概念部分主要考查的是风险点,敏感点,权衡点的概念:
系统架构风险: 是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
敏感点: 是指为了实现某种特定的质量属性,一个或多个构件所具有的特性。
权衡点: 是影响多个质量属性的特性,是多个质量属性的敏感点。

在这里插入图片描述

2.案例分析

在这里插入图片描述

下面给出属性效用树,需要在效用后面填入质量属性,在质量属性后面填入属于该质量属性的题干。(1)和(2)需要填入质量属性,我们前面提到质量属性主要考查性能,可用性,可修改性和安全性,所以我们可以利用这个bug可知(1)和(2)里面有一个是可修改性有一个是可用性,具体哪一个是,我们根据后面给出的题干进行分析,比如(1)后面给出的题干是e,题干e描述是 “需要在20人月内为系统添加一个新的CORBA中间件” 主要描述的是可修改性,所以(1)为可修改性,(2)为可用性,为了进一步验证我们可以分析一下d题干,“网络失效后,系统需要在1.5分钟内发现错误并启用备用系统;” 这明显是对可用性的描述,所以(1)为可修改性,(2)为可用性。(3) ~ (6) 需要对题干进行分析填入符合条件的质量属性的题干即可。

在这里插入图片描述

对题干进行分析后相关质量属性和风险点,非风险点,权衡点和敏感点的分析如下:

在这里插入图片描述

题2三个概念的描述如下:

在这里插入图片描述

三.Web架构综合考查

Web开发设计技术的综合应用主要围绕高性能,高可用,可维护,应变,安全等属性展开。

在这里插入图片描述

从不同维度来看Web系统架构所设计技术内容,如下:

在这里插入图片描述

Web系统的分层如系统所示:

在这里插入图片描述

1.Web服务器技术演变

单体机器,web应用和数据库存放在一台机器上,存在安全隐患,因为web应用暴露在外,供用户使用,数据库存储用户数据,应该避免这种暴露行为,并且web应用和数据库都比较消耗资源,当用户量大了,开销大了,单台机器可能承载不了这种开销造成宕机,所以将数据库与web服务器进行分离,将web应用服务器放在一台机器上,数据库服务器放在另外一台机器上,就算web应用蹦了也不会影响数据库服务器,且这种方式避免了数据库暴露在外。

在这里插入图片描述

当数据量非常大的时候,高并发场景下容易造成单点故障,可以通过搭建应用服务器集群的方式提供不同的应用服务器供用户使用,就算单台应用服务器蹦了,可以通过更换不同的应用服务器来供用户访问,避免单点故障。

在这里插入图片描述

在应用服务器集群中我们需要考虑以下二个问题

在这里插入图片描述

(1) 负载均衡技术

问题1主要通过负载均衡技术来解决用户请求转发的工作,负载均衡主要从应用层和传输层的角度进行实现。

在这里插入图片描述

负载均衡技术,从应用层角度进行实现分为基于特定软件的负载均衡(HTTP重定向)和反向大力负载均衡。

在这里插入图片描述

负载均衡技术,从传输层角度进行实现分为DNS域名解析的负载均衡和基于NAT的负载均衡。相比于应用层角度的负载均衡传输层负载均衡的性能更优。

在这里插入图片描述

下图给出的是负载均衡技术相应算法,上面讲解的负载均衡是实现方式,而算法是如何分配的问题,会按照相应算法策略去实现用户自动的,智能的分配应用服务器。

在这里插入图片描述

传统的情况下,应用服务器只有一台,用户进行登入后会将session写入到应用服务器中,这样避免了用户每访问一个页面就需要用户端提供用户信息,因为session中存放了用户的数据,由于采用了应用服务器的集群,如果还是传统的方式的话,用户在应用服务器1中登入后保存了session信息,但是当用户访问应用服务器2时这个信息就没有了,应用服务器就不知道用户已经进行了登入操作,就无法进行相关应用服务的访问和使用。所以为了解决这个问题提供了三种解决方案,方案1携带session的cookie,方案2服务器间同步session,方案3将session存入redis。这里的cookie是一种身份认证,比如用户1连接了应用服务器,用户2连接了应用服务器,应用服务器怎么知道哪一个是用户1和用户2呢,就可以通过用户发来的cookie进行识别,比如cookie里面存放userid=1,发送到应用服务器,服务器通过cookie中的userid=1就可以知道原来是用户1发来的请求,当发来的cookie的userid=2时就会知道是用户2发来的请求。

在这里插入图片描述

无状态服务和有状态服务,所谓的有状态服务就是服务请求会携带数据保存到服务器中帮助下一次服务使用,无状态不用保存数据到服务器中,这次服务完后对后面的服务没有任何影响。

在这里插入图片描述

(2) 持久化技术-ORM

持久化技术ORM是在JDBC接口基础上进行封装的一层框架,帮助程序员更容易操作数据,提高程序的易用性,常用的ORM框架有Hibernate和MyBatis。

在这里插入图片描述

(3) 数据库读写分离

数据读写分离的意思就是将数据库的读和写操作(增,删,改)分开,放在不同的数据库服务器上,其中写操作为主库,读操作为从库,主库和从库之间通过日志实现数据同步。没有读写分离时,大量的查询与对表增加排它锁,从而影响其他操作,所以可以通过读写分离进行避免。

在这里插入图片描述

2.缓存技术

对查多写(增,删,改)少的场景我们可以考虑使用数据缓存技术,减少数据库服务器的开销,当用户进行查询时,首先查询缓存中是否存在数据,如果存在就从缓存中取值,如果缓存中没有数据就从数据库中取值,并且更新数据到缓存中,如果用户对数据进行修改,数据库中的数据进行更新并且更新缓存中的数据保持数据的一致性。

在这里插入图片描述

缓存的数据常常采用key-value的形式进行存储,常用的缓存框架有Memcache和Redis。

在这里插入图片描述

Memcache和Redis的区别需要了解,如下图所示:

在这里插入图片描述

3.Redis技术

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

4.CDN(内容分发网络)

内容分发网络中的CDN类似于现实生活中的快递场景,用户不直接连接数据源站点而是连接离自己家最近的CDN站点,这里的CDN站点类似于快递取件点(菜鸟驿站),通过这样的方式可以使内容传输得更快,更稳定。

在这里插入图片描述

5.XML与JSON

XML和JSON是二种比较传统的网络交互方式,其中XML方式通过标签的方式描述数据,XML方式的优缺点如下图所示:

在这里插入图片描述

JSON是一种轻量级的数据交互格式,具有良好的可读和便于快速编写的特性,可以在不同平台进行数据交互。,优缺点如下所示:

在这里插入图片描述

6.Web应用服务器

在这里插入图片描述

7.REST

REST表述性状态转移是数据交换形式,对资源标准化的过程,把资源的操作更加规范化,如
http://www.educity.cn/orders/29127123134 网址就是通过REST进行了规范化,从网址我们能够猜测这是一个关于29127123134订单信息的处理,通过REST进行规范化后,结构非常清晰,便于理解,可以降低开发的复杂性,提高系统的可升缩性。我们在Web开发中也遵循该风格,也就是我们常说的Rest ful Api风格。

在这里插入图片描述

8.响应式Web设计

响应式Web设计就是网站对于不同设备的适配问题,我们可以采用流式布局和弹性化设计,就是使用相对单位通过设置百分比的方式表示图片的长宽。也可以采用响应式图片的方式,对图片同比缩放,并降低图片自身的分辨率。

在这里插入图片描述

9.中台技术

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/你好赵伟/article/detail/779516
推荐阅读
相关标签
  

闽ICP备14008679号