系统架构设计师重要知识点集-软件架构设计

重点1：软件架构的概念

要点1：软件架构的概念

架构设计就是需求分配，即将满足需求的职责分配到组件上。

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束；词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。

软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。

软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。

要点2：软件架构的发展史

要点3：软件架构建模

结构模型：以架构的构件、连接件和其他概念来刻画结构。
框架模型：不太侧重描述结构的细节而更侧重于整体的结构。
动态模型：系统的“大颗粒”的行为性质。
过程模型：构建系统的步骤和过程。
功能模型：由一组功能构件按层次组成，下层向上层提供服务。

重点2：软件架构风格

架构设计的一个核心问题是能否达到架构级的软件复用。

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完成的系统。

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

要点1：软件架构风格分类

数据流风格：批处理序列；管道/过滤器。
调用/返回风格：主程序/子程序；面向对象风格；层次结构。
独立构件风格：进程通信；事件驱动系统（隐式调用）。
虚拟机风格：解释器；基于规则的系统。
仓库风格：数据库系统；超文本系统；黑板系统。

要点2：数据流风格

1、批处理序列

构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互；每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。

2、管道-过滤器

每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流；这个过程通常是通过对输入数据流的变换或计算来完成的，包括通过计算和增加信息以丰富数据、通过浓缩和删除以精简数据、通过改变记录方式以转化数据和递增地转化数据等。这里的构件称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。

早期编译器就是采用的这种架构，要一步步处理的均可以考虑采用此架构风格。

要点3：调用/返回风格

1、主程序/子程序

单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。调用过程作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。

2、面向对象

构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的。

3、层次结构

构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义；每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度，修改某一层，最多影响其相邻的两层（通常只能影响上层）。

（1）优点：

支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
不同的层次处于不同的抽象级别，越靠近底层抽象级别越高，越靠近顶层抽象级别越低。
由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，也为软件复用提供了强大的支持。

（2）缺点：

并不是每个系统都可以很容易地划分为分层的模式。
很难找到一个合适的、正确的层次抽象方法。

要点4：独立构件风格

1、进程通信

构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程（方法）调用等。

2、事件驱动系统（隐式调用）

构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便；其缺点是构件放弃了对系统计算的控制。

要点5：虚拟机风格

1、解释器

解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。

2、基于规则的系统

基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。

要点6：仓库风格（以数据为中心的风格）

1、数据库系统

构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。

2、黑板系统

包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中（信号处理、问题规划和编译器优化等）。

3、超文本系统

构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。现代集成编译环境一般采用这种架构风格。

要点7：闭环架构控制（过程控制）

当软件被用来操作一个物理系统时，软件与硬件之间可以粗略地表示为一个反馈循环，这个循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态。适合于嵌入式系统，涉及连续的动作与状态。

要点8：层次架构风格

缺点：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用。

与B/S结构相比：

B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
B/S架构的安全性难以控制；
采用B/S架构的应用系统，在数据查询等响应速度上要远低于C/S架构；
B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。

要点9：MVC架构风格

Model（模型）是应用程序中用于处理应用程序数据逻辑的部分；通常模型对象负责在数据库中存取数据。

View（视图）是应用程序中处理数据显示的部分；通常视图是依据模型数据创建的。

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

在J2EE体系结构中：视图是JSP，控制器是Servlet，模型是Entity Bean或者Session Bean。

要点10：MVP架构风格

MVP是MVC的变种，它实现了V与M之间的解耦（V不直接使用M，修改V不会影响M）。

MVP更好的支持单元测试，业务逻辑在P中，可以脱离V来测试这些逻辑，此外可以将一个P用于多个V而不需要改变P的逻辑

MVP中V处理界面事件，业务逻辑在P中，MVC中界面事件由C处理。

要点11：MVVM架构风格

要点12：富互联网应用（RIA）

RIA结合了C/S架构反应速度快、交互性强的优点，以及B/S架构传播范围广及容易传播的特性。
RIA简化并改进了B/S架构的用户交互。
数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。

要点13：基于服务的架构（SOA）

1、服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

2、服务构件与传统构件的比较：

服务构件粗粒度，传统构件细粒度居多。
服务构件的接口是标准的，主要是WSDL接口，传统构件常以具体API形式出现。
服务构件的实现与语言无关，传统构件绑定某种特定语言。
服务构件可以通过构件容器提供QoS的服务，传统构件完全由程序代码直接控制。

3、SOA的关键技术

功能	协议
发现服务	UDDI、DISCO
描述服务	WSDL、XML Schema
消息格式层	SOAP、REST
编码格式层	XML（DOM，SAX）
传输协议层	HTTP、TCP/IP、SMTP等

4、REST特点：

HTTP+XML进行基于Web通信的技术。
简单性，缺少严格配置文件。
只支持几个操作（POST、GET、PUT、DELETE）。
强调信息本身，称为资源。

5、SOA的实现方式

（1）ESB的功能：

提供位置透明性的消息路由和寻址服务；
提供服务注册和命名的管理功能；
支持多种的消息传递泛型；
支持多种可以广泛使用的传输协议；
支持多种数据格式及其相互转换；
提供日志和监控功能。

（2）服务注册表

服务注册：应用开发者（服务提供者）向注册表公布服务的功能；
服务位置：服务使用者（服务应用开发者），帮助他们查询注册服务，寻找符合自身要求的服务；
服务绑定：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定、调用注册的服务以及与它们实现互动。

重点3：架构描述语言ADL

1、ADL是一种形式化语言，为软件系统的概念体系结构建模提供了具体语法和概念框架。基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持。

2、ADL的三个基本元素：

构件：计算或数据存储单元；
连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则；
架构配置：描述体系结构的构件与连接件的连接图。

3、主要的架构描述语言：

Aesop：支持体系结构风格的应用；
MetaH：为设计者提供了关于实时电子控制软件系统的设计指导；
C2：支持基于消息传递风格的用户界面系统描述；
Rapide：支持体系结构设计的模拟并提供了分析模拟结果的工具；
SADL：提供了关于体系结构加细的形式化基础；
Unicon：支持异构的构件和连接类型并提供了关于体系结构的高层编译器；
Wright：支持体系结构构件之间交互的说明和分析。

重点4：特定领域软件架构DSSA

要点1：领域分析机制

领域专家：有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等；它的主要任务包括提供关于领域中系统的需求规约和实现的知识。
领域分析人员：应由具有知识工程背景的有经验的系统分析员来担任。
领域设计人员：应由有经验的软件设计人员来担任。
领域实现人员：应由有经验的程序设计人员来担任。

要点2：建立过程

要点3：三层次模型

重点5：基于架构的软件开发ABSD

ABSD方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成（甚至远远没有完成），就开始了软件设计。

ABSD方法有三个基础，第一个是功能的分解，在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；第二个是通过选择架构风格来实现质量和业务需求；第三个是软件模版的使用，软件模版利用了一些软件系统的结构。

ABSD方法是递归的，且迭代的每一个步骤都是清晰地定义的，因此不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。

重点6：软件质量属性

1、性能（performance）：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

（1）代表参数：响应时间、吞吐量。

（2）设计策略：优先级队列、资源调度。

2、可靠性（reliability）：是软件系统在应用或系统错误面前，在意外或错误使用情况下维持软件系统的功能特性的基本能力。

（1）代表参数：MTTF、MTBF。

（2）设计策略：冗余、心跳线。

3、可用性（availability）：是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

（1）代表参数：故障间隔时间。

（2）设计策略：冗余、心跳线。

4、安全性（security）：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等。

（1）设计策略：追踪审计。

5、可修改性（modifiability）：是指能够快速地以较高的性能价格比对系统进行变更的能力；通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

（1）主要策略：信息隐藏。

6、功能性（functionality）：是系统所能完成所期望的工作的能力；一项任务的完成需要系统中许多或大多数构件的相互协作。

7、可变性（changeability）：是指体系结构经扩充或变更而成为新体系结构的能力，这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构，当要将某个体系结构作为一系列相关产品（例如软件产品线）的基础时，可变性是很重要的。

8、互操作性（interoperation）：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用；为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口；程序和其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种特性也影响应用的软件体系结构。

重点7：软件架构评估

要点1：风险点、敏感点和权衡点

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

2、敏感点是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。

3、权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

要点2：基于场景的方式

1、确定应用领域的功能和软件架构的结构之间的映射。

2、设计用于体现待评估质量属性的场景。

3、分析软件架构对场景的支持程度。

要点3：架构权衡分析法（ATAM）

要点4：质量效用树

要点5：成本效益分析法（CBAM）

整理场景并对场景进行求精。
确定场景的优先级。
分配效用。
形成“策略-场景-响应级别”的对应关系。
确定期望的质量属性响应级别的效用。
计算各架构策略的总收益
根据受成本限制影响的投资报酬率选择架构策略。

要点6：软件架构分析法（SAAM）

重点8：软件产品线

要点1：过程模型

要点2：建立方式

	演化方式	革命方式
基于现有产品	基于现有产品架构设计产品线的架构，经演化现有构件，开发产品线构件	核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集
全新产品线	产品线核心资源随产品新成员的需求而演化	开发满足所有预期产品线成员的需求的核心资源

要点3：组织类型

1、组织结构类型：

（1）设立独立的核心资源小组。

（2）不设立独立的核心资源小组。

（3）动态的组织结构。

2、要成功实施产品线，主要取决于以下因素：

（1）对该领域具备长期的深厚的经验。

（2）一个用于构建产品的好的核心资源库。

（3）好的产品线架构。

（4）好的管理（软件资源、人员组织、过程）支持。

重点9：架构与中间件技术

要点1：构件的定义

定义1：软件构建是一种组装单元，它具有规范的接口规约和显式的语境依赖；软件构件可以被独立地部署并由第三方任意地组装。

定义2：构件是某系统中有价值的、几乎独立的并可替换的一部分，它在良好定义的体系结构语境内满足某清晰的功能。

定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。

构件的特性	对象的特性	模块的特性
1、独立部署单元 2、第三方的组装单元 3、没有（外部的）可见状态	1、一个实例单元，具有唯一的标志 2、可能具有状态，且对外可见 3、封装了自己的状态和行为	结构化开发的产物

要点2：构件系统架构特性

构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。

构件框架是一种专用的体系结构（通常围绕一些关键的机制），同时也是一组固定地作用于构件层次机制的策略。

概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则。

构件是一组通常需要同时部署的原子构件，构件与原子构件之间的区别在于大多数原子构件永远不会被单独部署，尽管它们可以被单独部署。

一个原子构件是一个模块和一组资源。模块是一组类和可能的非面向对象的结构体，比如过程或者函数；资源是一个类型化的项的固定集合，资源这个概念可以包含代码资源，进而包含模块，问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其他的资源。在纯对象的方法中，资源是外部化的不可改变的对象，不可改变是因为构件没有持久化的标志而且复制不能被区分。

要点3：构件的复用

流程：检索与提取构件、理解与评价构件、修改构件、组装构件。

1、检索与提取构件

（1）基于关键字的检索：系统在图形用户界面上将构件库的关键字树形结构直观地展示给用户，复用者通过对树形结构的逐级浏览，寻找需要的关键字并提取相应的构件。

（2）刻画检索法：该方法基于刻画分类法，由三步构成，分别是构造查询、检索构件和对构件进行排序。这种方法的有点是它易于实现相似构件的查找，但复用者在构造查询时比较麻烦。

（3）超文本检索法：复用者首先给出一个或数个关键字，系统在构件的说明文档中进行精确或模糊的语法匹配，匹配成功后向复用者列出相应的构件说明。这种方法的优点是用户界面友好，但在某些情况下复用者难以在超文本浏览过程中正确选取构件。

2、理解与评价构件

（1）要复用构件，准确地理解构件至关重要，特别是对构件修改使用时。

（2）为达到目的，必须要求构件的开发过程遵循公共标准。

（3）一般构件库的文档中全面而准确地说明以下内容：构件的功能与行为、相关的领域知识、可适应性约束条件与例外情形、可以预见的修改部分及修改方法。

3、修改构件

（1）理想状态是直接复用构件库中现成的构件，但在大多数情况下，必须对构件进行或多或少的修改，以应对新的需求。

（2）为了减少构件修改的工作量，要求开发人员尽量使用构件的功能、行为和接口设计更为抽象化、通用化和参数化；这样复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍不足以使构件适用于新系统，复用者就必须借助设计信息和文档来修改构件。

（3）构件库中若无可修改使用的构件，则按新需求开发构件，并存入构件库。

4、组装构件

（1）基于功能的组装技术：采用子程序调用和参数传递的方式将构件组装起来；它要求库中的构件以子程序/过程/函数的形式出现，并且接口说明必须清晰，当使用这种组装技术进行软件开发时，开发人员首先要对新系统进行功能分解，将系统分解为强内聚、松耦合的功能模块，然后根据各模块的功能需求提取构件，进行适应性修改后，再连接在上述功能分解框架中。

（2）基于数据的组装技术：首先根据当前软件问题的核心数据结构设计出一个框架，然后根据框架中各结点的需求提取构件并进行适应性修改，再将构件逐个分配至框架中的适当位置。此后，构件的组装方式仍然是传统的子程序调用与参数传递，这种组装技术也要求库中构件以子程序形式出现，但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如Jackson系统开发方法。

（3）面向对象的组装技术：由于封装和继承特性，面向对象方法比其他软件开发方法更适合支持软件复用；在面向对象的软件开发方法中，如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接使用，否则必须以基类为父类，生成相应的之类，以满足新系统的需求。

5、在构件组装阶段失配问题主要包括：

（1）由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配。

（2）由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配。

（3）由于系统成分对全局体系结构的假设存在冲突引起的失配等。

要点4：中间件概念

中间件是一种独立的系统软件或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源。

1、中间件的主要作用：

（1）负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。

（2）提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。

（3）提供多层架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发。

（4）屏蔽硬件、操作系统、网络和数据库的差异。

（5）提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。

（6）提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以写作。

2、中间件的优点

（1）面向需求，即设计师集中精力于业务逻辑本身。

（2）业务的分隔和包容性：应用开发人员可以按照不同的业务进行功能的划分，体现为不同的接口或交互方式。

（3）设计与实现隔离：构件对外发生作用或构件间的交互都是通过接口进行的，构件使用者只需要知道构件的接口而不必关心起内部实现，这是设计与实现分离的关键。

（4）隔离复杂的系统资源：架构很重要的一个功能就是将系统资源与应用构件隔离，这是保证构件可复用甚至“即插即用”的基础，与中间件的意图也是一致的。

（5）符合标准的交互模型：实现了架构的模型和标准化的协议。

（6）软件复用：提供了构件封装、交互规则以及与环境隔离的机制。

（7）提供对应用构件的管理：基于中间件的软件可以方便地进行管理，因为构件总可以通过标识机制进行划分。

3、公共对象请求代理体系结构CORBA

私服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象并调用方法返回结果；客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

CORBA体系的主要内容包括以下几部分：

对象请求代理（Object Request Broker, ORB）：负责对象在分布环境中透明地收发请求和响应，它是构建分布对象应用、在异构或同构环境下实现应用间互操作的基础；
对象服务（Object Services）：为使用和实现对象而提供的基本对象集合，这些服务应独立于应用领域；
公共设施（Common Facilities）：向终端用户提供一组共享服务接口，例如系统管理、组合文档和电子邮件等；
应用接口（Application Interfaces）：由销售商提供的可控制其接口的产品，相应于传统的应用层表示，处于参考模型的最高层；
领域接口（Domain Interfaces）：为应用领域服务而提供的接口，如OMG组织为PDM系统制定的规范。

4、J2EE分布式多层应用程序

（1）Bean运行于EJB容器之中，共分三类：

会话Bean：描述了与客户端的一个短暂的会话；
实体Bean：持久化数据，O/R映射；
消息驱动Bean：会话Bean+JMS，客户把消息发送给JMS目的地，然后JMS提供者和EJB容器写作，把消息发送给消息驱动Bean。

（2）J2EE核心组成

容器：Applet Container、Application Container、Web Container、EJB Container；
组件：Applet、Application、JSP/Servlet、EJB；
服务：HTTP、RMI-IIOP、Java IDL、CORBA服务、JTA、JDBC、JMS、Java Mail、JAF、JNDI、JAXP、JCA、JAAS、JSF、JSTL、SAAJ、JAXR。

（3）J2EE企业应用框架

Struts：是一个基于J2EE平台的MVC框架，主要采用Servlet和JSP技术来实现；在Struts中，M由实现业务逻辑的JavaBean构成，C由ActionServlet和Action来实现，V由一组JSP文件构成；
Spring：通过RMI或Web Service远程访问业务逻辑，允许只有选择和组装各部分功能，还提供和其他软件集成的接口；Spring本身是个容器，管理构件的生命周期、构件的状态和依赖注入等，并且可以控制构件在创建时是以原型或单例模式来创建等；
Hibernate：是一个对象关系映射框架，提供了Java对象到数据库表之间的直接映射，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以使用对象编程思维来操作数据库；在Hibernate中，ORM机制的核心是一个XML语法的配置文件，该文件描述了数据库模式是怎样与一组Java类绑定的。

（4）J2EE轻量级与重量级框架的比较

模式	特点
重量级	1、占据资源多，在开发过程中效率低 2、配置运行过程耗时长，修改复杂 3、单元测试比较麻烦
轻量级	1、提高了开发速度 2、立即可以看到结果 3、做单元测试也非常简单 4、大量现成可供参考的开源代码

重点10：Web架构设计

要点1：主要技术和概念

1、架构：MVC、MVP、MVVM、REST、Web Service、微服务。

2、缓存：Mem Cache、Redis、Squid。

3、并发分流：集群（负载均衡）、CDN。

4、数据库：主从库（主从复制）、内存数据库、反规范化技术、NoSQL、分区（分表）技术、视图与物化视图。

5、持久化：Hibernate、MyBatis。

6、分布式存储：Hadoop、FastDFS、区块链。

7、数据编码：XML、JSON。

8、Web应用服务器：Apache、WebSphere、WebLogic、Tomcat、JBOSS、IIS。

9、其它：静态化、有状态与无状态、响应式Web设计。

要点2：Web架构的演化

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

2、应用服务器集群

系统演变到这里，将会出现下面几个问题：

用户的请求由谁来转发到具体的应用服务器；
用户如果每次访问到服务器不一样，如何维护Session的一致性。

要点3：负载均衡技术

1、类型

（1）基于特定软件的负载均衡（HTTP重定向）（应用层）

HTTP重定向就是应用层的请求转发，用户的请求实际已经到了HTTP重定向负载均衡服务器，服务器根据算法要求用户重定向，用户收到重定向请求后，再次请求真正的集群。

特点：实现简单，但性能较差。

（2）反向代理负载均衡（应用层）

在用户的请求到达反向代理服务器时（已经到达网站机房），由反向带来服务器根据算法转发到具体的服务器。

常用的Apache、Nginx都可以充当反向代理服务器。

特点：部署简单，但代理服务器可能成为性能的瓶颈。

（3）基于DNS的负载均衡（传输层）

DNS域名解析负载均衡就是在用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。

特点：效率比HTTP重定向高，减少维护负载均衡服务器的成本；但一个应用服务器故障，不能及时通知DNS，并且DNS服务器的控制权属于域名服务商，网站无法做更多的改善和更强大的管理。

（4）基于NAT的负载均衡（传输层）

基于NAT的负载均衡将一个外部IP地址映射为多个IP地址，对每次连接请求动态地转换为一个内部节点的地址。

特点：技术较为成熟，一般在网关位置，可以通过硬件实现，像四层交换机一般就采用了这种技术。

（5）混合型负载均衡。

2、算法

（1）静态算法：轮转算法、加权轮转算法、源地址哈希散列算法、目标地址哈希散列算法、随机算法。

（2）动态算法：最小连接数算法、加权最小连接数算法、加权百分比算法。

3、软硬件

（1）硬件负载均衡：F5。

（2）软件负载均衡：LVS、Nginx、HAproxy。

4、有状态与无状态

（1）无状态服务（stateless service）：对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里要么可以从外部获取到，服务器本身不存储任何信息。

（2）有状态服务（stateful service）：它会在自身保存一些数据，先后的请求是有关联的。

要点4：数据库优化技术

1、数据库读写分离化

2、用缓存缓解读库的压力

MemCached是一个自由开源的、高性能、分布式内存对象缓存系统，简洁的key-value存储系统。通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度。

要点5：内容分发网络CDN

内容分发网络（Content Delivery Network，CDN）的基本思想是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。

要点6：XML与JSON

1、XML

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

（1）XML的优点：

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

（2）XML的缺点：

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

2、JSON

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

（1）JSON的优点：

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

（2）JSON的缺点：没有XML格式这么广泛与通用。

要点7：Web应用服务器

1、Web应用服务器可以理解为两层意思

（1）Web服务器：其职能较为单一，就是响应浏览器发过来的请求并返回HTML页面。

（2）应用服务器：进行业务逻辑的处理。

2、常见的Web服务器：Apache、Tomcat、JBOSS、WebSphere、WebLogic、Jetty。

要点8：缓存技术

1、MemCache

MemCache是一个高性能的分布式的内存对象缓存系统，用于动态Web应用以减轻数据库负载。

MemCache通过在内存里维护一个统一的、巨大的Hash表，用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。

2、Redis

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

3、Squid

Squid是一个高性能的代理缓存服务器，Squid支持FTP、gopher、HTTPS和HTTP协议。

Squid是一个单独的、非模块化的、I/O驱动的进程来处理所有的客户端请求。

4、Redis与MemCache的差异

比较项	Redis	MemCache
内存数据库	是	是
支持Key-Value	是	是
支持多格式（如图片、视频）	否	是
支持List、Set、Hash	是	否
支持数据持久化	是	否
数据恢复	是	否
虚拟内存交换技术	是	否
支持关系数据库特性	是	否

如果有持久化方面的需求或对数据类型和处理有要求应该选择Redis，如果简单的使用Key-Value存储方式则建议选择MemCache。

要点9：表述性状态递增REST

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

2、REST的5个原则：

（1）网络上所有事物都被抽象为资源。

（2）每个资源对应一个唯一的资源标识。

（3）通过通用的连接件接口对资源进行操作。

（4）对资源的各种操作不会改变资源标识。

（5）所有的操作都是无状态的。