系统架构师软考案例分析总结

前言

历年案例分析题主要从五个方面考,软件架构设计,系统开发基础,数据库系统,嵌入式系统,WEB应用开发。第一题必做,大概率是软件架构方面,后面4选2,保证一题至少能拿到15分即可选择

一、软件架构设计

属性质量效用树,质量属性判断

性能

指系统的响应能力,即要经过多长时间才能对某个事件做出晌应,或者在某段时间内系统所能处理的事件的个数.如响应时间、吞吐量。设计策略:优先级队列、增加计林资源、减少计林开销、引入并发机制、采用资源调度等

可靠性

是软件系统在应用或系统错误面前,在意外或错误使用的倩况下维持软件系统的功能特性的基本能力。如如MTTF,MTBF。设计策略:心跳、 ping /Echo、冗余、选举

可用性

是系统静哆正常运行的时间比例,经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示.如故障间隔时间.设计策略:心跳、 ping /Echo、冗余、选举

安全性

指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。设计策略:入俊检测、用户认证、用户授权、追踪审计

可修改性

是指快速的以较高的性价比对系统变更的能。通常以某些具体为的变更为基准,通过考察这些变更的代价衡量,设计策略:接口-实现分类,抽象,信息隐藏

功能性

可变性

互操作性

主要概念(必背)

软件架构风格

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

架构风险

是指架构设计中潜在的、存在问题的架构决策所带来的隐患

风险点与非风险点

不是以标准专业术语形式出现的,只是一个常规概念,即可能引起风险的因素,可称为风险点。某个做法如果有隐患,有可能导致一些问题,则为风险点;而如果某件事是可行的可接受的,则为非风险点

敏感点

是指为了实现某种特定的质最属性,一个或多个构件所具有的特性

权衡点

权衡点是影响多个质里属性的特性,是多个质里属性的敏感点

架构风格对比

系统架构师软考案例分析总结_第1张图片

下午常考风格对比特点,优缺点

管道-过滤器

特点:过滤器相对独立

优点:功能模块复用;可维护性和扩散性较强;具有并发性;模块独立性高。

缺点:不利于交互性强的应用,对于存在关系的数据流必须进行协调。

适合领域:系统可划分清晰模块;模块相对独立;有清晰的模块接口

面对对象

特点:力争实现问题空间和软件系统空间结构的一致性

优点:高度模块性;实现封装;代码共享灵活;易维护;可扩充性好

缺点:增加了对象的依赖关系

适合领域:多种领域

时间驱动(隐式调用)

特点:系统有若干个子系统构成且称为一个整体;系统有一个统一的目标;子系统有主从之分;每一个子系统都有自己的事件收集和处理机制

优点:适合描写系统组;容易实现并发处理和多任务;可扩展性好;具有类层次结构;简化代码

缺点:因为树形结构所以削弱了对系统计算的控制能力;各个对象的逻辑关系复杂

适合领域:一个系统对外部的表现可以从它对事件的处理表征出来

分层风格

特点:每个层次的组件形成不同功能级别的虚拟机;多层相互协同工作,而且实现透明

优点:支持系统设计过程中的逐级抽象;可扩展好;支持软件复用

缺点:不同层次之间耦合度高的系统难以实现

适合领域:适合功能层次的抽象和相互之间低耦合的系统

数据共享风格(仓库风格)

特点:采用两个常用构件中央数据单元和一些相对独立的组件集合

优点:中央数据单元实现了数据的集中,以数据为中心

缺点:适用于特定领域

适合领域:适合于专家系统等人工智能领域问题的求解

解释器风格

特点:系统核心是虚拟机

优点:可以用多种操作来解释句子,灵活自定义场景

缺点:适用于特定领域

适合领域:适合于模式匹配系统和语言编译器

闭环控制风格

特点:通过不断地测量被控对象,认识和掌握被控对象;将控制理论引入体系结构构件

优点:将控制理论引入到计算机软件体系结构中

缺点:适用于特定领域

适合领域:该系统一定存在有目标的作用,信息处理闭环控制过程

MVC架构

强制性地把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离,形成了三个核心模块:控制器、模型、视图。

控制器(controller)

是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据。

模型(model)

是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据模型表示业务数据和业务逻辑。

视图(view)

是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据,并能接收用户的输入数据但是它并不进行任何实际的业务处理

系统架构师软考案例分析总结_第2张图片

J2EE四层结构

系统架构师软考案例分析总结_第3张图片

客户层组件:J2EE应用程序可以是基于web方式的,也可以是基于传统方式的静态的HTML (标准通用标记语言下的一个应用) 页面和Applets是客户层组件

web 层组件: J2EE web层组件可以是JSP 页面或Servlet。

业务层组件:业务层代码的逻辑用来满足特定领域的业务逻辑处理。

信息系统层:企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资信息系统层源计划(ERP),大型机事务处理,数据库系统,和其它的遗留信息系统.例如,J2EE 应用组件可能为了数据库连接需要访问企业信息系统。

JSP+Servlet+JavaBean+DAO

JSP: 用于显示、收集数据的部分。作为MVC中的视图v。

Servlet: 作为业务逻辑层,用于处理复杂的业务逻辑,如验证数据、实例化JavaBean.调用DAO连接数据库等。作为MVC中的控制器C。在其中会调用Service方法处理服务

JavaBean:用于数据的封装,方便将查询结果在servlet与isp页面之间进行传递等

DAO:用于连接数据库及进行数据库的操作如:查询、删除、更改等。

DAO与JavaBean合在一起为MVC中的模型M。

基本流程: JSP发一个数据到servlet,servlet收到后做下解析再根据数据调用相应的service去服务,service如果有要调用数据库就通过DAO跟数据库交互,使用iavaBean完成封装,返回结果给servlet,servlet再返回给JSP。

面向服务的架构SOA

 SOA是一种设计理念,其中包含多个服务,服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行,服务之间通过网络进行调用。

系统架构师软考案例分析总结_第4张图片

企业服务总线ESB:简单来说是一根管道,用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务,ESB 做了消息的转化、解释以及路由的工作,以此来让不同的服务互联互通。

系统架构师软考案例分析总结_第5张图片

 ESB特点

1、SOA的一种实现方式,ESB在面向服务的架构中起到的是总线作用,将各种服务进行连接与整合;

2、描述服务的元数据和服务注册管理

3、在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,并支持由实践中总结出来的一些模式如同步模式、异步模式等

4、发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。高级一些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等

ESB主要功能

服务位置透明性
传输协议转换
消息格式转换
消息路由
消息增强
安全性
监控与管理

二、系统开发基础

结构化需求分析

结构化特点:自顶向下,逐步分解,面向数据

三大模型:功能模型 (数据流图)、行为模型(状态转换图)、数据模型 (E-R图)以及数据字典。

数据字典:数据字典是在DFD 的基础上,对DFD中出现的所有命名元素都加以定义,使得每个图形元素的名字都有一个确切的解释。DFD 和数据字典等工具相配合,就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。

数据字典中一般有6 类条目,分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体。不同类型的条目有不同的属性需要描述

面向对象的分析方法

UML关系:依赖,关联,泛化,实现,组合,聚合

系统架构师软考案例分析总结_第6张图片

 UML图中,用例图,类图,活动图,状态图最为重要

面向对象分析模型

包含(include) 扩展(extend) 泛化(实线空心三角箭头)

系统架构师软考案例分析总结_第7张图片

 系统架构师软考案例分析总结_第8张图片

项目管理

系统架构师软考案例分析总结_第9张图片

 PERT(项目评估与评审技术)图是一种图形化的网络模型,描述一个项目中任务和任务之间的关系,每个节点表示一个任务,通常包括任务编号、名称、开始和结束时间、持续时间和松弛时间

Gantt图是一种简单的水平条形图,它以一个日历为基准描述项目任务,横坐标表示时间,纵坐标表示任务图中的水平线段表示对一个任务的进度安排,线段的起点和终点对应在横坐标上的时间分别表示该任务的开始时间和结束时间,线段的长度表示完成该任务所需的时。

PERT图主要描述不同任务之间的依赖关系;Gantt图主要描述不同任务之间的重叠关系

关键路径: 是项目的最短工期,但却是从开始到结束时间最长的路径进度网络图中可能有多条关键路径,因为活动会变化,因此关键路径也在不断变化中

关键活动:关键路径上的活动,最早开始时间=最晚开始时间

通常每个节点的活动会有如下几个时间:

最早开始时间(ES):某项活动能够开始的最早时间

最早结束时间(EF):某项活动能够完成的最早时间。EF=ES+工期

最迟结束时间(LF):为了使项目按时完成,某项活动必须完成的最迟时间

最迟开始时间(LS):为了使项目按时完成,某项活动必须开始的最迟时间。LS=LF-工期

顺推:最高开始ES=所有前置活动最早完成EF的最大值,最早完成EF=最早开始ES+持续时间

逆推:最晚完成LF=所有后续活动最晚开始LS的最小值,最晚开始LS=最晚完成LF-持续事件

总浮动时间(总时差、松弛时差):在不延误项目完工时间且不违反进度制约因素的前提下活动可以从最早开始时间推迟或拖延的时间量,就是该活动的进度灵活性。正常情况下,关键活动的总浮动时间为零。

总浮动时间=最迟开始LS-最早开始ES 或 最完成LF-最早完成EF 或 关键路径-非关键路径时长

自由浮动时间:是指在不延误任何紧后活动的最早开始时间且不违反进度制约因素的前提下活动可以从最早开始时间推迟或拖延的时间量

自由浮动时间=紧后活动最早开始时间的最小值-本活动的最早完成时间

信息安全

各种加密技术的应用,包括对称加密,非对称加密,信息摘要,数字签名,数字证书

系统架构师软考案例分析总结_第10张图片

 系统架构师软考案例分析总结_第11张图片

三、数据库系统

ORM

ORM,即object-Relationl Mapping,它在关系型数据库和对象之间作一个映射,这样,我们在具体的操作数据库的时候,就不需要再去和复杂的SQL语句打交道,只要像平时操作对象一样操作即可。

面向对象编程把所有实体看成对象 (object),关系型数据库则是采用实体之间的关系 (relation)连接数据。很早就有人提出,关系也可以用对象表达,这样的话,就能使用面向对象编程,来操作关系型数据库。

ORM 把数据库映射成对象。如:

  • 数据库的表 (table) -->类 (class)
  • 记录 (record,行数据) --> 对象 (object) 
  • 字段 (field) --> 对象的属性 (attribute)

ORM优点:

  • 使用ORM可以大大降低学习和开发成本
  • 程序员不用再写SQL来进行数据库操作
  • 减少程序的代码量。
  • 降低由于SQL代码质量差而带来的影响

ORM缺点:

  • 不太容易处理复杂查询语句。
  • 性能较直接用SQL差。

数据库分类比较

关系型数据库:关系数据库,是建立在关系模型基础上的数据库,借助集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。简单说,关系型数据库是由多张能互相联接的二维行列表格组成的数据库

NoSQL:泛指非关系型的数据库。随着互联网的兴起,传统的关系数据库在应付超大规模和高并发的纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题,包括超大规模数据的存储

内存数据库:将数据库整体存储在内存中,提高性能

缓存技术

MemCache: Memcache是一个高性能的分布式的内存对象缓存系统,用于动态Web应用以减轻数据库负载。Memcache通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、规频、文件以及数据库检索的结果等

Redis: Redis是一个开源的使用ANSI C语言编写,支持网络,可基于内存亦可持久化的日志型,key-value数据库,并提供多种语言的API

Redis与Memcache的差异:

1.Redis和Memcache都是将数据存放在内存中,都是内存数据库。他们都支持key-value数据类型。同时Memcache还可用于缓存其他东西,例如图片、现频等等,Redis还支持list、set、hash等数据结构的存储。

2.在Redis中,并不是所有的数据都一直存储在内存中的。这是和Memcache相比一个最大的区别。当物理内存用完时,Redis可以将一些很久没用到的value交换到磁盘

3.Redis在很多方面支持数据库的特性,可以这样说他就是一个数据库系统,而Memcache只是简单地K/V缓存

关系数据库比较实例

关系数据库与NOSQL

特征 关系数据库模式 NOSQL模式
并发支持 支持并发,效率低 并发性能高
存储与查询 关系表方式存储,sql查询 海量数据存储、查询效率高
扩展方式 向上扩展 向外扩展(水平扩展)
索引方式 B 树、哈希等 键值索引
应用领域 面向通用领域 特定应用领域
数据一致性 实时一致性 弱一致性
数据类型 结构化数据 非结构化
事务 高事务性 弱事务性
水平扩展
数据容量 有限数据 海量数据

关系数据库与内存数据库

主要数据模型 读写性能 存储容基 可靠性
内存数据库 Key-Value模式

内存直接读写

性能相对较高

基于内存存储

存储容量受限

恢复机制复杂

可靠性较低

关系数据库 关系模式

外存读写

性能根对较低

基于存盘存储

存储容量太

内建恢复机制

可靠性较高

关系数据库与文件系统

设计难度 数据冗余程度 数据架构 应用扩展性
关系数据库

针对特定应用系

统设计,难度较大

遵守数据库范式,

数据冗余较小

以数据库为中

心组织,管理

数据

数据库独立于应用系统,数

据库系统接口标准化,易于

在不同应用之间共享数据

文件系统

针对特定应用系统

设计,难度较小

可能在多个文件中

复制相同的数据属

性,数据冗余较大

以应用为中心

管理鸪拜据

符合特定应用系统要求的

文件数据很难在不同的应

用系统之间共享

并发控制

丢失更新:事务1对数据A进行了修改并写回,事务2也对A进行了修改并写回,此时事务2写回的数据会覆盖事务1写回的数据,就丢失了事务1对A的更新。即对数据A的更新会被覆盖。

不可重复读:事务2读A,而后事务1对数据A进行了修改并写回,此时若事务2再读A,发现数据不对。即一个事务重复读A两次,会发现数据A有误

读脏数据: 事务1对数据A进行了修改后,事务2读数据A,而后事务1回滚,数据A恢复了原来的值那么事务2对数据A做的事是无效的,读到了脏数据

写锁,读锁

系统架构师软考案例分析总结_第12张图片

规范化

不规范带来的4大问题

设有一个关系模式R (SNAME,CNAME,TNAME,TADDRESS),其属性分别表示学生姓名、选修的课程名、任课教师姓名和任课教师地址。仔细分析一下,就会发现这个模式存在下列存储异常的问题:

数据冗余:数据被重复存储,如某门课程有100个学生选修,那么在R的关系中就要出现100个元组,这门课程的任课教师姓名和地址也随之重复出现100次

修改异常:修改导致数据不一致,如由于上述几余问题,当需要修改这个教师的地址时,就要修改100个元组中的地址值,否则就会出现地址值不一致的现象

插入异常:插入时异常,如不知道听课学生名单,这个教师的任课情况和家庭地址就无法进入数据库

删除异常:删除了不该删除的数据,如当只有一条记录时,要删除这个学生选课信息,会将课程名、教师名和教师地址都给删除了

反规范化技术

规范化技术:规范化设计后,数据库设计者希望牺牲部分规范化来提高性能

 采用反规范化技术的益处:降低连接操作的需求、降低外码和索引的数目,还可能减少表的数目能够提高查询效率

可能带来的问题:数据的重复存储,浪费了磁盘空间,可能出现数据的完整性问题,为了保障数据的一致性,增加了数据维护的复杂性,会降低修改速度

具体方法:

  • 增加冗余列:在多个表中保留相同的列,通过增加数据几余减少或避免查询时的连接操作
  • 增加派生列:在表中增加可以由本表或其它表中数据计算生成的列,减少查询时的连接操作并避免计算或使用集合函数
  • 重新组表:如果许多用户需要查看两个表连接出来的结果数据,则把这两个表重新组成一个
    表来减少连接而提高性能。
  • 水平分割表:根据一列或多列数据的值,把数据放到多个独立的表中,主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用
  • 垂直分割表:对表进行分割,将主键与部分列放到一个表中,主键与其它列放到另一个表中在查询时减少I/0次数

分布式数据库

分布式数据库简介

分布式数据库是由一组数据组成的,这组数据分布在计算机网络的不同计算机上,网络中的每个节点具有独立处理的能力 (称为场地自治),它可以执行局部应用,同时,每个节点也能通过网络通信子系统执行全局应用。。分布式数据库系统是在集中式数据库系统技术的基础上发展起来的。具有如下特点:

数据独立性。在分布式数据库系统中,数据独立性这一特性更加重要,并具有更多的内容。
除了数据的逻辑独立性与物理独立性外,还有数据分布独立性 (分布透明性)。

集中与自治共享结合的控制结构。各局部的DBMS 可以独立地管理局部数据库,具有自治的功能。同时,系统又设有集中控制机制,协调各局部DBMS 的工作,执行全局应用

适当增加数据几余度。在不同的场地存储同一数据的多个副本,这样,可以提高系统的可靠性和可用性,同时也能提高系统性能。

全局的一致性、可串行性和可恢复性

分布式数据库优点

分布式数据库可以解决企业部门分散而数据需要相互联系的问题

如果企业需要增加新的相对自主的部门来扩充机构,则分布式数据库系统可以在对当前机构影响最小的情况下进行扩充

分布式数据库可以满足均衡负载的需要

当企业已存在几个数据库系统,而且实现全局应用的必要性增加时,就可以由这些数据库自下而上构成分布式数据库系统

相等规模的分布式数据库系统在出现故障的概率上不会比集中式数据库系统低,但由于其故障的影响仅限于局部数据应用,因此,就整个系统来说,它的可靠性是比较高的

数据仓库集成

数据仓库集成是把多种来源的数据集中在一起,建立数据仓库,所有数据都驻留在单个数据库服务器上,配置大型处理器和存储容量。数据仓库主要用于决策支持,在数据处理过程中强调分析其特点是:集成的数据,面向主题,数据相对稳定,包含历史信息

数据仓库的结构通常包含四个层次:

  • 数据源:是数据仓库系统的基础,是整个系统的数据源泉
  • 数据的存储与管理:是整个数据仓库系统的核心
  • OLAP (联机分析处理)服务器:对分析需要的数据进行有效集成,按多维模型组织,以便进行多角度、多层次的分析,并发现趋势
  • 前端工具:主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以及各种基于数据仓库或数据集市的应用开发工具

商业智能:

BI系统主要包括数据预处理、建立数据仓库、数据分析和数据展现四个主要阶段

四、嵌入式系统

系统可靠性

系统可靠性是系统在规定的时间内及规定的环境条件下,:也就是系统无完成规定功能的能力,故障运行的概率。

系统可用性是指在某个给定时间点上系统能够按照需求执行的概率

可靠度就是系统在规定的条件下、规定的时间内不发生失效的概率

失效率又称风险函数,也可以称为条件失效强度,是指运行至此刻系统未出现失效的情况下单位时间系统出现失效的概率

软件,硬件可靠性区别

复杂性: 软件复杂性比硬件高,大部分失效来自于软件失效。

物理退化:硬件失效主要是物理退化所致,软件不存在物理退化。

唯一性: 软件是唯一的,每个COPY版本都一样,而两个硬件不可能完全一样

版本更新周期:硬件较慢,软件较快

提高可靠性技术

提高系统可靠性的技术可以分为避错(排错)技术和容错技术

避错是通过技术评审、系统测试和正确性证明等技术,在系统正式运行之前避免、发现和改正错误

容错是指系统在运行过程中发生一定的硬件故障或软件错误时,仍能保持正常工作而不影响正确结果的一种性能或措施。容错技术主要是采用冗余方法来消除故障的影响。

排错技术

冗余是指在正常系统运行所需的基础上加上一定数量的资源,包括信息、时间、硬件和软件。冗余是容错技术的基础,通过冗余资源的加入,可以使系统的可靠性得到较大的提高。主要的冗余技术有结构冗余(静态、动态、混合)、信息冗余、时间冗余和冗余附加4 种

软件容错的主要方法是提供足够的几余信息和算法程序,使系统在实际运行时能够及时发现程序设计错误,采取补救措施,以提高系统可靠性,保证整个系统的正常运行

软件容错技术主要有N 版本程序设计、恢复块方法和防卫式程序设计等

N版本程序设计(静态冗余)

 其设计思想是用N个具有相同功能的程序同时执行一项计算,结果通过多数表决来选择。其中N个版本的程序必须由不同的人独立设计,使用不同的方法、设计语言、开发环境和工具来实现,目的是减少N个版本的程序在表决点上相关错误的概率

系统架构师软考案例分析总结_第13张图片

恢复块设计(动态冗余)

动态几余又称为主动几余,它是通过故障检测、故障定位及故障恢复等手段达到容错的目的。其主要方式是多重模块待机储备,当系统检测到某工作模块出现错误时,就用一个备用的模块来替代它并重新运行。也可以不工作。前者叫热备份系统 (双重系统),后者叫冷备份系统(双工系统、双份系统)。

 系统架构师软考案例分析总结_第14张图片

 恢复块方法和N版本程序设计对比

恢复块方法 N版本程序设计
硬件运行环境 单机 多机
错误检查方法 验证测试程序 表决
恢复策略 后向恢复 前向恢复
实时性

防卫式程序设计

是一种不采用任何传统的容错技术就能实现软件容错的方法,对于程序中存在的错误和不一致性,防卫式程序设计的基本思想是通过在程序中包含错误检查代码和错误恢复代码,使得一旦发生错误,程序就能撤销错误状态,恢复到一个已知的正确状态中去。其实现策略包括错误检测、破坏估计和错误恢复三个方面。

双机容错技术

是一种软硬件结合的容错应用方案。该方案是由两台服务器和一个外接共享磁盘阵列及相应的双机软件组成

双机容错系统采用“心跳”方法保证主系统与备用系统的联系。所谓心跳,是指主从系统之间相互按照一定的时间间隔发送通信信号,表明各自系统当前的运行状态。一旦心跳信号表明主机系统发生故障,或者备用系统无法收到主系统的心跳信号,则系统的高可用性管理软件认为主系统发生故障,立即将系统资源转移到备用系统上,备用系统替代主系统工作,以保证系统正常运行和网络服务不间断

工作模式:双机热备模式,双机互备模式,双机双工模式

集群技术

集群技术是将多台计算机组织起来进行协同工作,它是提高系统可用性和可靠性的一种技术在集群系统中,每台计算机均承担部分计算任务和容错任务,当其中一台计算机出现故障时,系统使用集群软件将这台计算机从系统中隔出离去,通过各计算机之间的负载转嫁机制完成新的负载分担,同时向系统管理人员发出警报。集群系统通过功能整合和故障过渡,实现了系统的高可用性和可靠性。

特点:可伸缩性、高可用性、可管理性、高性价比、高透明性

分类:高性能计算集群、负载均衡集群、高可用性集群

负载均衡

负载均衡是集群系统中的一项重要技术可以提高集群系统的整体处理能力,也提高了系统的可靠性,最终目的是加快集群系统的响应速度,提高客户端访问的成功概率。集群的最大特征是多个节点的并行和共同工作,如何让所有节点承受的负荷平均,不出现局部过大负载或过轻负载的情况,是负载均衡的重要目的。

比较常用的负载均衡实现技术主要有以下几种:

基于特定软件的负载均衡(应用层)。很多网络协议都支持重定向功能,例如,基于HTTP重定向服务,其主要原理是服务器使用HTTP重定向指令,将一个客户端重新定位到另一个位置。服务器返回一个重定向响应,而不是返回请求的对象。客户端确认新地址然后重发请求,从而达到负载均衡的目的。

基于DNS的负载均衡属于传输层负载均衡技术,其主要原理是在DNS服务器中为同一个主机名配置多个地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的节点上去,使得不同的客户端访问不同的节点,从而达到负载均衡的目的。

基于NAT的负载均衡。将一个外部IP 地址映射为多个内部IP 地址,对每次连接需求动态地转换为一个内部节点的地址,将外部连接请求引到转换得到地址的那个节点,上从而达到负载均衡的目的

反向代理负载均衡。将来自Internet上的连接请求以反向代理的方式动态地转发给内部网络上的多个节点进行处理,从而达到负载均衡的目的

混合型负载均衡

五、Web应用开发

WEB应用技术分类

  • 从架构来看: MVC,MVP MWM,REST,Webservice,微服务
  • 从缓存来看: MemCache,Redis
  • 从并发分流来看:集群(负载均衡),CDN
  • 从数据库来看:主从库(主从复制),内存数据库,反规范化技术,NoSQL
    分区 (分表) 技术,视图
  • 从数据编码看: XML,JSON
  • 其它:有状态与无状态,响应式Web设计

WEB技术演变

单台机器到数据库与WEB服务器分离

系统架构师软考案例分析总结_第15张图片

应用服务器集群,存在问题:用户的请求由谁来转发到具体的应用服务器用户如果每次访问到的服务器不一样,那么如何维护session的一致性

 系统架构师软考案例分析总结_第16张图片

采用负载均衡技术

系统架构师软考案例分析总结_第17张图片

数据库集群:分为主从库

系统架构师软考案例分析总结_第18张图片

用缓存缓解库读取压力

系统架构师软考案例分析总结_第19张图片

CND

CDN的全称是Content Delivery Network,即内容分发网络

CDN是构建在网络之上的内容分发网络,依靠部署在各地的边缘服务器通过中心平台的负载均衡、内容分发、调度等功能模块,使用户就近获取所需内容,降低网络拥塞,提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术

CDN的基本原理是广泛采用各种缓存服务器,将这些缓存服务器分布到用户访问相对集中的地区或网络中,在用户访问网站时,利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上,由缓存服务器直接响应用户请求。

REST

REST(表述性状态传递)

REST(Representational State Transfer,表述性状态转移)是一种只使用HTTP和XML进行基于Web通信的技术,可以降低开发的复杂性,提高系统的可伸缩性。

REST的5个原则

  • 网络上的所有事物都被抽象为资源
  • 每个资源对应一个唯一的资源标识
  • 通过通用的连接件接口对资源进行操作
  • 对资源的各种操作不会改变资源标识
  • 所有的操作都是无状态的

微服务

微服务架构建议将大型复杂的单体架构应用划分为一组微小的服务,每个微服务根据其负责的具体业务职责提炼为单一的业务功能,每个服务可以很容易地部署并发布到生产环境里隔离和独立的进程内部,它可以很容易地扩展和变更,对于一个具体的服务来说可以采用任何适用的语言和工具来快速实现;服务之间基于基础设施互相协同工作。

微服务的优势:

  • 解决了复杂性问题。它把庞大的单一模块应用分解为一系列的服务,同时保持总体功能不变
  • 让每个服务能够独立开发,开发者能够自由选择可行的技术,让服务来决定API约定
  • 每个微服务都能独立配置,开发者不必协调对于本地服务配置上的变化这种变化一旦测试完成就被配置了
  • 让每个服务都可以独立调整,你可以给每个服务配置正好满足容量和可用性限制的实例数

微服务架构带来的挑战:

  • 并非所有的系统都能转成微服务。例如一些数据库层的底层操作是不推荐服务化的。
  • 部署较以往架构更加复杂:系统由众多微服务搭建,每个微服务需要单独部署,从而增加部署的复杂度,容器技术能够解决这一问题
  • 性能问题,由于微服务注重独立性,互相通信时只能通过标准接口,可能产生延迟或调用出错。例如一个服务需要访问另一个服务的数据,只能通过服务间接口来进行数据传输,如果是频繁访问,则可能带来较大的延迟
  • 数据一致性问题,作为分布式部署的微服务,在保持数据一致性方面需要比传统架构更加困难。

XML与JSON

扩展标记语言(Extensible Markup Language,XML) ,用于标记电子文件是一种允许使其具有结构性的标记语言,可以用来标记数据、定义数据类型,用户对自己的标记语言进行定义的源语言

XML的优点

  • 格式统一,符合标准
  • 容易与其他系统选行远程交互,数据共享比较方便

XML的缺点

  • XML文件庞大,文件格式复杂传输占带宽
  • 服务器端和客户端都需要花费大量代码来解析XML,导致服务器端和客户端代
  • 码变得异常复杂且不易维护
  • 客户端不同浏览器之间解析XML的方式不一致,需要重复编写很多代码

JSON(JavaScript Object Notation)一种轻量级的数据交换格式具有良好的可读和便于快速编写的特性。可在不同平台之间进行数据交换

JSON的优点

  • 数据格式比较简单,易于读写,格式都是压缩的,占用带宽小;
  • 易于解析,客户端JavaScript可以简单的通过eval0进行JSON数据的读取
  • 支持多种语言,包括ActionScript, C,C#,ColdFusion,Java,JavaScript, PerlPHPPython,Ruby等服务器端语言,便于服务器端的解析
  • 因为JSON格式能直接为服务器端代码使用,大大简化了服务器端和客户端的代码开发量,旦完成任务不变,并且易于维护

JSON的缺点

其他

无状态服务(stateless service) 对单次请求的处理不依赖其他请求,也就是说,处理一次请求所需的全部信息,要么都包含在这个请求里,要么可以从外部获取到(比如说数据库),服务器本身不存储任何信息

有状态服务 (stateful service) 则相反,它会在自身保存一些数据,先后的请求是有关联的。

响应式web设计:是一种网络页面设计布局,其理念是: 集中创建页面的图片排版大小,可以智能地根据用户行为以及使用的设备环境进行相对应的布局

响应式web设计方法与策略

采用流式布局和弹性化设计:使用相对单位,设定百分比而非具体值的方式设置页面元素的大小

响应式图片:不仅要同比的缩放图片,还要在小设备上降低图片自身的分辨率

你可能感兴趣的:(系统架构)