一、信息系统架构设计理论与实践
1、信息系统架构概述和分类
信息系统架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
信息系统架构分为物理结构 与逻辑结构两种：
● 物理结构是指不考虑系统各部分的实际工作与功能结构，只抽象地考察其硬件系统的空间分布情况。
● 逻辑结构是指信息系统各种功能子系统的综合体。
（1）信息系统物理结构
按照信息系统硬件在空间上的拓扑结构，其物理结构分为两类：
◆ 集中式：是指物理资源在空间上集中配置。优点是资源集中，便于管理，资源利用率较高。缺点是资源过于集中会造成系统的脆弱，一旦主机出现故障，会使整个系统瘫痪。
◆ 分布式：指通过网络把不同地点的计算机硬件、软件、数据等资源联系在一起，实现不同地点的资源共享。优点是系统扩展方便，安全性好，某个结点故障不会导致整个系统停止运行。缺点是系统管理的标准不易统一，协调困难，不利于整体资源的规划与管理。
（2）信息系统逻辑结构
信息系统的逻辑结构是其功能综合体和概念性框架。例如工厂的管理信息系统，从管理职能角度划分，包括供应、生产、销售、人事、财务等主要功能的信息管理子系统。一个完整的信息系统支持组织的各种功能子系统，使得每个子系统可以完成事务处理、操作管理、管理控制与战略规划等各个层次的功能。在每个子系统中可以有自己的专用文件，同时可以共用系统数据库中的数据，通过接口文件实现子系统之间的联系。
（3）信息系统常用的模型
信息系统常用的5种架构模型：
1.单机应用系统：指运行在单台物理机器上的独立应用程序。应用领域就是信息系统领域，也就是以数据处理为核心的系统。
2.两层/多层C/S：是信息系统中最常见的模式。这种模式下客户端和服务器间通过 TCP/UDP 进行请求和应答。常见的客户机/服务器形式有以下几种：
① 二层 C/S。这是一种胖客户端，主要是指前台客户端 + 后台数据库的形式。
② 三层 C/S 和 B/S
◆ 三层 C/S：前台客户端 + 后台服务端 + 后台数据库。
◆ 瘦客户端：前台界面和业务逻辑处理分离，前台客户端仅含前台界面。
◆三层 B/S：Web 浏览器 + Web 服务器 + 后台数据库。
B/S 本质是浏览器与服务器间采用基于 TCP/IP 或 UDP 的 HTTP 协议。前台客户端与后台服务端通信协议有：TCP/IP 协议，基于 TCP/IP 协议通过 Socket 自定义实现协议，RPC 协议，CORBA/IIOP 协议，Java RMI 协议，J2EE JMS 协议，HTTP 协议。
③ 多层 C/S 和 B/S 结构
多层 C/S：是指三层以上的结构。形式是前台客户端 + 后台服务端 + 中间件/应用层 + 数据库，其中中间件/应用层的作用有以下几点：
◆ 提高并发性能和可伸缩性
◆ 请求转发，业务逻辑处理
◆ 增加数据安全性。
多层 B/S：是指三层以上的结构，形式是 Web 浏览器 + Web 服务器 + 中间件/应用层 + 数据库
3.MVC 结构
MVC 实际上是多层 C/S 结构的一种标准化模式。在 J2EE 架构中：
● View 视图层：指浏览器层，用于图形化展示请求结果。
● Controller 控制器：指 Web 服务器层。
● Model 模型层：指应用逻辑实现及数据持久化的部分。如 Struts+Spring+Hibernate（SSH）、JSP+Spring+Hibernate 等都是面向 MVC 架构的。
4.面向服务的架构SOA
SOA模型中，所有的功能都被定义成了独立的服务 ，所有的服务通过企业服务总线(ESB)或流程管理器来连接。这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统。
5.企业数据交换总线
企业数据交换总线，是不同的企业应用之间进行信息交换的公共通道。数据总线本身，其实质是一个可称之为连接器的软件系统（Connector），它可以基于中间件（如消息中间件或交易中间件）构建，也可以基于CORBA/IIOP协议开发，主要功能是按照预定义的配置或消息头定义，进行数据、请求或回复的接收与分发。
企业总线是企业应用间信息交换的公共通道，具有如下特征：
● 连接软件系统，主要提供服务代理功能和服务注册表。
● 按照协议消息头进行数据，请求，回复的接收和分发。
● 可以基于消息中间件，事务中间件，CORBA/IIOP 协议开发构建。
2、企业信息系统总体框架
信息系统的架构（ISA）模型应该是多维度、分层次、高度集成化的模型。要在企业中建立一个有效集成的ISA，必须考虑四方面：战略系统、业务系统、应用系统和信息基础设施。
（1）战略系统
战略系统是指企业中与战略制定、高层决策有关的管理活动和计算机辅助系统。战略系统由两个部分组成：以计算机为基础的高层决策支持系统企业的战略规划体系在ISA中设立战略系统有两重含义：
◆ 一是表示信息系统对企业高层管理者的决策支持能力；
◆ 二是表示企业战略规划对信息系统建设的影响和要求。
（2）业务系统
业务系统是指企业中完成一定业务功能的各部分（物质、能量、信息和人）组成的系统。如：生产系统、销售系统、采购系统、人事系统、会计系统等，每个业务系统由一些业务过程来完成该业务系统的功能。
（3）应用系统
应用系统即应用软件系统，指信息系统中的应用软件部分。企业信息系统中的应用软件（应用系统），一般按完成的功能可包含：事务处理系统TPS、管理信息系统MIS、决策支持系统DSS、专家系统ES、办公自动化系统OAS、计算机辅助设计/制造CAD/CAM等。
（4）企业信息基础设施
企业信息基础设施是指根据企业当前业务和可预见的发展趋势，及对信息采集、处理、存储和流通的要求，构筑由信息设备、通信网络、数据库、系统软件和支持性软件等组成的环境。
企业信息基础设施分成三部分：
◆ 技术基础设施：由计算机、网络、系统软件、支持性软件、数据交换协议等组成。
◆ 信息资源设施：由数据与信息本身、数据交换的形式与标准、信息处理方法等组成。
◆ 管理基础设施：企业中信息系统部门的组织结构、信息资源设施管理人员的分工、企业信息基础设施的管理方法与规章制度等。
3、信息系统架构设计方法
TOGAF是一种开放式企业架构标准 ，它为标准、方法论和企业架构专业人员之间的沟通提供一致性保障。
一备一中心八步一方法
ADM架构开发方法有3个级别的迭代：
① 基于ADM整体的迭代：用环形的方式来应用ADM方法，表明了在一个架构开发工作阶段完成后会直接进入随后的下一个阶段。
② 多个开发阶段间的迭代：例如在完成了技术架构阶段的开发工作后又重新回到业务架构开发阶段。
③ 在一个阶段内部的迭代：TOGAF支持基于一个阶段内部的多个开发活动，对复杂的架构内容进行迭代开发。
TOGAF反映了企业内部架构能力的结构和内容，TOGAF9版本包括六个组件：
①架构开发方法 ：是TOGAF的核心。它描述了TOGAF架构开发方法（ADM），即一种开发企业架构的分步方法。
②ADM指南和技术 ：这部分包含一系列可用于应用ADM的指南和技术。
③架构内容框架 ：这部分描述了TOGAF内容框架，包括架构工件的结构化元模型、可重用架构构建块（ABB）的使用以及典型架构可交付成果的概述。
④企业连续体和工具 ：这部分讨论分类法和工具，用于对企业内部架构活动的输出进行分类和存储。
⑤TOGAF参考模型 ：这部分提供了两个架构参考模型，即TOGAF技术参考模型（TRM）和集成信息基础设施参考模型（III-RM）。
⑥架构能力框架 ：这部分讨论在企业内建立和运营架构实践所需的组织、流程、技能、角色和职责。
架构开发方法（ADM）为开发企业架构所需要执行各个步骤以及它们之间的关系进行详细的定义，同时它也是 TOGAF 规范中最为核心的内容。ADM架构开发包括十个阶段：
(1) 预备阶段
为组织成功实施 TOGAF 项目做好准备。完成所需的准备和启动活动，以满足新的企业架构要面对的业务指示，包括定义组织机构、特定的架构框架、工具、定义原则等。
(2) 阶段A---架构愿景
在架构愿景阶段，将启动一次架构开发过程的迭代，设置迭代工作的范围、约束和期望创建架构愿景、验证业务上下文，创建架构工作说明书并取得大家的一致认可。愿景表达了我们对架构的期望结果，阐明重要涉众关注的问题和目标，可帮助团队关注架构的核心领域。
(3) 阶段B---业务架构
在业务架构阶段，将开发一个支持架构愿景的业务架构。架构愿景中概括的基线和目标业务架构将在此被细化，从而使它们可以作为技术分析的有效输入。本阶段的核心内容包括：
◆ 组织如何满足业务目标；
◆ 企业静态特征（业务目标、业务组织结构业务角色）；
◆ 企业动态特征（流程、功能、服务）。
(4) 阶段C---信息系统架构
在信息系统架构设计阶段，确定主要的信息类型和处理这些信息的应用系统。本阶段有两个主要的步骤，数据架构设计和应用架构设计，二者既可以依次开发，也可以并行开发。核心内容为：
◆ 信息系统如何满足企业的业务目标
◆ 信息以及信息之间的关系
◆ 应用以及应用之间的关系
(5) 阶段D---技术架构
在技术架构阶段，完成对系统基础服务设施的设计，定义了架构解决方案的物理实现，包括硬件、软件和通信技术。
(6) 阶段E---机会及解决方案
这是第一个直接关注实施的阶段，该阶段主要描述确定目标架构交付物（项目、程序或文件）的过程。
(7) 阶段F---迁移规划
该阶段通过制订一个详细的实现和迁移计划完成从基线架构向目标架构的转变。
(8) 阶段G---实施治理
该阶段定义了实施项目的架构约束，提供项目构建的架构监督，产生一个架构契约。
(9) 阶段H--架构变更管理
该阶段确保能够以一种可控制的方式对架构的改变进行管理。
(10) 需求管理
架构需求管理适用于ADM的所有阶段，是一个动态的过程，完成对企业需求的识别、存储并把它们插入或取出相应的ADM阶段。需求管理是ADM流程的中心。
4、信息化建设生命周期
信息系统建设生命周期的主要步骤包括：系统规划、系统分析、系统设计、系统实施和运行维护。
信息系统工程总体规划的方法论：
(1) 关键成功因素法(CSF)
在现行系统中，总存在着多个变量影响系统目标的实现，其中若干个因素是关键的和主要的（即关键成功因素）。通过对关键成功因素的识别，找出实现目标所需的关键信息集合，从而确定系统开发的优先次序。不同组织关键成功因素不同，不同时期关键成功因素也不相同。当在一个时期内的关键成功因素解决后，新的识别关键成功因素又开始。
(2) 战略目标集转化法(SST)
把整个战略目标看成是一个"信息集合"，由使命、目标、战略等组成，管理信息系统的规划过程即是把组织的战略目标转变成为管理信息系统的战略目标的过程。战略目标集转化法从另一个角度识别管理目标，它反映了各种人的要求，而且给出了按这种要求的分层，然后转化为信息系统目标的结构化方法。它能保证目标比较全面，疏漏较少但它在突出重点方面不如关键成功因素法。
(3) 企业系统规划法(BSP)
信息支持企业运行。通过自上而下地识别系统目标、企业过程和数据，然后对数据进行分析，自下而上地设计信息系统。企业系统规划法虽然也首先强调目标，但它没有明显的目标导引过程。它通过识别企业"过程"引出了系统目标，企业目标到系统目标的转化是通过企业过程/数据类等矩阵的分析得到的。
二、层次式架构设计理论与实践
1、层次式体系结构概述
层次式体系结构设计将系统组成一个层次结构，每一层为上层服务，并作为下层客户。内部的层接口只对相邻的层可见，每一层最多只影响两层，只要给相邻层提供相同的接口，允许每层用不同的方法实现，为软件重用提供了强大的支持。
层次式架构也称N层架构模式，分成表现层(展示层)、中间层(业务层)、数据访问层(持久层)和数据层。
（1）分层架构的特点
✓ 分层架构的一个特性就是关注分离。
✓ 该层中的组件只负责本层的逻辑，组件的划分很容易明确组件的角色和职责，也比较容易开发、测试、管理和维护。
✓ 层次式体系结构是一个可靠的通用的架构，对很多应用来说，如果不确定哪种架构适合，可以用层次式架构作为一个初始架构。
（2）但设计时要注意 以下两点：---合理分层不多不少
①要注意污水池反模式。污水池反模式，就是请求流简单地穿过几个层，每层里面基本没有做任何业务逻辑，或者做了很少的业务逻辑。如果请求超过20%，则应该考虑让一些层变成开放的。
②需要考虑的是分层架构可能会让你的应用变得庞大。即使你的表现层和中间层可以独立发布，但它的确会带来一些潜在的问题，比如：分布模式复杂、健壮性下降、可靠性和性能的不足，以及代码规模的膨胀等。
2、表现层设计模式和思想
（1）MVC模式
MVC 强制地把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成了控制器、模型、视图三个核心模块。
①视图（View）：用户看到并与之交互的界面。视图向用户显示相关的数据，并接收用户输入的数据，但是它并不进行任何实际的业务处理。
②控制器（Controller）：接受用户的输入并调用模型和视图去完成用户的需求。该部分是用户界面与模型的接口。一方面它解释来自于视图的输入，将其解释成为系统能够理解的对象，同时它也识别用户动作，并将其解释为对模型特定方法的调用；另一方面，它处理来自于模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。
③模型（Model）：应用程序的主体部分。模型表示业务数据和业务逻辑。一个模型能为多个视图提供数据。由于同一个模型可以被多个视图重用，所以提高了应用的可重用性。
使用MVC模式来设计表现层，可以有以下的优点:
①允许多种用户界面的扩展
②易于维护
③功能强大的用户界面
④增加应用的可拓展性、强壮型（应为健壮性）、灵活性
（2）MVP模型
MVP模式中Model提供数据，View负责显示，Presenter/Controller负责逻辑的处理。
MVP与MVC有一些显著的区别，MVC模式中允许View和Model直接进行"交流"，在MVP模式中是不允许的。在MVP中View并不直接使用Model，它们之间的通信是通过Presenter（MVC中的Controller）来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。
使用MVP模式来设计表现层，可以有以下的优点：
①模型与视图完全分离，可以修改视图而不影响模型。
②可以更高效地使用模型，因为所有的交互都发生在一个地方------Presenter内部。
③可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
④如果把逻辑放在Presenter中，就可以脱离用户接口来测试这些逻辑（单元测试）。
目前，MVP模式被更多地用在Android开发当中。
（3）MVVM模式
MVVM模式正是为解决MVP中UI种类变多，接口也会不断增加的问题而提出的。MVVM模式全称是模型-视图-视图模型（Model-View-ViewModel），它和MVC、MVP类似，主要目的都是为了实现视图和模型的分离，不同的是MVVM中，View与Model的交互通过ViewModel来实现。ViewModel是MVVM的核心，它通过DataBinding实现View与Model之间的双向绑定，其内容包括数据状态处理、数据绑定及数据转换。例如，View中某处的状态和Model中某部分数据绑定在一起，这部分数据一旦变化将会反映到View层。而这个机制通过ViewModel来实现。------（如view中的数据变化）
ViewModel，即视图模型，是一个专门用于数据转换的控制器，它可以把对象信息转换为视图信息，将命令从视图携带到对象。View和ViewModel之间使用DataBinding及其事件进行通信。View的用户接口事件仍然由View自身处理，并把相关事性映射到ViewModel，以实现View中的对象与视图模型内容的同步，且可通过双向数据绑定进行更新。
（4）动态生成设计思想
基于XML的界面管理技术可实现灵活的界面配置、界面动态生成和界面定制。其思路是用XML生成配置文件及界面所需的元数据，按不同需求生成界面元素及软件界面。
基于XML界面管理技术，包括界面配置、界面动态生成和界面定制三部分。
➢ 界面配置 是对用户界面的静态定义，通过读取配置文件的初始值对界面配置。由界面配置对软件功能进行裁剪、重组和扩充，以实现特殊需求。
➢ 界面定制 是对用户界面的动态修改过程，在软件运行过程中，用户可按需求和使用习惯对界面元素（如菜单、工具栏、键盘命令）的属性（如文字、图标、大小和位置等）进行修改。软件运行结束，界面定制的结果被保存。
（5）UIP设计思想
UIP是微软社区开发的众多Application Block中的其中之一，它是开源的。UIP提供了一个扩展的框架，用于简化用户界面与商业逻辑代码的分离的方法，可以用它来写复杂的用户界面导航和工作流处理，并且它能够复用在不同的场景并可以随着应用的增加而进行扩展。
UIP框架把表现层分为了以下二层：
◆ User Interface Components：这个组件就是原来的表现层，用户看到的和进行交互都是这个组件，它负责获取用户的数据并且返回结果。
◆ User Interface Process Components：这个组件用于协调用户界面的各部分，使其配合后台的活动，例如导航和工作流控制，以及状态和视图的管理。
3、中间层架构设计
（1）业务逻辑层组件设计
业务逻辑层组件分为接口和实现类两个部分。接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法是整个系统运行的核心。通常按模块来设计业务逻辑组件，每个模块设计一个业务逻辑组件，并且每个业务逻辑组件以多个 DAO（Data Access Object）组件作为基础，从而实现对外提供系统的业务逻辑服务。
（2）业务逻辑的内容
✔ 领域实体：定义了业务中的对象，对象有属性和行为；
✔ 业务规则：定义了需要完成一个动作，必须满足的条件；
✔ 数据完整性：某些数据不可少；
✔ 工作流：业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。
（3）业务逻辑层工作流设计
工作流管理联盟（Workow Management Coalition）将工作流定义为：业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。
（4）业务逻辑层实体设计
逻辑层实体提供对业务数据及相关功能（在某些设计中）的状态编程访问。业务逻辑层实体可以使用具有复杂架构的数据来构建，这种数据通常来自数据库中的多个相关表。业务逻辑层实体数据可以作为业务过程的部分 I/O 参数传递。业务逻辑层实体可以是可序列化的，以保持它们的当前状态。
（5）业务逻辑层框架
业务框架位于系统架构的中间层，是实现系统功能的核心组件。采用容器的形式，便于系统功能的开发、代码重用和管理。在业务容器中，业务逻辑是按照 Domain Model-Service-Control 思想来实现的。其中：
◆ Domain Model 是领域层业务对象，它仅仅包含业务相关的属性。
◆ Service 是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。
◆ Control 服务控制器，是服务之间的纽带，不同服务之间的切换就是通过它来实现的。通过服务控制器控制服务切换可以将服务的实现和服务的转向控制分离，提高了服务实现的灵活性和重用性。
4、数据访问层设计和架构规划
（1）在线访问
在线访问是最基本的数据访问模式。在线访问模式会占用一个数据库连接，读取数据，每个数据库操作都会通过这个连接不断地与后台的数据源进行交互。
在线访问方式的优点：
● 可以处理复杂的 Select 语句
● 性能比直接的 SQL要优越一些
在线访问方式的缺点：
● 业务对象和数据访问代码完全耦合在一起，代码混乱
● 修改维护上相对困难
● 开发程序员必须能看懂SQL语句
（2）DataAccess Object
DAO（数据访问对象）模式是标准J2EE设计模式之一，开发人员常常用这种模式将底层数据访问操作与高层业务逻辑分离开。业务对象应该关注的是业务逻辑，不应该关心数据存取的细节，DAO组件只对他的客户端暴露一些非常简单的DAO外部接口，而将数据源的实现细节对客户端完全的隐藏起来。
DAO提供了访问关系型数据库所需操作的接口，将数据访问和业务逻辑分离，对上层提供面向对象的数据访问接口。
优点 ：DAO设计模式可以减少代码量，增强程序的可移植性，提高代码的可读性。
典型的DAO实现包括以下组件：
● 一个DAO工厂类
● 一个DAO接口
● 一个实现了DAO接口的具体类
● 数据传输对象
（3）Data Transfer Object
DTO（数据传输对象）是这样一组对象或是数据的容器，它需要跨不同的进程或是网络的边界来传输数据。这类对象本身应该不包含具体的业务逻辑，与业务逻辑解耦。
（4）离线数据模式
离线数据模式是以数据为中心，数据从数据源获取之后，将按照某种预定义的结构存放在系统中，成为应用的中心。离线，对数据的各种操作独立于各种与后台数据源之间的连接或是事务；
XML集成，数据可以方便地与XML格式的文档之间互相转换；独立于数据源，离线数据模式的不同实现定义了数据的各异的存放结构和规则，这些都是独立于具体的某种数据源的。
（5）对象/关系映射（O/R Mapping）
对象/关系映射的基本思想来源于这样一种现实：多数应用的数据都是存在关系型数据库中，而这些应用程序中的数据在开发或是运行时是以对象的形式组织起来的，那么对象/关系映射就提供了这样一种工具或平台，能够将应用程序中的数据转换成关系型数据库中的记录，或是将关系数据库中的记录转换成应用程序中的代码便于操作的对象。
（6）数据访问层设计
1.工厂模式在数据访问层应用。工厂模式定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。这里可能会处理对多种数据库的操作，因此，需要首先定义一个操纵数据库的接口，然后根据数据库的不同，由类工厂决定实例化哪个类。
2.ORM，Hibernate 与 CMP2.0 设计思想。ORM（Object-Relation Mapping）在关系型数据库和对象之间作一个映射，这样，在具体操纵数据库时，就不需要再去和复杂的 SQL 语句打交道，只要像平时操作对象一样操作即可。Hibernate 是一个功能强大，可以有效地进行数据库数据到业务对象的 O/R 映射方案。Hibernate 推动了基于普通 Java 对象模型，用于映射底层数据结构的持久对象的开发。
3.XML Schema。用 XMLSchema 来描述 XML 文档合法结构、内容和限制，提供丰富的数据类型。
4.事务处理设计。事务必须服从 ISO/IEC 所制定的 ACID 原则。ACID 是原子性(Atomicity)、一致性(Consistency)、隔离性（Isolation）和持久性(Durability)的缩写。事务的原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。一致性表示当事务执行失败时，所有被该事务影响的数据都应该恢复到事务执行前的状态。隔离性表示在事务执行过程中对数据的修改，在事务提交之前对其他事务不可见。持久性表示已提交的数据在事务执行失败时，数据的状态都应该正确。 Java Bean使用JDBC方式进行事务处理。 Session Bean 中的JTA事务。
5.连接对象管理设计。建立一个数据库连接池，提供一套高效的连接分配、使用策略，保证了数据库连接的有效复用。
（7）数据架构规划与设计
⚡数据库设计与XML设计融合
①XML 文档分为两类：
● 以数据为中心的文档 ：这种文档在结构上是规则的，在内容上是同构的，具有较少的混合内容和嵌套层次，只关心文档中的数据而并不关心数据元素的存放顺序，这种文档简称为数据文档，常用来存储和传输Web数据。如XML文档包含销售数据、餐馆菜单。
● 以文档为中心的文档 ：这种文档的结构不规则，内容比较零散，具有较多的混合内容，并且元素之间的顺序是有关的，这种文档常用来在网页上发布描述性信息、产品性能介绍和E-mail信息等。
②XML文档的存储方式有两种：
◆ 基于文件的存储方式 ：基于文件的存储方式是指将XML文档按其原始文本形式存储。这种存储方式需维护某种类型的附加索引，以建立文件之间的层次结构。基于文件的存储方式的特点：
● 无法获取XML文档中的结构化数据；
● 通过附加索引可以定位具有某些关键字的XML文档，一旦关键字不确定，将很难定位；
● 查询时只能以原始文档的形式返回，即不能获取文档内部信息；
● 文件管理存在容量大、管理难的缺点。
◆ 数据库存储方式 ：数据库在数据管理方面具有管理方便、存储占用空间小、检索速度快、修改效率高和安全性好等优点。采用数据库对XML文档进行存取和操作，这样可以利用相对成熟的数据库技术处理XML文档内部的数据。数据库存储方式的特点：
● 能够管理结构化和半结构化数据；
● 具有管理和控制整个文档集合本身的能力；
● 可以对文档内部的数据进行操作；
● 具有数据库技术的特性，如多用户、并发控制和一致性约束等；
● 管理方便，易于操作。
5、层次式案例分析和物联网层次架构设计
①上图没有明显的数据访问层设计。这样的设计虽然提高了数据访问的性能，但也同时导致了业务逻辑层与数据访问的职责混乱。一旦要求支持的数据库发生变化，或者需要修改数据访问的逻辑，由于没有清晰的分层，会导致项目做大的修改。
②上图已经将数据访问逻辑作为单独的一层独立出来。
③上图性能上作了一定的改进，引入了缓存和异步处理机制，同时又充分利用了ASP.Net 2.0的新功能MemberShip。
④上图在数据访问层（DAL）中，仍然采用DAL Interface抽象出数据访问逻辑，并以DAL Factory作为数据访问层对象的工厂模块。对于DAL Interface而言，分别有支持MS-SQL的SQL Server DAL和支持Oracle的In Oracle DAL具体实现，而Model模块则包含了数据实体对象。
在数据访问层中，完全采用了"面向接口编程"思想。抽象出来的IDAL模块，脱离了与具体数据库的依赖，从而使得整个数据访问层有利于数据库迁移。
物联网层次架构：应用层、网络层、感知层
① 感知层
感知层用于识别物体、采集信息。感知层包括二维码标签和识读器、RFID标签和读写器、摄像头、GPS、传感器、M2M终端、传感器网关等，主要功能是识别对象、采集信息。
感知层解决的是数据获取问题。它首先通过传感器、数码相机等设备，采集外部物理世界的数据，然后通过RFID、条码、工业现场总线、蓝牙、红外等短距离传输技术传递数据。感知层的关键技术包括检测技术、短距离无线通信技术等。
② 网络层
网络层将感知层获取的信息进行传递和处理，数据可以通过移动通信网、互联网、企业内部网、各类专网、小型局域网进行传输。物联网的网络层是建立在现有的移动通信网和互联网基础上的。网络层的关键技术包括长距离有线和无线通信技术、网络技术等。
③ 应用层
应用层解决的是信息处理和人机交互问题。网络层传输来的数据在这一层进入各类信息系统进行处理，并通过各种设备与人进行交互。应用层分为两个子层：
● 应用程序层 ：进行数据处理，涵盖了国民经济和社会的每一领域，包括电力、医疗银行、交通、环保、物流、工业、农业、城市管理、家居生活等，是物联网作为深度信息化的重要体现。
● 终端设备层 ：提供人机接口。
例子：
三、云原生架构设计理论与实践
1、云原生概述和原则
（1）云原生架构定义
从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
（2）软件架构的目的
目的是帮助开发团队将关注点聚焦在业务代码的实现上。通常，开发软件系统，代码包含三部分内容：处理业务逻辑的代码、第三方依赖（和数据库建立连接和访问第三方交互数据）、处理非功能特性的代码。
（3）基于云原生架构的应用特点
①代码结构发生巨大变化：不再需要掌握文件及其分布式处理技术，不再需要掌握各种复杂的网络技术，简化让业务开发变得更敏捷、更快速。
②非功能性特性大量委托给云原生架构来解决：比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。
③高度自动化的软件交付：基于云原生的自动化软件交付可以把应用自动部署到成千上万的节点上。
（4）云原生架构原则
1.服务化原则
当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务（MiniService）架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁的模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。
2.弹性原则
弹性原则是指系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间，让企业不用操心额外软硬件资源的成本支出(闲置成本)，降低了企业的IT成本，更关键的是当业务规模面临海量突发性扩张的时候，不再因为平时软硬件资源储备不足而"说不"，保障了企业收益。
3.可观测原则
企业的软件规模在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、目前的故障影响哪些用户等问题，这些都要求系统具备更强的可观测能力。可观测性是在分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化------问题、原因、影响可观察。
4.韧性原则
业务上线后，最不能接受的就是业务不可用，影响体验和收入。韧性代表了当软件所依赖的软硬件组件出现异常时，软件表现出来的抵御能力，这些异常通常包括硬件故障、硬件资源瓶颈（如CPU/网卡带宽耗尽）、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件bug、黑客攻击等对业务不可用带来致命影响的因素。韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是降低软件的MTBF。从架构设计上，韧性包括服务异步化能力、重试 / 限流 / 降级 / 熔断 / 反压、主从模式、集群模式、AZ内的高可用、单元化、跨region容灾、异地多活容灾等，本质提高系统可靠性和可用性。
5.所有过程自动化原则
容器、微服务、DevOps、大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，因为整体增大了软件技术栈的复杂度和组件规模，所以不可避免地带来了软件交付的复杂性，如果这里控制不当，应用就无法体会到云原生技术的优势。通过IaC、GitOps、OAM、KubernetesOperator和大量自动化交付工具在CI/CD（如持续集成部署）流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
6.零信任原则
零信任安全核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，诸如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任引导安全体系架构从"网络中心化"走向"身份中心化"，其本质诉求是以身份为中心进行访问控制。零信任第一个核心问题就是身份，赋予不同的实体不同的身份，解决是谁在什么环境下访问某个具体的资源的问题。在研发、测试和运维微服务场景下，身份及其相关策略不仅是安全的基础，更是众多(资源、服务、环境)隔离机制的基础。
7.架构持续演进原则
云原生架构本身也必须是一个具备持续演进能力的架构，而不是一个封闭式架构。除了增量迭代、目标选取等因素外，还需要考虑组织(例如架构控制委员会)层面的架构治理和风险控制，特别是在业务高速迭代情况下的架构、业务、实现平衡关系。云原生架构对于新建应用而言的架构控制策略，相对容易选择(选择弹性、敏捷、成本的维度)，但对于存量应用向云原生架构迁移，则需要从架构上考虑遗留应用的迁出成本/风险和到云上的迁入成本/风险，以及技术上通过微服务/应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用和流量进行细颗粒度控制。
2、云原生涉及的主要架构模式
（1）服务化架构模式
服务化架构要求以应用模块为颗粒度划分一个软件，以接口契约（例如IDL）定义彼此业务关系，以标准协议（HTTP、gRPC等）确保彼此的互联通，结合DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。
服务化架构的典型模式是微服务和小服务模式，其中小服务可以看作是一组关系非常密切的服务的组合，这组服务会共享数据。
小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接口都可以单独升级，从而提升了整体的迭代效率。但也需要注意，服务拆分导致要维护的模块数量增多，如果缺乏服务的自动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。
（2）Mesh化架构模式
Mesh 化架构是把中间件框架（如 RPC、缓存、异步消息等）从业务进程中分离，让中间性SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，其至迁移到另外一个平台的中间件也对业务透明。分离后在业务进程中只保留很"薄"的 Client 部分，Client 通常很少变化，只负责与 Mesh 进程通信，原来需要在SDK 中处理的流量控制、安全等逻辑由Mesh进程完成。
实施Mesh化架构后，大量分布式架构模式（熔断、限流、降级、重试、反压、隔仓）都由Mesh 进程完成，即使在业务代码的制品中并没有使用这些三方软件包；同时获得更好的安全性（比如零信任架构能力）、按流量进行动态环境隔离、基于流量做冒烟/回归测试等。
（3）Serverless 模式
Serverless 将"部署"这个动作从运维中"收走"，使开发者不用关心应用运行地点、操作系统、网络配置、CPU 性能等，从架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发，也就是把应用的整个运行都委托给云。
Serverless 并非适用任何类型的应用，因此架构决策者需要关心应用类型是否适合于Serverless运算。如果应用是有状态的 ，由于Serverless 的调度不会帮助应用做状态同步，因此云在进行调度时可能导致上下文丢失；如果应用是长时间后台运行的密集型计算任务 ，会无法发挥 Serverless 的优势；如果应用涉及频繁的外部I/O(网络或者存储，以及服务间调用)，也因为繁重的I/O负担、时延大而不适合。
Serverless 非常适合于事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。
（4）存储计算分离模式
分布式环境中的 CAP 困难主要是针对有状态应用，由于 C（一致性）A（可用性）P（分区容错性）三者无法同时满足，最多满足其中两个。所以 无状态应用不存在 C（一致性）这个维度，可以获得很好的 A（可用性）和 P（分区容错性），因而获得更好的弹性。
（5）分布式事务模式
由于业务需要访问多个微服务，就会带来分布式事务问题，否则数据就会出现不一致。因此架构师需要根据不同的场景选择合适的分布式事务模式，常用的有：
✔ XA 模式：传统采用 XA 模式：由于 XA 规范是实现分布式事务处理的标准，通常采用 2PC（两阶段提交）的方法，具有很强的一致性，但是由于需要两次网络交互，所以性能差。
✔ 基于消息的最终一致性（BASE）：在可用性和一致性相冲突的情况下，为了权衡二者，BASE提出只要满足 BA（基本可用）和 E（最终一致性），接受数据的 S（软状态，未确定状态），来优先实现性能，所以这类系统通常具备很高的性能。但正是由于根据应用特点，选择可用性和一致性的妥协方案，导致通用性有限。
✔ TCC 模式：采用 try-confirm-cancel 二阶段模式，事务隔离性可控，高效，但需要应用代码将业务模型拆成二阶段，所以对业务侵入性强，设计开发维护等成本很高。
✔ SAGA 模式：每个正向事务都对应一个补偿事务，当正向事务执行失败，则会执行补偿事务进行回滚。所以开发维护成本高。
✔ 开源项目 SEATA 的 AT 模式：它将 TCC 模式中的二阶段委托给底层代码框架，并且取消了行锁，所以非常高性能且无代码开发工作量，且可以自动执行回滚操作，但存在一些使用场景限制。
（6）可观测架构
可观测架构包括 Logging、Tracing、Metrics，其中 Logging 提供多个级别跟踪，例如 INFO/ DEBUG/WARNING/ERROR；Tracing 收集一个请求从前端到后端的访问日志聚合，形成完整调用链路跟踪；Metrics 则提供对系统量化的多维度度量，包括并发度、耗时、可用时长、容量等。
（7）事件驱动架构
事件驱动架构(EDA，Event DrivenArchitecture)是一种应用/组件间的集成架构模式。适用于增强服务韧性、数据变化通知、构建开放式接口、事件流处理、CQRS（Command Query Responsibility Segregation，把对服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的 API 接口)等
（8）典型的云原生架构反模式
架构设计有时候需要根据不同的业务场景选择不同的方式，常见的云原生反模式有：
①庞大的单体应用：缺乏依赖隔离，代码耦合，责任和模块边界不清晰，模块间接口缺乏治理，变更影响扩散，不同模块间的开发进度和发布时间要求难以协调，一个子模块不稳定导致整个应用都变慢，扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容等。
②单体应用"硬拆"为微服务：强行把耦合度高、代码量少的模块进行服务化拆分；拆分后服务的数据是紧密耦合的；拆分后成为分布式调用，严重影响性能。
③缺乏自动化能力的微服务：人均负责模块数上升，人均工作量增大，也增加了软件开发成本。
3、云原生架构相关技术
（1）容器技术
容器作为标准化软件单元，它将应用及其所有依赖项打包，在运行的时候就不再依赖宿主机上的文件操作系统类型和配置。帮助开发者跳过设置冗杂的开发环境，不用担心不同环境下的软件运行的环境配置问题（将应用程序的配置和所有依赖打包成一个镜像在容器中）。在不同计算环境间快速、可靠地运行。
（2）容器编排K8S
Kubernetes已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用，是一个全新的基于容器技术的分布式架构解决方案。Kubernetes提供了分布式应用管理的核心能力。
✔ 资源调度：根据应用请求的CPU、Memory资源量，或者GPU等设备资源，在集群中选择合适的节点来运行应用。
✔ 应用部署与管理：支持应用的自动发布与应用的回滚，以及与应用相关的配置的管理；也可以自动化存储卷的编排，让存储卷与容器应用的生命周期相关联。
✔ 自动修复：Kubernetes能监测这个集群中所有的宿主机，当宿主机或者OS出现故障，节点健康检查会自动进行应用迁移；K8s也支持应用的自愈，极大简化了运维管理的复杂性。
✔ 服务发现与负载均衡：Service是对一组提供相同功能的Pods的抽象，并为它们提供一个统一的入口。借助Service，应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。。
✔ 弹性伸缩：K8s可以监测业务上所承担的负载，如果这个业务本身的CPU利用率过高，或者响应时间过长，它可以对这个业务进行自动扩容。
（3）微服务
微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为"微服务"，多个"微服务"共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。
微服务设计约束如下：
①微服务个体约束：微服务应用的功能在业务领域划分上应是相互独立的。
②微服务与微服务之间的横向关系：在合理划分好微服务间的边界后，从可发现性和可交互性处理微服务间的横向关系。可发现性是指当服务 A 发布和扩缩容的时候，依赖服务 A 的服务B 在不重新发布的前提下，能够自动感知到服务 A 的变化。可交互性是指服务 A 采用什么样的方式可以调用服务 B。
③微服务与数据层之间的纵向约束：提倡数据存储隔离（Data Storage Segregation，DSS）原则，对于数据的访问都必须通过相对应的微服务提供的 API 来访问。
④全局视角下的微服务分布式约束：高效运维整个系统，从技术上实现全自动化的 CI/CD 流水线满足对开发效率的诉求，并在这个基础上支持蓝绿、金丝雀等不同发布策略，以满足对业务发布稳定性的诉求。
主要的微服务技术：
✔ Apache Dubbo是阿里的一款高性能、轻量级的开源服务框架，提供了六大核心能力：面向接口代理的高性能RPC调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。
✔ Spring Cloud是一系列框架的有序集合，具有丰富的生态。它利用Spring Boot的开发便利性简化了分布式系统基础设施的开发，主要功能包括服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
例题：
（4）无服务器技术
无服务器技术的特点：
①全托管的计算服务------客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作；
②通用性------结合云BaaS（后端云服务）API的能力，能够支撑云上所有重要类型的应用；
③自动弹性伸缩------让用户无需为资源使用提前进行容量规划；
④按量计费------让企业使用成本得有效降低，无需为闲置资源付费。
无服务器技术关注点是：计算资源弹性调度（容错、资源利用率、性能、数据驱动）、负载均衡和流控、安全性。
（5）服务网格
服务网格(Service Mesh)是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。
服务网格把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以Sidecar的模式进行部署。服务网格通过将服务通信及相关管控功能从业务程序中分离并下沉到基础设施层，使其和业务系统完全解耦，使开发人员更加专注于业务本身。服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理组件组成。
✔ 管理组件被称为控制平面(Control plane)，负责与控制平面中的代理通信，下发策略和配置。
✔ 代理被称为数据平面(Data plane)，直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。Istio 是一个由Google和IBM等公司开源的，功能十分丰富的服务网格具体实现，也是目前业界最为流行的实现。Istio 的架构从逻辑上分成数据平面和控制平面。
✔ 数据平面：由一组和业务服务成对出现的 Sidecar 代理（Envoy）构成，主要功能是接管服务的进出流量，传递并控制服务和Mixer 组件的所有网络通信。
✔ 控制平面：包括了 Pilot、Mixer、Citadel 和Galley 4 个组件，主要功能是通过配置和管理 Sidecar 代理来进行流量控制，并配置Mixer 去执行策略和收集遥测数据。
服务网格旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。服务A调用服务B的所有请求，都被其下的服务代理截获，代理服务A完成到服务B的服务发现、熔断、限流等策略，而这些策略的总控是在控制平面（Control Plane）上配置。
服务网格的主要技术：Istio、Linkerd、Consul。
四、面向服务架构SOA设计理论与实践
1、SOA相关概念
（1）面向服务的架构(SOA)的定义
SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA是一种粗粒度、松耦合服务架构，标准化接口进行通信，不涉及底层编程接口和通信模型。
在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理，如下：
实施SOA的关键目标是实现企业IT资产重用的最大化，在实施SOA过程中要牢记以下特征：可从企业外部访问、随时可用（服务请求能被及时响应）、粗粒度接口（粗粒度提供一项特定的业务功能，而细粒度服务代表了技术构件方法）、服务分级、松散耦合（服务提供者和服务使用者分离）、可重用的服务及服务接口设计管理、标准化的接口（WSDL、SOAP、XML是核心）、支持各种消息模式、精确定义的服务接口。
从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。
| 服务 | 构件 | 对象 |
|---|---|---|
| 以服务为中心，进行业务功能的封装 | 构件粒度小一些比服务 服务>构件>对象 | 以对象为单位完成信息交互 |
| 以服务为单元，通过服务的组合完成应用集成 | 以对象为开发集成，工作流技术定制业务流 | |
| 接口是标准的一般为WSDL | 具体以API为表现形式 | 当业务发生变化的时候，需要修改代码与之相适应 |
| 语言无关性 | 需要绑定某种特定的语言 | |
| 通过构件同期提供Qos服务 | 完全由程序代码直接控制 |
（2）业务流程与BPEL
业务流程是指为了实现某种业务目的行为所进行的流程或一系列动作。在计算机领域，业务流程代表的是某一个问题在计算机系统内部得到解决的全部流程。
BPEL（面向Web服务的业务流程执行语言），是一种基于XML的用来描写业务过程的编程语言，被描写的业务过程的每个单一步骤则由Web服务来实现。使用BPEL，用户可以通过组合、编排和协调Web服务自上而下地实现面向服务的体系结构(SOA)。BPEL提供了一种相对简单易懂的方法，可将多个Web服务组合到一个新的复合服务（称作业务流程）中。两种方式组合Web服务 ：①编制、②编排
2、SOA参考架构
从服务为中心的视角来看，企业集成的架构划分为6大类：
①IT服务管理（IT Service Management）：支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。
②业务逻辑服务(Business Logic Service)：包括用于实现业务逻辑的服务和执行业务逻辑的能力，其中包括业务应用服务、业务伙伴服务以及应用和信息资产。
③连接服务(Connectivity Service)：通过提供企业服务总线提供分布在各种架构元素服务间的连接性。
④控制服务(Control Service)：包括实现人、流程和信息集成的服务，以及执行这些集成逻辑的能力。
⑤业务创新和优化服务(Business Innovation and Optimization Service)：用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。
⑥开发服务(Development Service)：贯彻整个软件开发生命周期的开发平台，从需求分析，到建模、设计、开发、测试和维护等全面的工具支持。
3、SOA主要协议和规范
WEB Service ：服务提供者、服务注册中心（中介，提供交易平台，可有可无）、服务请求者。服务提供者将服务描述发布到服务注册中心，供服务请求者查找，查找到后，服务请求者将绑定查找结果。如图：
服务注册表：
① 服务注册 ：应用开发者（服务提供者）在注册表中公布服务的功能。
② 服务位置 ：服务使用者（服务应用开发者），帮助他们查询注册服务，寻找符合自身要求的服务。
③ 服务绑定 ：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，以及与它们实现互动。
底层传输层、服务通信协议层、服务描述层、服务层、业务流程层、服务注册层
Web服务作为实现SOA中服务的最主要手段。Web服务最基本的协议包括UDDI、WSDL和SOAP，通过它们，可以提供直接而又简单的Web Service支持。
（1）UDDI协议
UDDI(统一描述、发现和集成协议)是一种用于描述、发现、集成Web Service的技术，它是Web Service协议栈的一个重要部分。通过UDDI，企业可以根据自己的需要动态查找并使用Web服务，也可以将自己的Web服务动态地发布到UDDI注册中心，供其他用户使用。
（2）WSDL规范
WSDL（Web服务描述语言）是一个用来描述Web服务和说明如何与Web服务通信的XML语言。也就是描述与目录中列出的Web服务进行交互时需要绑定的协议和信息格式。WSDL描述Web服务的公共接口。通过WSDL，可描述Web服务的三个基本属性：
① 服务做些什么--服务所提供的操作（方法）。
② 如何访问服务--和服务交互的数据格式以及必要协议。
③ 服务位于何处--协议相关的地址，如URL。
WSDL文档以端口集合的形式来描述Web服务，WSDL服务描述包含对一组操作和消息的一个抽象定义，绑定到这些操作和消息的一个具体协议，和这个绑定的一个网络端点规范。
WSDL文档被分为两种类型：服务接口和服务实现。
（3）SOAP协议
SOAP(简单对象访问协议)是在分散或分布式的环境中交换信息的简单协议，是一种轻量的、简单的、基于XML的协议。包括4部分：
● 封装(Envelop)：定义了一个框架，该框架描述了消息的内容是什么，是谁发送的，谁应当接收并处理以及如何处理它；
● 编码规则：定义了一种序列化的机制，用于表示应用程序需要使用的数据类型的实例；
● SOAP RPC表示：定义了用于表示远程过程调用和应答的协定；
● 绑定(Binding)：定义了SOAP使用哪种协议交换信息。HTTP/TCP/UDP协议都可以。
（4）REST规范
为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。微服务对外就是以RESTAPI形式暴露给调用者。RESTful即REST式的，是对遵循REST设计思想同时满足设计约束的一类架构设计或应用程序的统称，这一类都可称为RESTful，可以理解为资源表述性状态转移：
①资源 ：将互联网中一切暴露给客户端的事物都可以看作是一种资源。
②表述 ：REST中用表述描述资源在Web中某一个时间的状态。
③状态转移 ：分为两种，应用状态------对某个时间内用户请求会话相关信息的快照，保存在客户端。资源状态------在服务端保存，是对某个时间资源请求表述的快照。
④超链接 ：是通过在页面中嵌入链接和其他资源建立联系。
4、SOA的设计原则
SOA的设计原则如下：
(1) 无状态。避免服务请求者依赖于服务提供者的状态。
(2) 单一实例。避免功能冗余。
(3) 明确定义的接口。服务的接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界线。WS-Policy用于描述服务规约，XML模式用于定义所交换的消息格式(即服务的公共数据)。使用者依赖服务规约调用服务，所以服务定义必须长时间稳定，一旦公布，不能随意更改；服务的定义应尽可能明确，减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。
(4) 自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
(5) 粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用(RPC)，通常消息量比较大，但是服务之间的交互频度较低。
(6) 服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
(7) 重用能力。服务应该是可以重用的。
(8) 互操作性 、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，例如一个服务对安全性方面的要求；也可以是跟业务有关的语义方面的内容，例如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。WS-Policy用于定义可配置的互操作语义来描述特定服务的期望、控制其行为。在设计时，应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。
5、SOA的设计模式
（1）SOA设计标准要求
①文档标准化。SOA服务具有平台独立的自我描述XML文档。Web服务描述语言是用于描述服务的标准语言。
②通信协议标准。SOA服务用消息进行通信，该消息通常使用XML Shema来定义。
③应用程序统一登记与集成。在一个企业内部，SOA服务通过一个扮演目录列表（Directory Listing）角色的登记处(Registry)来进行维护。应用程序在登记处(Registry)寻找并调用某项服务。统一描述、定义和集成是服务登记的标准。
④服务质量（QoS）。主要包括：
◆ 可靠性：服务消费者和服务提供者之间传输文档时的传输特性（仅且仅仅传送一次、最多传送一次、重复消息过滤、保证消息传送）。
◆ 安全性：Web服务安全规范用来保证消息的安全性。
◆ 策略：服务提供者有时候会要求服务消费者与某种策略通信。例如，服务提供商可能会要求消费者提供Kerberos安全标示才能取得某项服务。
◆ 控制：在SOA中，进程是使用一组离散的服务创建的。BPEL4WS或者WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。
◆ 管理：针对运行在多种环境下的所有服务，必须有一个统一管理系统，以便系统管理员能够有效管理。任何根据WSDM实现的服务都可以由一个WSDM适应（WSDM - compliant）的管理方案来管理。
（2）服务注册表模式
服务注册表：主要在SOA设计时使用，虽然它们常常也具有运行时段的功能。注册表包括有关服务和相关软件组件的配置、遵从性和约束配置文件。任何帮助注册发现和检索服务合同、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个注册表。
① 服务注册 ：应用开发者（服务提供者）在注册表中公布服务的功能。
② 服务位置 ：服务使用者（服务应用开发者），帮助他们查询注册服务，寻找符合自身要求的服务。
③ 服务绑定 ：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，以及与它们实现互动。
（3）企业服务总线模式
企业服务总线（ESB），提供一种标准的软件底层架构，各种程序组件能够以服务单元的方式"插入"到该平台上运行，并且组件之间能够以标准的消息通信方式进行交互。
ESB本质上是以中间件形式支持服务单元之间进行交互的软件平台。各种程序组件以标准的方式连接在该"总线"上，并且组件之间能够以格式统一的消息通信的方式进行交互。
典型ESB环境中组件间的交互过程是：首先由服务请求者触发一次交互过程，产生一个服务请求消息，并将该消息按照ESB的要求标准化，然后标准化的消息被发送给服务总线。ESB根据请求消息中的服务名或者接口名进行目的组件查找，将消息转发至目的组件，并最终将处理结果逆向返回给服务请求者。这种交互过程不再是点对点的直接交互模式，而是由事件驱动的消息交互模式。通过这种方式，ESB最大限度上解耦了组件之间的依赖关系，降低了软件系统互连的复杂性。连接在总线上的组件无需了解其他组件和应用系统的位置及交互协议，只需要向服务总线发出请求，消息即可获得所需服务。
服务总线事实上实现了组件和应用系统的位置透明和协议透明。技术人员可以通过开发符合ESB标准的组件(适配器)将外部应用连接至服务总线，实现与其他系统的互操作。同时，ESB以中间件的方式，提供服务容错、负载均衡、QoS保障和可管理功能。
ESB的核心功能如下：
① 提供位置透明的消息路由和寻址服务。
② 提供服务注册和命名的管理功能。
③ 支持多种消息传递范型(如请求/响应、发布/订阅等)。
④ 支持多种可以广泛使用的传输协议。
⑤ 支持多种数据格式及其相互转换。
⑥ 提供日志和监控功能。
（4）微服务模式
微服务架构将一个大型的单个应用或服务拆分成多个微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。微服务架构围绕业务领域将服务进行拆分，每个服务可以独立进行开发、管理和迭代，彼此之间使用统一接口进行交流，实现了在分散组件中的部署、管理与服务功能，使产品交付变得更加简单，从而达到有效拆分应用，实现敏捷开发与部署的目的。
微服务的特点：
①复杂应用解耦：微服务架构将单一模块应用分解为多个微服务，同时保持总体功能不变。
②独立：微服务在系统软件生命周期中是独立开发、测试及部署的。
③技术选型灵活：微服务架构下系统应用的技术选型是去中心化的，每个开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术。
④容错：由于各个微服务相互独立，故障会被隔离在单个服务中，并且系统其他微服务可通过重试、平稳退化等机制实现应用层的容错，从而提高系统应用的容错性。
⑤松耦合，易扩展：微服务架构中每个服务之间都是松耦合的，可以根据实际需求实现独立扩展，体现微服务架构的灵活性。
SOA 与微服务的差异：
| SOA | 微服务 |
|---|---|
| 是整体的服务，所有服务放一起打包管理 | 能拆分就拆分 |
| 水平多层次性 | 纵向业务划分 |
| 按层次划分不同部门的组织责任 | 由单一的组织负责 |
| 粗粒度 | 细粒度 |
| 描述架构非常复杂 | 两句话就可以描述清楚 |
| 存在较复杂的组件 | 组件小 |
| 业务逻辑跨越多个业务领域 | 业务逻辑存在每个服务中 |
| 企业服务总线（ESB）充当了服务之间通信的角色 | 使用轻量级的通信方式，比如HTTP |
| 企业级，自上而下开展实施 | 团队级，自底向上开展实施 |
| 集成方式复杂（ESB/WS/SOAP） | 简单的集成方式（HTTP/REST/JSON） |
微服务架构模式方案 。主要包括：
①聚合器微服务：聚合器充当流程指挥者，调用多个微服务实现系统应用程序所需功能。
②链式微服务：客户端或服务在收到请求后，会发生多个服务间的嵌套递归调用，返回经过合并处理的响应。
③数据共享微服务：该模式适用于在单体架构应用到微服务架构的过渡阶段，服务之间允许存在强耦合关系，例如存在多个微服务共享缓存与数据库存储的现象。
④异步消息传递微服务：对于一些不必要以同步方式运行的业务逻辑，可以使用消息队列代替 REST 实现请求、响应，加快服务调用的响应速度。
微服务架构面临的问题与挑战：
①服务发现与服务调用链跟踪变得困难。
②很难实现传统数据库的强一致性，转而追求最终一致性。
（5）SOA应该注意的问题和解决方案
原有系统架构中的集成需求。包括：应用程序集成的需求、终端用户界面集成的需求、流程集成的需求以及已有系统信息集成的需求。
服务粒度的控制以及无状态服务的设计：
①服务粒度的控制：对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。
②无状态服务的设计：SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架中的服务应该是无状态的服务。
选择 SOA 解决方案。解决方案主要从以下三个方面选择：
①尽量选择能进行全局规划的方案。
②选择时充分考虑企业自身的需求。
③从平台、实施等技术方面进行考察。
业务流程分析。业务流程分析主要关注：
①建立服务模型：自顶向下分解法，业务目标分析法，自底向上分析法
②建立业务流程：建立业务对象（实体、过程、事件等业务对象）、建立服务接口、建立服务流程。
案例题：
例题：
五、嵌入式架构设计理论与实践
1、嵌入式系统概述
（1）发展历程
| 发展阶段 | 硬件 | 软件 | 主要特点 |
|---|---|---|---|
| SCM单片微型计算机 | 单片机 | 无操作系统，汇编语言 | 结构和功能相对单一，处理效率低，存储容量十分有限，几乎没有用户接口 |
| MCU微控制器 | 单片机、嵌入式微处理器、外围电路、接口电路 | 以简单操作系统为核心 | 微处理器微控制器种类繁多，通用性比较弱，系统开销小，处理效率高，智能化控制能力突出 |
| SoC片上系统 | 嵌入式微处理器 | 嵌入式操作系统 | 嵌入式系统兼容性好，操作系统内核小，处理效率高 |
| 以Internet为基础的嵌入式系统 | 嵌入式微处理器 | 嵌入式操作系统 | 微处理器集成网络接口，应用域网络环境中 |
| 智能化、云技术推动下的嵌入式系统 | 微型传感器、智能服务设备 | - | 低能耗，高速度，高集成，高可信，适应环境广 |
（2）传统嵌入式系统
主要硬件包括：
● 微处理器：微控制器 MCU，微处理器 MPU
● 存储器：RAM，ROM
● 总线：内总线，外总线
● 定时器/计数器 Timer
● 看门狗 WatchDog
● I/O 接口：串口，网络，USB，JTAG
● 外部设备：UART，LED
（3）嵌入式处理器的分类
嵌入式系统可以分为：
①微处理器（Micro Processor Unit, MPU）。特点是体积小，重量轻，成本低，可靠性高，但技术保密性差。
②微控制器（Micro Control Unit, MCU）。特点是单片化，体积小，功耗低，成本低，可靠性更高。
③信号处理器（Digital Signal Processor, DSP）特点是系统结构和指令采用特殊设计，通常采用哈佛结构，编译效率高，指令执行速度也高。
④图形处理器（Graphics Processing Unit, GPU）专注于浮点运算 ，弥补了 CPU 运算速度不足。
⑤片上系统（System on Chip, SoC），采用了片内再编程技术，可使片上系统内硬件的功能可以像软件一样通过编程来配置，从而可以实时地进行灵活而方便的修改和开发。
（4）存储器
存储器就是一种存储程序和数据用的时序逻辑电路。存储器具有如下分类：
◆ 随机存取存储器 （Random Access Memory，RAM）。它的特点是一旦系统断电，存放在里面的所有数据和程序都会自动清空掉，并且再也无法恢复。
◆ 只读存储器 （Read Only Memory，ROM）。ROM在元件正常工作的情况下，其中的代码数据将永久保存，并且不能够进行修改。
（5）总线
总线是功能部件间传输信息的公共通信干线。总线的拓扑结构有星形、树状、环形、总线型和交叉开关型等五种。总线的类型可以按照计算机所传输的信息种类、按连接部件进行划分。
（1）按照计算机所传输的信息种类可以分为：
◆ 数据总线：用于处理器与RAM间传输待处理和待存储的数据。
◆ 地址总线：用于传输RAM中存储数据的地址。
◆ 控制总线：用于传输处理器控制单元信号到周边设备。
（2）按连接部件分类
◆ 片内总线：内部总线，连接ALU，寄存器，指令部件等芯片内部元件。
◆ 系统总线：内部总线，又称板级总线，连接微控制器/处理器，主存，I/O接口。
◆ 局部总线：内部总线，连接少量组件用于交换数据。
◆ 通信总线：外部总线，又称外设总线，连接外部设备或外部系统。
（6）看门狗
看门狗为嵌入式系统提供必须的系统恢复能力，在系统发生软件问题和程序跑飞时重新启动系统。它的基本原理是由计数器自动计数，程序定期将其重置，如果系统卡死或程序跑飞，计数器溢出，进入中断处理，在设定实践间隔内，系统保留状态后复位重启。
2、嵌入式系统软件原理与特征
（1）嵌入式操作系统的定义及特点
嵌入式操作系统（Embedded Operating System，EOS）是指用于嵌入式系统的操作系统。与通用的操作系统相比，嵌入式操作系统具有：可剪裁性，可移植性，强实时性，强紧凑性，高质量代码，强定制性，标准接口，强稳定性，弱交互性，强确定性，操作简捷、方便，较强的硬件适应性，可固化性的特点。
（2）嵌入式系统的架构
嵌入式操作系统分为面向控制、通信领域以及面向消费电子产品两类。
（3）嵌入式操作系统的基本功能
（1）操作系统内核架构
⚡宏内核 ：用于管理用户程序和硬件间的系统资源，在宏内核中用户服务和内核服务在同一空间中实现，代码耦合度非常高，内核的功能组件代码可以互相调用。
⚡微内核 ：微内核管理所有系统资源，在微内核中用户服务和内核服务在不同空间中实现，系统结构清晰，代码量少。
（2）任务管理
任务是嵌入式操作系统调度最小单位为任务，类似于计算机操作系统中进程的概念。任务有三种工作状态：
● 执行状态：任务获得处理机，程序在处理机中执行。
● 就绪状态：任务已获得处理机以外资源，待获得处理机即可执行。
● 阻塞状态：执行状态任务因等待事件发生无法执行而放弃处理机。
（4）调度算法
嵌入式操作系统大都支持优先级抢占调度算法和时间片轮转调度算法。在实时系统的任务调度中，存在大量的实时调度方法，大致可以分为：
◆ 离线调度算法：系统运行前确定调度信息，如时间驱动，确定性，缺乏灵活性。
◆ 在线调度算法：系统运行中动态获得调度信息，如优先级驱动，灵活性较大。
◆ 抢占调度算法：运行任务可能被打断，更复杂，更耗资源。
◆ 非抢占调度算法：运行任务不被打断。
◆ 静态调度算法：任务优先级在设计时确定，不变化，简单，缺乏灵活性。
◆ 动态调度算法：任务优先级在运行中确定，不断变化，灵活，耗资源。
实时调度算法中还有强实时调度算法，具体可以分为：
◆ 最早截止时间优先（Earliest Deadline First，EDF）调度算法：根据任务截止时间确定优先级，截止时间越早，其优先级越高。
◆ 最低松弛度优先（Least Laxity First，LLF）调度算法：根据任务紧急或松弛程度确定优先级，紧急程度越高，优先级越高。
◆ 单调速率（Rate Monotonic Scheduling，RMS）调度算法：根据任务周期确定有限期，周期越短，优先级越高。这种算法被认为是最优的。
（5）存储管理
存储管理的主要目的是解决多个用户使用主存的问题，存储管理方法主要包括分区、分页、分段、段页式存储管理以及虚拟存储管理等。
（6）任务间通信
任务间通信管理也是嵌入式操作系统的关键功能之一。它主要为操作系统的应用程序提供多种类型的数据传输、任务同步/异步操作等手段。
（7）嵌入式数据库
嵌入式数据库具有嵌入式，实时性，移动性，伸缩性的特点。嵌入式数据库可以按照如下方式分类：
◆ 按嵌入对象：分为软件嵌入数据库，设备嵌入数据库，内存数据库
◆ 按系统结构：分为嵌入数据库，移动数据库，小型 C/S 结构数据库
◆ 按存储位置：分为：
① 基于内存的数据库系统：采用内存存储，属于实时事务最佳技术。
② 基于文件的数据库：以文件方式磁盘存储，安全性低。
③ 基于网络的数据库：远程服务器存储，无需解析 SQL，支持更多 SQL 操作，客户端小，便于代码重用。
嵌入式数据库架构------数据库管理系统与嵌入式数据库：
| 数据库管理系统 | 嵌入式数据库 | |
|---|---|---|
| 操作用户 | 允许非开发人员操作 | 只允许应用程序访问和控制 |
| 访问控制 | 数据与程序分离，便于访问控制 | 应用程序负责访问和控制 |
| 发布部署 | 独立安装、部署和管理 | 与应用程序一同发布 |
①基于内存的数据库系统。典型产品是 eXtremeDB 嵌入式数据库，它具有：最小化资源消耗、保持极小堆空间、维持极小代码体积、消除额外代码层、提供动态数据结构本地支持等特点。
②基于文件的嵌入式数据库系统架构。典型产品是 SQLite，它的特点是：开源的内嵌式关系型数据库、集成在程序中，无需配置管理、服务器客户端同进程，简化管理，减少网络开销、对数据类型有独特处理。
③基于网络的嵌入式数据库系统架构。C/S 架构的数据库、B/S 架构的数据库以及云数据库等都是属于这种类型。嵌入式数据库主要功能。除了具有通用数据库相似的功能外，嵌入式数据库还具备的功能包括：足够高效的数据存储机制、数据安全控制（锁机制）、实时事务管理机制、数据库恢复机制（历史数据存储）。
嵌入式中间件。是在嵌入式系统中处于嵌入式应用和操作系统之间层次的中间软件，其主要作用是对嵌入式应用屏蔽底层操作系统的异构性，常见功能有网络通信、内存管理和数据处理等。典型的嵌入式中间件有消息中间件、分布式对象中间件。
嵌入式系统软件开发环境。嵌入式软件开发环境的特点是集成开发环境，交叉开发，开放式架构，可扩展性，可操作性，可移植性，可配置性，实时性，可维护性，用户界面友好。
3、嵌入式系统软件架构设计方法
（1）属性驱动的软件设计方法
属性驱动的软件设计方法（Attribute - Driven Design，ADD）是把一组质量属性（可用性、性能、安全性等）场景作为输入，利用对质量属性实现与架构设计之间的关系的了解（如体系结构风格、质量战术等）对软件架构进行设计的一种方法。这种方法在满足质量属性基础上建立模块分解过程，通过输入质量场景，利用质量属性战术实现架构设计。采用ADD方法进行软件开发时，需要经历评审、选择驱动因子、选择系统元素、选择设计概念、实体化元素和定义接口、草拟视图和分析评价等七个阶段。
（2）实时系统设计方法
实时系统设计方法（Design Approach for Real - Time System，DARTS）基于传统结构化分析方法，扩展了行为建模部分。DARTS方法分成5个部分：用实时结构化分析方法开发系统规范、将系统划分为多个并发任务、定义任务间接口、设计每个任务、设计过程的成果。
DARTS方法的优势：
①强调将系统分解为并发任务，并提供确认任务的标准
②提供定义任务间接口的指南
③强调用任务架构图的重要性
④ 提供从实时结构化分析规格到实时结构化设计的转换
DARTS方法的不足:
①DARTS使用信息隐藏技术封装数据存储，封装性不好。
②如果实时结构化分析阶段的完成的不好，那么任务的结构化工作就会更加困难。
4、嵌入式系统软件架构实践
（1）鸿蒙操作系统
鸿蒙操作系统架构采用了分布式设计理念，实现了分布式软总线、分布式设系统的虚拟化、分布式数据管理和分布式任务调度等四种分布式能力。
鸿蒙操作系统的架构是一种层次式架构，由内核层、系统服务层、框架层、应用层组成。
①内核层 ：采用微内核设计，内核抽象层屏蔽多内核差异，对上层提供支持。
②系统服务层 ：属于核心能力集合部分，为应用程序提供进程/线程管理、内存管理、文件系统、网络管理、外设管理等基础内核能力。驱动子系统提供统一外设访问能力、驱动开发框架和驱动管理框架。
③框架层 ：为应用服务提供多语言用户程序框架、能力框架以及多语言框架API（提供各种硬件服务对外开放）。
④应用层 ：包括系统应用和第三方非系统应用，能实现特定业务功能，支持跨设备调度与分发，为用户提供一致、高效的应用体验。
鸿蒙操作系统架构的技术特性：
◆ 分布式架构用于终端操作系统，实现跨终端无缝协同体验。
◆ 确定时延引擎和高性能进程间通信技术，实现系统的流畅。
◆ 基于微内核架构，重塑终端设备的可信安全。
◆ 统一集成开发环境，一次开发，多端部署，实现跨终端生态共享。
（2）面向安全攸关系统
面向安全攸关系统的跨领域系统架构 GENESYS（GENeric Embedded SYStem ）是一种跨领域的通用嵌入式架构平台。GENESYS 采用消息交换方式实现软硬件构件的抽象级别的提升，使得构件在接口规范基础上可以被重用，而不需要知道构件的内部实现。GENESYS 设计了故障或错误的隔离框架，构件在瞬态故障引起失效后，可选择性的重启和用构件复制来屏蔽瞬态和永久错误。同时 GENESYS 可以减少构件的功率需求或者在不需要时（功率门）完全关闭构件。因此 GENESYS 的出现解决了复杂性管理、系统健壮性、能量有效使用 3 个方面的挑战。
GENESYS 架构主要提供了三组服务，即领域无关服务、领域专用服务和应用专用服务 （包括中间件）。
①领域无关服务 包括核心服务和选择服务，如嵌入式系统中的全局时间和消息传输等服务为核心服务 。信息安全服务、外部存储器管理器或者 Internet 网关服务等属于选择服务。
②领域专用服务 是由领域特有的选择服务子集加上待开发的领域特征的特定服务组合。
GENESYS 架构从硬件、软件的观点遵循了面向构件的风格，分离了计算与通信，将计算构件和通信设施作为独立构件进行设计。
GENESYS 架构的主要特征及优势包括：
① 精确的构件定位。具体体现为简单化，跨领域重用，规模的经济型，健壮性，可降低系统集成工作量几个特征。
② 开放性。体现为具有可集成性，可升级性，可扩展性，遗产系统集成，降低成本几个特征。
③ 三级集成。具有芯片级集成，设备级集成，系统级集成的集成。
④ 分层的服务。体现具有可重用性，领域定位，工效经济型的特性。
⑤ 确定的核心。体现在具有及时性，降低复杂性，可测试性，认证，故障掩蔽的特征。
⑥ 标准的互联集成。体现在对远程访问的保护，降低集成工作难度，常规人机交互，具有安全性 4 个方面。
（3）物联网操作系统软件架构
物联网操作系统至今没有一个明确的定义。物联网操作系统通常包括了芯片层、终端层、边缘层、云端层等多个层面内容。
物联网操作系统使用的软件以及技术，主要有：开源物联网操作系统 FreeRTOS、公共服务组件（网络协议、外设支持、可移植操作系统接口 POSIX 等）定制性服务组件：（消息队列遥测传输协议 MQTT，安全超文本传输协议 HTTPS，加密消息标准 PKCS 支持，安全套件等）。
物联网操作系统主要特征有：内核实时性、内核尺寸伸缩性、架构可扩展性、高可靠性、低功耗。
六、通信系统架构设计理论与实践
1、通信系统网络架构
通信网络主要形式：局域网，广域网，移动通信网。
（1）局域网网络架构
局域网是单一机构专用计算机的网络。通常由计算机、交换机、路由器等设备组成。特点是覆盖地理范围小，数据传输速率高，低误码率，可靠性高，支持多种传输介质，支持实时应用。局域网按网络拓扑分类有总线型、环型、星型、树、层次型等类型。按传输介质分类有线局域网、无线局域网。局域网网络架构有4种类型：
①单核心架构 。使用单台核心二层或三层交换设备作为网络核心。
优点：结构简单，设备投资节约，接入方便。
缺点：地理范围受限，核心单点故障，扩展能力有限，接入设备较多时核心端口密度要求高。
②双核心架构。采用两台核心三层及以上交换机作为网络核心。
优点：网络拓扑结构可靠，可靠性高，接入较为方便。
缺点：投资较单核心高，核心端口密度要求较高。
③环型架构。采用多台核心三层及以上交换机组成双RPR（Resilient Packet Ring）动态弹性分组环，作为网络核心。
优点：RPR具备自愈保护，节省光纤资源，提供多等级、可靠的QoS服务，有效利用带宽资源。
缺点：投资较高，路由冗余设计实施难度较高且易形成环路，多环智能通过业务接口互通无法直通。
④层次型架构。由核心层、汇聚层、接入层三层交换设备和用户设备组成层次模型。
核心层：负责高速数据转发。汇聚层：提供充足接口，与接入层间实现互访控制。接入层：用户设备接入。
层次型架构的优点是易扩展，分级排查网络故障便于维护。
（2）广域网网络架构
广域网利用公用分组交换网、无线分组交换网、卫星通信网构建通信子网连接分布的局域网以实现资源子网的共享。广域网由骨干网、分布网、接入网组成。广域网网络架构可以分为：
① 单核心架构。以单台核心三层交换设备作为网络核心。
优点：结构简单，设备投资节约，局域网互访效率高，新局域网接入方便。
缺点：核心单点故障，扩展能力欠佳，核心设备端口密度要求较高。
② 双核心架构。以两台核心三层及以上交换机作为网络核心。
优点：网络拓扑结构可靠，路由可热切换，可靠性高，局域网接入较为方便。
缺点：投资较单核心高，路由冗余设计实施难度较高，核心端口密度要求较高。
③ 环型架构。以多台核心三层及以上交换机组成路由环路作为网络核心。
优点：接入方便。
缺点：投资较高，路由冗余设计实施难度较高且易形成环路，核心端口密度要求较高。
④ 半/全冗余架构。以多台核心路由设备间互连组成网络核心，如任意核心存在两条以上到其他核心的链路为半冗余架构，如任何两个核心间均存在链路为全冗余架构。
优点：结构灵活，路由灵活，方便扩展，可靠性高。
缺点：结构零散，不便管理，不便排障。
⑤对等子域架构。将半冗余核心划为两个独立子域，子域间通过一条或多条链路互连。
优点：路由控制灵活。
缺点：子域间冗余设计实施难度较高，易形成环路或存在非法路由风险，子域互连设备性能要求高。
⑥层次子域架构：半冗余核心划为多个独立子域，子域间存在层次关系，高层次子域连接多个低层次子域
优点：扩展性较好，路由控制灵活。
缺点：子域路由冗余设计实施难度较高，易形成环路或存在非法路由风险，子域互连设备性能要求高。
（3）移动通信网
① 移动通信网网络架构
5G系统为移动终端用户提供数据网络互连，数据网络可以是互联网、IP媒体子系统、专用网络。用户设备通过5G系统接入数据网络的方式有透明模式和非透明模式。在透明模式下5G系统通过用户面功能接口接入运营商网络，然后通过防火墙或者代理连至Internet。非透明模式下，5G系统可以直接或通过其他网络连接至运营商网络或Internet。
②5G 网络边缘计算
能为垂直行业提供诸如以时间敏感、高带宽为特征的业务就近分流服务。
一来为用户提供极佳服务体验，二来降低了移动网络后端处理的压力。
③软件定义网络（Software Defined Network，SDN）
是一种新型网络创新架构， 核心思想是通过控制与转发分离，将网络中交换设备的控制逻辑集中到一个计算设备上，控制面集中管控，提升网络管理配置能力。
例题：
（4）存储网络架构
存储网络设计磁盘存储访问方式：直接附加存储 DAS，网络附加存储 NAS，存储区域网络 SAN。
① 直连式存储（Direct Attached Storage，DAS)：存储设备通过 IDE/ATA/SCSI 接口或光纤通道 直接连接到单台计算机，计算机通过 I/O 访问存储设备，存储设备可以是硬盘驱动器、RAID 阵列、CD、DVD、磁带驱动器。
② 网络连接的存储（Network Attached Storage，NAS)： 存储设备通过标准的网络拓扑结构连接到计算机群组，计算机通过 IP 局域网或广域网 TPC 或 UDP 协议，通过 RPC 接口访问 NAS 存储设备。
③ 存储区域网络（Storage Area Network，SAN)：一种采用 网状通道技术专门为存储建立的独立于 TCP/IP 网络之外的专用网络，通过网状通道交换机连接存储阵列和服务器。
| DAS | NAS | SAN | |
|---|---|---|---|
| 架构类别 | 单机存储架构 | 网络存储架构 | 网络存储架构 |
| 访问方式 | I/O 总线 | 网络 | 网络 |
| 资源利用 | 单机存储 | 共享存储 | 共享存储 |
| 访问媒介 | 总线 | 以太网 | 以太网/光纤通道 |
| 优势特点 | 易用易管理，设备成本低 | 易用易管理，可扩展性高，设备成本较低 | 高性能，低延迟，灵活性高 |
2、网络构建关键技术
（1）IPv4 与 IPv6 融合组网技术
目前网络演进还存在较长时间 IPv4 到 IPv6 过渡期或 IPv4 和IPv6 网络共存期。现阶段主要存在三种过渡技术：双协议栈、隧道技术、地址翻译。
①双协议栈：两种协议在同一平台上双栈共存，同时运行。
②隧道技术：隧道技术包括 ISATAP 隧道、6to4 隧道、4over6 隧道、6over4 隧道。
③网络地址翻译 NAT：网络地址翻译（Network Address Translator ）技术将 IPv4 地址和IPv6 地址分别看作内部地址和外部地址，或者相反，以实现地址转换。
（2）网络构建
⚡网络需求分析 。主要从 业务需求、用户需求、应用需求、计算机平台需求和网络需求进行分析。
⚡网络技术遴选及设计 。可用 生成树协议、虚拟局域网 VLAN、无线局域网 WLAN、线路冗余设计、服务器冗余设计等方式。
⚡广域网技术遴选 。可采用 远程接入技术、广域网互连技术如数字数据网络 DDN、同步数字体系 SDH、多业务传送平台 MSTP、虚拟专用网络 VPN 等。广域网性能优化策略有预留带宽、利用拨号线路、传输数据压缩、链路聚合、数据基于优先级排序、基于协议预留带宽等。
⚡层次化网络模型设计 。层次化设计优点为降低成本，充分利用模块化设备/部件，网络变化或演化容易。一般采用 接入层、汇聚层、核心层三层模型设计思路。设计原则：
①控制网络层次
②从 接入层开始， 向上分析规划
③尽量采用 模块化设计
④严格控制网络结构
⑤严格控制层次化结构
（3）网络安全控制技术
实施网络安全控制的相关技术主要有：
⚡防火墙。防护墙是网络间的安全屏障，可保护本地网络资源。能允许/拒绝/重定向数据流以及审计进出网络的访问或服务。体系包括硬件防火墙、软件防火墙、嵌入式防火墙。种类有包过滤、应用层网关、代理服务等。
⚡虚拟专用网络技术。利用公共网络建立私有专用网络，有成本低、接入方便、可扩展性强、管理和控制方便等优点。
⚡访问控制技术。主要有自主访问控制 DAC、强制访问控制 MAC、基于角色的访问控制 RBAC、基于任务的访问控制 TBAC 和基于对象的访问控制 OBAC。
⚡网络安全隔离。将攻击隔离在网络外，保证网络内信息不外泄。形式有子网隔离、物理隔离、VLAN 隔离、逻辑隔离。
⚡网络安全协议。
⚡网络安全审计。用于测试、评估和分析网络脆弱性，能实现自动响应、数据生成、分析、浏览、事件存储、事件选择等功能。
⚡绿色网络设计方法。采用精简设计、重用设计、回收设计的思路。设计原则有：
①标准化：减少转换设备，兼容异构方案。
②集成化：减少设备总量，降低资源需求。
③虚拟化：灵活调配，按需使用。
④智能化：降低人力成本，降低资源占用。
例题：
七、安全架构设计理论与实践
1、信息安全面临的威胁
①信息系统安全威胁来源。威胁可以来源于物理环境、通信链路、网络系统、操作系统、应用系统、管理系统。
②网络与信息安全风险类别。类别可以分为 人为蓄意破环（主动型攻击，被动型攻击）、灾害性攻击、系统故障、人员无意识行为。
● 被动攻击：收集信息为主，破坏保密性。
● 主动攻击：中断(可用性)、篡改(完整性)和伪造(真实性)
2、安全模型
◆ HRU：访问控制矩阵模型（Harrison、Ruzzo、Ullman）；
◆ MAC：强制访问控制模型（Mandatory Access Control）；
◆ DAC ： 自主访问控制模型（Discretionary Access Control）；
◆ RBAC ：基于角色的访问控制模型（Role-Based Access Control）。
（1）BLP模型
Bell-LaPadula模型是符合军事安全策略的计算机安全模型，简称BLP模型，机密性极高。其安全规则：
● 简单安全规则 ：安全级别低的主体不能读取安全级别高的客体（不能上读）；
● 星属性安全规则：安全级别高的主体不能往低级别的客体写（不能下写）。
● 强星属性安全规则：不允许对另一级别进行读写（级别隔离）。
● 自主安全规则：使用访问控制矩阵来定义说明自由存取控制。
（2）BiBa模型
此模型主要用于防止非授权修改系统信息 ，以保护系统的信息的完整性。模型也是采用主体、客体、完整性级别描述安全策略要求。BiBa模型能够防止数据从低完整性级别流向高完整性级别，其安全规则如下：
● 星完整性规则：表示完整性级别低的主体不能对完整性级别高的客体写数据（不能上写）；
● 简单完整性规则：表示完整性级别高的主体不能从完整性级别低的客体读取数据（不能下读）；
● 调用属性规则：表示一个完整性级别低的主体不能从级别高的客体调用程序或服务（不能上调）。
（3）Chinese Wall模型
在一个企业投资顾问公司里，一个咨询师大部分是同时为若干个企业提供投资咨询服务的，该咨询师就掌握了他所服务的所有企业的全部信息，包括企业的内部机密信息。如果该咨询师所服务的若干企业中有两家企业是在同一行业内的竞争对手，那么我们可以联想到，该咨询师可能会在给一家企业提供咨询过程中，有意或者无意地透露一些自己知道的有关另一家竞争企业的内部信息，使得一方得到利益，另一方遭受损失，这就导致了利益冲突，这是Chinese Wall安全模型策略需要解决的首要问题。
Clark-Wilson模型型实现了成型的事务处理机制，常用于银行系统中以保证数据完整性。Chinese Wall模型的访问客体控制的安全规则如下：
① 与主体曾经访问过的信息属于同一公司数据集合的信息，即墙内信息可以访问；
② 属于一个完全不同的利益冲突组的可以访问；
③ 主体能够对一个客体进行写的前提是主体未对任何属于其他公司数据集进行过访问。
定理1 ：一个主体一旦访问过一个客体，则该主体只能访问位于同一公司数据集的客体或在不同利益组的客体。
定理2 ：在一个利益冲突组中，一个主体最多只能访问一个公司数据集。
3、信息系统安全体系架构规划
主要是由技术体系、组织机构体系和管理体系三部分共同构成的。
⚡ 技术体系是全面提供信息系统安全保护的技术保障系统，该体系由物理安全技术和系统安全技术两大类构成。
⚡ 组织体系是信息系统的组织保障系统，由机构、岗位和人事三个模块构成。
⚡ 管理体系由法律管理、制度管理和培训管理三部分组成。
信息系统安全规划需要围绕技术安全、管理安全、组织安全考虑
信息系统安全规划以信息系统与信息资源的安全保护为核心
WPDRRC（Waring/Protect/Detect/React/Restore/Counterattack）WPDRRC 模型有6个环节和3大要素。
6个环节包括 ：预警、保护、检测、响应、恢复和反击，它们具有较强的时序性和动态性，能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。
3大要素包括 ：人员、策略和技术。人员是核心，策略是桥梁，技术是保证。
| 环节 | 解释 |
|---|---|
| W. 预警 | 利用远程安全评估系统提供的模拟攻击技术来检查系统存在的、可能被利用的薄弱环节，收集和测试网络与信息的安全风险所在，并以直观的方式进行报告，提供解决方案的建议，在经过分析后，分解网络的风险变化趋势和严重风险点，从而有效降低网络的总体风险，保护关键业务和数据。 |
| P 防护 | 通过采用成熟的信息安全技术及方法来实现网络与信息的安全。主要内容有加密机制，数字签名机制，访问控制机制，认证机制，信息隐藏和防火墙技术等。 |
| D 检测 | 通过检测和监控网络以及系统，来发现新的威胁和弱点，强制执行安全策略。在这个过程中采用入侵检测、恶意代码过滤等技术，形成动态检测的制度，奖励报告协调机制，提高检测的实时性。主要内容有入侵检测，系统脆弱性检测，数据完整性检测和攻击性检测等。 |
| R 响应 | 指在检测到安全漏洞和安全事件之后必须及时做出正确的响应，从而把系统调整到安全状态。为此需要相应的报警、跟踪、处理系统，其中处理包括了封堵、隔离、报告等能力。主要内容有应急策略、应急机制、应急手段、入侵过程分析和安全状态评估等。 |
| R 恢复 | 当前网络、数据、服务受到黑客攻击并遭到破坏或影响后，通过必要技术手段，在尽可能短的时间内使系统恢复正常。主要内容有容错、冗余、备份、替换、修复和恢复等。 |
| C 反击 | 是指采用一切可能的高新技术手段，侦察、提取计算机犯罪分子的作案线索与犯罪证据，形成强有力的取证能力和依法打击手段。 |
信息安全体系架构。具体可以从以下5个方面开展安全体系的架构设计工作：
(1) 物理安全 （前提 ）：包括环境安全、设备安全、媒体安全。
(2) 系统安全 （基础 ）：包括网络结构安全、操作系统安全、应用系统安全。
(3) 网络安全 （关键 ）： 包括访问控制、通信保密、入侵检测、网络安全扫描、防病毒。
(4) 应用安全：包括资源共享、信息存储。
(5) 安全管理：包括健全的体制，管理平台，人员安全防范意识
例题：
4、网络安全架构设计
（1）OSI/RM信息安全架构
（2）安全服务和安全机制的对应关系
（3）网络安全体系模型
网络安全体系模型经过多年发展，形成了PDP、PPDR、PDRR、MPDRR和WPDRRC等模型，这些模型在信息安全防范方面功能更加完善。
鉴别（Authentication）的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。鉴别信息是指申请者要求鉴别到鉴别过程结束所生成、使用和交换的信息。鉴别信息的类型有交换鉴别信息、申请鉴别信息和验证鉴别信息。
鉴别的方式主要基于以下5种：
(1) 已知的，如一个秘密的口令
(2) 拥有的，如IC卡、令牌等。
(3) 不改变的特性，如生物特征。
(4) 相信可靠的第三方建立的鉴别（递推）。
(5) 环境（如主机地址等）。
访问控制框架：访问控制（Access Control）决定开放系统环境中允许使用哪些资源、在什么地方适合阻止未授权访问的过程。在访问控制实例中，访问可以是对一个系统（即对一个系统通信部分的一个实体）或对一个系统内部进行的。
ACI（访问控制信息）是用于访问控制目的的任何信息，其中包括上下文信息。ADI（访问控制判决信息）是在做出一个特定的访问控制判决时可供ADF使用的部分（或全部）ACI。ADF（访问控制判决功能）是一种特定功能，它通过对访问请求、ADI以及该访问请求的上下文使用访问控制策略规则而做出访问控制判决。AEF（访问控制实施功能）确保只有对目标允许的访问才由发起者执行。
机密性框架：机密性服务的目的是确保信息仅仅是对被授权者可用。
① 通过禁止访问提供机密性
② 通过加密提供机密性
完整性框架：目的是通过阻止威胁或探测威胁，保护可能遭到不同方式危害的数据完整性和数据相关属性完整性。
① 阻止对媒体访问的机制。包括物理隔离的不受干扰的信道、路由控制、访问控制。
② 用以探测对数据或数据项序列的非授权修改的机制。
抗抵赖服务 ：包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。抗抵赖由4个独立的阶段组成：证据生成；证据传输、存储及恢复；证据验证和解决纠纷。
① 证据生成
在这个阶段中，证据生成请求者请求证据生成者为事件或行为生成证据。卷入事件或行为中的实体，称为证据实体，其卷入关系由证据建立。根据抗抵赖服务的类型，证据可由证据实体，或可能与可信第三方的服务一起生成，或者单独由可信第三方生成。
② 证据传输、存储及恢复
在这个阶段，证据在实体间传输或从存储器取出来或传到存储器。
③ 证据验证
在这个阶段，证据在证据使用者的请求下被证据验证者验证。本阶段的目的是在出现纠纷的事件中，让证据使用者确信被提供的证据确实是充分的。可信第三方服务也可参与，以提供验证该证据的信息。
④ 解决纠纷
在解决纠纷阶段，仲裁者有解决双方纠纷的责任。
5、数据库安全设计
（1）数据库完整性设计原则
具体包括：
①依据完整性约束类型设计其实现的系统层次和方式，并考虑性能。
②保障性能前提下，尽可能应用实体完整性约束和引用完整性约束。
③慎用触发器。
④制订并使用完整性约束命名规范。
⑤测试数据库完整性，尽早排除冲突和性能隐患。
⑥设有数据库设计团队，参与数据库工程全过程。
⑦使用 CASE 工具，降低工作量，提高工作效率。
（2）数据库完整性作用
数据库完整性作用体现在以下几个方面：
① 防止不合语义的数据入库。
② 降低开发复杂性，提高运行效率。
③ 通过测试尽早发现缺陷。
6、系统架构脆弱性分析
系统脆弱性组成：包括物理装备脆弱性、软件脆弱性、人员管理、规章制度、安全策略脆弱性等。
典型架构的脆弱性表现：
⚡ 分层架构。分层脆弱性体现在：
◆层间脆弱性：一旦某个底层发生错误，那么整个程序将会无法正常运行。
◆层间通信脆弱性：如在面向对象方法中，将会存在大量对象成员方法的调用（消息交互），这种层层传递，势必造成性能的下降。
⚡ C/S 架构。这种架构的脆弱性有：客户端脆弱性、网络开放性脆弱性、网络协议脆弱性。
⚡ B/S 架构。如果 B/S 架构使用的是 HTTP 协议，会更容易被病毒入侵。
⚡ 事件驱动架构。事件驱动的架构的脆弱性体现在：组件脆弱性、组件间交换数据的脆弱性、组件间逻辑关系的脆弱性、事件驱动容易死循环、高并发脆弱性、固定流程脆弱性。
⚡ MVC 架构。MVC 的脆弱性体现在：
◆复杂性脆弱性。如一个简单的界面，如果严格遵循 MVC 方式，使得模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
◆视图与控制器连接紧密脆弱性。视图与控制器是相互分离但确是联系紧密的部件，如果没有控制器的存在，视图应用是有限的。反之亦然，这就妨碍了它们的独立重用。
◆视图对模型低效率访问脆弱性。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。
⚡ 微内核架构。微内核架构的脆弱性体现在：
◆整体优化脆弱性。微内核系统的核心态只实现了最基本的系统操作，因此内核以外的外部程序之间的独立运行使得系统难以进行良好的整体优化。
◆进程通信开销脆弱性。微内核系统的进程间通信开销也较单一内核系统要大得多。
◆通信损失脆弱性。微内核把系统分为各个小的功能块，从而降低了设计难度，系统的维护与修改也容易，但带来的问题是通信效率的损失。
⚡ 微服务架构。微服务架构的脆弱性体现在：
◆分布式结构复杂性脆弱性。开发人员需要处理分布式系统的复杂结构。
◆服务间通信脆弱性。开发人员要设计服务之间的通信机制，通过写代码来处理消息传递中速度过慢或者不可用等局部实效问题。
◆服务管理复杂性脆弱性。在生产环境中要管理多个不同的服务实例，这意味着开发团队需要全局统筹。
7、安全架构设计案例分析
（1）RADIUS远程认证拨号用户服务
RADIUS （Remote Authentication Dial-In User Service，远程认证拨号用户服务 ）。是应用最广泛的高安全级别 AAA 协议（认证 Authentication、授权 Authorization、审计 Accounting况），具有高性能和高可扩展性，且可用多种协议实现。
RADIUS 通常由协议逻辑层，业务逻辑层和数据逻辑层三层组成层次式架构。
① 协议逻辑层：起到分发处理功能，相当于转发引擎。
② 业务逻辑层：实现认证、计费、授权三种类型业务及其服务进程间的通信。
③ 数据逻辑层：实现统一的数据访问代理池，降低数据库依赖，减少数据库压力，增强系统的数据库适应能力。
（2）基于混合云的工业安全生产管理系统
混合云融合了公有云和私有云。在基于混合云的工业安全生产管理系统中，工厂内部的产品设计、数据共享、生产集成使用私有云实现。公有云则用于工厂间与公司总部与智能工厂间的业务管理、协调和统计分析等。整个生产管理系统架构采用层次式架构，分为设备层、控制层、设计/管理层、应用层。
（1）设备层：包括智能工厂生产用设备，包括智能传感器，智能仪器仪表，工业机器人，其他生产设备。
（2）控制层：包括智能设备控制用自动控制系统，包括采集与监视控制系统 SCADA，分布式控制系统 DCS，现场总线控制系统 FCS，可编程控制器 PLC（内置编程程序），人机接口 HMI，其他现场控制程序。
（3）设计/管理层：包括智能工厂所有控制开发，业务控制和数据管理相关系统及其功能的集合，实现了数据集成和应用，包括制造执行系统 MES（很多企业称之为生产信息管理系统），计算机辅助设计/工程/制造 CAD/CAE/CAM，供应链管理 SCM，企业资源规划 ERP，客户关系管理 CRM，供应商关系管理 SRM，商业智能分析 BI，产品生命周期管理 PLM。
（4）应用层：云平台上的信息处理，包括数据处理与管理、数据与行业应用相结合，如定制业务、协同业务、产品服务。
在设计基于混合云的工业安全生产管理系统时，需要考虑安全问题有：设备安全、网络安全、控制安全、应用安全和数据安全。
例题：
八、大数据架构设计理论与实践
1、传统数据处理系统存在的问题
传统应用的数据系统架构设计时，应用直接访问数据库系统。用户访问量增加时，数据库无法支撑日益增长的用户请求的负载，导致数据库服务器无法及时响应用户请求，出现超时错误。过载问题常用解决方法如下：
①增加异步处理队列，通过工作处理层批量处理异步处理队列中的数据修改请求。
②建立数据库水平分区，通常建立 Key 分区，以主键/唯一键 Hash 值作为 Key。
③建立数据库分片或重新分片，通常专门编写脚本来自动完成，且要进行充分测试。
④引入读写分离技术，主数据库处理写请求，通过复制机制分发至从数据库。
⑤引入分库分表技术，按照业务上下文边界拆分数据组织结构，拆分单数据库压力。
2、大数据处理系统架构分析
（1）大数据的特点
大数据具有体量大、时效性强的特征，类型多样。处理大数据时，传统数据处理系统因数据过载、来源复杂、类型多样等原因性能低下，需采用以新式计算架构和智能算法为代表的新技术。大数据应用重在发掘数据间相关性，目的和价值在于发现新知识、洞悉并进行科学决策。现代大数据处理技术主要分为以下几种：
①基于分布式文件系统 Hadoop。
②使用 Map/Reduce 或 Spark 数据处理技术。
③使用 Kafka 数据传输消息队列及 Avro 二进制格式。
（2）大数据利用过程
大数据的利用过程分为：采集、清洗、统计和挖掘几个过程。
（3）大数据处理系统面临的挑战
主要有以下几点：
①如何 利用信息技术等手段处理非结构化和半结构化数据。
②如何 探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模。
③ 数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响。
（4）大数据处理系统应具有的属性和特征
包括 鲁棒性和容错性、低延迟、横向扩展（通过增强机器性能扩展）、通用、可扩展、即席查询（用户按照自己要求进行查询）、最少维护和可调试。
3、Lambda架构和Kappa架构
（1）Lambda架构
Lambda架构分为三层：
● 批处理层 ：核心功能是存储主数据集，其数据具备原始、不可变、真实的特征。周期性将增量数据转储至主数据集，并在主数据集上执行批处理以生成批视图。架构实现上，可用Hadoop HDFS或HBase存储主数据集，利用Spark或Map/Reduce执行周期批处理，之后借助Map/Reduce创建批视图。
● 加速层 ：核心在于处理增量实时数据，生成实时视图以快速执行即席查询。实现时，可用Hadoop HDFS或HBase存储实时数据，通过Spark或Storm完成实时数据处理和实时视图创建。
● 服务层 ：核心是响应用户请求，合并批视图和实时视图的结果数据集得到最终数据集。具体为接收用户请求，通过索引加速访问批视图，直接访问实时视图，再合并两者结果数据集生成最终数据集来响应请求。架构实现可选用HBase或Cassandra作为服务层，通过Hive创建可查询视图。
Lambda架构优缺点：
● 优点 ：容错性好，查询灵活度高，弹性伸缩，易于扩展。
● 缺点 ：编码量大，持续处理成本高，重新部署和迁移成本高。
与Lambda架构相似的模式有事件溯源模式 、命令查询职责分离模式。
（2）Kappa架构
Kappa架构是在Lambda基础上进行的优化，删除了BatchLayer架构，以消息队列替代数据通道。该架构分为实时层与服务层：
① 实时层 ：核心功能为处理输入数据并生成实时视图。具体通过流式处理引擎逐条处理输入数据来实现，架构实现上采用Apache Kafka回访数据，再用Flink或Spark Streaming处理。
② 服务层 ：核心是使用实时视图中的结果数据集响应用户请求，实践中以数据湖中的存储作为服务层。
Kappa架构本质是改进Lambda架构中的加速层，使其既能实时处理数据，又能在业务逻辑更新时重新处理历史数据。
优点：将离线和实时处理代码统一，便于维护。
缺点：消息中间件存在性能瓶颈、数据关联处理开销大，且舍弃了离线计算的可靠性。
（3）Lambda架构与Kappa架构对比
架构特征对比：
| 对比内容 | Lambda架构 | Kappa架构 |
|---|---|---|
| 复杂度与开发维护成本 | 维护两套系统（引擎），复杂度高，成本高 | 维护一套系统（引擎），复杂度低，成本低 |
| 计算开销 | 周期性批处理计算，持续实时计算，计算开销大 | 必要时进行全量计算，计算开销相对较小 |
| 实时性 | 满足实时性 | 满足实时性 |
| 历史数据处理能力 | 批式全量处理，吞吐量大，历史数据处理能力强，批视图与实时视图存在冲突可能 | 流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱 |
设计考量：
| 设计考虑 | Lambda架构 | Kappa架构 |
|---|---|---|
| 业务需求与技术要求 | 依赖Hadoop、Spark、Storm技术 | 依赖Flink计算引擎，偏流式计算 |
| 复杂度 | 实时处理和离线处理结果可能不一致 | 频繁修改算法模型参数 |
| 开发维护成本 | 成本预算充足 | 成本预算有限 |
| 历史数据处理能力 | 频繁使用海量历史数据 | 仅使用小规模数据集 |
4、大数据处理系统架构案例分析
（1）大规模视频网络
某网采用基于Lambda架构搭建的大数据平台来处理里约奥运会大规模视频网络观看数据，涉及具体平台架构设计。
（2）广告平台
某网基于 Lambda 架构的广告平台，分为批处理层（Batch layer）、加速层（Speed layer）、服务层（Serving layer）
（1）批处理层：每天凌晨将 Kafka 中浏览、下单等消息同步到 HDFS 中，将 HDFS 中数据解析为 Hive 表，然后使用 HQL 或 Spark SQL 计算分区统计结果 Hive 表，将 Hive 表转储到 MySQL 中作为批视图。
（2）加速层：使用 Spark Streaming 实时监听 Kafka 下单、付款等消息，计算每个追踪链接维度的实时数据，将实时计算结果存储在 Redis 中作为实时视图。
（3）服务层：采用 Java Web 服务，对外提供 HTTP 接口，Java Web 服务读取 MySQL 批视图表和 Redis 实时视图表。
（3）某证券公司智能决策大数据系统
该系统是一个基于 Kappa 架构的实时日志分析平台，具体的实时处理过程如下：
（1）日志采集：用统一的数据处理引擎 Filebeat 实时采集日志并推送给 Kafka 缓存。
（2）日志清洗解析：利用基于大数据计算集群的 Flink 计算框架实时读取 Kafka 消息并进行清洗，解析日志文本转换成指标。
（3）日志存储：日志转储到 ElasticSearch 日志库，指标转储到 OpenTSDB 指标库。
（4）日志监控：单独设置告警消息队列，保持监控消息时序管理和实时推送。
（4）电商智能决策大数据系统
该智能决策大数据平台基于 Kappa 架构，使用统一的数据处理引擎 Funk 可实时处理流数据，并将其存储到数据仓库工具 Hive 与分布式缓存 Tair 中，以供后续决策服务的使用。实时处理的过程如下：
（1）数据采集：B 端实时采集用户点击、下单、广告曝光、出价等数据然后推送给 Kafka 缓存。
（2）数据清洗聚合：由 Flink 实时读取 Kafka 消息，按需过滤参与业务需求的指标，将聚合时间段的数据转换成指标。
（3）数据存储：Flink 将计算结果转储至 Hive 日志库，将模型需要的参数转储至实时计算数据库 Tair 缓存，然后后续决策服务从 Tair 中获取数据进行模型训练。