案例题（第一版）

案例题目

软件架构设计考点（历年必考）

软件架构设计通常在每年的第一题，该题必考

必备概念

必备概念即考试必须要默写出来的概念

概念	描述
软件架构风格	是指描述特定软件系统组织方式和惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反应众多系统共有的结构和语义
架构风险	是指架构设计中潜在的、存在问题的架构决策所带来的隐患
风险点与非风险点	不是以标准专业术语形式出现的，只是一个常规概念，即可能引发风险因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题则为风险点；而如果某件事是可行的可接受的，则为非风险点
敏感点	是指为了实现某种特定的质量属性，一个或多个构件所具有的特性
权衡点	是影响多个质量属性的特性，是多个质量属性的敏感点

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

质量属性效用树是必考知识点，题目会给出几个例子给你判断用的是那种质量属性，然后需要能写出质量属性的基本说明以及设计策略

属性	定义	设计策略
性能(重点)	指系统的响应能力，既要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件个数，如响应时间、吞吐量	优先级队列、增加计算机资源、减少计算开销、引入并发机制、采用资源调度等
可靠性(重点)	是软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力，如MTTF、MTBF	心跳、ping/Echo、冗余、选举
可用性(重点)	是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或出现故障时系统能够恢复正常的速度来表示，如故障间隔时间	心跳、ping/Echo、冗余、选举
安全性(重点)	是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力，如保密性、完整性、不可抵赖性、可控性	入侵检测、用户认证、用户授权、追踪审计
可修改性(重点)	指能够快速的以较高的性能价格比对系统进行变更的能力，通常以某些具体的变更为基准，通过考察这些变更的代价衡量	接口-实现分离、抽象、信息隐藏
功能性	是系统所能完成所期望的工作的能力，一项任务的完成需要系统中许多或大多数构件的相互协作
可变性	指系统结构经扩充或变更而成为新体系结构的能力，这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构，当要将某个体系结构作为一些列相关产品的基础时，可变性是很重要的
互操作性	作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用，为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口，程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构

架构风格

必须清楚的找到每种架构风格的含义，能通过一段描述得出架构的风格类型，以及架构的简介

传统架构风格

风格名称	简介	常见关键字
数据流-批处理	一个接一个，以整体为单位	传统编译器，每个阶段产生的结果作为下一个阶段的输入，区别在于整体
数据流-管道-过滤器	一个接一个，前一个输出是后一个输入	传统编译器，每个阶段产生的结果作为下一个阶段的输入，区别在于整体
调用/返回-主程序/子程序	显示调用主程序直接调用子程序
调用/返回-面向对象	对象是构件，通过对象调用封装的方法和属性
调用/返回-层次结构	分层，每层最多影响其上下两层，有调用关系
独立构件-进程通信	进程间独立的消息传递，同步异步
独立构件-事件驱动（隐式调用）	不直接调用，通过事件驱动	事件触发推动动作，如程序语言的语法高亮、语法错误提示
虚拟机-解释器	解释自定义的规则，解释友情、存储区、数据结构	自定义流程，按流程执行，规则随时改变，灵活定义，业务灵活组合机器人
虚拟机-规则系统	规则集、规则解释器、选择器和工作内存，用于DSS和人工智能、专家系统	自定义流程，按流程执行，规则随时改变，灵活定义，业务灵活组合机器人
仓库-数据库	中央共享数据源，独立处理单元	现代编译器的集成开发环境IDE，以数据为中心，又称数据共享风格
仓库-超文本	网状链接，多用于互联网	现代编译器的集成开发环境IDE，以数据为中心，又称数据共享风格
仓库-黑板	语言识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统，黑板、知识源、控制	现代编译器的集成开发环境IDE，以数据为中心，又称数据共享风格
闭环-过程控制	发出控制命令并接受反馈，循环往复达到平衡	汽车定速巡航，空调温度控制，设定参数，并不断调整
C2风格	通过连接件绑定在一起按照一组规则运作并行构件网络	构件和连接件、顶部和底部

历年常考传统架构风格分析

架构风格	特点	优点	缺点	适合领域
管道-过滤器	过滤器相对独立	功能模块复用；可维护性和可扩展性较强；具有并发性；模块独立性高；	不适于交互性强的应用，对于存在关系的数据流必须进行协调	系统可划分清晰的模块；模块相对独立；有清晰的模块接口
面向对象	力争实现问题空间和软件系统空间结构的一致性	高度模块性；实现封装；代码共享灵活；易维护；可扩展性好；	增加了对象之间的依赖关系	多种领域
事件驱动	系统由若干子系统构成且称为一个整体；系统有统一的目标；子系统有主从之分；每一个系统有自己的事件收集和处理机制	适合描写系统组；容易实现并发处理和多任务；可扩展性好；具有类层次结构；简化代码；	运维树结构所以削弱了对系统即使的控制能力；各个对象的逻辑关系复杂	一个系统外部的表现可以从它对事件的处理表征出来
分层风格	各个层次组件形成不同功能级别的虚拟机；多层相互协同工作，而且实现透明	支持系统设计过程中的逐级抽象；可扩展性好；支持软件复用；	不同层次之间耦合度高的系统很难实现	适合功能层次的抽象和相互之间低耦合的系统
数据共享风格	采用两个常用构件中央数据单元和一些相对独立的组件集合	中央数据单元实现了数据的集中，以数据为中心	适合于特定领域	适合于专家系统等人工智能领域问题的求解
解释器风格	系统核心是虚拟机	可以用多种操作来解释一个句子，灵活应对自定义场景	适合于特定领域	适合于模式匹配系统与语言编译器
闭环管理系统风格	通过不断的测量被控对象，认识和掌握被控对象；将控制理论引入体系结构构建	将控制理论引入到计算机软件体系结构中	适合于特定领域	改系统中一定存在有目标的作用、信息处理闭环控制过程

新架构风格

MVC架构

MVC强制性的吧一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成三个核心模块：控制器、模型、视图

模块	说明
控制器（Controller）	是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入并向模型发送数据
模型（Model）	是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据中存取数据。模型表示业务数据和业务逻辑
视图（View）	是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行任何实际的业务处理

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

MVC特点

MVC分层有助于管理复杂的应用程序，因为你可以在一个时间内专门关注一个方面。例如，您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。
MVC分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

J2EE四层架构

模块	说明
客户层组件	J2EE应用程序可以是基于web方式的，也可以是基于传统方式的静态的HTML（标准通用标记语言下的一个应用）页面和Applets是客户层组件
web层组件	J2EE web层组件可以是JSP页面或Servlet
业务层组件	业务层代码的逻辑用于满足特定领域的业务逻辑处理
信息系统层	企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划（ERP），大型机事务处理，数据库系统，和其他的遗留信息系统，例如，J2EE应用组件可能为了数据库连接需要访问企业信息系统

在这里插入图片描述

J2EE通常会与EJB概念联合考察，以下是EJB中的Bean三种类型说明

Session Bean职责：维护一个短暂的会话

Entity Bean职责：维护一个持久稳固的数据

Message-Driven Bean职责：异步接受消息

SOA架构

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

在这里插入图片描述

ESB企业服务总线

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

ESB主要功能

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

在这里插入图片描述

ESB特点

SOA的一种实现方式，ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接于整合
描述服务的元数据和服务注册管理
在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等
发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载均衡等

系统开发考点（重点，易得分）

该题目是直选题目，通常考察数据流图、行为模型、数据模型，对于考过软件设计师友好得分率高

结构化的需求分析

结构化特点：自顶向下、逐步分解、面向数据。
三大模型：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R图）以及数据字典
数据字典：数据字典是在DFD的基础上，对DFD中出现的所以命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。DFD和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述
数据字典的6类条目：数据元素、数据结构、数据流、数据储存、加工逻辑、外部实体，不同条目有不同的属性需要描述

面向对象

分析方法

UML关系：依赖、关联、泛化、实现、组合、聚合

在这里插入图片描述

UML图：用例图、类图、活动图、状态图

在这里插入图片描述

分析模型

模型对象分析最终是为了产出2个模型

用例模型：对应用例图

分析模型：对应静态分析模型（类图）、动态分析模型（时序图）

在这里插入图片描述

项目管理

PERT图

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

在这里插入图片描述

关键路径计算：求开始到结束时间最长的路径
顺推：最高开始ES=所有前置活动最早完成EF的最大值；最早完成EF=最早开始ES+持续时间
逆推：最晚完成LF=所有后续活动最晚开始LS的最小值；最晚开始LS=最晚完成LF-持续时间
总浮动时间=最迟开始LS-最早开始ES/最迟完成LF-最早完成EF/关键路径-非关键路径时长
自由浮动时间=紧后活动最早开始时间的最小值-本活动的最早完成时间

Gantt图

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

在这里插入图片描述

PERT图与Gantt图区别

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

信息安全

PGP协议为例：对称加密、非对称加密、信息摘要、数字签名、数字证书

在这里插入图片描述

数据库系统考点（历年考点）

ORM

ORM（Object-Relation-Mapping），它在关系型数据库和对象之间作为一个映射，这样我们具体的操作数据库的适合就不需要再去和复杂的SQL语句打交道，只要像平时操作对象一样操作即可，常见如Hibernate、MyBatis是ORM框架

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

ORM把数据库映射成对象：数据库的表（table）=> 类（class）=> 记录（record，行数据）=> 对象（Object）=> 字段（field）=> 对象的属性（attribute）

优点

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

缺点

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

数据库分类

类型	特点
关系型数据库	是建立再关系模型基础上的数据库，借助集合、代数数学概念和方法来处理数据库中的数据。实现世界中的各种实体以及实体之间的各种联系均用关系模型来表示。简单说关系型数据库是由多张相互连接的二维表行列表格组成的数据库，如Mysql、SQL server
NoSQL	泛指非关系型数据库，随着互联网的兴起，传统的关系数据库在应付超大规模的高并发的动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储，如Redis
内存数据库	将数据库整体存储在内存中，提高性能，如Redis是一种在内存中的NoSQL

关系数据库与NoSQL比较

特征	关系数据库	NoSQL
并发支持	支持并发、效率低	并发性能高
存储与查询	关系表方式存储、SQL查询	海量数据存储、查询效率高
扩展方式	向上扩展（加服务器，加磁盘）	水平扩展（加服务器，将原有数据分区）
索引方式	B树、哈希等	键-值
应用领域	面向通用领域	特定应用领域
数据一致性	实时一致性	弱一致性
数据类型	结构化数据	非结构化数据
事务	高事务性	弱事务性
水平扩展	弱	强
数据容量	有限数据	海量数据

关系数据库和内存数据库比较

	主要数据模型	读写性能	存储容量	可靠性
内存数据库	Key-Value模式	内存世界读写，性能高	基于内存存储，存储容量受限	恢复机制复杂，可靠性低
关系数据库	关系模式	外存读写，性能相对较低	基于磁盘存储，存储容量大	内建恢复机制，可靠性高

关系数据库和文件系统比较

	设计难度	数据冗余程度	数据架构	应用扩展性
关系数据库	针对特定应用系统设计，年度较大	遵守数据库范式，数据冗余较小	以数据库为中心组织，管理数据	数据库独立于应用系统，数据库系统接口标准化，易于在不同应用之间共享数据
文件系统	针对特定应用系统设计，难度较小	可能在多个文件中复制相同的数据属性，数据冗余较大	以应用为中心，管理数据	符合特定应用系统要求的文件数据很难在不同应用系统之间共享

缓存技术

应用	特点
MemCache	Memcache是一个高性能的分布式的内存对象缓存系统，用于动态Web应用以减轻数据库负载。Memcache通过在内存里维护一个统一的巨大的hash表，它能用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等
Redis	Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存可持久化的日志型、Key-Value数据库，并提供多语言的API

Redis与Memcache的差异

Redis和Memcache都是数据存放在内存中，都是内存数据库。他们都支持Key-value数据类型。同时Memcache还可用于缓存其他东西，例如图片、视频等等，Redis还支持list、set、hash等数据结构的存储
在Redis中，并部署所有数据都一直存储在内存中。这是和Mencache相比一个最大的区别。当物理内存用完了，Redis可以通过持久技术定期将内存数据持久化到磁盘中
Redis在很多方面支持数据库的特性，可以这样说他就是一个数据库系统，而Memcache只是简单的K/V缓存

并发控制

数据库并发读写时会存在的问题如下

丢失更新：事务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做的事是无效的，读到了脏数据

在这里插入图片描述

规范化

不规范化的问题

设有关系模式R（学生名、课程名、教师名、教师地址），仔细分析一下，就会发现这个模式存在下列存储异常的问题

数据冗余：数据被重复存储，假如一个学生同时选秀了10个课程，那么再R的关系中教师名称、地址也会随之出现10条数据
修改异常：修改数据不一致，假如需要修改某个教师地址那么就需要修改所有有这个教师的数据
插入异常：插入时异常，假如只想插入一个学生信息，但是没有课程和教师的信息无法插入到数据库中
删除异常：删除不了该删除的数据，假如只有一个数据时，删除学生的选修课信息会把课程、教师信息都删除了

反规范化技术

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

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

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

常见方法：

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

分布式数据库

特点

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

数据独立性：在分布式数据库系统中，数据独立性这一特性更加重要，并具有更多的内容。除了数据的逻辑独立性于物理独立性，在数据分片独立性（分片透明）
集中于自治共享结合的控制结构：各局部的DBMS可以独立的管理局部数据库，具有自治的功能，同时系统又设有集中控制机制，协调各局部DBMS的工作，执行全局应用
适当增加数据冗余度：在不同的场地存储同一数据的多个副本，这样可以提高系统的可靠性和可用性，同时也能提高系统性能
全局的一致性，可串行性和可恢复性

优点

分布式数据库可以解决企业部门分散而数据需要相互联系的问题
如果企业需要增加新的相对自主的部门来扩充机构，则分布式数据库系统可以在对当前机构影响最小的情况下进行扩充
分布式数据库可以满足负载均衡的需要
当企业已存在几个数据库系统，而且实现全局应用的必要性增加时，就可以由这些数据库自下而上构成分布式数据库系统
相等规模的分布式数据库系统在出现故障的概率上不会比集中式数据库系统低，但由于其故障的影响仅限于局部数据应用，因此就整个系统来说它的可靠性是比较高的

数据库仓库

数据仓库集成是把多种源的数据集中在一起，建立数据仓库，所有数据都驻留在单个数据库服务器上，配置大型处理器和存储容量，数据仓库主要用于决策支持，在数据处理中强调分析，特点如下

集成的数据
面向主题
数据相对稳定
包含历史信息

结构层次

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

商业智能

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

嵌入式考点（历年考点）

可靠性

软件可靠性和硬件可靠性区别

复杂性：软件复杂性比硬件高，大部分失效来自于软件失效
物理退化：硬件失效主要是物理退化所致，软件不存在物理退化
唯一性：软件是唯一的，每个copy版本都一样，而2个硬件不可能完全一样
版本更新周期：硬件较慢，软件较快

提高可靠性

提高了系统可靠性的技术分为避错（排错）技术和容错技术。避错是通过技术评审、系统测速和正确性证明等技术，在系统正式运行之前避免、发现和改正错误

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

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

软件容错：主要方法是提高足够的冗余信息和算法程序，使系统在实际运行时能够及时发现程序设计错误，采取补救措施，以提高系统可靠性，保证整个系统的正常运行，软件容错技术主要有N版本程序设计、恢复块方法和防卫式程序设计等

N版本程序设计

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

在这里插入图片描述

动态冗余（恢复块设计）

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

在这里插入图片描述

防卫式程序设计

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

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

双机容错设计

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

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

工作模式：双机热备模式、双机互备模式、双机双工模式

集群技术

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

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

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

负载均衡

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

技术	说明
基于特定软件的负载均衡（应用层）	很多网络协议都支持重定向功能，例如基于HTTP重定向服务，其主要原理是服务器使用HTTP重定向指令，将一个客户端重新定位到另一个位置。服务器返回一个重定向响应，而不是返回请求的对象。客户端确认新地址然后重发请求，从而达到负载均衡的目的
基于DNS的负载均衡属于传输层负载均衡技术	其主要原理是在DNS服务器中为同一个主机名配置多个地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端在访问引导到不同节点上去，使得不同的客户端访问不同的节点，从而达到负载均衡目的
基于NAT的负载均衡	将一个外部IP地址映射为多个内部IP地址，对每次连接需求动态地转换为一个内部节点的地址，将外部连接请求引到转换得到地址的那个节点上从而达到负载均衡的目的
反向代理负载均衡	将来自Internet上的连接请求以反向代理的方式动态的转发给内部网络上的多个节点进行处理，从而达到负载均衡目的
混合型负载均衡

Web应用开发（历年考点）

技术分类

从架构来看：MVC、MVP、MVVM、REST、Webservice、微服务

从缓存来看：MemCache、Redis、Squid

从并发分流来看：集群（负载均衡）、CND

从数据库来看：主从复制、内存数据库、反规范化技术、NoSQL、分区（发表）技术、视图

从持久化来看：Hibernate、Mybatis

从分布式存储来看：Hadoop、FastDFS、区块链

从数据编码来看：XML、JSON

从Web应用服务器来看：Apache、WebSphere、Weblogic、Tomcat、JBOSS、IIS

其它：有状态与无状态、响应式Web设计

Web技术演变

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

在这里插入图片描述

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

在这里插入图片描述

在客户端与服务器之间添加一层负载均衡技术

在这里插入图片描述

数据库集群，主从库

在这里插入图片描述

用缓存缓解库读取压力

在这里插入图片描述

CDN

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

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

REST

REST（Representational State Transfer）即表述性中台转移是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性，REST的5个原则如下

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

微服务

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

微服务优势

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

微服务带来的挑战

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

微服务与SOA比较

微服务	SOA
能拆分的就拆分	是整体的，服务能放一起都放一起
纵向业务拆分	是水平分多层
由单一组织负责	按层级划分不同部门和组织负责
细粒度	粗粒度
两句话可以解释明白	几百字相当于SOA的目录
独立的子公司	类似大公司里面划分一些业务单元（BU）
业务逻辑存在于每个服务中	业务逻辑横跨多个业务领域
使用轻量级的通信方式，如HTTP	企业服务总线（ESB）充当了服务之间通信的角色

微服务于SOA实现

微服务架构实现	SOA实现
团队级，自底向上开展实施	企业级，自顶向下开展实施
一个系统被拆分成多个服务，颗粒度细	服务由多个子系统组成，颗粒度大
无集中式总线，松散的服务架构	企业服务总线，集中式的服务架构
集成方式简单（HTTP/REST/JSON）	集成方式复杂（ESB/WS/SOAP）
服务能独立部署	单块架构系统，相互依赖，部署复杂

缓存技术

技术	说明
MemCache	Memacahe是一个高性能的分布式的内存对象存储系统，用于动态Web应用以减轻数据库负载。Memcache通过在内存里维护一个统一巨大的hash表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等
Redis	Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API
Squid	Squid是一个高性能的代理缓存服务器，Squid支持FTP、gopher、HTTPS和HTTP协议。和一般的代理缓存软件不同，Squid用一个单独的、非模块化的、I/O驱动的进程来处理所有用户端请求

Redis和Memcache的差异

Redis和Memcache都是将数据存放到内存中，都是内存数据库。他们都支持key-value数据类型。同时Memcache还开源用于缓存其他东西，例如图片、视频等等，Redis还支持list、set、hash等数据结构的存储
Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用，Memcache挂掉后，数据就没了
灾难恢复Memcache挂掉数据不可恢复，Redis可以恢复
在Redis中，并不是所有数据都一直存储在内存中的。这是和Memcache相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘
Redis在很多方面支持数据库的特性，可以这样说他就是一个数据库系统，而Memcache只是简单的K/V缓存