案例分析背诵点

信息系统架构的设计理论与实践

信息系统架构的定义

软件或计算机系统的信息系统架构是该系统的一个（或多个）结构，而结构由软件元素，元素的外部可见属性及它们之间的关系组成。

信息系统架构的分类

按照信息系统硬件在空间上的拓扑结构，其物理结构一般分为集中式与分布式两大类。

集中式是指物理资源在空间上集中配置。早期的单机系统是最典型的集中式结构，集中式结构的优点是资源集中，便于管理，资源利用率较高。但是随着系统规模的扩大，以及系统的日趋复杂，集中式结构的维护与管理越来越困难
分布式是指通过计算机网络把不同地点的计算机硬件、软件、数据等资源联系在一起，实现不同地点的资源共享。分布式可以根据应用需求来配置资源，提高信息系统对用户需求与外部环境变化的应变能力，系统扩展方便，安全性好，某个结点所出现的故障不会导致整个系统停止运作。然而由于资源分散，且又分属于各个子系统，系统管理的标准不易统一，协调困难，不利于对整个资源的规划与管理。

信息系统常用的四种架构模型

单机应用模式

单机应用系统是最简单的软件结构，是指运行在一台物理机器上的独立应用程序。当然，该应用可以是多进程或多线程的。当然至今，这种复杂的单机系统也有很多，它们大多都是专业领域的产品，例如Photoshop等等。

客户机/服务器(C/S)模式

客户机/服务器模式是信息系统中最常见的一种。C/S 概念可理解为Client方向Server方发送一个TCP或UDP包，然后Server方根据接收到的请求向Client方回送TCP或UDP数据包，目前C/S架构主要有两层C/S、三层C/S与B/S、多层C/S、MVC这四种常见的客户机/服务器的架构。

面向服务架构(SOA)模式

面向服务架构SOA模式是指多个多层C/S结构的应用系统之间需要相互进行通信，将由多层服务组成的一个结点应用看作是一个单一的服务，面向服务架构的本质是消息机制或远程过程调用(RPC)。

企业数据交换总线

企业数据交换总线是不同的企业应用之间进行信息交换的公共通道，这种架构在大型企业不同应用系统进行信息交换时使用较普遍，在国内，主要是银行或电信等信息化程度较高的行业采用此种结构

企业信息系统的总体框架

信息系统体系结构总体参考框架由四个部分组成，即战略系统、业务系统、应用系统和信息基础设施。战略系统处在第一层，其功能与战略管理层次的功能相似，一方面向业务系统提出重组的要求。另一方面向应用系统提出集成的要求。业务系统和应用系统同在第二层，属于战术管理层，业务系统在业务处理流程的优化上对企业进行管理控制和业务控制，应用系统则为这种控制提供计算机实现的手段，并提高企业的运行效率。信息基础设施处在第三层，是企业实现信息化的基础部分，相当于运行管理层，它在为应用系统和战略系统提供数据上支持的同时，也为企业的业务系统实现重组提供一个有效的、灵活响应的技术上和管理上的支持平台。

开放式企业架构框架标准(TOGAF)的定义

TOGAF是一种开放式企业架构框架标准，它为标准、方法论和企业架构专业人员之间的沟通提供一致性保障

TOGAF版本的六个组件

(1)架构开发方法:这部分是TOGAF的核心。它描述了TOGAF架构开发方法(ADM),即一种开发企业架构的分步方法。

(2) ADM指南和技术:这部分包含一系列可用于应用ADM的指南和技术。

(3)架构内容框架:这部分描述了TOGAF内容框架，包括架构工件的结构化元模型、可重用架构构建块(ABB)的使用以及典型架构可交付成果的概述。

(4)企业连续体和工具:这部分讨论分类法和工具，用于对企业内部架构活动的输出进行分类和存储。

(5) TOGAF参考模型:这部分提供了两个架构参考模型，即TOGAF技术参考模型(TRM)和集成信息基础设施参考模型(II-RM)。

(6)架构能力框架:这部分讨论在企业内建立和运营架构实践所需的组织、流程、技能、角色和职责。

TOGAF的核心思想

(1)模块化架构: TOGAF标准采用模块化结构。

(2)内容框架: TOGAF标准包括了一个使遵循架构开发方法(ADM)所产出结果更加一致的内容框架。TOGAF内容框架为架构产品提供了详细的模型。

(3)扩展指南: TOGAF标准的一系列扩展概念和规范为大型组织内部团队开发多层级集成架构提供支持，这些架构均在一个总体架构治理模式内运行。

(4)架构风格: TOGAF标准在设计上注重灵活性，可用于不同的架构风格。

ADM架构开发方法的定义

架构开发方法(ADM) 是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成。架构开发方法(ADM) 为开发企业架构所需要执行各个步骤以及它们之间的关系进行详细的定义，同时它也是TOGAF规范中最为核心的内容

ADM架构开发的全生命周期

ADM全生命周期划分为准备、需求管理、架构愿望、业务架构、信息系统架构(应用和数据)、技术架构、机会和解决方案、迁移规划、实施治理、架构变更管理等十个阶段，ADM方法被迭代式的应用在架构开发的整个过程中、阶段之间和每个阶段内部。

四个维度对架构活动范围的限定

信息化的概念

信息化是指培育、发展以智能化工具为代表的新的生产力并使之造福于社会的历史过程。国家信息化就是在国家统一规划和组织下，在农业、工业、科学技术、国防及社会生活各个方面应用现代信息技术，深入开发广泛利用信息资源，加速实现国家现代化进程”。实现信息化就要构筑和完善6个要素(开发利用信息资源，建设国家信息网络，推进信息技术应用，发展信息技术和产业，培育信息化人才，制定和完善信息化政策)的国家信息化体系。

完整的信息化内涵

(1)信息网络体系:包括信息资源，各种信息系统，公用通信网络平台等。

(2)信息产业基础:包括信息科学技术研究与开发，信息装备制造，信息咨询服务等。

(3)社会运行环境:包括现代工农业、管理体制、政策法律、规章制度、文化教育、道德观念等生产关系与上层建筑。

(4)效用积累过程:包括劳动者素质，国家现代化水平，人民生活质量不断提高，精神文明和物质文明建设不断进步等。

信息化的特征

信息化主要体现以下6种特征:

1)易用性

易用性对软件推广来说最重要，是能否帮助客户成功应用的首要因素，故在产品的开发设计上尤为重点考虑。一套软件功能再强大，但如果不易用，用户会产生抵触情绪，很难向下推广。

2)健壮性

健壮性表现为软件能支撑的最大并发用户数，支持大的数据量，使用多年以后速度、性能不会受到影响。

3)平台化、灵活性、拓展性

通过自定义平台，可以实现在不修改一行源代码的前提下，通过应用人员就可以搭建功能模块，以及小型业务系统，从而实现系统的自我成长。同时通过门户自定义、知识平台自定义、工作流程自定义、数据库自定义、模块自定义，以及大量的设置和开关，让各级系统维护人员对系统的控制力大大加强。

4)安全性

系统能够支持多种如Windows、Linux、 Unix 等操作系统，对安全性要求高的用户通常将系统部署在LINUX平台或国内的麒麟基础软件平台，同时，从流程、公文、普通文件等在传输和存储上都是绝对加密的，系统本身有严格的思维管理权限、IP地址登录范围限制、关键操作的日志记录、电子签章和流程的绑定等多种方式来保证系统的安全性。

5)门户化、整合性

协同办公系统只是起点，后续必然会逐步增加更多的系统建设，如何将各个孤立的系统协同起来，以综合性的管理平台将数据统一一展示给用户，选择具有拓展性的协同办公系统就成为向后一体信息化建设的关键。

技术上:产品底层设计选择了整合性强的技术架构，系统内预留了大量接口，为整合其他系统提供了技术保障。

经验上:成功实施了大量系统整合案例，丰富的系统整合经验确保系统整合达到客户预期的效果。

6)移动性

信息化平台嵌入手机，使用户通过手机也可以方便使用信息化服务。

信息化架构模式有哪两种

信息化架构一般有两种模式，一种是数据导向架构，一种是流程导向架构。

对于数据导向架构重点是在数据中心，BI商业智能等建设中使用较多，关注数据模型和数据质量;

对于流程导向架构，关注端到端流程整合，以及架构对流程变化的适应度。

两种架构并没有严格的边界，而是相互配合和补充。

信息化建设生命周期

信息系统的生命周期可以分为系统规划、系统分析、系统设计、系统实施、系统运行和维护等五个阶段。

(1)系统规划阶段

对企业的环境、目标、现行系统的状况进行初步调查，对建设新系统的需求做出分析和预测，研究建设新系统的必要性和可能性。产物：可行性分析报告，系统设计任务书。

(2)系统分析阶段

对现行系统进行详细调查,指出现行系统的局限性和不足之处，提出新系统的逻辑模型。产物：系统说明书（是系统设计的依据，也是将来验收系统的依据）

(3)系统设计阶段

根据系统说明书中规定的功能要求，考虑实际条件，设计新系统的物理模型。这个阶段又可分为总体设计和详细设计两个阶段。产物：系统设计说明书

(4)系统实施阶段

包括计算机等设备的购置、安装和调试、程序的编写和调试、人员培训、数据文件转换、系统调试与转换等。系统实施是按实施计划分阶段完成的，每个阶段应写出实施进度报告。产物：系统测试分析报告、实施进度报告。

(5)系统运行和维护阶段

系统投入运行后，需要经常进行维护和评价，记录系统运行的情况，根据一定的规格对系统进行必要的修改，评价系统的工作质量和经济效益。

信息化工程总体规划的方法论（用于管理信息系统规划的方法）

主要是关键成功因素法(CSF)、战略目标集转化法(SST)和企业系统规划法(BSP)。其他还有企业信息分析与集成技术、产出/方法分析、投资回收法、征费法(chargout)、零线预算法和阶石法等。用得最多的是前面三种。

关键成功因素法

在现行系统中，总存在着多个变量影响系统目标的实现，其中关键的和主要的因素就是关键成功因素。通过对关键成功因素的识别，找出实现目标所需的关键信息集合，从而确定系统开发的优先次序。关键成功因素法能抓住主要矛盾，使目标的识别突出重点。

战略目标集转化法

把整个战略目标看成是一个“信息集合”，由使命、目标、战略等组成，管理信息系统的规划过程即是把组织的战略目标转变成为管理信息系统的战略目标的过程。

企业系统规划法

信息支持企业运行，通过自上而下地识别系统目标、企业过程和数据，然后对数据进行分析，自下而上地设计信息系统。

层次式架构的设计理论与实践

层次式架构的定义和特性

软件层次式体系结构是最通用的架构，也被叫作N层架构模式。层次式体系结构设计是将系统组成一个层次结构，每一层为上层服务，并作为下层客户。分层式体系结构能有效地使设计简化，使设计的系统机构清晰，便于提高复用能力和产品维护能力。

分层架构的一个特性就是关注分离，该层中的组件只负责本层的逻辑，组件的划分很容易明确组件的角色和职责，也比较容易开发，测试，管理和维护

层次式架构的一般组成

层次式体系结构是一个可靠的通用的架构，对很多应用来说，如果不确定哪种架构适合，可以用它作为一个初始架构。但是，设计时要注意以下两点：

(1)要注意的是污水池反模式。

所谓污水池反模式（architecturesinkholeanti-patem),就是请求流简单地穿过几个层，每层里面基本没有做任何业务逻辑，或者做了很少的业务逻辑。比如一些javaee例子，业务逻辑层只是简单的调用了持久层的接口，本身没有什么业务逻辑。

每一层或多或少都有可能遇到这样的场景，关键是分析这样的请求的百分比是多少。二八原则可以帮助你决定是否正在遇到污水池反模式。如果请求超过20%,则应该考虑让一些层变成开放的。

(2)需要考虑的是分层架构可能会让你的应用变得庞大。

即使你的表现层和中间层可以独立发布，但它的确会带来一些潜在的问题，比如：分布模式复杂，健壮性下降，可靠性和性能的不足，以及代码规模的膨胀等。

MVC

MVP

MVVM

XML的定义

XML (可扩展标记语言)与HTML类似，是一种标记语言。与主要用于控制数据的显示，和外观的HTML标记不同，XML标记用于定义数据本身的结构和数据类型。XML已被公认为是优秀的数据描述语言，并且成为了业内广泛采用的数据描述标准。

请从设计模式的角度，简要说明设计方案采用XML作为GUI描述语言的机制

从设计模式的角度来说，整个XML表现层解析的机制是一种策略模式。在调用显示GUI时，不是直接调用特定的表现技术的API,而是装载GUI对应的XML配置文件，然后根据特定的表现技术的解析器解析XML,得到GUI视图实例对象。这样，对于GUI开发人员来说，GUI视图只需要维护一套XML文件即可。

UIP的定义

UIP是指用户界面处理应用程序块，是一种用于构建基于.NET技术的Web应用程序的软件框架。UIP框架提供了一套可重用的组件和设计模式，用于简化和加速Web应用程序的开发过程，有助于提高开发效率和维护性

UIP的分层

UIP的组件的功能

管理经过UIC的信息流;
管理UIP中各个事件之间的事务;
修改用户过程的流程以响应异常;
将概念上的用户交互流程从实现或者涉及的设备上分离出来;
保持内部的事务关联状态，通常是持有一个或者多个的与用户交互的事务实体。

因此，这些组件也能从UI组件收集数据，执行服务器的成组的升级或是跟踪UIP中的任务过程的管理。

表现层动态生成设计思想(基于XML界面管理技术)

基于XML界面管理技术，包括界面配置、界面动态生成和界面定制三部分，基于XML的界面管理技术实现的管理信息系统实现了用户界面描述信息与功能实现代码的分离，可针对不同用户需求进行界面配置和定制，能适应一定程度内的数据库结构改动。只须对XML文件稍加修改，即可实现系统的移植。

界面配置模块含义：界面配置是对用户界面的静态定义，通过读取配置文件的初始值对界面配置。由界面配置对软件功能进行裁剪、重组和扩充，以实现特殊需求。

界面定制模块含义：界面定制是对用户界面的动态修改过程，在软件运行过程中，用户可按需求和使用习惯，对界面元素(如菜单、工具栏、键盘命令)的属性(如文字、图标、大小和位置等)进行修改,软件运行结束，界面定制的结果被保存。

界面动态生成模块含义：系统通过DOM API读取XML配置文件的表示层信息(如初始界面大小、位置等)，通过数据存取类读取数据库中的数据层信息，运行时由界面元素动态生成界面。界面配置和定制模块在软件运行前后修改配置文件、更改界面内容。

工作流定义

业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。

(1) interface 1:过程定义导入/导出接口。这个接口的特点是:转换格式和API调用，从而支持过程定义信息间的互相转换。这个接口也支持已完成的过程定义或过程定义的一部分之间的互相转换。早期标准是WPDL,后来发展为XPDL。

(2) interface 2:客户端应用程序接口。通过这个接口工作流机可以与任务表处理器交互，代表用户资源来组织任务。然后由任务表处理器负责，从任务表中选择、推进任务项。由任务表处理器或者终端用户来控制应用工具的活动。

(3) interface 3:应用程序调用接口。允许工作流机直接激活一个应用工具，来执行一个活动。典型的是调用以后台服务为主的应用程序，没有用户接口。当执行活动要用到的工具，需要与终端用户交互，通常是使用客户端应用程序接口来调用那个工具，这样可以为用户安排任务时间表提供更多的灵活性。

(4) iterface 4:工作流机协作接口。其目标是定义相关标准，以使不同开发商的工作流系统产品相互间能够进行无缝的任务项传递。WFMC定义了4个协同工作模型，包含多种协同工作能力级别。

(5) interface 5:管理和监视接口。提供的功能包括用户管理、角色管理、审查管理、资源控制、过程管理和过程状态处理器等。

工作流的优点

将应用逻辑与过程逻辑分离，在不修改具体功能的情况下，通过修改过程模型改变系统功能，完成对生产经营部分过程或全过程的集成管理，可有效地把人、信息和应用工具合理地组织在一起，发挥系统的最大效能。

将业务逻辑层实体表示为XML的优点

(1)标准支持。XML是World Wide Web Consortium (W3C)的标准数据表示格式。

(2)灵活性。XML能够表示信息的层次结构和集合。

(3)互操作性。在所有平台上，XML都是与外部各方及贸易伙伴交换信息的理想选择。

将业务逻辑层实体表示为通用DataSet的优点

(1)灵活性。DataSet 可以包含数据的集合，能够表示复杂的数据关系。

(2)序列化。在层间传递时，DataSet 本身支持序列化。

(3)数据绑定。可以把DataSet绑定到ASP.NET应用程序和Windows窗体应用程序的任意用户界面控件。

(4)排序与过滤。可以使用DataView对象排序和过滤DataSet。应用程序可以为同一个DataSet创建多DataView对象，以便用不同方式查看数据。

(5)与XML的互换性。可以用XML格式读写DataSet.

(6)开放式并发。在更新数据时，可以配合使用数据适配器与DataSet方便地执行开放式并发检查。

(7)可扩展性。如果修改了数据库架构，则适当情况下数据访问逻辑组件中的方法可以创建包含修改后的DataTable 和DataRelation对象的DataSet。

将业务逻辑层实体表示为有类型的DataSet的优点

(1)代码易读。要访问有类型的DataSet中的表和列，可以使用有类型的方法和属性。

(2)有类型的方法和属性的提供使得使用有类型的DataSet比使用通用DataSet更方便。使用有类型的DataSet时，IntelliSense 将可用。

(3)编译时类型检查，无效的表名称和列名称将在编译时而不是在运行时检测。

业务逻辑层框架

在业务容器中，业务逻辑是按照Domain Model- -Service- Control 思想来实现的。

(1) Domain Model是领域层业务对象，它仅仅包含业务相关的属性。

(2) Service 是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点，一是它的灵活性，二是当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。

(3) Control 服务控制器，是服务之间的纽带，不同服务之间的切换就是通过它来实现的。通过服务控制器控制服务切换可以将服务的实现和服务的转向控制分离，提高了服务实现的灵活性和重用性。

Domain Model--Service- -Control 三者的互动关系

(1) Service 的运行会依赖于Domain Model的状态，反之，Service 也会根据业务规则改变Domain Model的状态。

(2) Control 作为服务控制器，根据Domain Model的状态和相关参数决定Service之间的执行顺序及相互关系。

Domain Model- -Service- Control 的互动关系，是吸取了Model- -View- Control 的优点，在“控制和显示的分离”的基础之上演变而来的，通过将服务和服务控制隔离，使程序具备高度的可重用性和灵活性。

5种数据访问模式

在线访问

在线访问是最基本的数据访问模式，也是在实际开发过程中最常采用的。这种数据访问模式会占用一个数据库连接，读取数据，每个数据库操作都会通过这个连接不断地与后台的数据源进行交互。

DAO模式

DAO模式是标准J2EE设计模式之一，开发人员常常用这种模式将底层数据访问操作与高层业务逻辑分离开。

一个典型的DAO实现通常有以下组件

(1)一个DAO工厂类。

(2)一个DAO接口。

(3) 一个实现了DAO接口的具体类。

(4)数据传输对象。

DTO模式

DTO本身是这样一组对象或是数据的容器，它需要跨不同的进程或是网络的边界来传输数据。这类对象本身应该不包含具体的业务逻辑，并且通常这些对象内部只能进行一些诸如内部一致性检查和基本验证之类的方法，而且这些方法最好不要再调用其他的对象行为。

离线数据模式

离线数据模式是以数据为中心，数据从数据源获取之后，将按照某种预定义的结构存放在系统中，成为应用的中心。

对象/关系映射(ORM)

对象/关系映射是指的提供了这样一种工具或是平台，能够帮助将应用程序中的数据转换成关系型数据库中的记录;或是将关系数据库中的记录转换成应用程序中代码便于操作的对象。ORM在关系型数据库和对象之间作一个映射，这样，在具体操纵数据库时，就不需要再去和复杂的SQL语句打交道，只要像平时操作对象一样操作即可。

工厂模式在数据访问层应用

工厂模式定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。这里可能会处理对多种数据库的操作，因此，需要首先定义一个操纵数据库的接口，然后根据数据库的不同，由类工厂决定实例化哪个类，这样实现了良好的封装性

ORM的定义和优点

ORM（对象关系映射）的优点

提高了开发效率：ORM可以将数据库中的数据表映射为面向对象的类，通过面向对象的方式来操作数据库，使得开发人员可以更加方便地进行数据持久化操作，减少了手写SQL的工作量。
易于维护和扩展：ORM框架隐藏了底层数据库的细节，使得开发人员可以更加专注于业务逻辑的实现。同时，通过面向对象的方式来操作数据库，使得代码更加易于维护和扩展，提高了代码的可读性和可重用性。
提高了数据访问的安全性：ORM框架通常提供了一些机制，例如SQL注入防护、数据校验等，可以提高数据访问的安全性。
便于数据库迁移：当需要更换数据库时，只需要修改ORM框架的配置文件，就可以轻松地将应用程序迁移到新的数据库中，而不需要修改大量的SQL语句。
支持多种数据库：ORM框架通常支持多种数据库，例如MySQL、Oracle、SQL Server等，这使得开发人员可以更加灵活地选择适合的数据库。

Hibernate的定义和优点

Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序使用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任

Hibernate优点

封装了JDBC，简化了很多重复性代码。
简化了DAO层编码工作，使开发更对象化了。
移植性好，支持各种数据库，如果换个数据库只要在配置文件中变换配置就可以了，不用改变hibernate代码。
支持透明持久化，因为hibernate操作的是纯粹的java对象，没有实现任何接口，没有侵入性。所以说它是一个轻量级框架。

XML Schema的定义和优点

XML Schema，全称XML Schema Definition（XSD），是以可扩展标记语言（标准通用标记语言的子集）为基础的，它用于可替代文档类型定义（DTD）。一份XML schema文件描述了XML文档的结构。

XML Schema优点

支持数据类型：XML Schema最重要的能力之一就是对数据类型的支持。通过对数据类型的支持，可以更容易地描述允许的文档内容，验证数据的正确性，与来自数据库的数据一并工作，定义数据约束（data facets），定义数据模型（或称数据格式），并在不同的数据类型间转换数据。
使用XML语法：另一个关于XML Schema的重要特性是，它们由XML编写。这样，开发人员不必学习新的语言，可以使用XML编辑器来编辑Schema文件，可以使用XML解析器来解析Schema文件，可以通过XML DOM来处理Schema，还可以通过XSLT来转换Schema。
保护数据通信：当数据从发送方被发送到接受方时，其要点是双方应有关于内容的相同的“期望值”。通过XML Schema，发送方可以用一种接受方能够明白的方式来描述数据。

事务的定义

事务是指一系列操作，这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。在数据库中，事务指的是单个逻辑工作单元执行的一系列操作，这些操作要么全部成功，要么全部失败回滚。

ACID原则

ACID原则是数据库事务正常执行的四个，分别指原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。具体如下：

原子性：一个事务的所有操作要么全部完成，要么全部不执行，不可分割。
一致性：事务结束后，数据库从一个一致性状态变到另一个一致性状态。
隔离性：事务之间不能互相干扰，事务A对数据库的操作不能影响事务B的操作。
持久性：一旦事务完成，它对数据库所做的修改将永久保存到数据库中，即使数据库发生故障也不会丢失。

XML文档分类

一类是以数据为中心的文档，这种文档在结构上是规则的，在内容上是同构的，具有较少的混合内容和嵌套层次，人们只关心文档中的数据而并不关心数据元素的存放顺序，这种文档简称为数据文档，它常用来存储和传输Web数据。

另一类是以文档为中心的文档，这种文档的结构不规则，内容比较零散，具有较多的混合内容，并且元素之间的顺序是有关的，这种文档常用来在网页上发布描述性信息、产品性能介绍和E-mail信息等。

XML文档的存储方式

XML文档的存储方式有两种:基于文件的存储方式和数据库存储方式。

(1)基于文件的存储方式。基于文件的存储方式是指将XML文档按其原始文本形式存储，主要存储技术包括操作系统文件库、通用文档管理系统和传统数据库的列(作为二进制大对象BLOB或字符大对象CLOB)。这种存储方式需维护某种类型的附加索引，以建立文件之间的层次结构。

基于文件的存储方式的特点:

无法获取XML文档中的结构化数据;
通过附加索引可以定位具有某些关键字的XML文档，一旦关键字不确定，将很难定位;
查询时，只能以原始文档的形式返回，即不能获取文档内部信息;
文件管理存在容量大、管理难的缺点。

(2)数据库存储方式。数据库在数据管理方面具有管理方便、存储占用空间小、检索速度快、修改效率高和安全性好等优点。一种比较自然的想法是采用数据库对XML文档进行存取和操作，这样可以利用相对成熟的数据库技术处理XML文档内部的数据。

数据库存储方式的特点:

能够管理结构化和半结构化数据:
具有管理和控制整个文档集合本身的能力;
可以对文档内部的数据进行操作:
具有数据库技术的特性，如多用户、并发控制和一致性约束等;
管理方便，易于操作。

物联网的一般层次架构(三层体系结构)

物联网可以分为三个层次，底层是用来感知数据的感知层，即利用传感器、二维码、RFID等设备随时随地获取物体的信息。第二层是数据传输处理的网络层，即通过各种传感网络与互联网的融合，将对象当前的信息实时准确地传递出去。第三层则是与行业需求结合的应用层，即通过智能计算、云计算等将对象进行智能化控制。

云原生架构设计理论与实践

云原生的定义

云原生是一种面向云计算环境的软件开发和部署方法，通过采用容器化、微服务架构和持续交付等技术，实现应用程序的高可用性、弹性和可扩展性。它提供了一种现代化的开发方式，帮助企业更好地利用云计算的优势，并加速应用程序的开发和部署过程。

云原生架构定义

云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

由于云原生是面向“云”而设计的应用，因此，技术部分依赖于传统云计算的3层概念，即基础设施即服务(IaaS)、平台即服务(PaaS) 和软件即服务(SaaS)。

云原生架构的特征

容器化：云原生架构使用容器技术（如Docker）来打包应用程序及其所有依赖项。容器化使应用程序具有轻量级、可移植和可扩展的特性，从而实现快速部署和扩展。

微服务架构：云原生架构倡导将应用程序拆分成一组小型、自治的服务，每个服务都可以独立开发、部署和扩展。这种架构模式提供了更高的灵活性和可伸缩性，使团队能够更快地迭代和交付新功能。

弹性和可伸缩性：云原生架构利用云计算平台提供的自动化和弹性扩展机制，根据负载和需求变化自动调整应用程序的资源使用。这使得应用程序能够根据实际需求进行自动扩展，以满足用户的需求。

声明式配置和自动化：云原生架构使用声明式配置来描述应用程序的状态和所需资源，以实现更简单、可重复和可管理的部署。同时，借助自动化工具和流程，可以实现持续集成、持续交付和自动化运维，提高开发和运维效率。

服务发现和治理：云原生架构中的服务之间通常通过服务发现机制来进行通信和协调。服务注册和发现工具（如Kubernetes中的Service和Ingress）可以帮助应用程序动态地发现和访问其他服务，从而实现更高的可靠性和弹性。

云原生的代码包括哪三部分

云原生的代码通常包括三部分:业务代码、三方软件、处理非功能特性的代码。其中“业务代码"指实现业务逻辑的代码;“三方软件”是业务代码中依赖的所有三方库，包括业务库和基础库;“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。

云原生架构的设计原则

服务化原则

将应用程序拆分成一组小型、自治的服务（微服务架构，小服务架构）。每个服务都有明确定义的边界和功能，可以独立开发、部署和扩展。这种微服务化的设计原则可以提高应用程序的灵活性、可伸缩性和可维护性。

弹性原则

利用云计算平台提供的自动化和弹性扩展机制，根据负载和需求变化自动调整应用程序的资源使用。弹性原则可以确保应用程序能够根据实际需求进行自动扩展，以满足用户的需求

可观测原则

可观测原则强调在云原生架构中实现对应用程序的全面监测和分析。通过使用日志、指标、追踪等工具和技术，可以实时收集和分析应用程序的运行数据，以便及时发现和解决问题。

韧性原则

韧性原则强调应用程序的健壮性和容错能力。韧性原则要求应用程序能够适应各种异常情况和不可预测的环境变化，包括网络故障、硬件故障、资源不足等。为了实现韧性，云原生架构通常采用故障隔离、容错机制和自愈能力，以确保应用程序能够继续正常运行或快速恢复。

所有过程自动化原则

所有过程自动化原则强调通过自动化来提高开发、部署和运维的效率和可靠性。云原生架构倡导采用自动化工具和流程来实现持续集成、持续交付和自动化运维。通过自动化，可以减少人为错误、加快交付速度、提高系统稳定性，并降低开发和运维的成本和工作量。

零信任原则

零信任原则强调不信任任何网络或用户，并将安全性置于首要位置。根据零信任原则，应用程序和系统在设计时，需要对每个用户、设备、服务和网络流量进行验证和授权，无论是在内部网络还是在外部网络。这意味着每个访问请求都需要进行身份验证和授权，以确保只有合法用户和设备能够访问敏感数据和资源。

架构持续演进原则

架构持续演进原则强调云原生架构的设计应该是一个持续演进的过程，而不是一次性的设计决策。根据这个原则，架构应该具备灵活性和可扩展性，以适应不断变化的需求和技术发展。架构持续演进原则鼓励采用敏捷开发和持续交付的方法，以便快速响应和适应业务需求的变化，并通过不断迭代和改进来优化架构的性能、可靠性和安全性。

云原生架构模式

服务化架构模式

定义

服务化架构是云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约（例如idl)定义彼此业务关系，以标准协议（http,grpc等）确保彼此的互联互通，结合ddd(领域模型驱动）,tdd(测试驱动开发）,容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务模式，其中小服务可以看作是组关系非常密切的服务的组合

优点

通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。
此由于在进程级实现了模块的分离，每个接口都可以单独升级，从而提升了整体的迭代效率。

缺点

服务拆分导致要维护的模块数量增多，如果缺乏服务的自动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。

Mesh化架构模式

mesh化架构是把中间件框架（如rpc,缓存，异步消息等）从业务进程中分离，让中间件sdk与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。

Serverless模式

serverless将"部署"这个动作从运维中"收走",使开发者不用关心应用运行地点，操作统，网络配置，cpu性能等，从架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发，也就是把应用的整个运行都委托给云

scrverless并非适用任何类型的应用，因此架构决策者需要关心应用类型是否适合于serverless运算。如果应用是有状态的，由于serverless的调度不会帮助应用做状态同步，因此云在进行调度时可能导致上下文丢失：如果应用是长时间后台运行的密集型计算任务，会无法发挥serverless的优势：如果应用涉及频繁的外部l0(网络或者存储，以及服务间调用）,也因为繁重的l0负担，时延大而不适合。serverless非常适合于事件驱动的数据计算任务，计算时间短的请求/响应应用，没有复杂相互调用的长周期任务。

存储计算分离模式

在云环境中，推荐把各类暂态数据（如session),结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。但仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大，需要不断根据上下文重新获取等，这时可以考虑通过采用时间日志+快照（或检查点）的方式，实现重启后快速增量恢复服务，减少不可用对业务的影响时长。

分布式事务模式

微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。

(1)传统采用xa模式，虽然具备很强的一致性，但是性能差。

(2)基于消息的最终一致性（base)通常有很高的性能，但是通用性有限。

(3)tcc模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效：但是对业务的侵入性非常强，设计开发维护等成本很高。

(4)saga模式与tcc模式的优缺点类似但没有ty这个阶段，而是每个正向事务都对应一个补偿事务，也是开发维护成本高。

(5)开源项目seata的at模式非常高性能且无代码开发工作量，且可以自动执行回滚操作，同时也存在一些使用场景限制。

可观测架构

观测架构包括logging,tracing,metrics三个方面，其中logging提供多个级别的详细信息跟踪，由应用开发者主动提供：tracing提供一个请求从前到后端的完整调用链路跟踪，对于分布式场景尤其有用：metris则提供对系统量化的多维度度量。

事件驱动架构

事件驱动架构本质上是一种应用/组件间的集成架构模式。事件和传统的消息不同，事件具有schema,所以可以校验event的有效性，同时eda具备Qos保障机制，也能够对事件处理失败进行响应。事件驱动架构不仅用于（微）服务解棍，还可应用于下面的场景中。

(1)增强服务韧性：由于服务间是异步集成的，也就是下游的任何处理失败甚至岩机都不会被上游感知，自然也就不会对上游带来影响

(2)cqrs把对服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的api接口：结合eda中的eventSourcing机制可以用于维护数据变更的一致性，当需要重新构建服务状态时，把eda中的事件重新"播放"一遍即可。

(3)数据变化通知：在服务架构下，往往一个服务中的数据发生变化，另外的服务会感兴趣，比如用户订单完成后，积分服务，信用服务等都需要得到事件通知并更新用户积分和信用等级。

(4)构建开放式接口：在eda下，事件的提供者并不用关心有哪些订阅者，不像服务调用的场景一数据的产生者需要知道数据的消费者在哪里并调用它，因此保持了接口的开放性。

(5)事件流处理：应用于大量事件流（而非离散事件）的数据分析场景，典型应用是基于kaika的日志处理。基于事件触发的响应：在t时代大量传感器产生的数据，不会像人机交互一样需要等待处理结果的返回，天然适合用eda来构建数据处理应用。

容器技术是什么

容器技术是一种虚拟化技术，用于将应用程序及其所有依赖项打包成独立、可移植的运行环境，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。

传统、虚拟化、容器部署模式比较

当谈到传统、虚拟化和容器部署模式时，它们都是不同的部署方式，每种方式都有其独特的优势和适用场景。

1. 传统部署模式：

传统部署模式是指将应用程序直接安装在物理服务器上的方式。这种方式的优势在于简单直接，没有额外的虚拟化或容器化层，可以直接利用硬件资源。然而，传统部署模式的缺点是部署和扩展相对较为复杂，而且在故障恢复和资源利用方面的灵活性有限。

2. 虚拟化部署模式：

虚拟化部署模式通过使用虚拟化软件（如VMware、Hyper-V等）在物理服务器上创建多个虚拟机来运行应用程序。每个虚拟机都具有自己的操作系统和应用程序，可以独立管理和扩展。虚拟化的优势在于提供了更好的资源利用率、灵活性和故障恢复能力。然而，虚拟化也存在一些缺点，如性能损失和资源浪费。

3. 容器部署模式：

容器部署模式使用容器技术（如Docker）来打包和运行应用程序。容器是一种轻量级的虚拟化技术，可以在同一物理机上运行多个容器，每个容器都有自己的文件系统、运行时环境和资源隔离。容器的优势在于快速部署、资源利用率高、可移植性强和灵活性高。然而，容器也需要一定的学习和管理成本，并且在处理长时间运行和大规模部署方面可能存在一些挑战。

kubemctes提供的分布式应用管理的核心能力有哪些

资源调度：根据应用请求的资源量cpu,memory,或者gpu等设备资源，在集群中选择合适的节点来运行应用。

应用部署与管理：支持应用的自动发布与应用的回滚，以及与应用相关的配置的管理；也可以自动化存储卷的编排，让存储卷与容器应用的生命周期相关联。

自动修复：kubermetes能监测这个集群中所有的宿主机，当宿主机或者os出现故障，节点健康检查会自动进行应用迁移：k8s也支持应用的自愈，极大简化了运维管理的复杂性。

服务发现与负载均衡：通过service资源出现各种应用服务，结合dns和多种负载均衡机制，支持容器化应用之间的相互通信。

弹性伸缩：k8s可以监测业务上所承担的负载，如果这个业务本身的cpu利用率过高或者响应时间过长，它可以对这个业务进行自动扩容。

微服务的定义

微服务模式将后端单体应用拆分为松合的多个子应用，每个子应用负贵一组子功能。这些子应用称为"微服务",多不"微服务"共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发，测试与部署流程，提高整体迭代效率。此外，微服务模式通过分布式架构将应用水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性

云原生微服务技术的定义

在云原生时代，云原生微服务体系将充分利用云资源的高可用和安全体系，让应用获得更有保障的弹性，可用性与安全性。应用构建在云所提供的基础设施与基础服务之上，充分利用云服务所带来的便捷性，稳定性，降低应用架构的复杂度。云原生的微服务体系也将帮助应用架构全面升级，让应用天然具有更好的可观测性，可控制性，可容错性等特性。

微服务设计约束

微服务个体约束

个设计良好的微服务应用，所完成的功能在业务域划分上应是相互独立的，微服务的"微"并不是为了微而微，而是按照问题域对单体应用做合理拆分。

微服务与微服务之间的横向关系

微服务之间需要引用第三方服务注册中心来满足服务的可发现性，微服务的可交互性是指服务a采用什么样的方式可以调用服务b.由于服务自治的约束，服务之间的调用需要采用与语言无关的远程调用协议，比如rest协议，服务与服务之间需要通过事先约定接口来完成调用。微服务体系中需要有一个独立的元数据中心来存储服务的元数据信息，服务通过查询该中心来理解发起调用的细节。

微服务与数据层之间的纵向约束

在微服务领域，提倡数据存储隔离（datastoragesegregation,dss)原则，即数据是微服务的私有资产，对于该数据的访问都必须通过当前微服务提供的api来访问。由于容器调度对底层设施稳定性的不可预知影响，微服务的设计应当尽量遵循无状态设计原则，这意味着上层应用与底层基础设施的解耦，微服务可以自由在不同容器间被调度。

全局视角下的微服务分布式约束

从微服务系统设计一开始，就需要考虑以下因素：高效运维整个系统，从技术上要准备全自动化的ci/cd流水线满足对开发效率的诉求，并在这个基础上支持蓝绿，金丝雀等不同发布策略，以满足对业务发布稳定性的诉求。

主要微服务技术有哪些

Dubbo作为源自阿里巴巴的一款开源高性能rpc框架。

springcloud为开发者提供了分布式系统需要的配置理，服务发现，断路器等能力和开发工具

Tars是腾讯将其内部使用的微服务框架taf多年的实践成果总结而成的开源项目

sofastack是由蚂蚁金服开源的一套用于快速建金融级分布式架构的中间件，也是在金融场景里的最佳实践。

dapr是微软新推出的一种可移植的，无服务器的微服务

无服务器技术serverless的定义

无服务器技术（Serverless）是一种计算模型，它允许开发者在云平台上构建和运行应用程序，而无需关注服务器的管理和维护。在无服务器架构中，开发者只需编写和部署函数级别的代码，而无需关心底层的服务器和基础设施。需要注意的是，尽管称为"无服务器"，但实际上仍然需要底层的服务器和基础设施来支持无服务器应用程序的执行，只是开发者无需直接管理这些服务器。

无服务器技术serverless的特征

(1)全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的，负担繁重的基于服务器等基础设施的开发，运维，安全，高可用等工作；

(2)通用性，结合云basapi的能力，能够支撑云上所有重要类型的应用；

(3)自动弹性伸缩，让用户无需为资源使用提前进行容量规划；

(4)按量计费，让企业使用成本得有效降低，无需为闲置资源付费。

无服务器技术serverless的技术关注点

计算资源弹性调度

为了实现精准、实时的实例伸缩和放置，必须把应用负载的特征作为资源调度依据，使用“白盒”调度策略，由Serverless平台负责管理应用所需的计算资源。平台要能够识别应用特征，在负载快速上升时，及时扩容计算资源，保证应用性能稳定;在负载下降时，及时回收计算资源，加快资源在不同租户函数间的流转，提高数据中心利用率。

负载均衡和流控

为了支撑每秒近百万次的资源调度请求，系统要对资源调度服务的负载进行分片，横向扩展到多台机器上，避免单点瓶颈。在多租户环境下，流量隔离控制是保证服务质量的关键。

安全性

系统应从权限管理，网络安全，数据安全，运行时安全等各个维度全面保障应用的安全性。

服务网格的定义

服务网格(ServiceMesh) 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。

服务网格的典型架构

在这张架构图中，服务a调用服务b的所有请求，都被其下的服务代理截获，代理服务完成到服务b的服务发现，熔断，限流等策略，而这些策略的总控是在控制平面（conrolplane)上配置。

以开源的lstio服务网格为例，其可以运行在虚拟机或容器中，lstio的主要组包括pilot(服务发现，流量管理）,mixer(访问控制，可观测性）,citadel(终端用户认证，流量加密）:整个服务网格关注连接和流量控制，可观测性，安全和可运维性。虽然相比较没有服务网格的场景多了4个pc通信的成本，但整体调用的延迟随着软硬件能力的提升而并不会带来显薯的影响，特别是对于百毫秒级别的业务调用而言可以控制在2%以内。从另一方面，服务化的应用并没有做任何改造，就获得了强大的流量控制能力，服务治理能力，可观测能力，4个9(9999%)以上高可用，容灾和安全等能力，加上业务的横向扩展能力，整体收益仍然是远大于额外ipc通信支出。

面向服务的架构设计理论与实践

面向服务的体系结构（SOA)定义

SOA是一个组件模型，它将应用程序的不同功能单元(称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台，操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

SOA架构是一个面向服务的架构，可将其视为组件模型，其将系统整体拆分为多个独立的功能模块，模块之间通过调用接口进行交互，有效整合了应用系统的各项业务功能，系统各个模块之间是松稠合的。SOA架构以企业服务总线链接各个子系统，是集中式的技术架构，应用服务间相互依赖导致部署复杂，应用间交互使用远程通信，降低了响应速度。

SOA与微服务的区别

(1)微服务相比于SOA更加精细，微服务更多地以独立的进程的方式存在，互相之间并无影响：

(2)微服务提供的接口方式更加通用化，例如http restfu方式，各种终端都可以调用。无关语言，平台限制

(3)微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。

微服务架构是SOA架构的进一步优化，去除了esb企业服务总线，是一个真正意义上去中心化的分布式架构。其降低了微服务之间的耦合程度，不同的微服务采用不同的数据库技术，服务独立，数据源唯一，应用极易扩展和维护，同时降低了系统复杂性。

总而言之，微服务架构是SOA架构思想的一种扩展，更加强调服务个体的独立性，拆分粒度更小。

面向Web服务的业务流程执行语言(BPEL)

BPEL（面向Web服务的业务流程执行语言）是一种用于描述和执行业务流程的标准化语言。它可以帮助组织在分布式系统中协调和管理各种Web服务的交互。BPEL提供了一种基于XML的语法，用于定义业务流程的逻辑和参与者之间的通信。

使用BPEL，您可以将业务流程抽象为一系列的活动和任务，这些活动和任务可以由不同的Web服务实现。BPEL定义了一组活动和结构，用于描述流程的控制流、数据传输和异常处理。

BPEL的主要优势之一是它的可扩展性。它可以与现有的Web服务技术（如SOAP和WSDL）集成，使得在不同的平台和技术之间进行协作变得更加容易。此外，BPEL还支持事务处理和并行执行，以提高业务流程的效率和可靠性。

总的来说，BPEL是一种强大的工具，可以帮助组织在复杂的分布式系统中管理和执行业务流程。它提供了一种标准化的语言和方法来描述和协调Web服务之间的交互，从而提高了组织的业务流程的效率和可靠性。

SOA的参考架构

从服务为中心的视角来看，企业集成的架构（如图15-2所示）可划分为6大类。

(1)业务逻辑服务（businesslogieservice):包括用于实现业务逻辑的服务和执行业务逻辑的能力，其中包括业务应用服务（businessappicationservice),业务伙伴服务（parnerervice)以及应用和信息资产（applicationandlnformationasset).

(2)控制服务（controlservice):包括实现人（people),流程（process)和信息（infor-mation)集成的服务，以及执行这些集成逻辑的能力。

(3)连接服务（connecivityservice):通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。

(4)业务创新和优化服务（businesinnovationandoptimizationservice):用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。

(5)开发服务（developmentservice):贯彻整个软件开发生命周期的开发平台，从需求分析，到建模，设计，开发，测试和维护等全面的工具支持。

(6)服务管理（servicemanagement):支持业务系统运行的各种基础设施管理能力或服务，如安全服务，目录服务，系统管理和资源虚拟化。

各种服务

SOA主要遵守的协议和规范

web服务最基本的协议包括UDDI,WSDL,SOAP

UDDI协议

UDDI(统一描述，发现和集成协议）计划是一个广泛的，开放的行业计划，它使得商业实体能够彼此发现：定义它们怎样在lntemet上互相作用，并在一个全球的注册体系架构中共享信息。

WSDL规范

wsdl(web服务描述语言）,是一个用来描述web服务和说明如何与web服务通信的xml语言，通过wsdl,可描述web服务的三个基本属性。

(1)服务做些什么一服务所提供的操作（方法）

(2)如何访问服务一和服务交互的数据格式以及必要协议。

(3)服务位于何处一协议相关的地址，如url.

SOAP协议

soap是在分散或分布式的环境中交换信息的简单的协议，是一个基于xml的协议。

它包括4个部分：

soap封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接收并处理它以及如何处理它们的框架
soap编码规则用于表示应用程序需要使用的数据类型的实例
soaprpc表示是远程过程调用和应答的协定
soap绑定是使用底层协议交换信息。

REST规范

rest是一种设计风格而不是一个架构。restful不可能摒弃rest而独立存在，是人们借助http,json,url,html等web服务开发中广泛使用的标准和协议，同时使用不同的编程语言编写客户端和服务端，通过http方法操作资源状态，最后遵循rest设计原则实现的应用程序或服务架构。rest对应的翻译是表述性状态转移，可以理解为资源表述性状态转移。

1.资源（resource)

将互联网中一切给客户端的事物都可以看作是一种资源，对资源相关数据和表述进行组合，借助url(统资源标识符）标识web上的资源。但是url和资源又不是一一映射，一个资源可以设计多个url,但一个url只能对应一种资源。

2.表述（representational)

rest中用表述描述资源在web中某一个时间的状态。客户端和服务端借助restful api传递数据，实际就是在进行资源表述的交互。表述在web常用表现形式有html,json,xml,纯文本等

3.状态转移（statetransfer)

rest定义中状态分为两种：应用状态和资源状态。应用状态是对某个时间内用户请求会话相关信息的快照，保存在客户端，由客户端自身维护，可以和缓存配合降低服务端并发请求压力。资源状态在服务端保存，是对某个时间资源请求表述的快照，保证在服务端，如果一段时内没有对资源状态进行改变，客户端对同一资源请求返回的表述一致。同时状态转移还要借助http方法来实现，如get方法，post方法，delete方法等。

4.超链接

超链接是通过在页面中嵌入链接和其他资源建立联系，这里的资源可以是文本，图片，文件等。

SOA的作用

业务整合和灵活性：SOA可以帮助组织将业务逻辑划分为独立的服务，这些服务可以在不同的应用程序和系统之间共享和重用。这种松耦合的架构使得组织可以更轻松地进行业务整合和改变，以适应不断变化的业务需求。
跨平台和集成性：SOA提供了一种标准化的方法来描述和通信服务，使得不同的应用程序和系统可以跨平台进行集成。通过使用通用的协议和接口，SOA促进了不同技术和平台之间的互操作性，使得组织可以更好地整合现有系统和引入新的技术。
可伸缩性和可靠性：SOA支持服务的分布式部署和调用，使得系统可以根据需求进行水平和垂直的扩展。这种可伸缩性和可靠性使得组织可以更好地应对高负载和故障恢复等情况，提高系统的性能和可用性。

简单来说，SOA的最大作用是解决了信息孤岛的难题

SOA 的设计原则

(1)无状态。以避免服务请求者依赖于服务提供者的状态。

(2)单一实例。避免功能冗余。

(3)明确定义的接口。

(4)自包含和模块化。服务封装了那些在业务上稳定，重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署，版本控制，自我管理和恢复。

(5)粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用（rpc)

(6)服务之间的松耦合性。服务使用者看到的是服务的接口，其位置，实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。

(7)重用能力。服务应该是可以重用的。

企业服务总线ESB的定义和特征能力

ESB的定义

企业服务总线是由中间件技术实现的支持面向服务架构的基础软件平台，支持异构环境中的服务以基于消息和事件驱动模式的交互，并且具有适当的服务质量和可管理性。

ESB的基本特征和能力

esb的基本特征和能力包括：描述服务的元数据和服务注册管理：在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式，异步模式等：发现，路由，匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持，服务质量保证，可管理性和负载平衡等。

需要注意的是，esb是一种架构模式，不能简单地等同于特定的技术或者产品，但实现esb确实需要各种产品在运行时和工具方面的支持。

ESB的本质

esb本质上是以中间件形式支持服务单元之间进行交互的软件平台。各种程序组件以标准的方式连接在该"总线"上，并且组件之间能够以格式统一的消息通信的方式来进行交互。

ESB环境中组件之间的交互过程

首先由服务请求者触发一次交互过程，产生一个服务请求消息，并将该消息按照esb的要求标准化，然后标准化的消息被发送给服务总线。esb根据请求消息中的服务名或者接口名进行目的组件查找，将消息转发至目的组件，并最终将处理结果逆向返回给服务请求者。这种交互过程不再是点对点的直接交互式，而是由事件驱动的消息交互模式。通过这种方式，esb最大限度上解耦了组件之间的依赖关系，降低了软件系统互连的复杂性。

ESB的核心功能

1)提供位置透明性的消息路由和寻址服务。

2)提供服务注册和命名的管理功能

3)支持多种消息传递范型（如请求/响应，发布/订阅等）.

4)支持多种可以广泛使用的传输协议。

5)支持多种数据格式及其相互转换。

6)提供日志和监控功能

SOA的设计模式

服务注册表模式

企业服务总线模式

微服务模式

微服务

微服务是一种软件架构风格，在该架构中，一个应用程序被拆分成多个小型、独立的服务，这些服务通过轻量级的通信协议相互协作。每个服务都可以独立开发、测试、部署和扩展，可以使用不同的编程语言、技术栈和数据库。

微服务架构的优点

1. 独立开发和部署：每个微服务可以独立开发和部署，不会影响其他服务的运行。

2. 弹性和扩展性：由于每个微服务都是独立的，可以根据需求独立扩展或伸缩。

3. 技术多样性：微服务架构支持使用不同的编程语言、技术栈和数据库，可以选择最合适的技术来解决特定的问题。

4. 容错性和可恢复性：微服务之间的故障不会导致整个系统崩溃，只会影响到部分功能，提高系统的容错性和可恢复性。

微服务架构的缺点

1. 维护困难：微服务架构中的服务分布在多个节点上，需要处理分布式系统带来的复杂性，例如服务发现、消息传递、数据一致性等。

2. 服务间通信开销：由于微服务之间需要进行通信，因此会增加一定的网络开销和延迟。

3. 数据一致性难题：由于数据在不同的微服务之间分布，维护数据一致性变得更加复杂。需要采用一致性机制来保证数据的一致性。

4. 测试和监控复杂性：由于服务的数量增加，测试和监控变得更加复杂，需要付出更多的努力来确保系统的稳定性和质量。

设计SOA架构应注意的问题

控制SOA系统中服务粒度，通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。

SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。

选择SOA解决方案

在实施SOA之前，选择最佳的解决方案，是保证SOA实施成功的前提条件。总体来说，必须从以下三个方面进行选择。

1.尽量选择能进行全局规划的方案

实施SOA之前首先要对自己的系统做全面的评估，要有整体的规划，这也是实施soa最为基础的一步。

2.选择时充分考虑企业自身的需求

SOA具体实施的进度和资金投入一方面取决于企业对IT应用的沉淀，另一方面取决于实行SOA的目标层次。

3.从平台和实施等技术方面进行考察

在选择SOA产品和技术时，应该从平台的选择，实施方法与途径，供应商的选择三个方面进行考量。

业务流程分析

建立服务模型

1)自顶向下分解法

自上而下的领域分解方式从业务着手进行分析，选择端到端的业务流程进行逐层分解至业务活动，并对其间涉及的业务活动和业务对象进行变化分析。

2)业务目标分析法

通过关键性能指标分析来验证已有服务候选者以及发现遗漏的服务候选者，它的思想是这样的：从企业的业务目标出发，目标分解为子目标，子目标再分派给相关的服务来实现

3)自底向上分析法

通过建立已有系统所具有的功能模块目录列表，可以方便地发现那些在不同的系统中被重复实现的功能模块以及可以复用的功能模块，从而将这些模块包装成服务发布出来。

安全架构的设计理论与实践

常见的威胁/分类有哪些？

物理安全威胁：物理安全威胁是指对系统所用设备的威胁，如自然灾害、电源故障、操作系统引导失败或数据库信息丢失、设备被盗被毁造成数据丢失或信息泄露;

通信链路安全威胁：通信链路安全威胁是指在传输线路上安装窃听装置或对通信链路进行干扰;

网络安全威胁：网络安全威胁是指由于互联网的开放性、国际化的特点，人们很容易通过技术手段窃取互联网信息，对网络形成严重的安全威胁;

操作系统安全威胁：操作系统安全威胁是指对系统平台中的软件或硬件芯片中植入威胁，如“木马”和“陷阱门”、BIOS的万能密码;

应用系统安全威胁：应用系统安全威胁是指对于网络服务或用户业务系统安全的威胁，也受到“木马”和“陷阱门”的威胁;

管理系统安全威胁：管理系统安全威胁是指由于人员管理上疏忽而引发人为的安全漏洞，如人为的通过拷贝、拍照、抄录等手段盗取计算机信息。

常见的安全威胁有哪些？

安全架构的定义

安全架构是架构面向安全性方向上的一种细分，比如细分领域含有运维架构，数据库架构等。

三道安全防线

如果安全性体现在产品上，那么，通常的产品安全架构，安全技术体系架构和审计架构可组成三道安全防线

(1)产品安全架构：构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品。

(2)安全技术体系架构：构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施，安全工具和技术，安全组件与支持系统等，系统性地增强各产品的安全防御能力。

(3)审计架构：独立的审计部门或其所能提供的风险发现能力，审计的范围主要包括安全风险在内的所有风险。

安全架构的特性

安全架构应具备可用性，完整性和机密性等特性。

可用性（availaility)是指要防止系统的数据和资源丢失

完整性（lntegrit)是指要防止系统的数据和资源在未经授权情况下被修改

机密性（confdeniality)是指要防止系统的数据和资源在未授权的情况下被披露。

安全架构的范围

安全架构设计可以从安全技术的角度考虑，主要包括：身份鉴别，访问控制，内容安全，冗余恢复，审计响应，恶意代码防范和密码技术等。

安全模型的定义

安全模型是准确地描述安全的重要方面及其与系统行为的关系，安全策略是从安全角度为系统整体和构成它的组件提出基本的目标，它是一个系统的基础规范，使系统集成后评估它的基准。安全策略勾画出的安全目标，是宽泛、模糊而抽象的。而安全模型提供了实现目标应该做什么，不应该做什么，具有实践指导意义，它给出了策略的形式。

常见的五种安全模型

状态机模型(BLP)模型

状态机模型描述了一种无论处于何种状态都是安全的系统。它是用状态语言将安全系统描述成抽象的状态机，用状态变量表述系统的状态，用转换规则描述变量变化的过程。

Bell-IaPadula模型

Bell-IaPadula模型属于强制访问控制模型，以敏感度来划分安全级别。将数据划分为多安全级别与敏感度的系统，即多级安全系统。当主体和客体位于不同的安全级别时，主体对客体就存在一定的访问限制。通过该模型可保证信息不被不安全主体访问

bell-lapadula模型的安全规则如下：

(1)简单安全规则:安全级别低的主体不能读安全级别高的客体

(2)星属性安全规则:安全级别高的主体不能往低级别的客体写

(3)强星属性安全规则:不允许对另一级别进行读写：

(4)自主安全规则:使用访问控制矩阵来定义说明自由存取控制。其存取控制体现在内容相关和上下文相关。

Biba模型

biba模型跟bell-lapadula模型很相似，被用于解决应用程序数据的完整性问题。bell-lapadula使用安全级别,

这些安全级别用于保证敏感信息只被授权的个体所访问。biba模型不关心信息机密性的安全级别，因此它的访问控制不是建立在安全级别上，而是建立在完整性级别上。

完整性的三个目标

保护数据不被未授权用户更改

保护数据不被授权用户越权修改（未授权更改）

维持数据内部和外部的一致性

模型安全规则

biba模型能够防止数据从低完整性级别流向高完整性级别，其安全规则如下：

(1)星完整性规则:表示完整性级别低的主体不能对完整性级别高的客体写数据：

(2)简单完整性规则:表示完整性级别高的主体不能从完整性级别低的客体读取数据；

(3)调用属性规则:表示一个完整性级别低的主体不能从完整性级别高的调用程序或服务。

Clark-Wilson (CWM)模型

cwm模型实现了成型的事务处理机制，常用于银行系统中以保证数据完整性。

CWM的主要特征

(1)采用Subject/Program /0biject三元素的组成方式。Subject 要访问Object只能通过Program进行;

(2)权限分离原则:将要害功能分为有2个或多个Subject完成，防止已授权用户进行未授权的修改;

(3)要求具有审计能力(Auditing)。

ChineseWall模型

chinesewal模型是应用在多边安全系统中的安全模型。也就是说，是指通过行政规定和划分，内部监控，t系统等手段防止各部门之间出现有损客户利益的利益冲突事件。本模型最初为投资银行设计的，但也可应用在其他相似的场合。

模型的安全规则

chinesewall模型的访问客体控制的安全规则如下：

(1)与主体曾经访问过的信息属于同一公司数据集合的信息，即墙内信息可以访问；

(2)属于一个完全不同的利益冲突组的可以访问：

(3)主体能够对一个客体进行写的前提是主体未对任何属于其他公司数据集进行过访问。

模型举例

在一个企业投资顾问公司里，一个咨询师大部分是同时为若干个企业提供投资咨询服务的，该咨询师就掌握了他所服务的所有企业的全部信息，包括企业的内部机密信息。如果该咨询师所服务的若干企业中有两家企业是在同一行业内的竞争对手，那么我们可以联想到，该咨询师可能会在给一家企业提供咨询过程中，有意或者无意地透露一些自己知道的有关另一家竞争企业的内部信息，使得一方得到利益，另一方遭受损失，这就导致了利益冲突，这是chinesewal安全模型策略需要解决的首要问题。

安全技术体系架构

安全技术体系构框架是拥有信息技术系统的组织机构根据其策略的要求和风险评估的结果，参考相关技术体系构架的标准和最佳实践，结合组织机构信息技术系统的具体现状和需求，建立的符合组织机构信息技术系统战略发展规划的信息技术系统整体体系框架。

信息技术系统分析模型

信息系统安全体系规划

信息系统安全体系主要是由技术体系，组织机构体系和管理体系三部分共同构成的。

技术体系是全面提供信息系统安全保护的技术保障系统，该体系由物理安全技术和系统安全技术两大类构成。

组织体系是信息系统的组织保障系统，由机构，岗位和人事三个模块构成。

机构分为领导决策层，日常管理层和具体执行层：
岗位是信息系统安全管理部门根据系统安全需要设定的负责某一个或某几个安全事务的职位：
人事是根据管理机构设定的岗位，对岗位上在职，待职和离职的员工进行素质教育，业绩考核和安全监管的机构。

管理体系由法律管理、制度管理和培训管理三部分组成。

信息系统安全规划框架

信息化战略规划是以整个企业的发展目标、发展战略和企业各部门的业务需求为基础，结合行业信息化方面的需求分析、环境分析和对信息技术发展趋势的掌握，定义出企业信息化建设的远景、使命、目标和战略，规划出企业信息化建设的未来架构，为信息化建设的实施提供一幅完整的蓝图，全面系统地指导企业信息化建设的进程。

信息系统安全规划依托企业信息化战略规划，对信息化战略的实施起到保驾护航的作用。信息系统安全规划的目标应该与企业信息化的目标是一致的，而且应该比企业信息化的目标更具体明确、更贴近安全。信息系统安全规划的一切论述都要围绕着这个目标展开和部署。

PDRR模型的定义

在PDRR模型中，安全的概念己经从信息安全扩展到了信息保障，信息保障内涵已超出传统的信息安全保密，它是保护（protect),检测（detect),反应（react),恢复（restore)的有机结合，称为PDRR模型。PDRR模型把信息的安全保护作为基础，将保护视为活动过程，要用检测手段来发现安全漏洞，及时更正，同时采用应急响应措施对付各种入侵，在系统被入侵后，要采取相应的措施将系统恢复到正常状态，这样才能使信息的安全得到全方位的保障。该模型强调的是自动故障恢复能力。

WPDRRC信息安全模型

定义

WPDRRC信息安全模型是我国八六三"信息安全专家组提出的适合中国国情的信息系统安全保障体系建设模型。WPDRRC是在PDRR信息安全体系模型的基础上前后增加了预警和反击功能。

wpdrrc模型的6个环节和3大要素

wpdrrc模型的3大要素

3大要素包括：人员，策略和技术。人员是核心，策略是桥梁，技术是保证，落实在wpdrrc的6个环节的各个方面，将安全策略变为安全现实。

wpdrrc模型的6个环节

预警：预警主要是指利用远程安全评估系统提供的模拟攻击技术来检查系统存在的、可能被利用的薄弱环节，收

集和测试网络与信息的安全风险所在，并以直观的方式进行报告，提供解决方案的建议

保护/防护：保护/防护通常是通过采用成熟的信息安全技术及方法来实现网络与信息的安全。主要内容有加密机制，数字签名机制，访问控制机制，认证机制，信息隐藏和防火墙技术等。

检测：检测通过检测和监控网络以及系统，来发现新的威胁和弱点，强制执行安全策略。

响应：响应是指在检测到安全漏洞和安全事件之后必须及时做出正确的响应，从而把系统调整到安全状态。

恢复：恢复灾难恢复系统是当前网络，数据，服务受到黑客攻击并遭到破坏或影响后，通过必要技术手段，在尽可能短的时间内使系统恢复正常。

反击：反击是指采用一切可能的高新技术手段，侦察，提取计算机犯罪分子的作案线索与犯罪证据，形成强有力的取证能力和依法打击手段。

系统安全保障体系

安全保障体系是由安全服务，协议层次和系统单元等三个层面组成，且每个层都涵盖了安全管理的内容。

系统安全保障体系设计工作主要考虑以下几点：

(1)安全区域策略的确定：根据安全区域的划分，主管部门应制定针对性的安全策略。如定时审计评估，安装入侵检测系统，统一授权，认证等；

(2)统一配置和管理防病毒系统：主管部门应当建立整体防御策略，以实现统一的配置和管理。网络防病毒的策略应满足全面性，易用性，实时性和可扩展性等方面要求；

(3)网络安全管理：在网络安全中，除了采用一些技术措施之外，加强网络安全管理，制定有关规章制度。在安全管理中，任何的安全保障措施，最终要落实到具体的管理规章制度以及具体的管理人员职责上，并通过管理人员的工作得到实现。

信息安全体系架构从哪五个方面分析和设计

具体在安全控制系统，我们可以从物理安全，系统安全，网络安全，应用安全和管理安全等5个方面开展分析和设计工作。

1)物理安全

保证计算机信息系统各种设备的物理安全是保障整个网络系统安全的前提。物理安全是保护计算机网络设备，设施以及其他媒体免受地震，水灾，火灾等环境事故以及人为操作失误或错误及各种计算机犯罪行为导致的破坏过程。

2)系统安全

系统安全主要是指对信息系统组成中各个部件的安全要求。系统安全是系统整体安全的基础。

3)网络安全

网络安全是整个安全解决方案的关键。它主要包括：访问控制，通信保密，入侵检测，网络安全扫描系统和防病毒等。

4)应用安全

应用安全主要是指多个用户使用网络系统时，对共享资源和信息存储操作所带来的安全问题。

5)安全管理

安全管理主要体现在三个方面。其一是制定健全的安全管理体制。其二是构建安全管理平台。其三是增强人

员的安全防范意识。

一种面向企业的安全控制系统安全架构设计

从图18-14中可以看出，给架构采用了传统的层次化结构，分为数据层，功能层和展现层。

数据层主要对企业数据进行统一管理，按数据的不同安全特性进行存储，隔离与保护等，功能层是系统安全防范的主要核心功能，包括可信性监控，服务支持和安全性监控。可信性监控主要实现网络安全，系统安全和应用安全中的监控能力，服务支持主要针对安全管理功能而设计的，实现安全管理平台的大多数功能，安全性监控主要针对系统中发现的任何不安全现象进行相关处理，涵盖了威胁追溯，安全域审计评估，授权，认证等，以及风险分析与评估等，展现层主要完成系统安全架构的使用，维护，决策等功能的实现

OSI安全体系结构能提供啥

(1)提供安全服务与有关安全机制在体系结构下的一般描述，这些服务和机制必须是为体系结构所配备的。

(2)确定体系结构内部可以提供这些服务的位置。

(3)保证安全服务完全准确地得以配置，并且在信息系统的安全周期中一直维持，安全功能务必达到一定强度的要求。

OSI安全架构

OSI安全架构(7层协议)

OSI（Open Systems Interconnection）安全架构是基于OSI参考模型的一种安全框架，它涵盖了OSI模型的所有七个层次。每个层次都有特定的安全机制和协议来保护数据的机密性、完整性和可用性。

以下是OSI安全架构的七个层次及其相关安全机制：

1. 物理层：物理层主要关注传输介质的安全性，如电缆的保护、防止窃听和干扰等。

2. 数据链路层：数据链路层通过MAC地址和帧检查序列（FCS）来确保数据在链路上的完整性和准确性。它还可以使用技术如VLANs和802.1X来实现访问控制和身份验证。

3. 网络层：网络层主要关注IP数据包的安全性。它包括IPSec协议，用于加密和认证IP数据包，以及虚拟专用网络（VPN）技术，用于建立安全的远程连接。

4. 传输层：传输层提供端到端的数据传输和可靠性。在安全方面，它可以使用传输层安全协议（TLS/SSL）来加密和认证数据传输。

5. 会话层：会话层主要关注建立、管理和终止会话。在安全方面，它可以使用安全套接字层（SSL）协议来确保会话的机密性和完整性。

6. 表示层：表示层负责数据的格式转换和加密。它可以使用加密算法和数据压缩技术来保护数据的机密性和减少传输带宽。

7. 应用层：应用层提供了用户与网络服务的接口。在安全方面，应用层可以使用安全套接字层（SSL）协议或其他安全协议来保护应用程序数据的安全性。

总的来说，OSI安全架构提供了一套综合的安全机制和协议，用于保护数据在不同层次的传输和处理过程中的安全性。每个层次都有特定的安全措施，以确保数据的机密性、完整性和可用性。

鉴别

鉴别的目的

鉴别（authcntication)的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。

鉴别的主要方式

(1)已知的，如一个秘密的口令

(2)拥有的，如ic卡，令牌等

(3)不改变的特性，如生物特征

(4)相信可靠的第三方建立的鉴别（递推）

(5)环境（如主机地址等）

鉴别服务分为几个阶段

鉴别服务分为以下阶段：安装阶段，修改鉴别信息阶段，分发阶段，获取阶段，传送阶段，验证阶段、停活阶段、重新激活阶段、取消安装阶段。

在安装阶段，定义申请鉴别信息和验证鉴别信息。
修改鉴别信息阶段，实体或管理者申请鉴别信息和验证鉴别信息变更（如修改口令）
在分发阶段，为了验证交换鉴别信息，把验证鉴别信息分发到各实体（如申请者或验证者）以供使用。
在获取阶段，申请者或验证者可得到为别实例生成特定交换鉴别信息所需的信息，通过与可信第三方进行交互或鉴别实体间的信息交换可得到交换鉴别信息。例如，当使用联机密钥分配中心时，申请者或验证者可从密钥分配中心得到一些信息如鉴别证书。
在传送阶段，在申请者与验证者之间传送交换鉴别信息。
在验证阶段，用验证鉴别信息核对交换鉴别信息。
在停活阶段，将建立一种状态，使得以前能被别的实体暂时不能被鉴别。
在重新激活阶段，使在停活阶段建立的状态将被终止。
在取消安装阶段，实体从实体集合中被拆除。

访问控制框架

机密性框架

完整性框架

抗抵赖框架

数据库的完整性

定义

数据库完整性是指数据库中数据的正确性和相容性。数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。数据库完整性约束可以通过dbms或应用程序来实现，基于dbms的完整性约束作为模式的一部分存入数据库中。

数据库完整性设计原则

在实施数据库完整性设计时，需要把握以下基本原则

(1)根据数据库完整性约束的类型确定其实现的系统层次和方式，并提前考虑对系统性能的影响。一般情况下，静态约束应尽量包含在数据库模式中，而动态约束由应用程序实现。

(2)实体完整性约束，引用完整性约束是关系数据库最重要的完整性约束，在不影响系统关键性能的前提下需尽量应用。用一定的时间和空间来换取系统的易用性是值得的。

(3)要慎用目前主流dbms都支持的触发器功能，一方面由于触发器的性能开销较大：另方面，触发器方面，触发器的多级触发难以控制，容易发生错误，非用不可时，最好使用befor型语句级触发器。

(4)在需求分析阶段就必须制定完整性约束的命名规范，尽量使用有意义的英文单词，缩写词，表名，列名及下画线等组合，使其易于识别和记忆

(5)要根据业务规则对数据库完整性进行细致的测试，以尽早排除隐含的完整性约束间的冲突和对性能的影响。

(6)要有专职的数据库设计小组，自始至终负责数据库的分析，设计，测试，实施及早期维护。数据库设计人员不仅负责基于dbms的数据库完整性约束的设计实现，还要负责对应用软件实现的数据库完整性约束进行审核。

(7)应采用合适的case工具来降低数据库设计各阶段的工作量。好的case工具能够支持整个数据库的生命周期，这将使数据库设计人员的工作效率得到很大提高，同时也容易与用户沟通

数据库完整性的作用

(1)数据库完整性约束能够防止合法用户使用数据库时向数据库中添加不合语义的数据。

(2)利用基于dbms的完整性控制机制来实现业务规则，易于定义，容易理解，而且可以降低应用程序的复杂性，提高应用程序的运行效率。同时，基于dbms的完整性控制机制是集中管理的，因此比应用程序更容易实现数据库的完整性。

(3)合理的数据库完整性设计，能够同时兼顾数据库的完整性和系统的效能。例如装载大量数据时，只要在装载之前临时使基于dbms的数据库完整性约束失效，此后再使其生效，就保证既不影响数据装载的效率又能保证数据库的完整性。

(4)在应用软件的功能测试中，完善的数据库完整性有助于尽早发现应用软件的错误。

(5)数据库完整性约束可分为6类：列级静态约束，元组级静态约束，关系级静态约束列级动态约束，元组级动态约束和关系级动态约束。动态约束通常由应用软件来实现。

完整性约束有哪些

软件脆弱性

定义

软件脆弱性是指由软件缺陷的客观存在所形成的一个可以被攻击者利用的实例，每个脆弱性都由至少一个软件缺陷引起，但是一个软件缺陷也可能不产生任何脆弱性，而且不同的软件缺陷可能导致相同的脆弱性。软件脆弱性就是软件规范，开发或配置中错误的实例，其执行结果将会违反安全策略。

在软件开发过程中，软件脆弱性包含什么

在软件开发过程中，软件脆弱性包含了软件基础模型的脆弱性，软件架构设计的脆弱性，软件模块设计的脆弱性，软件接口设计的脆弱性，软件界面设计的脆弱性，数据库设计的脆弱性，架构模式和设计模式的脆弱性以及实现的脆弱性等

软件脆弱性的特点

(1)脆弱性是软件系统中隐藏的一个弱点，本身不会引起危害，但被利用后会产生严重的安全后果

(2)在软件开发过程中，自觉或不自觉引入的逻辑错误是大多数脆弱性的根本来源：

(3)与具体的系统环境密切相关，系统环境的任何差异都有可能导致不同的脆弱性问题；

(4)旧的脆弱性得到修补或纠正的同时可能引入新的腌弱性，因此脆弱性问题会长期存在。

软件脆弱性分类

软件脆弱性可以从不同视角进行分类，比较典型的分类法有：isos分类法，pa分类法，andwehr分类法，aslam分类法，bishop分类法和ibm分类法。

isos分类法主要是面向信息系统的安全和隐私方面分类的，其目的是帮助信息系统管理人员理解安全问题，并为提高系统安全性提供相应信息。

pa分类法主要研究操作系统中与安全保护相关的缺陷，其目标是希望能够让缺乏计算机安领域知识的人可以利用模式指导的方法来发现计算机安全问题。

landwehr分类法是美国海军研究室在搜集和分析了不同操作系统中的50余个软件安全缺陷的基础上，提出了基于缺陷的起因（有意的或无意的）,引入的时间（开发阶段，维护阶段或者运行阶段）和分布的位置（软件或硬件）三个维度的分类。对于每个维度，可以更细致地多层次分类和描述，并从不同角度给出缺陷分布图。

aslam分类法是针对uni操作系统中的安全故障，从软件生命周期的角度将其分为编码故障和突发故障两大类。为了实现分类过程的自动化和无歧义化，分类法为每个特定的类别设计了一系列问题，构成了判断相应类别的决策树。

bishop分类法是针对信息安全领域的一种分类方法，它描述了一种针对uni和网络相关脆弱性的分类方法，bishop分类法使用6个轴线来对脆弱性进行分类。这6个轴线分别是脆弱性的性质，引入时间，利用率，影响域，最小数量和来源。

ibm分类法是以landwehr分类法为分类框架的基础，以新出现的安全缺陷对其进行扩充和改造以适应现今脆弱性的变化。该分类法采用多层次的分类，面向脆弱性检测工具的开发人员，并融合了脆弱性，安全威胁，攻击以及检测方法等。

软件脆弱性的生命周期

软件脆弱性的生命周期，它包含了引入，产生破坏效果，被修补和消失等阶段。

脆弱性的引入阶段（引入软件脆弱性的原因）：

(1)输入验证错误；

(2)权限检查错误：

(3)操作序列化错误

(4)边界检出错误；

(5)软件设计时的缺陷：

(6)其他错误。

产生破坏效果节段：

(1)非法执行代码；

(2)非法修改目标对象：

(3)访问数据对象；

(4)拒绝服务攻击。

修补阶段：

(1)删除伪造实体（如p伪造，名字伪造等）;

(2)增加新的实体：

(3)写该实体不正确的位置：

(4)其他情况。

软件脆弱性可以从哪些方面去分析

(1)分析软件故障现象，分析故障的技术本质、总结脆弱性模式;

(2)分析软件开发，发现安全管理和技术的薄弱环节，提高软件安全性;

(3)分析软件使用，发现其脆弱性，采取相应措施，避免脆弱性转化为安全故障。

大数据架构设计理论与实践

大数据处理系统面临的挑战

1.如何利用信息技术等手段处理非结构化和半结构化数据

2如何探索大数据复杂性，不确定性特征描述的刻画方法及大数据的系统建模

3.数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响

大数据处理系统的属性/特征

1.鲁棒性和容错性

2.低延迟读取和更新能力

3.横向扩容

4.通用性

5.延展性

6,即席查询能力

7.最少维护能力

8.可调试性

Lambda架构

定义

Lambda是用于同时处理离线和实时数据的，可容错的，可扩展的分布式系统。它具备强鲁棒性，提供低延迟和持续更新。

优缺点

优点

(1)容错性好。lambda架构为大数据系统提供了更友好的容错能力，一旦发生错误，我们可以修复算法或从头开始重新计算视图。

(2)查询灵活度高。批处理层允许针对任何数据进行临时查询。

(3)易伸缩。所有的批处理层、加速层和服务层都很容易扩展。因为它们都是完全分布式的系统，我们可以通过增加新机器来轻松地扩大规模。

(4)易扩展。添加视图是容易的，只是给主数据集添加几个新的函数。

缺点

(1)全场景覆盖带来的编码开销。

(2)针对具体场景重新离线训练一遍益处不大。

3)重新部署和迁移成本很高。

应用场景

1.机器学习中的lambda架构

2.物联网的lambda架构

3.流处理和lambda架构挑战

Lambda的体系结构

lambda架构可分解为三层，即批处理层，加速层和服务层。

(1)批处理层（batchlayer):存储数据集，批处理层在数据集上预先计算查询函数，并构建查询所对应的view，批处理层可以很好地处理离线数据，但有很多场景数据是不断实时生成且需要实时查询处理，对于这种情况，加速层更为适合。

(2)加速层（speedlayer):批处理层处理的是全体数据集，而加速层处理的是最近的增量数据流。加速层为了效率，在接收到新的数据后会不断更新real-time view,而批处理层是根据全体离线数据集直接得到batch view.

(3)服务层（servinglayer):服务层用于合并batch view和real-ime view中的结果数据集到最终数据集

Lambda架构将数据处理分解为Batch Layer和Speed Layer的优点

Kappa架构

Kappa架构的定义

kappa只会通过流计算一条的数据链路计算并产生视图。kappa同样采用了重新处理事件的原则，对于历史数据分析类的需求，kappa要求数据的长期存储能够以有序日志流的方式重新流入流计算引擎，重新产生历史数据的视图。本质上是通过改进lamba架构中的加速层，使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据。

kappa架构的原理

在lambda的基础上进行了优化，删除了批处理层的架构，将数据通道以消息队列进行替代。因此对于kappa架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次则可

Kappa的应用场景

从使用场景上来看，kappa架构与lambda相比，主要有两点区别：
(1)kappa不是lambda的替代架构，而是其简化版本，kappa放弃了对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求，例如各种时序数据场景，天然存在时间窗口的概念，流式计算直接满足其实时计算和历史补偿任务需求；
(2)lambda直接支持批处理，因此更适合对历史数据分析查询的场景，比如数据分析师需要按任意条件组合对历史数据进行探索性的分析，并且有一定的实时性需求，期望尽快得到分析结果，批处理可以更直接高效地满足这些需求。

Kappa的优缺点

kappa架构的优点

在于将实时和离线代码统一起来，方便维护而且统一了数据口径的问题。避免了lambda架构中与离线数据合并的问题，查询历史数据的时候只需要重放存储的历史数据即可。

kappa的缺点
(1)消息中间件缓存的数据量和回溯数据有性能瓶颈。通常算法需要过去180天的数据，如果都存在消息中间件，无疑有非常大的压力。同时，一次性回溯订正180天级别的数据，对实时计算的资源消耗也非常大。
(2)在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失。
(3)kappa在抛弃了离线数据处理模块的时候，同时抛弃了离线计算更加稳定可靠的特点。