全国计算机技术与软件专业技术资格（水平）考试

系统架构设计师 案例分析一本通

本资料为软考诸葛老师案例分析一本通，包含复习说明、考点分析、考点汇总、案例真题及解析等全部内容，请同学们务必结合案例分析专题课程认真学习。

第1章是案例分析概述，大家认真浏览一遍，做到心中有数即可。

第2章是历年案例真题精华考点，包括软件架构设计、软件系统设计、数据库系统设计、嵌入式系统设计以及Web系统设计。

第3章是第二版教材下篇架构设计考点，此章为第二版教材新增内容，有大量关于不同架构设计实战内容，涉及到不少新技术，务必也要掌握。

第4章是案例分析真题，包括2016年以来的历年全部真题，务必全部做完。

第5章是案例分析真题答案解析，每做完一年真题，要认真核对答案解析，查漏补缺。

第1章 案例分析概述

1.1 案例分析作答要求

案例分析第一题必做，后面四道题四选二。机试选做题很简单，选哪一道题就做哪一道，不选的就清空不要写任何数据。考试的时候灵活应变，看清楚要求即可。

除此之外，综合知识和案例分析2个科目连考，作答总时长240分钟，综合知识科目最长作答时长150分钟，最短作答时长120分钟。诸葛老师不建议大家提前交卷，案例时间较为紧张，需要全都利用起来。

1.2 历年真题考点分析

根据历年真题考点分析，将架构案例分析真题分为如下几个大类：

①软件架构设计：每年必考1-2题，并且是第1题必选题，必须掌握，主要涉及质量属性、软件架构风格、软件架构评估、MVC架构、面向服务的架构SOA、ESB、J2EE架构等。
②软件系统设计：几乎每年必考1题，主要涉及UML的图、关系的识别，尤其是类图、用例图、活动图、状态图；设计模式识别；数据流图、E-R图等简单识别；信息安全相关技术；项目管理-进度管理-关键路径。
③ 数据库系统设计：几乎每年必考 1 题，主要考查数据库的一些新技术的比较，如关系型数据库、非关系型数据库 NoSQL 以及内存数据库 Redis 等，还会包括反规范化技术、主从复制、负载均衡等。
④ 嵌入式系统设计：几乎每年必考1题，选做题，考查比较的多的是嵌入式系统的实时性和可靠性以及容错性等概念。大概率会考到一些嵌入式领域陌生技术，如果是完全没见过的技术，不选即可。
⑤Web系统设计：几乎每年必考1题，主要考查Web相关技术，一般结合架构进行考查。偶尔会考到新技术，遇到完全没听说过的技术，就不选。

改版后下篇八大架构是重中之重。

此外，若偶尔考到一些完全陌生的架构和技术，可直接选择忽略，因为陌生技术不会再考第二次，无法归纳总结，完全没有必要了解。

历年案例分析考点归纳如下（红色字体是试题一必答题）。

1.3 学习建议

案例分析学习建议：

第一步，听课，听一遍诸葛老师的系统架构设计师《案例分析专题课程》，里面详细讲解了大量典型案例真题、解题技巧、如何分析题目等，很重要。

第二步，学习考点，读此一本通第2章、第3章案例真题精华考点，将相关考点都理解和记忆，不理解的再去听课程对应部分知识点。

第三步，刷题，做此一本通第4章历年案例真题，先按题目分类进行专题训练，再按年份做题，并按规定90分钟练习，以模拟真实考试场景，浏览五道题目，第一题必做，其他四选二。做完后核对答案（在第5章），看看自己哪些知识点需要加强。当然，四选二的题，要选择自己擅长的题目，要学会临场应变。

第二版教材下篇架构设计是纯新增内容，有大量关于不同架构设计实战内容，涉及到不少新技术，是比较难理解的，同学们一定要先听教材下篇的诸葛老师课程讲解，再来看第3章，否则很难把握重点，同时，因为这一块实战性强，新技术多，老师也难免会有遗漏错误之处，敬请理解，也欢迎大家一起讨论反馈。

1.4 答题技巧

答题时，先看问题，再看题目描述。

第一题必做，先做完第一题。对于四选二，快速浏览所有题目问题和问题描述，是否能看懂，再进行选题。

问题与题目描述相结合，尤其是遇到系统分析和设计以及新技术等问题，答案一般都在题目描述里，从题目描述里抽象总结出问题答案即可。当然要以简练的语言写出答案，一般题目会有最大字数要求，不建议超过。

列条目回答问题，把自己认为对的都写上，多写不会扣分，少写一定会扣分。

若遇到新的知识点，没关系，要稳住心态。能避开则避开，否则就理解所问问题的倾向性，顺势答题即可。

系统架构设计师学习QQ群：231352210 软件设计师学习QQ群：1169209218

诸葛老师QQ: 362842353

VIP购买方式，淘宝搜索：软考诸葛老师

第2章 历年案例真题精华考点

注意：本章只是结合历年真题考查情况做的精简汇总，还是要以第一阶段：基础精讲为准，将案例分析涉及到的知识点章节内容全部理解记忆，必要时可以将官方教材通读一遍。

2.1 软件架构设计

系统架构设计师案例分析必考题，每年会必考1-2题，并且第1题是必选题，必须要掌握，主要考查质量属性、软件架构风格、软件架构评估、MVC架构、面向服务的架构SOA等知识。

对于其他未考查的架构领域重点知识如DSSA、ABSD等，也必须重点掌握，最好将软件架构设计章节通读一遍。

本题考查比较简单，知识点固定，一般可以拿到20分。

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

在架构评估过程中，所普遍关注的质量属性有以下几种。

（1）性能：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
（2）可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性通常用平均失效等待时间（Mean Time To Failure，MTTF）和平均失效间隔时间（Mean Time Between Failure，MTBF）来衡量。在失效率为常数和修复时间很短的情况下，MTTF 和 MTBF 几乎相等。可分为容错和健壮性。容错是指在错误发生时确保系统正确的行为，并进行内部“修复”。健壮性是指系统不受错误使用和错误输入的影响，按既定程序忽略错误。设计策略：冗余、心跳、选举、Ping/Echo。

（3）可用性：是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。设计策略：冗余、心跳、选举、Ping/Echo。
（4）安全性：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服

务的能力。可分为机密性、完整性、不可否认性、可控性。机密性保证信息不泄露给未授权的用户、实体或过程；完整性保证信息的完整和准确，防止信息被非法修改；不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为；可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。设计策略：入侵检测、用户认证、用户授权、追踪审计。

（5）可修改性：是指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价来衡量可修改性。可分为可维护性、可扩展性、结构重组和可移植性。

可维护性：在错误发生后“修复”软件系统的难易程度。

可扩展性：软件因适应新需求或需求变化而增加新功能的能力。

结构重组：重新组织软件系统的构件及构件之间的关系。

可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

设计策略：接口-实现分类、抽象、信息隐藏。

（6）功能性：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
（7）可变性：指架构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
（8）互操作性：作为系统组成部分的软件不是独立存在的，通常与其他系统或自身环境相互作用。为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件架构。

质量属性效用树

ATAM方法采用效用树（Utility tree）这一工具来对质量属性进行分类和优先级排序。效用树的结构包括：树根–质量属性–属性分类–质量属性场景（叶子节点）。需要注意的是，ATAM主要关注4类质量属性：性能、安全性、可修改性和可用性，这是因为这4个质量属性是利益相关者最为关心的。

1. 软件架构风格

必背概念

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

敏感点和权衡点：敏感点是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

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

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

架构风格对比

所有架构风格汇总如下，要理解每个架构风格的含义，有生疏的同学再去学习第一阶段：基础知识。

表 2.1 架构风格含义

表 2.2 常考架构风格对比

3.MVC架构

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

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

图13-2 MVC设计模式

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

MVC可以将业务处理与显示分离，将应用分为控制器、模型和视图，增加了应用的可拓展性、强壮性及灵活性。基于MVC的优点，目前比较先进的Web应用框架都是基于MVC设计模式的。

4.J2EE架构

四层结构：

• 客户层组件：J2EE 应用程序可以是基于 Web 方式的，也可以是基于传统方式的、静态的 HTML（标准通用标记语言下的一个应用）页面和 Applets（客户层组件）。

• Web层组件：J2EEWeb层组件可以是JSP页面或Servlet。

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

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

EJB是JavaEE服务器端组件模型，设计目标与核心应用是部署分布式应用程序。简单来说就是把已经编写好的程序(即：类)打包放在服务器上执行。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。

EJB中有三种企业级的bean：会话session)beans，实体-entity)beans，和消息驱动(message-driven)beans。会话bean表示与客户端程序的临时交互。当客户端程序执行完后，会话bean和相关数据就会消失。相反，实体bean表示数据库的表中一行永久的记录。当客户端程序中止或服务器关闭时，就会有潜在的服务保证实体bean的数据得以保存。消息驱动bean结合了会话bean和JMS的消息监听器的特性，允许一个业务层组件异步接收JMS消息。

JSP+Servlet+JavaBean+DAO

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

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

JavaBean：用于数据的封装，方便将查询结果在Servlet与JSP页面之间进行传递等。

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

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

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

5.面向服务的架构SOA

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

典型的SAO结构图

单个服务的内部结构

1. 企业服务总线ESB

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

图15-6 ESB示意图

ESB的特点：

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

ESB 的主要功能：① 服务位置透明性；② 传输协议转换；③ 消息格式转换；④ 消息路由；⑤ 消息增强；⑥ 安全性；⑦ 监控与管理。

2.2 软件系统设计

选做题，几乎每年必考1题，但是不会涉及大范围的系统分析与设计原理，而是偏向于软件设计与建模的范围，主要考查UML中的图、关系的识别；设计模式识别；数据流图、E-R图等；信息安全相关技术；项目管理-进度管理-关键路径。答案基本都在题目描述里，从题目描述抽象总结出问题答案。本题考查比较简单，一般可以拿到20分。

1. 数据流图（DFD）

数据流图中的基本图形元素包括数据流、加工、数据存储和外部实体。

• 数据流：数据的流向。在 DFD 中，数据流的流向可以有以下几种：从一个加工流向另一个加

工；从加工流向数据存储(写)；从数据存储流向加工(读)；从外部实体流向加工(输入)；从加工流向外部实体(输出)。数据流必须与加工有关。除了流向数据存储或从数据存储流出的数据流不必命名外，每个数据流都必须有一个明确的名字。

• 加工：描述了输入数据流到输出数据流之间的变换，也就是输入数据流经过什么处理后变成了输出数据流。一个加工可以有多个输入数据流和多个输出数据流，但至少有一个输入数据流和一个输出数据流。“黑洞”：加工有输入但没输出。“奇迹”：加工没输入但有输出；“灰洞”：加工输入不足以产生输出。
• 数据存储：用来存储数据。DFD中的数据存储在具体实现时可以用文件系统实现，也可以用数据库系统实现。数据存储的存储介质可以是磁盘、磁带或其他存储介质。
• 外部实体：外部实体是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地和系统所产生的数据的归宿地。例如，对于一个考务处理系统而言，考生向系统提供报名单(输入数据流)，所以考生是考务处理系统的一个数据发源地；而考务处理系统要将考试成绩的统计分析表(输出数据流)传递给考试中心，所以考试中心是该系统的一个数据归宿地。

(a) 外部实体

(b）加工

(d）数据流

(c）数据存储

（a）顶层图

DFD的基本图形元素
（b）0层图

数据流图的主要考点：

1. 补充外部实体

外部实体就是与信息系统进行交互的实体，可以是人员、组织或外部系统。外部实体会与信息系统进行交互，反应在数据流图中就是一个个事件流，依据事件的名称结合题目说明就可以轻易得出答案。（根据外部实体与信息系统之间的数据流得到外部实体，仅看上下文数据流图就可以）

2. 补充数据存储

数据存储出现在0层数据流图中，反应系统内部数据的存储，可以直接根据数据流图中数据存储的输入数据流和输出数据流判断该数据存储的名字（一般为输入数据流名+表/信息表/文件即可）。快速定位数据存储：找从加工流向数据存储的加工所在的功能描述。

3. 补充加工

一般情况下，数据流图中的加工名称与信息系统的功能标题一一对应。

详细分析题目说明，掌握数据平衡原则。

数据流图的设计原则：

1. 数据平衡原则

（1）父图与子图平衡

父图与子图：如果某图(记为A)中的某一个加工分解成一张子图(记为B)，则称A是B的父图，B是A的子图。父图与子图平衡：是指任何一张DFD子图边界上的输入/输出数据流必须与其父图中对应加工的输入/输出数据流保持一致。

（2）每张图的图内平衡

对于图内的每一个加工，要求既要有输入数据流，也要有输出数据流，避免出现黑洞、奇迹、灰洞。根据这一原则，可以对每个输入进行判断，是否有相应的输出，反之亦然，就可以知道是否缺少某条数据流，从而进行相应的补充。

2. 数据流相关原则

在DFD中，数据流的流向可以有以下几种：从一个加工流向另一个加工；从加工流向数据存储(写)；从数据存储流向加工(读)；从外部实体流向加工(输入)；从加工流向外部实体(输出)。数据流必须与加工有关。除了流向数据存储或从数据存储流出的数据流不必命名外，每个数据流都必须有一个明确的名字。

外部实体与外部实体之间不存在数据流；外部实体与数据存储之间不存在数据流；数据存储与数据存储之间不存在数据流。

3. 加工相关原则

对于每个加工，必须既有输入数据流，又有输出数据流。

对同一个加工来说，输入数据流和输出数据流名称不能相同（但类型要匹配），即使它们的组成成分相同。

数据字典（DD）：

1. 相关概念

数据字典：就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。

举例：机票 $=$ 姓名 $+$ 日期 $+$ 航班号 $+$ 起点 $+$ 终点 $+$ 费用
终点=[上海|深圳|北京]

2. 数据字典的内容

数据字典的4类条目：数据流、数据项、数据存储、基本加工。

3.加工逻辑描述（加工规格说明）

在数据流图的分解中，位于层次树最低层的加工也称为基本加工或原子加工，每一个基本加工都需要进一步说明，这称为加工规格说明。

在编写基本加工的规格说明时，主要目的是表达“做什么”而不是“怎么做”。

常用的加工逻辑描述方法（加工规格说明）有结构化语言、判定表（决策表）和判定树（决策树）三种。

2. E-R图

E-R模型，就是实体-联系模型，用来描述现实世界的概念模型（接近于人的思维方式，容易理解），其中有三个主要的概念：实体、联系和属性。

1. 实体

用矩形表示，每个实体由一组属性表示，包括候选键、主键、外键。实体集是指具有相同属性的实体集合。

候选键：能唯一地标识一行元组的属性集。

主键：从候选键中选一个作为主键。

外键：在另一个关系模式中充当主键的属性。

2. 联系

用菱形表示，实体集之间的对应关系称为联系，分为一对一（1：1）、一对多（1：n或1：）、多对多（m：n或：*）。

①一对一联系（1：1）。实体集A中的一个实体最多只与实体集B中的一个实体相联系，反之亦然。
②一对多联系（1：n或1：）。实体集A中的一个实体可与实体集B中的多个实体相联系。
③多对多联系（m：n或：*）。实体集A中的多个实体可与实体集B中的多个实体相联系。多对多的联系会产生一个新的关系模式，此关系模式的属性由联系的两个实体的主键以及自己的特有属性所组成。

1: 1: 一个学校只有一名校长, 而每位校长只在一个学校工作。

1: n或1: *：一个学校有很多学生，而每个学生只在一个学校上课。

m: n或*:*: 名生可以选修多门课程, 而一门课程也可以由多名学生选修。

(a)1:1的联系

(b)1:n的联系

(c)m:n的联系

3. 属性

用椭圆表示，是实体某方面的特性。E-R模型中的属性分为：

① 简单和复合属性：简单属性是原子的、不可再分的，复合属性可以划分为多个子属性，如通信地址。
② 单值和多值属性：对于一个特定的实体都只有一个单独的值（单值属性）。例如，对于一个特定的员工，只对应一个员工号、员工姓名。而员工可能有0个、1个或多个亲属，那么员工的亲属姓名可能有多个，这样的属性称为多值属性。
③NULL属性：某个属性没有值或属性值未知时，使用NULL值，表示无意义或不知道。
④派生属性：派生属性可以从其他属性得来。例如，职工实体集中有“参加工作时间”和“工

作年限”属性，那么“工作年限”的值可以由当前时间和参加工作时间得到。“工作年限”就是一个派生属性。

弱实体集：一个实体的存在必须以另一个实体为前提，这类实体称为弱实体集。例如：职工的家属必须以职工在职为前提，依赖于职工。

4. 实体-联系方法

E-R圈中的主要构件

学校教学管理系统的E-R模型

3. UML

UML 中有四种关系：依赖、关联、泛化和实现，如下表所示。

UML中的图

主要考查用例图、类图、顺序图、活动图、状态图。

UML图形分类

（1）用例图

描述了一组用例、参与者以及它们之间的关系。(也就是描述系统与外部系统及用户的交互，用图形描述谁将使用系统，用户期望用什么方式与系统交互。常用于系统语境建模、系统需求建模)

用例之间的关系有3种：①包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们，用«include»表示。②扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和若干个扩展用例，这样的描述可能更加清晰，用«extend»表示。③泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成父用例，其他的用例作为泛化关系中的子用例。

学生登记用例：

Seminar: 研讨课

包含关系：有公共的行为：登记

扩展关系：明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支。

学生登记为基本用例，安全检查为扩展用例。

泛化关系：登记学生和登记学生家庭成员共同拥有一种类似的结构和行为，

即登记信息，这就是泛化关系。

(2）类图

描述类、类的特性以及类之间的关系。类图中包含的内容如下图所示。

（3）顺序图

又称序列图，描述对象之间的交互（消息的发送与接收），重点在于强调顺序，反映对象间消息的发送与接收。有同步消息(进行阻塞调用，调用者中止执行，等待控制权返回，需要等待返回消息，用实心三角箭头表示)、异步消息(发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，由空心箭头表示)和返回消息(由从右到左的虚线箭头表示)三种。

UML顺序图

数据库使用数据库代理的顺序图：在顺序图中，首先把参加交互的对象放在图的最上方，沿水平方向排列。通常把发起交互的对象放在左边，下级对象依次放在右边。然后把这些对象发送和接收的消息沿垂直方向按时间顺序从上到下放置。这样，就提供了控制流随时间推移的清晰的可视化轨迹。（消息在箭头上传递，对象作为实体在最上端）

（4）活动图

描述过程行为和并行行为。它是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程，对于系统的功能建模特别重要，并强调对象间的控制流程。活动图中的分岔和汇合线是一条水平粗线。牢记图中并发分岔、并发汇合、监护表达式、分支、流等名词及含义。每个分岔的分支数代表了可同时运行的线程数。活动图中能够并行执行的是在一个分岔粗线下的分支上的活动。

（5）状态图

描述对象状态及其转换。就是一个状态机，由状态、转换、事件等组成。状态是指对象在其生命周期中的某个条件或状态。转换可以通过事件触发，事件触发后相应的监护条件会进行检查。如

下图中圆角矩形表示状态，箭头上表示事件，实心圆表示起点和终点。状态图关注系统的动态视图，强调对象行为的事件顺序。

这是一个接电话的状态图，状态图的状态通常包括简单状态和组合状态（含有子状态的状态称为组合状态），除此之外状态图中还有转换、事件等。

4. 软件项目管理

进度安排的常用图形描述方法有甘特图（GanttChart）和项目计划评审技术图（PERT）。

（1）甘特图（Gantt图）

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

Gantt图实例

优点：能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。缺点：不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。

（2）项目活动图（PERT图）

下面是一个软件项目的活动图（PERT图），描述一个项目中任务和任务之间的关系，顶点表示里程碑，连接顶点的边表示活动，边上的权重表示完成该活动所需要的时间（天）。

关键路径：从开始顶点到结束顶点之间距离最长的一条路径。关键路径上的长度就是完成整个工程项目的最短工期。松弛时间：最迟开始时间-最早开始时间，最迟开始时间从后往前推

（关键路径长度-该活动开始顶点到项目活动图的结束顶点的最长长度），最早开始时间从前往后推（等于项目活动图的开始顶点到该活动开始顶点的最长长度），或者关键路径的总时间-包含该活动的最长路径的总时间。关键路径上的活动的松弛时间均为0。

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

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

(1)最早开始时间(ES)，某项活动能够开始的最早时间。
(2)最早结束时间(EF)，某项活动能够完成的最早时间。EF=ES+工期。
(3)最迟结束时间(LF)，为了使项目按时完成，某项活动必须完成的最迟时间。
(4)最迟开始时间(LS)，为了使项目按时完成，某项活动必须开始的最迟时间。LS=LF-工期顺推：最高开始ES=所有前置活动最早完成EF的最大值；最早完成EF=最早开始ES+持续时间。

逆推：最晚完成 $\mathrm{LF} =$ 所有后续活动最晚开始LS的最小值；最晚开始 $\mathrm{LS} =$ 最晚完成LF-持续事件。

图10-14 关键路径法示例

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

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

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

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

掌握关键路径的计算，会依据表格和题目描述画图，然后求出关键路径。

2.3 数据库系统设计

选做题，几乎每年必考1题，主要考查数据库的一些新技术的比较，如关系型数据库、非关系型数据库NoSQL以及内存数据库Redis等，还会包括反规范化技术、主从复制、负载均衡等。

1. ORM技术

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

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

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

数据库的表(table)—>类(class)

记录(record，行数据)–对象(object)

字段.field)–>对象的属性(attribute)

ORM 的优点：

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

ORM的缺点：

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

2. 数据库类型比较

关系型数据库：关系数据库，是建立在关系模型基础上的数据库，借助集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。

简单地说，关系型数据库是由多张能互相联接的二维行列表格组成的数据库。

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

内存数据库：将数据库整体存储在内存中，提高性能，如Redis。

表 2.3 关系数据库模式与 NoSQL 模式的特征对比

表 2.4 内存数据库与关系数据库的对比

表 2.5 关系型数据库与文件系统的对比

3. 缓存技术

（1）Redis

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

表 2.6 Redis 数据类型表

Redis 新版本增加的数据类型： bitmap：更细化的一种操作，以 bit 为单位；hyperloglog：基于概率的数据结构。为 V2.8.9 新增；geo：地理位置信息的存储，并对这些信息进行操作，为 V3.2 新增；stream：流，相当于消息队列的 topic，为 V5.0 新增。

（2）MemCache

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

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

Redis与Memcache的差异：

① 数据类型方面。Redis 和 Memcache 都是将数据存放在内存中，都是内存数据库。他们都支持 Key-Value 数据类型。同时 Memcache 还可用于缓存其他东西，如图片、视频等（仍是 key/value 缓存），Redis 还支持 List、Set、Hash 等数据结构的存储。
②内存管理机制方面。在Redis中，并不是所有的数据都一直存储在内存中的，这是和Memcached相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的Value交换到磁盘。而在Memcached中，数据都是缓存在内存中。
③数据持久化方面。Redis支持内存数据的持久化（定期保存到磁盘），而且提供两种主要的持久化策略：RDB快照和AOF日志。Memcached不支持数据持久化操作。Redis支持数据的备份，即master-slave模式的数据备份。Memcache宕机后，数据不可恢复，Redis数据丢失后可以通过AOF恢复。

表 2.7 Redis 与 MemCache 能力比较

缓存中的常见问题：

• 缓存击穿是指在高并发访问下，被频繁访问的数据项在缓存中失效时，大量的并发请求会直接涌入后端存储数据库上，导致数据库负载增大。缓存击穿可以通过使用互斥锁、分布式锁、热点数据预加载等方式来避免。
• 雪崩是指缓存层整体失效，导致大量请求涌入后端。雪崩问题可以通过设置不同的过期时间、使用多个独立的缓存集群等来避免。
• 缓存穿透是指请求查询一个不存在于缓存和数据库中的键。缓存穿透可以使用布隆过滤器来判

断请求的键是否有效，从而减轻数据库压力。

4. 分布式锁

分布式锁是一种在分布式系统环境下，通过多个节点对共享资源进行访问控制的一种同步机制。它的主要目的是防止多个节点同时操作同一份数据，从而避免数据的不一致性。

一般来说，实现分布式锁的方式有以下几种：

（1）使用MySQL，基于唯一索引。
（2）使用 ZooKeeper，基于临时有序节点。
（3）使用Redis，基于setnx命令。

Redis 实现简单分布式锁过程：

（1）获取锁：使用 setnx 命令加锁（key 不存在时加锁成功），并使用 expire 命令为锁添加一个超时时间（避免死锁），超过该时间则自动释放锁，锁的 value 值为一个随机生成的 UUID。
（2）释放锁：通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。

解决死锁的策略：设置锁的超时时间、使用Redlock算法、引入锁的等级、使用一致性哈希算法以及使用锁粒度更小的方式等。

5. 不规范化带来的四大问题

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

(1)数据冗余：数据被重复存储，如某门课程有100个学生选修，那么在R关系中就要出现100个元组，这门课程的任课教师姓名和地址也随之重复出现100次。
(2)修改异常：修改导致数据不一致，如由于上述冗余问题，当需要修改这个教师的地址时，就要修改100个元组中的地址值，否则就会出现地址值不一致的现象。
(3)插入异常：插入时异常，如不知道听课学生名单，这个教师的任课情况和家庭地址就无法进入数据库；否则就要在学生姓名处插入空值。
(4)删除异常：删除了不该删除的数据，如当只有一条记录时，要删除这个学生选课信息，会将课程名、教师名和教师地址都给删除了。

6. 反规范化技术

规范化设计后，数据库设计者希望牺牲部分规范化来提高性能，这种从规范化设计的回退方法称为反规范化技术。

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

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

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

7. 并发控制

并发操作就是在多用户系统中，可能出现多个事务同时操作同一数据的情况。并发操作会导致3种数据不一致的问题：

1. 丢失更新

当两个事务T1和T2读入同一数据做修改，并发执行时，T1把T2或T2把T1的修改结果覆盖掉，造成了数据的丢失更新问题，导致数据不一致。

2. 不可重复读

事务T1读取了数据R，事务T2读取并更新了数据R。当事务T1再读取数据R以进行核对时，得到的两次读取数据不一致。

3. 读脏数据

事务T1更新了数据R，事务T2读取了更新后的数据R，事务T1由于某种原因被撤销，进行了事务回滚，数据R恢复原值，事务T2读取了脏数据。

造成以上3种数据不一致的主要原因是事务的并发操作破坏了事务的隔离性。

8.封锁协议

并发控制的主要技术是封锁（Lock）技术。

表 2.6 两种封锁协议

加锁遵循一个基本原则：如果该事务只读数据，就只加读锁；如果该事务要写数据，就加写锁。

9. 分布式数据库

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

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

分布式数据库的优点：

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

10. 数据分片

数据分片将数据库整体逻辑结构分解为合适的逻辑单位(片段)，然后由分布模式来定义片段及其副本在各场地的物理分布，其主要目的是提高访问的局部性，有利于按照用户的需求，组织数据的分布和控制数据的冗余度。

(1)水平分片。水平分片将一个全局关系中的元组分裂成多个子集，每个子集为一个片段。分片条件由关系中的属性值表示。对于水平分片，重构全局关系可通过关系的并操作实现。
(2)垂直分片。垂直分片将一个全局关系按属性分裂成多个子集，应满足不相交性(关键字除外)。对于垂直分片，重构全局关系可通过连接运算实现。
(3)导出分片。导出分片又称为导出水平分片，即水平分片的条件不是本关系属性的条件，而是其他关系属性的条件。
(4)混合分片。混合分片是在分片中采用水平分片和垂直分片两种形式的混合。

分布透明性是指用户不必关心数据的逻辑分片，不必关心数据存储的物理位置分配细节，也不必关心局部场地上数据库的数据模型。

(1)分片透明性是分布透明性的最高层次，它是指用户或应用程序只对全局关系进行操作而不必考虑数据的分片。
(2)位置透明性。位置透明性是指用户或应用程序应当了解分片情况，但不必了解片段的存储场地。
(3)局部数据模型透明性。局部数据模型透明性是指用户或应用程序应当了解分片及各片断存储的场地，但不必了解局部场地上使用的是何种数据模型。

11. 数据仓库

数据仓库集成是把多种来源的数据集中在一起，建立数据仓库，所有数据都驻留在单个数据库

服务器上，配置大型处理器和存储容量。数据仓库主要用于决策支持，在数据处理过程中强调分析。其特点是：(1)集成的数据；(2)面向主题；(3)数据相对稳定；(4)包含历史信息。

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

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

2.4 嵌入式系统设计

几乎每年必考一题，选做题，考查较多的是嵌入式系统的实时性和可靠性以及容错等概念。大概率会考到一些嵌入式领域陌生技术，如果是完全没见过的技术，不选即可。

这一块没什么内容补充，超纲较多而且不会考第二遍。

2.5 Web 系统设计

选做题，几乎每年必考1题。主要考查Web相关技术，尤其是新技术的应用，涵盖基础知识章节：系统设计-Web应用设计。

Web技术一般不会重复考查，每年都有新技术，需要依据答题技巧灵活应变，遇到完全没听说过的技术，就不选，一般结合架构进行考查。

1. Web 应用技术分类

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

从缓存来看：MemCache，Redis，Squid。

从并发分流来看：集群(负载均衡)、CDN。

从数据库来看：主从库(主从复制)，内存数据库，反规范化技术，NoSQL，分区(分表)技术，视图与物化视图。

从持久化来看：Hibernate，Mybatis。

从分布存储来看：Hadoop，FastDFS，区块链。

从数据编码看：XML，JSON。

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

其它：有状态与无状态，响应式Web设计等。

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

应用服务器集群

存在的问题：

用户的请求由谁来转发到具体的应用服务器；

用户如果每次访问到的服务器不一样，那么如何维护session的一致性（负载均衡和有无状态问题）。

数据库服务器

采用负载均衡技术

数据库服务器

负载均衡技术

应用层负载均衡技术

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

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

2、反向代理服务器。在用户的请求到这反向代理服务器时(已经到达网站机房)，由反向代理服务器根据算法转发到具体的服务器。常用的Apache，Nginx都可以充当反向代理服务器。

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

传输层负载均衡技术

1、DNS域名解析负载均衡。DNS域名解析负载均衡就是在用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。
特点：效率比HTTP重定向高，减少维护负载均衡服务器成本。但一个应用服务器故障，不能及时通知DNS，而且DNS负载均衡的控制权在域名服务商那里，网站无法做更多的改善和更强大的管理。
2、基于NAT的负载均衡。基于NAT的负载均衡将一个外部IP地址映射为多个IP地址，对每次连接请求动态地转换为一个内部节点的地址。

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

数据库集群分为主从库

用缓存缓解库读取压力

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

2. CDN

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

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。CDN主要加速静态资源，如HTML、CSS、JS、图片、视频等。

3. REST(表述性状态传递)

REST（Representational State Transfer，REST），即表述性状态转移，是一种针对网络应用设计和开发的架构风格，可以降低开发的复杂性，提高系统的可伸缩性。目的是为了让不同的软件或应用程序在任何网络环境下都可以进行信息的互相传递。

REST的核心思想是，将Web应用程序的功能作为资源来表示，使用统一资源标识符（URI）

来对这些资源进行操作，并通过 HTTP 协议（GET、POST、PUT、DELETE 等）来定义对这些资源的操作，强调无状态、缓存机制、统一接口、分层系统、客户端-服务器分离等原则。

RESTful 是遵循 REST 原则的 Web 服务，是 REST 的形容词。

REST的核心概念：

（1）资源。REST是以资源为中心构建，资源可以是一个订单，也可以是一幅图片。将互联网中一切暴露给客户端的事物都可以看作是一种资源，对资源相关数据和表述进行组合，借助URI（统一资源标识符）标识Web上的资源，客户端通过这个URI来访问资源。资源和URI是一对多关系。
(2)表述。REST中用表述描述资源在Web中某一个时间的状态。客户端和服务端借助RESTful API传递数据，实际就是在进行资源表述的交互。表述在Web中常用表现形式有HTML、JSON、XML、纯文本等，但是资源表述返回客户端的形式只是统一格式，是开发阶段根据实际需求设计一个统一的表述格式。
（3）状态转移。REST定义中状态分为两种：应用状态和资源状态。应用状态是对某个时间内用户请求会话相关信息的快照，保存在客户端，由客户端自身维护，可以和缓存配合降低服务端并发请求压力。资源状态在服务端保存，是对某个时间资源请求表述的快照，保证在服务端，如果一段时间内没有对资源状态进行改变，则客户端对同一资源请求返回的表述一致。同时状态转移还要借助HTTP方法来实现，如GET、POST、DELETE方法。
（4）超链接。超链接是通过在页面中嵌入链接和其他资源建立联系，这里的资源可以是文本、图片、文件等。REST定义中超链接是很重要的一部分，在资源表述中除了处理当前请求资源信息外，还会添加一些相关资源 URI，将一些资源接口暴露给客户端，便于用户请求这些资源，实现资源状态转移。这些超链接是包含在应用状态中，由客户端维护保存，并不是服务端提前设定好的，是服务请求过程中添加进去，客户端对其解析提供给用户。

REST是一种设计风格而不是一个架构。

REST的主要特点：

（1）无状态性。服务器不保存客户端的状态信息。每次请求都是独立的，服务器根据请求本身（包括 URI、HTTP方法、请求头、请求体等）来响应请求。这有助于构建可伸缩的服务器，因为服务器可以轻松地处理大量的并发请求。
（2）缓存。REST允许对响应进行缓存。客户端可以缓存GET请求的响应，并在需要时重用这些缓存的响应，而无需再次与服务器通信。这可以显著提高应用程序的性能。
（3）统一接口。REST 风格要求客户端和服务器之间通过统一的接口进行交互。这包括使用标准的 HTTP 方法来表示对资源的操作，以及使用标准的 HTTP 状态码来表示请求的结果。

（4）分层系统。客户端不能直接与服务器交互，而是通过一系列的中间层（如负载均衡器、安全层）来与服务器通信。这些中间层对客户端是透明的，客户端不需要知道它们的存在。
（5）客户端-服务器。REST风格基于客户端-服务器模型，客户端发送请求，服务器接收并处理请求，然后返回响应。客户端和服务器之间的交互是松耦合的（相互分离），这有助于系统的扩展和维护。

4. 微服务

微服务架构将一个大型的单个应用或服务划分成一组微型、可独立部署的服务，微服务架构围绕业务领域将服务进行拆分，每个服务可以独立进行开发、管理和迭代，彼此之间使用统一接口进行交流，实现了在分散组件中的部署、管理与服务功能，使产品交付变得更加简单，从而达到有效拆分应用，实现敏捷开发与部署的目的。

微服务架构

微服务的优势：

（1）复杂应用解耦。微服务架构将单一模块应用分解为多个微服务，同时保持总体功能不变。
（2）独立。每个微服务可进行独立开发与部署，并具备独立的运行进程。
(3)技术选型灵活。开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术。
（4）容错。由于各个微服务相互独立，故障会被隔离在单个服务中，并且其他微服务可通过重试、平稳退化等机制实现应用层的容错，从而提高系统应用的容错性。
（5）松耦合，易扩展。微服务架构中每个服务之间都是松耦合的，可以根据实际需求实现独立扩展，体现微服务架构的灵活性。

微服务架构带来的挑战：

（1）并非所有的系统都能转成微服务。例如一些数据库层的底层操作是不推荐服务化的。
（2）部署较以往架构更加复杂：系统由众多微服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，容器技术能够解决这一问题。
（3）性能问题：由于微服务注重独立性，互相通信时只能通过标准接口，可能产生延迟或调用

出错。例如一个服务需要访问另一个服务的数据，只能通过服务间接口来进行数据传输，如果是频繁访问，则可能带来较大的延迟。

（4）数据一致性问题：作为分布式部署的微服务，在保持数据一致性方面需要比传统架构更加困难。

表 2.9 微服务与 SOA 比较

表 2.10 微服务架构实现与 SOA 实现对比

5. XML和JSON

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

XML 的优点：

• 格式统一，符合标准；

• 容易与其他系统选行远程交互，数据共享比较方便。

XML的缺点：

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

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

JSON 的优点：

• 数据格式比较简单，易于读写，格式都是压缩的，占用带宽小；
• 易于解析，客户端 JavaScript 可以简单的通过 eval()进行 JSON 数据的读取；
• 支持多种语言，包括ActionScript、C、C###、ColdFusion、Java、JavaScript、Perl、PHP、Python、Ruby等服务器端语言，便于服务器端的解析；

因为JSON格式能直接为服务器端代码使用，大大简化了服务器端和客户端的代码开发量，且完成任务不变，并且易于维护。

JSON的缺点：

没有XML格式这么推广的深入人心和喜用广泛，没有XML通用性强。

6. 有状态和无状态

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

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

7.响应式Web设计

响应式Web设计是一种网络页面设计布局，其理念是：集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境进行相对应的布局调整，提供最佳的显示效果。

方法与策略：

（1）采用流式布局和弹性化设计：使用相对单位，设定百分比而非具体值的方式设置页面元素的大小。
（2）响应式图片：不仅要同比的缩放图片，还要在小设备上降低图片自身的分辨率。

8. Web 应用服务器

WEB应用服务器可以理解为两层意思：

（1）WEB服务器：其职能较为单一，就是把浏览器发过来的Request请求，返回HTML页面。
（2）应用服务器：进行业务逻辑的处理。

Apache：Web服务器，市场占有率达 $60%$ 右。它可以运行在几乎所有的Unix、Windows、Linux系统平台上。

IIS早期Web服务器，目前小规模站点仍有应用。

Tomcat：开源、运行servlet和JSPWeb应用软件的基于Java的Web应用软件容器。

JBOSS：JBOSS是基于J2EE的开放源代码的应用服务器，一般与Tomcat或Jetty绑定使用。

WebSphere：一种功能完善、开放的Web应用程序服务器，是基于Java的应用环境，用于建立、部署和管理Internet和IntranetWeb应用程序。

Weblogic：BEA Weblogic Server 是一种多功能、基于标准的 web 应用服务器，为企业构建自己的应用提供了坚实的基础。

Jetty: Jetty 是一个开源的 servlet 容器，是基于 Java 的 web 容器。

9. 缓存技术

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

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

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

和一般的代理缓存软件不同，Squid用一个单独的、非模块化的、I/O驱动的进程来处理所有的客户端请求。

Redis与Memcache的差异

（1）Redis 和 Memcache 都是将数据存放在内存中，都是内存数据库。他们都支持 key-value 数据类型。同时 Memcache 还可用于缓存其他东西，例如图片、现频等等，Redis 还支持 list、set、hash 等数据结构的存储。
（2）Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用，Memcache挂掉之后，数据就没了。

（3）灾难恢复。Memcache挂掉后，数据不可恢复；Redis数据丢失后可以恢复。
（4）在Redis中，并不是所有的数据部一直存储在内存中的。这是和Memcache相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。
（5）Redis在很多方面支持数据库的特性，可以这样说他就是一个数据库系统，而Memcache只是简单地K/V缓存。

所以在选择方面如果有持久方面的需求或对数据类型和处理有要求的应该选择Redis。

如果简单的key/value存储应该选择Memcache。

系统架构设计师学习QQ群：231352210 软件设计师学习QQ群：1169209218

诸葛老师QQ: 362842353

VIP购买方式，淘宝搜索：软考诸葛老师

第3章 第二版教材下篇架构设计考点

3.1 信息系统架构设计

3.1.1 信息系统架构基本概念

信息系统架构(ISA)是指对某一特定内容里的信息进行统筹、规划、设计、安排等一系列有机处理的活动。

为了更好地理解信息系统架构的定义，特作如下说明：

(1)架构是对系统的抽象，它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象。因此，仅与内部具体实现有关的细节是不属于架构的，即定义强调元素的“外部可见”属性。
(2)架构由多个结构组成，结构是从功能角度来描述元素之间的关系的，具体的结构传达了架构某方面的信息，但是个别结构一般不能代表大型信息系统架构。
(3)任何软件都存在架构，但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而存在。如文档已过时，则该文档不能反映架构。
(4)元素及其行为的集合构成架构的内容。体现系统由哪些元素组成，这些元素各有哪些功能(外部可见)，以及这些元素间如何连接与互动。即在两个方面进行抽象：在静态方面，关注系统的大粒度(宏观)总体结构(如分层)；在动态方面，关注系统内关键行为的共同特征。

(5)架构具有“基础”性：它通常涉及解决各类关键重复问题的通用方案(复用性)，以及系统设计中影响深远(架构敏感)的各项重要决策(一旦贯彻，更改的代价昂贵)。
(6)架构隐含有“决策”，即架构是由架构设计师根据关键的功能和非功能性需求(质量属性及项目相关的约束)进行设计与决策的结果。

3.1.2 信息系统架构

1. 架构风格

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

2. 信息系统架构分类

信息系统架构可分为物理结构与逻辑结构两种，物理结构是指不考虑系统各部分的实际工作与功能结构，只抽象地考查其硬件系统的空间分布情况。逻辑结构是指信息系统各种功能子系统的综合体。

物理结构一般分为集中式与分布式两大类。

在信息系统开发中，强调各子系统之间的协调一致性和整体性。要达到这个目的，就必须在构造信息系统时注意对各种子系统进行统一规划，并对各子系统进行综合。

1)横向综合：将同一管理层次的各种职能综合在一起，例如，将运行控制层的人事和工资子系统综合在一起，使基层业务处理一体化。
2)纵向综合：把某种职能的各个管理层次的业务组织在一起，这种综合沟通了上下级之间的联系，如工厂的会计系统和公司的会计系统综合在一起，它们都有共同之处，能形成一体化的处理过程。
3)纵横综合：主要是从信息模型和处理模型两个方面来进行综合，做到信息集中共享，程序尽量模块化，注意提取通用部分，建立系统公用数据库和统一的信息处理系统。

3. 信息系统架构的一般原理

信息系统架构指的是在全面考虑企业的战略、业务、组织、管理和技术的基础上，着重研究企业信息系统的组成成分及成分之间的关系，建立起多维度分层次的、集成的开放式体系结构，并为企业提供具有一定柔性的信息系统及灵活有效的实现方法。

4. 信息系统常用4种架构模型

（1）单机应用模式（Standalone)：是最简单的软件结构，是指运行在一台物理机器上的独立应用程序。单机系统本身也可以很复杂。
（2）客户机/服务器（Client/Server）模式：即两层、三层C/S、B/S模式、MVC模式等。
（3）面向服务架构（SOA）模式。
（4）企业数据交换总线：不同的企业应用之间进行信息交换的公共通道。

5. 企业信息系统的总体框架

要在企业中建立一个有效集成的ISA，必须考虑企业中的四个方面：战略系统、业务系统、应用系统和信息基础设施。

图12-7 信息系统体系结构的总体框架

（1）战略系统

战略系统是指企业中与战略制定、高层决策有关的管理活动和计算机辅助系统。

在ISA中战略系统由两个部分组成，其一是为以计算机为基础的高层决策支持系统，其二是企业的战略规划体系。

在ISA中设立战略系统有两重含义：一是它表示信息系统对企业高层管理者的决策支持能力；二是它表示企业战略规划对信息系统建设的影响和要求。

（2）业务系统

业务系统是指企业中完成一定业务功能的各部分(物质、能量、信息和人)组成的系统。

作用：对企业现有业务系统、业务过程和业务活动进行建模，并在企业战略的指导下，采用业务流程重组(BPR)的原理和方法进行业务过程优化重组。

（3）应用系统

应用系统即应用软件系统，指信息系统中的应用软件部分。如TPS、MIS、DSS等。

包含两个基本组成部分：内部功能实现部分和外部界面部分。

（4）企业信息基础设施

企业信息基础设施(EII)是指根据企业当前业务和可预见的发展趋势，及对信息采集、处理、存

储和流通的要求，构筑由信息设备、通信网络、数据库、系统软件和支持性软件等组成的环境。这里可以将企业信息基础设施分成三部分：技术基础设施、信息资源设施和管理基础设施。

·技术基础设施由计算机、网络、系统软件、支持性软件、数据交换协议等组成；
·信息资源设施由数据与信息本身、数据交换的形式与标准、信息处理方法等组成；

• 管理基础设施指企业中信息系统部门的组织结构、信息资源设施管理人员的分工、企业信息基础设施的管理方法与规章制度等。

3.1.3 信息系统架构设计方法

1.ADM架构开发方法

（1）TOGAF概述

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

该框架旨在通过以下四个目标帮助企业组织和解决所有关键业务需求：确保从关键利益相关方到团队成员的所有用户都使用相同的语言、避免被“锁定”到企业架构的专有解决方案、节省时间和金钱更有效地利用资源、实现可观的投资回报。

TOGAF 框架核心思想：模块化架构、内容框架、扩展指南、架构风格。

TOGAF的关键是架构开发方法（Architecture Development Method：ADM），为开发企业架构所需要执行各个步骤以及它们之间的关系进行详细的定义。

（2）ADM架构开发方法

ADM方法是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成。

将ADM全生命周期十个阶段主要活动：

表 3.1 ADM 架构设计方法各阶段主要活动

ADM三个级别的迭代：基于ADM整体的迭代、多个开发阶段间的迭代、在一个阶段内部的迭代。

2. 信息化总体架构方法

（1）信息化的一般概念

信息化是指培育、发展以智能化工具为代表的新的生产力井使之造福于社会的历史过程。

实现信息化就要构筑和完善6个要素(开发利用信息资源，建设国家信息网络，推进信息技术应用，发展信息技术和产业，培育信息化人才，制定和完善信息化政策)的国家信息化体系。

完整的信息化内涵包括四方面内容：信息网络体系、信息产业基础、社会运行环境、效用积累过程。

信息化建设指品牌利用现代信息技术来支撑品牌管理的手段和过程。信息化建设包括了企业规模，企业在电话通信、网站、电子商务方面的投入情况，在客户资源管理、质量管理体系方面的建设成就等。

信息化主要体现以下6种特征：易用性；健壮性；平台化、灵活性、扩展性；安全性；门户化、整合性；移动性。

（2）信息化工程建设方法

信息化架构一般有两种模式，一种是数据导向架构，一种是流程导向架构。对于数据导向架构重点是在数据中心，BI商业智能等建设中使用较多，关注数据模型和数据质量；对于流程导向架构，SOA本身就是关键方法和技术，关注端到端流程整合，以及架构对流程变化的适应度。两种架构并没有严格的边界，而是相互配合和补充。

数据导向架构研究的是数据对象和数据对象之间的关系，这个是首要的内容。在这个完成后仍然要开始考虑数据的产生、变更、废弃等数据生命周期，这些自然涉及的数据管理的相关流程。

流程导向架构关注的是流程，架构本身目的是为了端到端流程整合服务。因此研究切入点会是价值链分析，流程分析和分解，业务组件划分。

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

1）系统规划阶段：任务是对组织的环境、目标及现行系统的状况进行初步调查，根据组织目标和发展战略确定信息系统的发展战略，对建设新系统的需求做出分析和预测，同时考虑建设新系统所受的各种约束，研究建设新系统的必要性和可能性。根据需要与可能，给出制建系统的备选方案。

输出：可行性研究报告、系统设计任务书。

2）系统分析阶段：任务是根据系统设计任务书所确定的范围，对现行系统进行详细调查，描述现行系统的业务流程，指出现行系统的局限性和不足之处，确定新系统的基本目标和逻辑功能要求，即提出新系统的逻辑模型。系统分析阶段又称为逻辑设计阶段。这个阶段是整个系统建设的关键阶段，也是信息系统建设与一般工程项目的重要区别所在。

输出：系统说明书。

3）系统设计阶段：系统分析阶段的任务是回答系统“做什么”的问题，而系统设计阶段要回答的问题是“怎么做”。该阶段的任务是根据系统说明书中规定的功能要求，具体设计实现逻辑模型的技术方案，也就是设计新系统的物理模型。这个阶段又称为物理设计阶段，可分为总体设计(概要设计)和详细设计两个子阶段。

输出：系统设计说明书(概要设计、详细设计说明书)。

4）系统实施阶段：是将设计的系统付诸实施的阶段。这一阶段的任务包括计算机等设备的购置、安装和调试、程序的编写和调试、人员培训、数据文件转换、系统调试与转换等。这个阶段的特点是几个互相联系、互相制约的任务同时展开，必须精心安排、合理组织。系统实施是按实施计划分阶段完成的，每个阶段应写出实施进展报告。系统测试之后写出系统测试分析报告。

输出：实施进展报告、系统测试分析报告。

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

3.1.4 信息系统架构案例分析

1. 价值驱动的体系结构–连接产品与体系结构

价值模型核心的特征可以简化为三种基本形式：

(1)价值期望值：表示对某一特定功能的需求，包括内容(功能)、满意度(质量)和不同级别质量的实用性。
(2)反作用力：系统部署实际环境中，实现某种价值期望值的难度，通常期望越高难度越大，即反作用力。
(3)变革催化剂：表示环境中导致价值期望值发生变化的某种事件，或者是导致不同结果的限制因素。

反作用力和变革催化剂称为限制因素，把这三个统称为价值驱动因素。

体系结构挑战是因为一个或多个限制因素使得满足一个或多个期望值变得更困难。制定系统的体系结构策略始于：

(1)识别合适的价值背景并对其进行优先化。
(2)在每一背景中定义效用曲线和优先化期望值。
(3)识别和分析每一背景中的反作用力和变革催化剂。
(4)检测限制因素使满足期望值变难的领域。

优化体系结构需要权衡：重要性、程度、后果、隔离。

2. Web 服务在 HL7 上的应用–Web 服务基础实现框架

（1）HL7模型概念

对于一个给定的卫生保健领域，HL73.0版本说明书是基于参考信息模型的(RIM)。这是一种公共的模型框架，包括病例模型、信息模型、交互模型、消息模型和实现信息说明书。

（2）体系结构

HL7应用参考体系结构：
图12-12 参考体系结构

能够抽象出H7发送者/接收者内部的这两组功能：商业逻辑和Web服务适配器。

商业逻辑的任务如下。

(1)发送端：创建一种具体HL7消息类型的XML描述，消息类型包含消息体、Transmission and Control Wrappers。将消息传送到Web服务适配器，适配器负责传送到接收应用端。
(2)接收端：“找回”由Web服务适配器接收的HL7消息，同时从接收到的XML消息那里打开Transmission Wrapper、Control Wrapper和消息体；验证HL7消息是否满足用来交互的商业规则和约束；核实发送应用端是否需要一个应用层的确认信息(HL7消息类型 MCI)——如果是那样的话，发送那个消息。

Web服务适配器的功能主要是用来处理消息的分发和确认信息。因此，主要包括如下内容。

1)发送端

读取接收到的HL7消息的Transmission Wrapper，以便决定如何到达Web服务基层结构上的发送容器(例如接收应用软件)，从而配置SOAP。

(2)基于HL7消息类型、应用配置和规则(如安全性)来准备一个SOAP消息，包括作为一个SOAP

消息体部分的 HL7XML 消息，这个消息被发送到 Web 服务基层组织。

(3)把SOAP消息传递到Web服务代理，通过网络进行传输。
(4)无论发送端什么时候请求，都准备接收并存储来自接收端的相应信息或是应用层的确认消息。

2)接收端

(1)从Web服务站处接收SOAP消息。
(2)验证接收到的SOAP消息满足应用配置和一些约束条件(如安全性)。
(3)或者将这些接收到的消息在内存中以永久的形式保留。
(4)有选择性地从SOAP消息里打开HL7XML消息，同时核对接收到的HL7消息是否与期望的HL7消息类型相符合。
(5)验证是否任意通信层的确认信息都需要被执行，在哪种情况下需要返回一个合适的消息发送到源消息发送端。
(6)传递 HL7 消息给接收应用端。

3. 以服务为中心的企业整合

（1）案例背景

某航空公司已经在几个主要的核心系统之间构建了用于信息集成的信息Hub(Information Hub)，其他应用间也有不少点到点的集成。然而还存在如下困难：

(1)因为大部分核心应用构建在主机之上，所以InformationHub是基于主机技术开发，很难被开放系统使用。
(2) Information Hub 对 Event 支持不强，被集成的系统间的事件以点到点流转为主，被集成系统间耦合性强。
(3)牵扯到多个系统间的业务协作以硬编码为主，将业务活动自动化的成本高，周期长，被开发的业务活动模块重用性差。

为了解决这些企业集成中的问题，该公司决定以Ramp Control系统为例探索一条以服务为中心的企业集成道路。

（2）业务环境分析

在航空业中，Ramp Coordination是指飞机从降落到起飞过程中所需要进行的各种业务活动的协调过程。需要协调的业务活动有：检查机位环境是否安全，以及卸货、装货和补充燃料是否方便和安全等。

三种类型航班：short turn around 航班是降落后不久就起飞的航班、Arrival Only 航班指降落后需要隔夜才起飞的，Departure Only 航班是指每天一早第一班飞机。

每种细分的航班类型的Ramp Coordination的流程都是略有不同。如此多的流程之间共享着一个业务活动的集合，如此多种类型的流程都是这些业务活动的不同组装方式。以服务为中心的企业集成中流程服务就是通过将这些流程间共享的业务活动抽象为可重用的服务，并通过流程服务提供的流程编排的能力将它们组成各种大同小异的流程类型，来降低流程集成成本，加快流程集成开发效率的。以服务为中心的企业集成，通过服务建模过程发现这些可重用的服务，并通过流程模型将这些服务组装在一起。

（3）服务建模

Ramp Coordination 相关的服务模型和 Ramp Coordination 流程相关的有两个业务组件：

①Ramp Control 负责 Ramp Control 相关各种业务活动的组件；
② Flight Management 负责航班相关信息的管理，包括航班日程，乘客信息等。

这两个业务组件分别输出如下服务。

(1) Retrieve Flight B0: 由 Flight Management 输出，主要用于提取和航班相关的数据信息。
(2)Ramp Coordination：由 Ramp Control 输出，主要用于 Ramp Coordination 流程的编排。
(3)Check Spot：由Ramp Control输出，用于检测机位安全信息。
(4)Check Unloading：由Ramp Control输出，用于检查卸货状况。
(5)Check Loading：由Ramp Control输出，用于检查装货状况。
(6)CheckPushBack：由RampControl输出，用于检查关门动作。

4. IT环境分析

目前，Ramp Coordination 流程需要 4 种类型的外围应用交互。

(1)从乘务人员管理系统提取航班乘务员的信息。
(2)从订票系统中提取乘客信息。
(3)从机务人员管理系统中提取机务人员信息。
(4)接收来自航班调度系统的航班到达事件。

5. 高层架构设计

据需求和设计阶段的业务模型和现有IT环境调研结果，再结合传统的IT应用开发方法，Ramp Coordination系统的高层架构被设计了出来，如下图所示。

图12-15RampCoordination系统架构

主要架构元素如下：

(1)信息服务。Federation Service 是 Ramp Coordination 流程中需要从已有系统中提取 4 类信息，在 Service 建模阶段这 4 类信息被聚合为 Flight BO(Business Object)，集成了的 Crew Info、Cockpit Info 和 Passage Info 等信息。
(2)企业服务总线中的事件服务。Event Service 是在检查机务环境安全(Check Spot)前，Ramp Coordinator 需要被通知航班已经到达。这个业务事件由航班调度系统激发，Flight Arrival 是典型事件发现服务(Event Detect Service)，它通过 MQ 将事件传递给 Message Broker，通过 JMS 的 Pub/Sub，这个事件被分发给 Check Spot。

(3)流程服务。

(4)企业服务总线中的传输服务。RCMS是即将新建系统，用于提供包括Ramp Coordination在内的Ramp Control的功能。

3.2 层次式架构设计

3.2.1 层次式架构概述

软件体系结构贯穿于软件研发的整个生命周期内，具有重要的影响，表现为三个方面：利益相关人员之间的交流、系统设计的前期决策、可传递的系统级抽象。

层次式体系结构设计是将系统组成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。

软件层次式体系结构是最通用的架构，也被叫作N层架构模式。大部分的应用会分成表现层(或

称为展示层)、中间层(或称为业务层)、数据访问层(或称为持久层)和数据层。

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

常用的层次式架构

3.2.2 表现层框架设计

1. 表现层设计模式

（1）MVC模式

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

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

使用MVC模式来设计表现层，可以有以下的优点。

（1）允许多种用户界面的扩展。在MVC模式中，视图与模型没有必然的联系，都是通过控制器发生关系，这样如果要增加新类型的用户界面，只需要改动相应的视图和控制器即可，而模型则无须发生改动。
（2）易于维护。控制器和视图可以随着模型的扩展而进行相应的扩展，只要保持一种公共的接口，控制器和视图的旧版本也可以继续使用。
（3）功能强大的用户界面。用户界面与模型方法调用组合起来，使程序的使用更清晰，可将友好的界面发布给用户。
（4）将业务处理与显示分离，增加了应用的可拓展性、强壮性及灵活性。基于MVC的优点，目前比较先进的Web应用框架都是基于MVC设计模式的。

(2）MVP模式

MVP是把MVC中的Controller换成了Presenter(呈现)，目的就是为了完全切断View跟Model之间的联系，由Presenter充当桥梁，做到View-Model之间通信的完全隔离。Controller/Publisher负责逻辑的处理，Model提供数据，View负责显示。

MVP模式的优点：

① View 与 Model 完全分离，可以修改视图而不影响模型。
②View与Model不通信，都通过Presenter传递。Presenter完全把Model和View进行了分离，主要的程序逻辑在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之间使用DataBinding及其事件进行通信。ViewModel通常要实现一个观察者，当数据发生变化，ViewModel能够监听到数据的变化，然后通知对应的视图做自动更新；而当用户操作视图，ViewModel也能监听到视图的变化，再通知数据做改动，从而形成数据的双向绑定。这使得MVVM更适用于数据驱动的场景，尤其是数据操作特别频繁的场景。

MVVM设计模式

2. 使用XML设计表现层，统一WebForm与WindowsForm的外观

由于XML的设计目标是描述数据并集中于数据的内容，所以虽然XML和HTML类似，但是业内很少采用XML作为表现层技术，表现层技术仍然是HTML唱主角。但是，由于Web应用程序对特定浏览器的局限以及性能问题，基于窗体表现形式的胖客户端应用程序又开始有了卷土重来的趋势。这两种应用程序各有优势，在未来很长一段时间这两种技术架构都会并存。

因此，许多开发厂商在开发新产品时提出了既要支持胖客户端的表现形式，又要支持Web的表现形式。于是，有人提出将用一个标准的形式描述，对于不同的表现形式，提供特定形式的转换器，根据GUI的描述转换成相应的表现形式。这就要求描述语言有非常好的通用性和扩展性，XML恰恰是这种描述语言理想的载体。

3. 表现层中UIP设计思想

UIP 提供了一个扩展的框架，用于简化用户界面与商业逻辑代码的分离的方法，可以用它来写复杂的用户界面导航和工作流处理，并且它能够复用在不同的场景、并可以随着应用的增加而进行扩展。

使用UIP框架的应用程序把表现层分为了以下几层。

• User Interface Components：这个组件就是原来的表现层，用户看到的和进行交互都是这个组件，它负责获取用户的数据并且返回结果。
• User Interface Process Components：这个组件用于协调用户界面的各部分，使其配合后台的活动，例如导航和工作流控制，以及状态和视图的管理。用户看不到这一组件，但是这些组件为User Interface Components提供了重要的支持功能。

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

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

4. 表现层动态生成设计思想

基于XML的界面管理技术可实现灵活的界面配置、界面动态生成和界面定制。其思路是用XML生成配置文件及界面所需的元数据，按不同需求生成界面元素及软件界面。基于XML界面管理技术，包括界面配置(静态)、界面动态生成和界面定制(动态)三部分。

图13-6基于XML的界面管理技术框图

3.2.3 中间层架构设计

1. 业务逻辑层组件设计

业务逻辑组件分为接口和实现类两个部分。接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法是整个系统运行的核心。增加业务逻辑组件的接口，是为了提供更好的解耦，控制器无须与具体的业务逻辑组件耦合，而是面向接口编程。

2. 业务逻辑层工作流设计

工作流定义为：业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。工作流参考模型见图：其包含6个基本模块，分别是工作流执行服务、工作流引擎、流程定义工具、客户端应用、调用应用和管理监控工具。

图13-7 工作流参考模型

(1)interface1：过程定义导入/导出接口。这个接口的特点是：转换格式和API调用，从而支持过程定义信息间的互相转换。
(2)interface2：客户端应用程序接口。通过这个接口工作流机可以与任务表处理器交互，代表用户资源来组织任务。然后由任务表处理器负责，从任务表中选择、推进任务项。由任务表处理器或者终端用户来控制应用工具的活动。
(3)interface3：应用程序调用接口。允许工作流机直接激活一个应用工具，来执行一个活动。典型的是调用以后台服务为主的应用程序，没有用户接口。当执行活动要用到的工具，需要与终端用户交互，通常是使用客户端应用程序接口来调用那个工具，这样可以为用户安排任务时间表提供更多的灵活性。
(4)interface 4：工作流机协作接口。其目标是定义相关标准，以使不同开发商的工作流系统产品相互间能够进行无缝的任务项传递。
(5)interface 5：管理和监视接口。提供的功能包括用户管理、角色管理、审查管理、资源控制、过程管理和过程状态处理器等。

3. 业务逻辑层实体设计

业务逻辑层实体提供对业务数据及相关功能(在某些设计中)的状态编程访问。业务逻辑层实体可以使用具有复杂架构的数据来构建，这种数据通常来自数据库中的多个相关表。

在应用程序中表示业务逻辑层实体的方法有很多(从以数据为中心的模型到更加面向对象的表示法)，如XML、通用DataSet、有类型的DataSet等。

如下所示是业务实体用XML表示，右图所示为用于Order业务逻辑层实体的通用DataSet对象。此DataSet对象具有两个DataTable对象，分别保存订单信息和订单详细信息。每个DataTable具有一个对应的UniqueConstraint对象，用于标识表中的主键。此外，该DataSet还有一个Relation对象，用于将订单详细信息与订单相关联。

<?xml version="1.0"?>
< Product xmlns="urn: aUniqueNamespace">
< ProductID > 1 < /ProductID >
< ProductName > Chai < /ProductName >
< QuantityPerUnit> 10 boxes x 20 bags < /QuantityPerUnit >
< UnitPrice > 18.00 < /UnitPrice >
< UnitsInStock > 39 < /UnitsInStock >
< UnitsOnOrder > 0 < /UnitsOnOrder >

<ReorderLevel  $>10 <   /$  ReorderLevel  $>$    
</Product>

图13-9 用于Order业务逻辑层实体的通用DataSet

4. 业务逻辑层框架

业务框架位于系统架构的中间层，是实现系统功能的核心组件。采用容器的形式，便于系统功能的开发、代码重用和管理。下图便是在吸收了SOA思想之后的一个三层体系结构的简图。

图13-10 业务框架在整个系统架构中的位置

业务层采用业务容器的方式存在于整个系统当中，采用此方式可以大大降低业务层和相邻各层的耦合，表示层代码只需要将业务参数传递给业务容器，而不需要业务层多余的干预。如此一来，可以有效地防止业务层代码渗透到表示层。

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

(1)Domain Model 是领域层业务对象，它仅仅包含业务相关的属性。
(2)Service是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。
(3)Control 服务控制器，是服务之间的纽带，不同服务之间的切换就是通过它来实现的。

3.2.4 数据访问层设计

1.5种数据访问模式

（1）在线访问：会占用一个数据库连接，读取数据，每个数据库操作都会通过这个连接不断地与后台的数据源进行交互。
（2）DataAccess Object：是标准J2EE设计模式之一，开发人员常常用这种模式将底层数据访问操作与高层业务逻辑分离开。
（3）Data Transfer Object：是经典 EJB 设计模式之一。DTO 本身是这样一组对象或是数据的容器，它需要跨不同的进程或是网络的边界来传输数据。这类对象本身应该不包含具体的业务逻辑，并且通常这些对象内部只能进行一些诸如内部一致性检查和基本验证之类的方法，而且这些方法最好不要再调用其他的对象行为。
（4）离线数据模式：以数据为中心，数据从数据源获取之后，将按照某种预定义的结构(这种结构可以是SDO中的Data图表结构，也同样可以是ADO.NET中的关系结构)存放在系统中，成为应用的中心。离线，对数据的各种操作独立于各种与后台数据源之间的连接或是事务。
（5）对象/关系映射(Object/Relation Mapping，O/R Mapping)：大多数应用中的数据都是依据关系模型存储在关系型数据库中；而很多应用程序中的数据在开发或是运行时则是以对象的形式组织起来的。那么，对象/关系映射就提供了这样一种工具或是平台，能够帮助将应用程序中的数据转换成关系型数据库中的记录；或是将关系数据库中的记录转换成应用程序中代码便于操作的对象。

2. 工厂模式在数据库访问层的应用

首先定义一个操纵数据库的接口 DataAccess，然后根据数据库的不同，由类工厂决定实例化哪个类。

因为 DataAccess 的具体实现类有一些共同的方法，所以先从 DataAccess 实现一个抽象的 AbstractDataAccess 类，包含一些公用方法。然后，分别为 SQL Server、Oracle 和 OleDb 数据库编写三个数据访问的具体实现类。

现在已经完成了所要的功能，下面需要创建一个Factory类，来实现自动数据库切换的管理。这个类很简单，主要的功能就是根据数据库类型，返回适当的数据库操纵类。

3. 事务处理设计

JavaBean中使用JDBC方式进行事务处理：在JDBC中，打开一个连接对象Connection时，默认是auto-commit模式，每个SQL语句都被当作一个事务，即每次执行一个语句，都会自动地得到事务确认。为了能将多个SQL语句组合成一个事务，要将auto-commit模式屏蔽掉。在auto-commit

模式屏蔽掉之后，如果不调用commit()方法，SQL语句不会得到事务确认。在最近一次commit()方法调用之后的所有SQL会在方法commit()调用时得到确认。

4. 连接对象管理设计

通过资源池解决资源频繁分配、释放所造成的问题。

建立连接池的第一步，就是要建立一个静态的连接池。所谓静态，是指池中的连接是在系统初始化时就分配好的，并且不能够随意关闭。Java中给我们提供了很多容器类，可以方便地用来构建连接池，如Vector、Stack等。在系统初始化时，根据配置创建连接并放置在连接池中，以后所使用的连接都是从该连接池中获取的，这样就可以避免连接随意建立、关闭造成的开销。

有了这个连接池，下面就可以提供一套自定义的分配、释放策略。当客户请求数据库连接时，首先看连接池中是否有未分配出去的连接。如果存在空闲连接则把连接分配给客户，并标记该连接为已分配。若连接池中没有空闲连接，就在已经分配出去的连接中，寻找一个合适的连接给客户，此时该连接在多个客户间复用。

当客户释放数据库连接时，可以根据该连接是否被复用，进行不同的处理。如果连接没有使用者，就放入到连接池中，而不是被关闭。

3.2.5 数据架构规划与设计

数据库设计与XML设计融合

XML文档分为两类：一类是以数据为中心的文档，这种文档在结构上是规则的，在内容上是同构的，具有较少的混合内容和嵌套层次，人们只关心文档中的数据而并不关心数据元素的存放顺序，这种文档简称为数据文档，它常用来存储和传输Web数据。另一类是以文档为中心的文档，这种文档的结构不规则，内容比较零散，具有较多的混合内容，并且元素之间的顺序是有关的，这种文档常用来在网页上发布描述性信息、产品性能介绍和E-mail信息等。

经提出的XML文档的存储方式有两种：基于文件的存储方式和数据库存储方式。

(1)基于文件的存储方式。基于文件的存储方式是指将XML文档按其原始文本形式存储，主要存储技术包括操作系统文件库、通用文档管理系统和传统数据库的列。这种存储方式需维护某种类型的附加索引，以建立文件之间的层次结构。基于文件的存储方式的特点：无法获取XML文档中的结构化数据；通过附加索引可以定位具有某些关键字的XML文档，一旦关键字不确定，将很难定位；查询时，只能以原始文档的形式返回，即不能获取文档内部信息；文件管理存在容量大、管理难的缺点。

(2)数据库存储方式。数据库在数据管理方面具有管理方便、存储占用空间小、检索速度快、修改效率高和安全性好等优点。一种比较自然的想法是采用数据库对XML文档进行存取和操作，这样可以利用相对成熟的数据库技术处理XML文档内部的数据。数据库存储方式的特点：能够管理结构化和半结构化数据；具有管理和控制整个文档集合本身的能力；可以对文档内部的数据进行操作；具有数据库技术的特性，如多用户、并发控制和一致性约束等；管理方便，易于操作。

3.2.6 物联网架构设计

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

感知层用于识别物体、采集信息。感知层包括二维码标签和识读器、RFID标签和读写器、摄像头、GPS、传感器、M2M终端、传感器网关等，主要功能是识别对象、采集信息，与人体结构中皮肤和五官的作用类似。感知层解决的是人类世界和物理世界的数据获取问题。

网络层用于传递信息和处理信息。网络层包括通信网与互联网的融合网络、网络管理中心、信息中心和智能处理中心等。网络层将感知层获取的信息进行传递和处理，类似于人体结构中的神经中枢和大脑。网络层解决的是传输和预处理感知层所获得数据的问题。

应用层实现广泛智能化。应用层是物联网与行业专业技术的深度融合，结合行业需求实现行业智能化，这类似于人们的社会分工。

物联网应用层利用经过分析处理的感知数据，为用户提供丰富的特定服务。应用层解决的是信息处理和人机交互的问题。

3.2.7 层次式架构案例分析

1. 电子商务网站（网上商店PetShop）

图13-15Net中标准的BS分层式结构

图13-16 PetShop2.0的体系架构

从图13-16中可以看到，并没有明显的数据访问层设计。这样的设计虽然提高了数据访问的性能，但也同时导致了业务逻辑层与数据访问的职责混乱。

PetShop3.0纠正了此前层次不明的问题，将数据访问逻辑作为单独的一层独立出来。

PetShop 4.0 基本上延续了 3.0 的结构，但在性能上作了一定的改进，引入了缓存和异步处理机制，同时又充分利用了 ASP.Net 2.0 的新功能 MemberShip。

图13-19 数据访问层的模块结构图

可以看到，在数据访问层中，完全采用了“面向接口编程”思想。抽象出来的IDAL模块，脱离了与具体数据库的依赖，从而使得整个数据访问层有利于数据库迁移。DALFactory模块专门管理DAL对象的创建，便于业务逻辑层访问。SQLServerDAL和OracleDAL模块均实现IDAL模块的接口，其中包含的逻辑就是对数据库的Select、Insert、Update和Delete操作。因为数据库类型的不同，对数据库的操作也有所不同，代码也会因此有所区别。

此外，抽象出来的IDAL模块，除了解除了向下的依赖之外，对于其上的业务逻辑层同样仅存在弱依赖关系，如图13-20所示。

图13-20 业务逻辑层的模块结构图

图13-21 表示层的楼块结构

图13-20中，BLL是业务逻辑层的核心模块，它包含了整个系统的核心业务。在业务逻辑层中，不能直接访问数据库，而必须通过数据访问层。注意，图13-20中对数据访问业务的调用，是通过接口模块IDAL来完成的。既然与具体的数据访问逻辑无关，则层与层之间的关系就是松散耦合的。如果此时需要修改数据访问层的具体实现，只要不涉及IDAL的接口定义，那么业务逻辑层就不会受到任何影响。毕竟，具体实现的SQLServerDAL和OracalDAL根本就与业务逻辑层没有半点关系。

2. 基于物联网架构的电子小票服务系统

采用感知层、网络层和应用层的3层物联网体系架构模型：

图13-22 电子小票物联网架构

3.3 云原生架构设计

3.3.1 云原生架构产生背景

云原生（Cloud Native），Cloud指软件都是在云端而非传统数据中心。Native代表应用软件一开始就是基于云环境、专门为云端特性设计，可充分利用和发挥云平台的优势（如弹性+分布式）。

发展历程：瀑布式流程—->敏捷开发—->DevOps。

敏捷开发只是解决了软件开发的效率和版本更新的速度，还没有和运维打通。出于协调开发和运维的“信息对称”问题，开发者又推出了一套新的方法——DevOps，DevOps 可以看作是开发、技术运营和质量保障三者的交集，促进之间的沟通、协作与整合，从而提高开发周期和效率。而云原生的容器、微服务等技术正是为 DevOps 提供了很好的前提条件，保证 IT 软件开发实现 DevOps 开发和持续交付的关键应用。

3.3.2 云原生架构内涵

1. 云原生架构定义

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

云原生的代码通常包括三部分：业务代码、三方软件、处理非功能特性的代码。从业务代码中剥离大量非功能性特性(不会是所有，比如易用性还不能剥离)到IaaS和PaaS中，从而减少业务代码开发人员的技术关注范围，通过云厂商的专业性提升应用的非功能性能力。

具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力，进一步加快软件开发。其特点包括：代码结构发生巨大变化、非功能性特性大量委托、高度自动化的软件交付。

2. 云原生架构原则

（1）服务化原则：拆分为微服务架构、小服务架构，分别迭代。
（2）弹性原则：系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。
（3）可观测原则：通过日志、链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗

时、返回值和参数都清晰可见。

（4）韧性原则：当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力。
（5）所有过程自动化原则：一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
（6）零信任原则：默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，以身份为中心。
（7）架构持续演进原则：云原生架构本身也必须是一个具备持续演进能力的架构。

3. 主要架构模式

（1）服务化架构模式：典型模式是微服务和小服务模式。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。
（2）Mesh化架构模式：把中间件框架(如RPC、缓存、异步消息等)从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务进程中只保留很“薄”的Client部分，Client通常很少变化，只负责与Mesh进程通信，原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。
（3）Serverless模式：将“部署”这个动作从运维中“收走”，使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等，从架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发，也就是把应用的整个运行都委托给云。
（4）存储计算分离模式：在云环境中，推荐把各类暂态数据(如session)、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。
（5）分布式事务模式：大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。
（6）可观测架构：可观测架构包括Logging、Tracing、Metrics三个方面，其中Logging提供多个级别的详细信息跟踪，由应用开发者主动提供；Tracing提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics则提供对系统量化的多维度度量。
（7）事件驱动架构：本质上是一种应用/组件间的集成架构模式。可用于服务解耦、增强服务韧性、数据变化通知等场景中。

典型的云原生架构反模式：庞大的单体应用、单体应用“硬拆”为微服务、缺乏自动化能力的微服务。

3.3.3 云原生架构相关技术

1. 容器技术

（1）容器技术的背景与价值

容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。

通过容器技术，企业可以充分发挥云计算弹性优势，降低运维成本。一般而言，借助容器技术，企业可以通过部署密度提升和弹性降低 $50%$ 计算成本。

（2）容器编排

Kubernetes（K8s）已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提供了分布式应用管理的核心能力，包括：资源调度、应用部署与管理、自动修复、服务发现与负载均衡、弹性伸缩、声明式 API、可扩展性架构、可移植性。

2. 云原生微服务

（1）微服务发展背景

微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。

（2）微服务设计约束

1)微服务个体约束：功能在业务域划分上应是相互独立的，低耦合、单一职责。
2)微服务与微服务之间的横向关系：主要从微服务的可发现性和可交互性处理服务间的横向关系，一般需要服务注册中心。
3)微服务与数据层之间的纵向约束：在微服务领域，提供数据存储隔离原则，即数据是微服务的私有资产，对于该数据的访问都必须通过当前微服务提供的API来访问。
4)全局视角下的微服务分布式约束：故障发现时效性和根因精确性始终是开发运维人员的核心诉求。

（3）主要微服务技术

Apache Dubbo 作为源自阿里巴巴的一款开源高性能 RPC 框架，特性包括基于透明接口的 RPC、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。

Spring Cloud 作为开发者的主要微服务选择之一，为开发者提供了分布式系统需要的配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性 Token、全局锁、决策竞选、分布式会

话与集群状态管理等能力和开发工具。

Eclipse MicroProfile 作为 Java 微服务开发的基础编程模型，它致力于定义企业 Java 微服务规范，MicroProfile 提供指标、API 文档、运行状况检查、容错与分布式跟踪等能力，使用它创建的云原生微服务可以自由地部署在任何地方，包括服务网格架构。

Tars是腾讯将其内部使用的微服务框架，包含一整套开发框架与管理平台，兼顾多语言、易用性、高性能与服务治理，理念是让开发更聚焦业务逻辑，让运维更高效。

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

DAPR(分布式应用运行时)是微软新推出的一种可移植的、无服务器的、事件驱动的运行时，它使开发人员可以轻松构建弹性，无状态和有状态微服务，这些服务运行在云和边缘上，并包含多种语言和开发框架。

3. 无服务器技术

无服务器技术(Serverless)因为屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。Serverless计算包含以下特征：

(1)全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作；
(2)通用性，结合云BaaSAPI的能力，能够支撑云上所有重要类型的应用；
(3)自动弹性伸缩，让用户无需为资源使用提前进行容量规划；
(4)按量计费，让企业使用成本得有效降低，无需为闲置资源付费。

函数计算(FaaS)是Serverless中最具代表性的产品形态。通过把应用逻辑拆分多个函数，每个函数都通过事件驱动的方式触发执行。

无服务器技术关注点：计算资源弹性调度、负载均衡和流控、安全性。

4. 服务网格

服务网格(ServiceMesh)是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。

图14-4 服务网格的典型架构

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

3.3.4 云原生架构案例分析

1. 某旅行公司云原生改造

（1）背景与挑战

面临两个问题：公司主体由两个公司合并，技术体系不同，需要整合为一体；节假日高并发流量。

（2）基于云原生架构的解决方案

改造第一阶段，某旅行技术团队为了提升集群资源利用率，降低资源使用成本。利用云原生思维重构部分技术体系，将多套旧有系统合并、收拢到一套以云原生应用为核心的私有云平台上，同时将IDC、物理网络、虚拟网络、计算资源、存储资源等通过IaaS、PaaS等，实现虚拟化封装、切割、再投产的自动化流程。

随着服务器集群规模的扩大，部分机器开始频繁出现故障。此时，保障服务稳定性成了第二阶段改造的首要任务。

第二阶段基于公有云、私有云和离线专属云集群等新型动态计算环境，某旅行公司的技术团队帮助业务构建和运行具有弹性的云原生应用，促进业务团队开始使用声明式API，同时通过不可变基础设施、服务网格和容器服务，来构建容错性好、易于管理和观察的应用系统，并结合平台可靠的自动化恢复、弹性计算来完成整个服务稳定性的提升。

第三阶段通过基础组件、服务的云原生改造、服务依赖梳理和定义等方式，使应用不再需要考虑底层资源、机房、运行时间和供应商等因素。此外，还利用标准的云原生应用模型，实现了服务的跨地域、跨云自动化灾备、自动部署，并向云原生场景下的 DevOps 演进。架构图如下：

图14-5 某旅行公司云原生平台架构图

2. 云原生技术助力某汽车公司数字化转型实践

战略性构建容器云平台。通过平台实现对某云行App、二手车、在线支付、优惠券等核心互联网应用承载。以多租户的形式提供弹性计算、数据持久化、应用发布等面向敏捷业务服务，并实现高水平资源隔离。标准化交付部署，快速实现业务扩展，满足弹性要求。利用平台健康检查、智能日志分析和监控告警等手段及时洞察风险，保障云平台和业务应用稳定运行。

数字混合云交付。采用私有云+公有云的混合交付模式，按照服务的敏态/稳态特性和管控要求划分部署，灵活调度公有云资源来满足临时突发或短期高TPS业务支撑的需求。利用PaaS平台标准化的环境和架构能力，实现私有云和公有云一致交付体验。

深度融合微服务治理体系，实现架构的革新和能力的沉淀，逐步形成支撑数字化应用的业务中台。通过领域设计、系统设计等关键步骤，对原来庞大的某云体系应用进行微服务拆分，形成能量、社群、用户、车辆、订单等多共享业务服务，同步制定了设计与开发规范、实施路径和配套设施，形成一整套基于微服务的分布式应用架构规划、设计方法论。

图14-6 某容器云平台架构示意图

3. 某快递公司核心业务系统云原生改造

某快递公司核心业务系统原架构基于 Vmware+Oracle 数据库进行搭建。随着搬迁上阿里云，架构全面转型为基于 Kubernetes 的云原生架构体系。

通过引入云原生数据库、应用容器化、微服务改造技术，得到了如下的上云架构：

图14-7 某快递公司核心业务上云架构示意图

（1）架构阐述。基础设施，全部计算资源取自阿里云的神龙裸金属服务器。流量接入，阿里云提供两套流量接入，一套是面向公网请求，另外一套是服务内部调用。
（2）平台层。基于 Kubernetes 打造的云原生 PaaS 平台优势明显突出。
（3）应用服务层。每个应用都在 Kubernetes 上面创建单独一个 Namespace，应用和应用之间实现资源隔离。
（4）运维管理。线上 Kubernetes 集群采用阿里云托管版容器服务，免去了运维 Master 结点的工作，只需要制定 Worker 结点上线及下线流程即可。

4. 某电商业务云原生改造

方案的关键点是：

• 通过容器化部署，利用阿里云容器服务的快速弹性应对大促时的资源快速扩容。
• 提前接入链路追踪产品，用于对分布式环境下复杂的服务调用进行跟踪，对异常服务进行定位，帮助客户在测试和生产中快速定位问题并修复，降低对业务的影响。
• 使用阿里云性能测试服务(PTS)进行压测，利用秒级流量拉起、真实地理位置流量等功能，以最真实的互联网流量进行压测，确保业务上线后的稳定运营。
• 采集压测数据，解析系统强弱依赖关系、关键瓶颈点，对关键业务接口、关键第三方调用、数据库慢调用、系统整体负载等进行限流保护。
• 配合阿里云服务团队，在大促前进行 ECS/RDS/安全等产品扩容、链路梳理、缓存/连接池预热、监控大屏制作、后端资源保障演练等，帮助大促平稳进行。

图14-8 某核心应用架构示意图

3.4 面向服务架构设计

3.4.1 SOA的相关概念

在面向服务的体系结构（Service-Oriented Architecture，SOA）中，服务的概念有了延伸，泛指系统对外提供的功能集。

1. SOA的定义

从应用的角度定义，可以认为SOA是一种应用框架，它着眼于日常的业务应用，并将它们划分

为单独的业务功能和流程，即所谓的服务。SOA使用户可以构建、部署和整合这些服务，且无需依赖应用程序及其运行平台，从而提高业务流程的灵活性。

从软件的基本原理定义，可以认为SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

2. 业务流程与BPEL

业务流程是指为了实现某种业务目的行为所进行的流程或一系列动作。

BPEL，即面向Web服务的业务流程执行语言，是一种使用Web服务定义和执行业务流程的语言。使用BPEL，用户可以通过组合、编排和协调Web服务自上而下地实现面向服务的体系结构。BPEL目前用于整合现有的WebServices，将现有的WebServices按照要求的业务流程整理成为一个新的WebServices，在这个基础上，形成一个从外界看来和单个Service一样的Service。

3.4.2 SOA 的发展历史

SOA的微服务化发展

SOA架构向更细粒度、更通用化程度发展，就成了所谓的微服务了。SOA与微服务的区别在于如下几个方面：

(1)微服务相比于SOA更加精细，微服务更多地以独立的进程的方式存在，互相之间并无影响；
(2)微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；
(3)微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。

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

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

3.4.3 SOA 的参考架构

典型的以服务为中心的企业集成架构如下图所示，采用“关注点分离”的方法规划企业集成中的各种架构元素，同时从服务视角规划每种架构元素提供的服务，以及服务如何被组合在一起完成某种类型的集成。可划分为六大类：

图15-2 IBMWebSphere业务集成参考架构

(1)业务逻辑服务：包括用于实现业务逻辑的服务和执行业务逻辑的能力，其中包括业务应用服务、业务伙伴服务以及应用和信息资产。
(2)控制服务：包括实现人、流程和信息集成的服务，以及执行这些集成逻辑的能力。
(3)连接服务：通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。
(4)业务创新和优化服务：用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。
(5)开发服务：贯彻整个软件开发生命周期的开发平台，从需求分析，到建模、设计、开发、测试和维护等全面的工具支持。
(6)IT服务管理：支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。

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

2.业务逻辑服务

1)整合已有应用——应用和信息访问服务：实现对已有应用和信息的集成，主要有两类访问服务：可接入服务、事件发现服务。
2)整合新开发的应用——业务应用服务：实现新应用集成，主要有三类业务应用服务：组件服务(可重用)、核心服务(运行时)、接口服务。
3)整合客户和业务伙伴(B2C/B2B)——伙伴服务：提供与企业外部的B2B的集成能力，包括：社区服务、文档服务、协议服务。

3.控制服务

1)数据整合——信息服务：提供集成数据的能力，目前主要包括如下集中信息服务：联邦服务(不同类型数据聚合)、复制服务(远程数据本地访问)、转换服务(格式转换)、搜索服务。
2)流程整合——流程服务：完成业务流程集成，包括：编排服务(预定义流程顺序)、事务服务(保证ACID)、人工服务(人工活动集成到流程中)。
3)用户访问整合——交互服务：实现用户访问集成，包括：交付服务(运行时交互框架)、体验服务、资源服务(运行时交互组件的管理)。
4.开发服务：开发环境和工具中为不同开发者的角色提供的功能被称为开发服务。根据开发过程中开发者角色和职责的不同，有如下4类服务：建模服务、设计服务、实现服务、测试服务。

5.业务创新和优化：以业务性能管理(BPM)技术为核心提供业务事件发布、收集和关键业务指标监控能力。包括以下服务：

(1)公共事件框架服务：通过一个公共事件框架提供IT和业务事件的激发、存储和分类等。
(2)采集服务通过基于策略的过滤和相关性分析检测感兴趣的服务。
(3)监控服务：通过事件与监控上下文间的映射，计算和管理业务流程的关键性能指标。

6.IT服务管理：为业务流程和服务提供安全、高效和健康的运行环境，包括：安全和目录服务、系统管理和虚拟化服务。

3.4.4 SOA主要协议和规范

Web 服务最基本的协议包括 UDDI、WSDL 和 SOAP，通过它们，可以提供直接而又简单的 Web Service 支持，如图所示。

图15-4 基本Web服务协议

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

WSDL(Web 服务描述语言)，是一个用来描述 Web 服务和说明如何与 Web 服务通信的 XML 语言。可描述三个基本属性：服务做些什么、如何访问服务、服务位于何处。

SOAP 是在分散或分布式的环境中交换信息的简单的协议，是一个基于 XML 的协议。它包括 4 个部分：SOAP 封装，定义了一个描述消息中的内容是什么，是谁发送的，谁应当接收并处理它以及如何处理它们的框架；SOAP 编码规则，用于表示应用程序需要使用的数据类型的实例；SOAP RPC 表示是远程过程调用和应答的协定；SOAP 绑定是使用底层协议交换信息。

虽然这4个部分都作为SOAP的一部分，作为一个整体定义的，但它们在功能上是相交的、彼此独立的。特别地，信封和编码规则是被定义在不同的XML命名空间（Namespace）中，这样使得定义更加简单。

REST(表述性状态转移)的设计不只是要适用于互联网环境，而是一个普遍的设计理念，目的是为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。包括四个要素：

资源：REST是以资源为中心构建，资源可以是一个订单，也可以是一幅图片。将互联网中一切暴露给客户端的事物都可以看作是一种资源，对资源相关数据和表述进行组合，借助URI(统一资源标识符)标识Web上的资源。

表述：用表述描述资源在Web中某一个时间的状态。

状态转移：分为应用状态(用户请求会话信息快照)和资源状态(时间资源请求表述的快照)。

超链接：在页面中嵌入链接和其他资源建立联系。

3.4.5 SOA设计的标准要求

SOA设计的标准要求

文档标准化：XML文档，Web描述语言。

通信协议标准：用消息进行通信，消息使用XML Schema来定义。

应用程序统一登记与集成：通过扮演目录列表角色的登记处来维护，UDDI是标准。

服务质量(QoS)：每项SOA服务都有一个与之相关的服务质量。QoS的一些关键元素有安全需求(例如认证和授权)、可靠通信以及谁能调用服务的策略。其服务和标准包括：

可靠性：“仅且仅仅传送一次”“最多传送一次”“重复消息过滤”和“保证消息传送”等特性消息的发送和确认。

安全性：主要包括认证交换、消息完整性和消息保密。

策略：服务提供者有时候会要求服务消费者与某种策略通信。

控制：在SOA中，进程是使用一组离散的服务创建的。BPEL4WS或者WSBPEL是用来控制这些服务的语言。

管理：让系统管理员管理所有，运行在多种环境下的服务的管理系统。

3.4.6 SOA 的作用

SOA对于实现企业资源共享，打破“信息孤岛”的步骤如下。

（1）把应用和资源转换成服务。
（2）把这些服务变成标准的服务，形成资源的共享。

3.4.7 SOA的设计原则

SOA的设计原则

(1)无状态。以避免服务请求者依赖于服务提供者的状态。
(2)单一实例。避免功能冗余。
(3)明确定义的接口。使用者依赖服务规约调用服务，所以服务定义必须长时间稳定，一旦公布，不能随意更改；服务的定义应尽可能明确，减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。
(4)自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
(5)粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用(RPC)，通常消息量比较大，但是服务之间的交互频度较低。

(6)服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
(7)重用能力。服务应该是可以重用的。
(8)互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，例如一个服务对安全性方面的要求；也可以是跟业务有关的语义方面的内容，例如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。

3.4.8 SOA的设计模式

1. 服务注册表模式

服务注册表模式，支持如下SOA治理功能：

(1)服务注册：应用开发者，也叫服务提供者，向注册表公布他们的功能。他们公布服务合同，包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性。
(2)服务位置：也就是服务应用开发者，帮助他们查询注册服务，寻找符合自身要求的服务。注册表让服务的消费者检索服务合同。对谁可以访问注册表，以及什么服务属性通过注册表暴露的控制。
(3)服务绑定：服务的消费者利用检索到的服务合同来开发代码，开发的代码将与注册的服务绑定、调用注册的服务以及与它们实现互动。开发者常常利用集成的开发环境自动将新开发的服务与不同的新协议、方案和程序间通信所需的其他接口绑在一起。

2. 企业服务总线模式

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

一个典型的在ESB环境中组件之间的交互过程是：首先由服务请求者触发一次交互过程，产生一个服务请求消息，并将该消息按照ESB的要求标准化，然后标准化的消息被发送给服务总线。ESB根据请求消息中的服务名或者接口名进行目的组件查找，将消息转发至目的组件，并最终将处理结果逆向返回给服务请求者。这种交互过程不再是点对点的直接交互模式，而是由事件驱动的消息交互模式。

ESB的核心功能如下。

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

(2)提供服务注册和命名的管理功能。
(3)支持多种消息传递范型(如请求/响应、发布/订阅等)。
(4)支持多种可以广泛使用的传输协议。
(5)支持多种数据格式及其相互转换。
(6)提供日志和监控功能。

3. 微服务模式

微服务模式，不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

微服务模式特点：复杂应用解耦、独立、技术选型灵活、容错、松耦合易扩展。

常见的微服务设计模式：

1. 聚合器微服务：聚合器调用多个微服务实现系统应用程序所需功能，具体有两种形式，一种是将检索到的数据信息进行处理并直接展示；另一种是对获取到的数据信息增加业务逻辑处理后，再进一步发布成一个新的微服务作为一个更高层次的组合微服务，相当于从服务消费者转换成服务提供者。
   2)链式微服务：客户端或服务在收到请求后，会返回一个经过合并处理的响应，服务之间形成一条调用链。
   3)数据共享微服务：当服务之间存在强耦合关系时，可能存在多个微服务共享缓存与数据库存储的现象。
   4)异步消息传递微服务：消息队列将消息写入一个消息队列中，实现业务逻辑以异步方式运行，从而加快系统响应速度。对于一些不必要以同步方式运行的业务逻辑，可以使用消息队列代替REST实现请求、响应，加快服务调用的响应速度。

微服务架构的问题与挑战：微服务架构分布式特点带来的复杂性；微服务架构的分区数据库体系，不同服务拥有不同数据库；增加了测试的复杂性。在大规模应用部署中，在监控、管理、分发及扩容等方面，微服务也存在着巨大挑战。

3.4.9 构建SOA架构时应该注意的问题

1. 原有系统架构中的集成需求

当SOA架构师遇到一个十分复杂的企业系统时，首先考虑的应该是如何重用已有的投资而不是替换遗留系统。集成类型包括：应用程序集成的需求，终端用户界面集成的需求，流程集成的需求

以及已有系统信息集成的需求。

2. 服务粒度的控制以及无状态服务的设计

SOA系统中服务的构建有两点需要特别注意的地方：首先是对于服务粒度的控制，另外就是对于无状态服务的设计。

SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。当某一个服务需要依赖时，最好把它定义成具体的业务流程(BPEL)。

3.4.10 SOA 实施的过程

1. 选择SOA解决方案

从以下三个方面选择SOA最佳的解决方案：尽量选择能进行全局规划的方案、选择时充分考虑企业自身的需求、从平台实施等技术方面进行考查。

2. 业务流程分析

（1）建立服务模型

1)自顶向下分解法：从业务着手进行分析，选择端到端的业务流程进行逐层分解至业务活动，并对其间涉及的业务活动和业务对象进行变化分析。
2)业务目标分析法：通过关键性能指标分析来验证已有服务候选者以及发现遗漏的服务候选者，这也可以称为“目标服务建模”。
3)自底向上分析法：利用已有资产来实现服务。

（2）建立业务流程

1)建立业务对象：业务对象是对数据进行检索和处理的组件，是简单的真实世界的软件抽象。
业务对象的分类包括：实体、过程、事件。
2)建立服务接口。
3)建立业务流程：流程是指定的活动顺序，包含明确确定的用于提供业务值的输入和输出。

3.5 嵌入式系统架构设计

3.5.1 嵌入式系统概述

嵌入式系统（Embedded System）是为了特定应用而专门构建的计算机系统。

从传统意义上讲，嵌入式系统主要由嵌入式微处理器（控制器（Micro Control Unit，MCU）、存储器（RAM/ROM）、（外）总线逻辑、定时/计数器（Time）、看门狗电路、I/O接口（串口、网络、USB，JTAG等）和外部设备（UART、LED等）等部件组成。

3.5.2 嵌入式系统软件架构原理与特征

1. 两种典型的嵌入式系统架构模式

嵌入式系统的典型架构可概括为两种模式，即层次化模式架构和递归模式架构。

（1）层次化模式架构

系统通过层次化的方法进行搭建，位于高层的抽象概念与低层的更加具体的概念之间存在着依赖关系。层次化模式架构主要设计思想是：

(1)当一个系统存在高层次的抽象，这些抽象的表现形式是一个个的抽象概念，而这些抽象概念需要具体的低层概念进行实现时，就可采用层次化模式。
(2)分层模式结构只包含了一个主要的元素(域包)和它的接口，以及用来说明模式结构的约束条件。
(3)层次化模式可以分为两种：封闭型和开放性。封闭型的特征是：一层中的对象只能调用同一层或下一个底层的对象提供的方法。而开放型一层中的对象可以调用同一层或低于该层的任意一层的对象提供的方法。

（2）递归模式架构

递归模式解决的问题是：需要将一个非常复杂的系统进行分解，并且还要确保分解过程是可扩展的，即只要有必要，该分解过程就可以持续下去。

在创建这种模式的实例时，通常使用两种相反的工作流程。

• 自顶向下：自顶向下的工作流从系统层级开始并标识结构对象，这些对象提供实现协作的服务。在实时系统和嵌入式系统中，大多数情况下是基于某个标准方法，将系统分成一个个子系统。当开发人员逐步降低抽象层级，向下推进时，容易确保开发者的工作没有偏离用例中所规定的需求。
• 自底向上：自底向上专注于域的构造——首先确定域中的关键类和关系。这种方法之所以可行是因为：开发者以往有丰富的开发经验，并能将其他领域所获得的知识映射到当前开发所在的域中。通过这种方法，最终开发者会到达子系统级的抽象。

2. 嵌入式操作系统

（1）嵌入式操作系统的定义及特点

嵌入式操作系统(EOS)是指用于嵌入式系统的操作系统。通常包括与硬件相关的底层驱动软件、系统内核、设备驱动接口、通信协议、图形界面、标准化浏览器等。

嵌入式操作系统特点：可裁剪性、可移植性、强实时性、强紧凑性、高质量代码、强定制性、标准接口、强稳定性、弱交互性、强确定性、操作简洁方便、较强的硬件适应性、可固化性。

（2）嵌入式操作系统的分类

嵌入式操作系统通常分为两类，一类是面向控制、通信等领域的嵌入式实时操作系统，如VxWorks、Nucleus等；另一类是面向消费电子产品的非实时嵌入式操作系统，如Android、iOS、WinCE等。

（3）嵌入式操作系统的一般架构

从嵌入式操作系统体系架构看，主要存在4种结构：整体结构、层次结构、客户/服务器结构和面向对象结构。

整体结构也称为模块结构或无序结构，它是基于结构化程序设计的一种软件设计方法，其架构如下图所示：

图16-7 一般嵌入式操作系统的体系结构

（4）嵌入式操作系统的基本功能

• 操作系统内核结构

在嵌入式操作系统中，内核是操作系统的核心部分，它管理着系统的各种资源。内核可以看成连接应用程序和硬件的一座桥梁，是直接运行在硬件上的最基础的软件实体。目前从内核架构来划

分，可分为宏内核(即单体内核)和微内核。

• 任务管理

任务管理是嵌入式操作系统最基本功能之一，这里的任务(task)是指嵌入式操作系统调度的最小单位，类似于一般操作系统进程或线程的概念。

在实时系统的任务调度中，存在大量的实时调度方法，大致可以概述为主要三种划分，即离线和在线调度(在运行前还是运行时获得调度信息)、抢占和非抢占调度(能否打断正在运行的任务)、静态和动态调度(在设计时还是运行时确定任务优先级)等。

典型的强实时调度算法：

(1)最早截止时间优先(Earliest Deadline First，EDF)算法。根据任务的开始截止时间来确定任务的优先级。截止时间愈早，其优先级愈高。
(2)最低松弛度优先(Least Laxity First，LLF)算法。根据任务紧急(或松弛)的程度，来确定任务的优先级。任务的紧急程度愈高，该任务被赋予的优先级就愈高，以使之优先执行。松弛度(又叫富裕度)即进程的富裕时间，或者可以理解为自由时差。
(3)单调速率调度算法(Rate Monotonic Scheduling，RMS)。是一种静态优先级调度算法，是经典的周期性任务调度算法。RMS 的基本思路是任务的优先级与它的周期表现为单调函数的关系，任务的周期越短，优先级越高；任务的周期越长，优先级越低。

$\bullet$ 存储管理

存储管理方法的主要目的是解决多个用户使用主存的问题，其存储管理方法主要包括分区存储管理、分页存储管理、分段存储管理、段页存储管理以及虚拟存储管理等5种。

• 任务间通信

操作系统任务之间一般存在以下关系：相互独立、竞争、同步、通信。要实现多任务间的协同工作，操作系统必须提供任务间的通信手段。嵌入式操作系统一般都会提供多任务间通信的方法，常用的通信方式包括：

• 共享内存：数据的简单共享。多任务访问同一地址空间。
• 信号量：基本的互斥和同步。最优，主要手段，任务间最快速通信。
• 消息队列：同一CPU内多任务间消息传递。类似于缓冲区的对象，像一个管道接收发送者消息等待接收者读取。
• Socket 和远程调用：任务间透明的网络通信，不同计算机之间通信。
• Signals(信号): 用于异常处理。通知进程发生了异步事件, 是对中断机制的一种模拟。

3. 嵌入式数据库

与传统数据库相比，嵌入式数据库系统有以下几个主要特点：嵌入式、实时性、移动性、伸缩性。

嵌入式数据库按存储位置的不同可分为三类：基于内存方式、基于文件方式、基于网络方式。

（1）基于内存的数据库系统（MainMemoryDatabaseSystem，MMDB）是实时系统和数据库系统的有机结合。内存数据库是支持实时事务的最佳技术，其本质特征是以其“主拷贝”或“工作版本”常驻内存，即活动事务只与实时内存数据库的内存拷贝打交道。典型产品是eXtremeDB嵌入式数据库。

eXtremeDB主要特点：

• 最小化支持持久数据所必需的资源：实质上就是将内存资源减到最小。
• 保持极小的必要堆空间：在某些配置上 eXtremeDB 只需要不到 1KB 的堆空间。
• 维持极小的代码体积。
• 通过紧密的集成持久存储和宿主应用程序语言消除额外的代码层。
• 提供对动态数据结构的本地支持：例如变长字符串、链表和树。

图16-17 eXtremeDB嵌入式数据库的架构

图16-18 SQLite嵌入式数据库系统架构

（2）基于文件的数据库（File Database，FDB）系统就是以文件方式存储数据库数据，即数据按照一定格式储存在磁盘中。使用时由应用程序通过相应的驱动程序甚至直接对数据文件进行读写。典型产品是SQLite，它由公共接口、编译器系统、虚拟机和后端四个子系统组成。

SQLite主要特点：

• SQLite 是一个开源的、内嵌式的关系型数据库。

• SQLite 数据库服务器就在你的数据库应用程序中，其好处是不需要网络配置和管理，也不需要通过设置数据源访问数据库服务器。

• SQLite 数据库的服务器和客户端运行在同一个进程中。这样可以减少网络访问的消耗，简化数据库管理，使你的程序部署起来更容易。

• SQLite 在处理数据类型时与其他的数据库不同。区别在于它所支持的类型以及这些类型是如何存储、比较、强化(enforce)和指派(assign)。

（3）基于网络的数据库（Netware Database，NDB）系统是基于手机4G/5G的移动通信基础之上的数据库系统，在逻辑上可以把嵌入式设备看作远程服务器的一个客户端。实际上，嵌入式网络数据库是把功能强大的远程数据库映射到本地数据库，使嵌入式设备访问远程数据库就像访问本地数据库一样方便。嵌入式网络数据库主要由三部分组成：客户端、通信协议和远程服务器。其架构如下：

图16-19 嵌入式数据库管理系统的架构

在了解嵌入式数据库架构之前，我们必须清楚数据库服务器架构与嵌入式数据库架构差异。

数据库服务器架构：数据库客户端通常通过数据库驱动程序如JDBC、ODBC等访问数据库服务器，数据库服务器再操作数据库文件。数据库服务是一种客户端服务器模式，客户端和服务器是完全两个独立的进程。它们可以分别位于在不同的计算机甚至网络中。客户端和服务器通过TCP/IP进行通信。这种模式将数据与应用程序分离，便于对数据访问的控制和管理。

嵌入式数据库架构：嵌入式数据库不需要数据库驱动程序，直接将数据库的库文件链接到应用程序中。应用程序通过API访问数据库，而不是TCP/IP。因此，嵌入式数据库的部署是与应用程序在一起的。

数据库服务器和嵌入式数据库对比如下：

(1)数据库服务器通常允许非开发人员对数据库进行操作，而在嵌入式数据中通常只允许应用程序对其进行访问和控制。
(2)数据库服务器将数据与程序分离，便于对数据库访问的控制。而嵌入式数据库则将数据的访问控制完全交给应用程序，由应用程序来进行控制。
(3)数据库服务器需要独立的安装、部署和管理，而嵌入式数据通常和应用程序一起发布，不需要单独地部署一个数据库服务器，具有程序携带性的特点。

嵌入式数据库有其自身的特殊需要，它应具备的功能包括以下4点：

• 足够高效的数据存储机制；
• 数据安全控制(锁机制)；
• 实时事务管理机制；
• 数据库恢复机制(历史数据存储)。

这样，一般嵌入式数据库可划分成数据库运行处理、数据库存取、数据管理、数据库维护和数据库定义等功能。

在嵌入式环境下开发实时数据库系统需要特别解决以下几个设计问题：

(1)存储空间管理模块。嵌入式实时数据库系统由于采用了内存缓冲的技术，必然要涉及嵌入式操作系统的内存管理。系统运行时，由该模块通过实时OS向系统申请内存缓冲区，作为共享的内存数据区使用。之后，将历史数据库中的初始化数据调入内存区对这些空白内存进行初始化。
(2)数据安全性、完整性控制模块。
(3)事务并发控制模块。在实时数据库中的封锁粒度通常选择一张关系表为一个单位。
(4)实时数据转储模块。该模块实现的功能是将实时数据存储为历史数据，通常由该模块先将历史数据保存在内存缓冲区中，缓冲区满时才一次性写入磁盘；读历史数据时，先从缓冲区内取数据，取不到数据时再进行文件的读写。
(5)运行日志管理模块。日志文件可以用来进行事务故障恢复和系统故障恢复。

4. 嵌入式中间件

（1）嵌入式中间件的定义及特点

嵌入式中间件是在嵌入式系统中处于嵌入式应用和操作系统之间层次的中间软件，其主要作用是对嵌入式应用屏蔽底层操作系统的异构性，常见功能有网络通信、内存管理和数据处理等。

中间件=平台+通信。中间件的共性特点：通用性、异构性、分布性、协议规范性、接口标准化。

具体到嵌入式中间件而言，它还应提供对下列环境的支持：

• 网络化：支持移动、无线环境下的分布应用，适应多种设备特性以及不断变化的网络环境；
• 支持流媒体应用，适应不断变化的访问流量和宽带约束；
• QoS 质量品质：在分布式嵌入式实时环境下，适应强 QoS 的分布应用的软硬件约束；
• 适应性：能够适应未来确定的应用要求。

（2）嵌入式中间件的分类

从现代中间件观点看，通用中间件大致存在以下几类：

• 企业服务总线中间件：ESB是一种开放的、基于标准的分布式同步/异步信息传递中间件。

• 事务处理监控器：为发生在对象间的事务处理提供监控功能，以保证操作成功。

• 分布式计算环境：指创建运行在不同平台上的分布式应用程序所需的一组技术服务。

• 远程过程调用：指客户机向服务器发送关于运行某程序的请求时所需的标准。

• 对象请求代理：为用户提供与其他分布式网络环境中对象通信的接口。

• 数据库访问中间件：支持用户访问各种操作系统或应用程序中的数据库。

• 消息传递：电子邮件系统是该类中间件的其中之一。

• 基于XML的中间件：XML允许开发人员为实现Internet中交换结构化信息而创建文档。

消息中间件的一般架构：消息中间件是消息传输过程中保存消息的一种容器。架构如下图。包括点对点和发布/订阅两种模式。

两个基本特点：采用异步处理模式、应用程序和应用程序调用关系为松耦合关系。

图16-20 消息中间件原理架构示意图

嵌入式系统软件开发环境、分布式中间件等内容在基础知识-嵌入式章节已有详解，不再赘述。

3.5.3 嵌入式系统软件架构设计方法

1. 基于架构的软件设计开发方法的应用

在嵌入式系统中，其设计通常采用了自顶向下的设计方法，基于架构的软件设计(ABSD)可适应于嵌入式系统的软件设计方法。ABSD已经在系统架构设计章节有详解，不再赘述。

2. 属性驱动的软件设计方法

属性驱动的软件设计(ADD)是把一组质量属性场景作为输入，利用对质量属性实现与架构设计之间的关系的了解(如体系结构风格、质量战术等)对软件架构进行设计的一种方法。

采用ADD方法进行软件开发时，需要经历评审、选择驱动因子、选择系统元素、选择设计概念、实体化元素和定义接口、草拟视图和分析评价等七个阶段，如图所示：

图16-24 ADD架构开发过程

步骤一：评审输入

首先需要确保设计流程的输入是可用且正确的。其次，确认设计目的是否符合设计的类型，要确保设计过程中其他的属性驱动因子也是可用的。最后，如果是设计一个已有的系统，还需要分析已经存在的架构设计的输入存在是否合理。

步骤二：通过选择驱动因子(架构)建立迭代目标。

根据使用的开发模型去选择设计的回合。一个设计回合需要在一系列的设计迭代中进行，每一个迭代着重完成一个目标，特别是满足驱动因子的目标。

步骤三：选择一个或者多个系统元素来细化。

系统元素可以是指一个软件模块，或者是指包含了多个元素或子模块的整个软件系统。本步骤主要是指选取可满足驱动因子需要的一个或者多个架构结构，这些结构是由具有内在关联的元素组成的。

步骤四：选择一个或者多个设计概念来细化。

本步骤是从常用的架构设计模式中选取一种或多种设计概念，对选中的驱动因子进行细化。

步骤五：实例化架构元素、分配职责和定义接口。选择好了一个或者多个设计概念后，就要求

做另一个设计决策了，包括所选择的实例化元素的设计概念。比如，如果选择分层，就需要决定分多少层。

步骤六：草拟视图和记录设计决策。将上述活动的结果用文字或图的方式记录或绘制出来。

步骤七：分析当前设计、评审迭代目标、实现设计目的。到本步骤，应该说已经创建好了部分设计，可以得到这个迭代设计建立的目标。在这个确定的目标前提下，可以得到项目利益相关者的认同，避免否定，导致返工。

3. 实时系统设计方法

实时系统设计方法（Design Approach for Real-Time System，DARTS）主要是将实时系统分解为多个并发任务，并定义这些任务之间的接口。提供了一些分解规则和一套处理并发任务的设计步骤，还提供了一套把实时系统建造成并发任务的标准和定义并发任务间接口的指南。

（1）DARTS开发方法的基本概念

RTSAD(实时结构化分析和设计方法)是DARTS方法的起源，是对传统结构化分析和设计方法的补充扩展，专门用于开发实时系统。

实时结构化分析(RTSA)主要对传统的结构化分析方法扩充了行为建模部分，它通过状态转换图(STD)刻画系统的行为特征，并利用控制转换与数据流图集成在一起。

实时结构化设计(RTSD)是利用内聚和耦合原则进行程序设计的一个方法，它通过事务和变换两种策略将RTSA的分析结构DFD/CFD转换为程序结构图。

任务结构化标准可以为设计人员将实时系统分解为并发任务的时候提供帮助。这些标准是从设计并发系统所积累的经验中得到的启发。确定任务过程中主要考虑的问题是系统内部功能的并发特性。信息隐藏作为封装数据存储的标准来使用。信息隐藏模块用于信息数据存储和状态转换表的内容和表示。

RTSAD设计方法使用任务架构图来显示系统分解为并发任务的过程，以及采用消息、事件和信息隐藏模块形式的任务间接口。

（2）DARTS开发过程

DARTS 方法由以下 5 部分组成：

1)用实时结构化分析方法(RTSA)开发系统规范：本阶段要开发系统环境图(SCD)和状态转换图(STD)。
2)将系统划分为多个并发任务：任务结构化标准应用于数据流/控制流图层次集事件合中的叶子节点上。初步任务架构图(TAD)可以显示使用任务结构化标准确定的任务。
3)定义任务间接口：通过分析在上一阶段确认的任务间的数据/控制流接口可以定义任务间的接

口。任务间的数据流被映射为松耦合的或紧密耦合的消息接口。事件流被映射为事件信号。数据存储被映射为信息隐藏模块。这个阶段应该完成时间约束分析。

4)设计每个任务：每个任务都代表了一个顺序程序的执行。在这个阶段要定义各个模块的功能以及与其他模块之间的接口。此外，还要设计各个模块的内部结构。
5)设计过程的成果：RTSA规范、任务结构规范(定义每个并发任务功能及接口)、任务分解(定义每个任务分解为模块的过程以及模块的功能接口详细设计)。

DARTS开发方法的主要优势：

• 强调把系统分解成并发的任务，并提供了确认这些任务的标准。强调并发在并发实时系统的设计中非常重要；
• 提供了详细的定义任务间接口的指南；
• 强调了用任务架构图(STD)的重要性，这在实时系统的设计中也非常重要；
• 提供了从RTSA规格到实时设计的转换。

DARTS 开发方法的不足之处：

• 用结构化的设计方法把任务创建成了程序模块，而并非完全用IHM来封装数据存储；
• 如果RTSA阶段的工作没有做好，创建任务就非常困难。

3.5.4 嵌入式系统软件架构案例分析

1.鸿蒙操作系统架构案例分析

鸿蒙操作系统(HarmonyOS)是一款“面向未来”、面向全场景(移动办公、运动健康、社交通信、媒体娱乐等)的分布式操作系统。在传统的单设备系统能力的基础上，HarmonyOS 提出了基于同一套系统能力、适配多种终端形态的分布式理念，能够支持多种终端设备的能力。

鸿蒙(HarmonyOS)整体采用分层的层次化设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统” $\rightarrow$ “子系统” $\rightarrow$ “功能/模块”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或功能/模块。

图16-27 鸿蒙操作系统的层次化架构

（1）鸿蒙的层次化分析

1)内核层：主要由内核子系统和驱动子系统组成。

• 内核子系统：HarmonyOS采用多内核设计，支持针对不同资源受限设备选用适合的OS内核。内核抽象层通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。
• 驱动子系统：HarmonyOS驱动框架是HarmonyOS硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架。
  2)系统服务层：是HarmonyOS的核心能力集合，通过框架层对应用程序提供服务。该层包含4个部分：
• 系统基本能力子系统集：为分布式应用在 HarmonyOS 多设备上的运行、调度、迁移等操作提供了基础能力。
• 基础软件服务子系统集：为 HarmonyOS 提供公共的、通用的软件服务。
• 增强软件服务子系统集：为 HarmonyOS 提供针对不同设备的、差异化的能力增强型软件服务。
• 硬件服务子系统集：为 HarmonyOS 提供硬件服务。

3)框架层：为 HarmonyOS 的应用程序提供了 Java/C/C++/JS 等多语言的用户程序框架和 Ability 框架，以及各种软硬件服务对外开放的多语言框架 API；同时为采用 HarmonyOS 的设备提供了

C/C++/JS 等多语言的框架 API，不同设备支持的 API 与系统的组件化裁剪程度相关。

4)应用层：包括系统应用和第三方非系统应用。HarmonyOS 的应用由一个或多个 FA(Feature Ability)或 PA(Particle Ability)组成。其中，FA 有 UI 界面，提供与用户交互的能力；而 PA 无 UI 界面，提供后台运行任务的能力以及统一的数据访问抽象。

（2）鸿蒙操作系统的架构分析

鸿蒙操作系统架构具有4个技术特性：

1)分布式架构首次用于终端OS，实现跨终端无缝协同体验。
2)确定时延引擎和高性能IPC技术实现系统天生流畅。
3)基于微内核架构重塑终端设备可信安全。
4)通过统一IDE支撑一次开发，多端部署，实现跨终端生态共享。

在HarmonyOS架构中，重点关注于分布式架构所带来的优势，主要体现在分布式软总线、分布式设备虚拟化、分布式数据管理和分布式任务调度等四个方面。

• 分布式软总线是多种终端设备的统一基座，为设备之间的互联互通提供了统一的分布式通信能力，能够快速发现并连接设备，高效地分发任务和传输数据；
• 分布式设备虚拟化平台可以实现不同设备的资源融合、设备管理、数据处理，多种设备共同形成一个超级虚拟终端。针对不同类型的任务，为用户匹配并选择能力合适的执行硬件，让业务连续地在不同设备间流转，充分发挥不同设备的资源优势；
• 分布式数据管理基于分布式软总线的能力，实现应用程序数据和用户数据的分布式管理。用户数据不再与单一物理设备绑定，业务逻辑与数据存储分离，应用跨设备运行时数据无缝衔接，为打造一致、流畅的用户体验创造了基础条件；
• 分布式任务调度构建统一的分布式服务管理(发现、同步、注册、调用)机制，支持对跨设备的应用进行远程启动、远程调用、远程连接以及迁移等操作，能够根据不同设备的能力、位置、业务运行状态、资源使用情况，以及用户的习惯和意图，选择合适的设备运行分布式任务。

HarmonyOS 架构的系统安全性主要体现在搭载 HarmonyOS 的分布式终端上，可以保证“正确的人，通过正确的设备，正确地使用数据”。这里通过“分布式多端协同身份认证”来保证“正确的人”，通过“在分布式终端上构筑可信运行环境”来保证“正确的设备”，通过“分布式数据在跨终端流动的过程中，对数据进行分类分级管理”来保证“正确地使用数据”。

HarmonyOS架构提供了基于硬件的可信执行环境来保护用户的个人敏感数据的存储和处理，确

保数据不泄露。

2. 面向安全攸关系统的跨领域GENESYS系统架构案例分析

GENESYS 是一种跨领域的通用嵌入式架构平台，主要解决了嵌入式系统面临的三方面挑战：复杂性管理的挑战(采用消息交换方式提高软硬件抽象级别)、系统健壮性的挑战(设计故障的隔离框架)、能量有效使用的挑战(采用综合化资源管理方法)。

GENESYS 整个架构包括两类构成系统：即构件和基础平台。基础平台提供了一种“腰”型核心服务和大量用于实现系统构件的可选择服务的最小集合。

图16-29 GENESYS腰型架构示意图

GENESYS架构主要提供了三组服务，即领域无关服务、领域专用服务和应用专用服务(包括中间件)。领域无关服务又分为核心服务和选择服务；领域专用服务又分为领域专用中心服务(DSC)和领域专用选择服务(DSO)。

(1)核心服务。是强制性的，是GENESYS架构实例的一部分。核心服务应包含那些可构造较高级服务或者为了维持该结构性质而不可缺少的服务，它是系统服务中的最小集。
(2)选择服务。是在核心服务之上构造的。它是一种需要时可以扩展的开放式的集合。
(3)领域专用服务。是由领域特有的选择服务子集加上待开发的领域特征的特定服务组合。

GENESYS 架构的重要思想是分离计算与通信，将计算构件和通信设施作为独立构件进行设计。

GENESYS 的通信设施构件是基于消息传输的风格。构件中的基本交往机制是多播单向消息的交换。消息在发送时刻发出，在某个稍后的时刻达到在接收者那里。每一个消息有专门标识的发送者和若干个接受者。

GENESYS架构将构件归为四类：硬件构件和软件构件、系统构件和应用构件。硬件构件的功能使用硬件被预先确定，因此不能修改。在软件构件中，将加载在软件构件上的软件称为作业。将作业分配给适当的可以执行该作业的硬件单元就创建了新的构件。系统构件是提供某些架构服务的构件。系统构件可以广泛重用在许多不同的应用场景中，应用设计者只考虑应用构件的开发。

基于GENESYS架构的四类基于消息的构件接口：

• 链接接口(LIF): LIF 提供了构件与构件之间基于消息的操作服务, 它是构件的综合接口。
• 局部接口(LI): LI 是构件连接到外部环境(如 I/O、其他系统)的接口, 它建立了构件和局部环境之间的连接关系。
• 技术无关接口(TII)：TII是指用于系统运行需要的配置或管理资源的接口，它属于非功能属性范畴。
• 技术相关的接口(TDI): TDI是指用于查看构件内部、观察构件的内部变量的接口, 如构件诊断。

GENESYS 定义了三级的集成，即芯片级(Chip Level)、设备级(Device Level)和系统级(System Level)。芯片级的构件是 IP 核，IP 核间可通过 NoC(Network of Chip)相互连接；设备级的构件是芯片，芯片间可以由内部通信芯片互相连接。一个设备可以是在互联网上的一个可寻址实体，也可以是一个 IP 地址；系统级的构件是设备，它们可以由有线或无线通信服务互相连接。

3. 物联网操作系统软件架构案例分析

在物联网应用中有三项关键，分别是感知层、网络传输层和应用层。

FreeRTOS是一款开源的物联网操作系统，主要由BSP驱动、内核和组件等组成。

图16-31 FreeRTOS软件架构

物联网操作系统的主要特征：内核尺寸伸缩性以及整体架构的可扩展性、内核的实时性、高可靠性、低功耗。

3.6 通信系统架构设计

3.6.1 通信系统概述

通信系统（也称为通信网络）是利用各种通信线路将地理上分散的、具有独立功能的计算机系统和通信设备按不同的形式连接起来，依靠网络软件及通信协议实现资源共享和信息传递的系统。

3.6.2 通信系统网络架构

当今，通信网络从大的方面主要包括局域网、广域网、移动通信网等网络形式。不同的网络会采用不同的技术进行网络构建。

1. 局域网网络架构

局域网，即计算机局部区域网络，是一种为单一机构所拥有的专用计算机网络。其特点是：覆盖地理范围小，通常限定在相对独立的范围内。低误码率，可靠性高；通常为单一部门或单位所有；支持多种传输介质支持实时应用。就网络拓扑而言，有总线型、环型、星型、树型等型式。从传输介质来说，包含有线局域网和无线局域网。

局域网已从早期只提供二层交换功能的简单网络发展到如今不仅提供二层交换功能，还提供三层路由功能的复杂网络。局域网，现代通常用在园区网络的构建中，某种意义上，局域网也称为园区网。以下给出局域网的几种典型架构风格。

（1）单核心架构

单核心局域网通常由一台核心二层或三层交换设备充当网络的核心设备，通过若干台接入交换设备将用户设备(如用户计算机、智能设备等)连接到网络中。

图17-1 典型单核心局域网

此类局域网可通过连接核心网交换设备与广域网之间的互连路由设备(边界路由器或防火墙)接

入广域网，实现业务跨局域网的访问。单核心网具有如下特点：

(1)核心交换设备通常采用二层、三层及以上交换机；
(2)接入交换设备采用二层交换机，仅实现二层数据链路转发；
(3)核心交换设备和接入设备之间可采用100M/GE/10GE等以太网连接。

用单核心构建网络，其优点是：网络结构简单，可节省设备投资。需要使用局域网的部门接入较为方便，直接通过接入交换设备连接至核心交换设备空闲接口即可；

其不足是网络地理范围受限，要求使用局域网的部门分布较为紧凑；核心网交换设备存在单点故障，容易导致网络整体或局部失效；网络扩展能力有限；在局域网接入交换设备较多的情况下，对核心交换设备的端口密度要求高。

（2）双核心架构

双核心架构通常是指核心交换设备通常采用三层及以上交换机。核心交换设备和接入设备之间可采用100M/GE/10GE等以太网连接。

图17-2 典型双核心局域网

网络内划分VLAN时，各VLAN之间访问需通过两台核心交换设备来完成。网络中仅核心交换设备具备路由功能，接入设备仅提供二层转发功能。

核心交换设备之间互联，实现网关保护或负载均衡。需要使用局域网的部门接入较为方便，直接通过接入交换设备连接至核心交换设备空闲接口即可。

（3）环型架构

环型局域网是由多台核心交换设备连接成双RPR动态弹性分组环，构建网络的核心。核心交换设备通常采用三层或以上交换机提供业务转发功能。

图17-3 典型环型局域网

典型环型局域网网络内各VLAN之间通过RPR环实现互访。通过RPR组建大规模局域网时，多环之间只能通过业务接口互通，不能实现网络直接互通。环型局域网设备投资比单核心局域网的高。核心路由冗余设计实施难度较高，且容易形成环路。

此网络通过与环上的交换设备互联的边界路由设备接入广域网。

（4）层次局域网架构

层次局域网架构(或多层局域网)由核心层交换设备、汇聚层交换设备和接入层交换设备，以及用户设备等组成。

层次局域网模型

2. 广域网网络架构

广域网属于多级网络，通常由骨干网、分布网、接入网组成。在网络规模较小时，可仅由骨干网和接入网组成。通常，在大型网络构建中，通过广域网将分布在各地域的局域网互连起来，形成

一个大的网络。以下给出不同形式的广域网构建模型以及各自的特点。

（1）单核心广域网

通常由一台核心路由设备和各局域网组成。核心路由设备采用三层及以上交换机。网络内各局域网之间访问需要通过核心路由设备。

（2）双核心广域网

通常由两台核心路由设备和各局域网组成。其主要特征是核心路由设备通常采用三层及以上交换机。核心路由设备之间实现网关保护或负载均衡。各局域网访问核心局域网，以及它们相互访问可有多条路径选择，可靠性更高，路由层面可实现热切换，提供业务连续性访问能力。

（3）环型广域网

通常是采用三台以上核心路由器设备构成路由环路，用以连接各局域网，实现广域网业务互访。核心路由设备之间具备网关保护或负载均衡机制，同时具备环路控制功能。各局域网访问核心局域网，或互相访问，有多条路径可选择，可靠性更高，路由层面可实现无缝热切换，保证业务访问连续性。

（4）半冗余广域网

半冗余广域网是由多台核心路由设备连接各局域网而形成的。其中，任意核心路由设备至少存在两条以上连接至其他路由设备的链路。如果任何两个核心路由设备之间均存在链接，则属于半冗余广域网特例，即全冗余广域网。

图17-8 半冗余广域网

（5）对等子域广域网

对等子域广域网是通过将广域网的路由设备划分成两个独立的子域，每个子域路由设备采用半冗余方式互连。两个子域之间通过一条或多条链路互连，对等子域中任何路由设备都可接入局域网络。

对等子域广域网的主要特征是对等子域之间的互访是以对等子域之间互连链路为主。对等子域之间可做到路由汇总或明细路由条目匹配，路由控制灵活。通常，子域之间链路带宽应高于子域内链路带宽。

（6）层次子域广域网

层次子域广域网是将大型广域网路由设备划分成多个较为独立的子域，每个子域内路由设备采用半冗余方式互连，多个子域之间存在层次关系，高层次子域连接多个低层次子域。层次子域中任何路由设备都可以接入局域网。

3. 移动通信网网络架构

（1）5GS与DN互连

5GS(5GSystem)在为移动终端用户(UE)提供服务时通常需要DN(Data Network)网络，各式各样的上网、语音、AR/VR、工业控制和无人驾驶等5GS中UPF网元作为DN的接入点。5GS和DN之间

通过5GS定义的N6接口互连。5GS和DN之间是一种路由关系。

图17-11 5G网络与DN网络连接关系

此外，从 UE 通过 5GS 接入 DN 的方式来说，存在两种模式，即透明模式和非透明模式。

1)透明模式：5GS通过UPF的N6接口直接连至运营商特定的IP网络，然后通过防火墙或代理服务器连至DN(即外部IP网络)，如Internet等。

在此模式下，5GS至少为UE提供一个基本ISP服务。对于5GS而言，它只须提供基本的隧道QoS流服务即可。UE访问某个Intranet网络时，UE级别的配置仅在UE和Intranet网络之间独立完成，这对5GS而言是透明的。

图17-12 UE透明接入5G网络

2)非透明模式：5GS可直接接入Intranet/ISP，或通过其他IP网络(如Internet)接入Intranet/ISP。如5GS通过Internet方式接入Intranet/ISP，通常需要在UPF和Intranet/ISP之间建立专用隧道来转发UE访问Intranet/ISP的业务。UE被指派属于Intranet/ISP地址空间的IP地址。此地址用于UE业务在UPF、Intranet/ISP中转发。

（a）直接接入
图17-13 UE通过5GS非透明接入DN原理图

（b）间接接入

（2）5G网络边缘计算

5G网络的边缘计算(MEC)架构如图所示，支持在靠近终端用户UE的移动网络边缘部署5GUPF网元，结合在移动网络边缘部署边缘计算平台(MEP)，为垂直行业提供诸如以时间敏感、高带宽为特征的业务就近分流服务。

运营商自有应用或第三方应用 AF 通过 5GS 提供的能力开放功能网元 NEF，触发 5G 网络为边缘应用动态地生成本地分流策略，由 PCF 将这些策略配置给相关 SMF，SMF 根据终端用户位置信息或用户移动后发生的位置变化信息动态实现 UPF(即移动边缘云中部署的 UPF)在用户会话中插入或移除，以及对这些 UPF 分流规则的动态配置，达到用户访问所需业务的极佳效果。

图17-14 5G网络边缘计算架构

4. 存储网络架构

一般来说，计算机访问磁盘存储有3种方式：

• 直连式存储（Direct-Attached Storage，DAS），是指将存储设备通过 SCSI 接口直接连接到一台服务器上使用，其本身是硬件的堆叠，存储操作依赖于服务器，不带有任何存储操作系统。

存在问题：在传递距离、连接数量、传输速率等方面都受到限制。容量难以扩展升级；数据处理和传输能力较低；服务器异常会波及存储器。

• 网络连接存储（Network-Attached Storage，NAS），是通过网络接口与网络直接相连，由用户通过网络访问（支持多种TCP/IP协议），有独立的存储系统。NAS设备有自己的OS，类似于一个专用的文件服务器，一般存储信息采用RAID进行管理，即插即用。不仅响应速度快，而且数据传输速率也很高。NAS的性能特点是进行小文件级的共享存取；支持即插即用；可以很经济的解决存储容量不足的问题，但难以获得满意的性能。

• 存储区域网络（Storage Area Network，SAN），是通过专用交换机将磁盘阵列与服务器连接起来的高速专用子网。它没有采用文件共享存取方式，而是采用块（block）级别存储。SAN 是通过专用高速网将一个或多个网络存储设备和服务器连接起来的专用存储系统，其最大特点是将存储设备从传统的以太网中分离了出来，成为独立的存储区域网络 SAN 的系统结构。目前主要使用以太网（IP SAN）和光纤（FC SAN）两类环境。

5. 软件定义网络架构

（1）软件定义网络

软件定义网络(Software Defined Network，SDN)：核心思想是通过对网络设备的控制面与数据面进行分离，控制面集中化管控，同时对外提供开放的可编程接口，为网络应用创新提供极佳的能力开放平台；而数据面则通用化、轻量化，高效转发，以提升网络的整体运行效能。

具体来说，SDN利用分层的思想，将网络分为控制层和数据层。

控制层包括可编程控制器，具有网络控制逻辑的中心，掌握网络的全局信息，方便运营商或网络管理人员配置网络和部署新协议等。

数据层包括哑交换机(与传统的二层交换机不同，专指用于转发数据的设备)，仅提供简单的数据转发功能，可以快速处理匹配的数据包。

两层之间采用开放的统一接口(如OpenFlow等)进行交互。通过此接口控制器向转发设备(如交换机等)下发统一标准的转发规则，转发设备仅需按照这些规则执行相应动作即可。

（2）SDN网络架构

SDN架构如图所示，由下至上分为数据平面、控制平面和应用平面。

图17-17 SDN网络架构

数据平面由网络转发设备(如通常由通用硬件构成)组成，网络转发设备之间通过由不同规则形成的SDN数据通路连接起来；

控制平面包含了逻辑上为中心的SDN控制器，它掌握着网络全局信息，负责转发设备的各种转发规则的下发；

应用平面包含各种基于SDN的网络应用，应用无须关心网络底层细节就可以编程、部署新应用。

以控制器为逻辑中心，南向接口负责与数据平面进行通信，北向接口负责与应用平面进行通信，东西向接口负责多控制器之间的通信。

3.6.3 网络构建关键技术

网络的高可用性是一个系统级的概念。对于一个网络来说，它由网络元素(或网络部件)，按照一定的连接模型连接在一起而构成。因此，网络可用性包括网络部件、网络连接模型以及有关网络协议等方面的可靠性。

1)网络部件：是组成网络的基本要素，典型代表有各种交换机、路由器等网络设备。网络部件的高可用性是网络高可用性的关键。包括硬件结构和软件系统。硬件可用性通过冗余、热备等保证；软件可用性通过异常保护、数据冗余等保证。
2)网络连接模型：除了网络部件本身的高可用性外，网络物理拓扑连接形式也影响网络的可用性程度。这就涉及到串并联系统的可靠性计算。
3)网络协议及配置：高可用性离不开运行于网络中的路由、链路检测等协议，可以部署链路检测协议发现故障。

IPV4和IPV6三种过渡技术、SDN等不再赘述。

3.6.4 网络构建和设计方法

1. 网络需求分析

网络需求分析是网络构建及开发过程的起始环节，也是极其重要的阶段。在该阶段，可尽早明确客户使用网络的真实用途或痛点，以便为后续能够构建和设计出更贴近客户真实诉求的网络打下坚实基础。需求分析过程，主要围绕以下几个方面来开展：业务需求、用户需求、应用需求、计算机平台需求和网络需求。最终形成约束后续网络设计的网络需求规格说明书。

2. 网络技术遴选及设计

网络技术遴选及设计：网络遴选工作是通信系统设计中关键的一项工作，根据计划实施的网络建设要求，遴选工作通常分为局域网、广域网和路由协议的选择。

（1）局域网技术遴选：生成树协议(STP)、虚拟局域网、无线局域网、线路冗余设计、交换设备功能的合理使用、服务器冗余设计。
（2）广域网技术遴选：远程接入技术、广域网互联技术。
（3）地址规划模型：地址分配应遵循以下原则：

① 使用结构化网络层编址模型，即对地址进行层次化的规划。

②通过中心授权机构管理地址，比如由组织的IT部门为网络层编址提供一个全局模型。根据网络的核心、汇聚、接入层次化结构，为组织的各个区域、分支机构等进行地址规划。
③ 编址授权下发。即由地址授权管理中心，将编址授权给分支机构来进行地址规划。
④为终端用户设备指派动态地址，即对于频繁变更位置、移动性角度的用户分配动态地址。
⑤私有地址合理使用。使用私有地址的用户在访问外部网络，需要进行地址转换(NAT)。

（4）路由协议选择包括以下内容：

① 路由协议类型的选择：路由协议选择主要包括距离矢量协议和链路状态协议。
② 路由选择协议度量值的合理设置。
③路由选择协议顺序的合理指定。
④层次化与非层次化路由选择协议。
⑤内部与外部路由选择协议。
⑥分类与无类路由选择协议。
⑦静态路由指定。

（5）层次化网络模型设计：核心层、汇聚层、接入层。
（6）网络高可用设计方法：提高网络可靠性、缩短网络恢复时间。

3. 网络安全

（1）防火墙。
（2）VPN：虚拟专用网。
（3）访问控制技术：主体依据控制策略或权限对客体本身或其资源实施的不同授权访问。
（4）网络安全隔离：是在网络运行过程中将网络攻击隔离在可信网络之外，同时保证可信网络内信息不被外泄。
（5）网络安全协议：SSL、SET、HTTPS等。
（6）网络安全审计：是对网络的脆弱性进行测试评估和分析，最大限度保障业务的安全正常运行的切行为和手段。

4. 绿色网络设计方法

绿色网络设计原则：

1)标准化：在设计之初就应考虑解决方案标准化，整体架构标准化可大幅减少转换设备，从而大大降低了能耗。
2)集成化：可使得整个网络系统的通信设备数量尽可能降低，通过减少设备总量、降低设备使用所需资源(空间、机架、线缆、人力等)，来实现节能减排目标。
3)虚拟化：是一种网络资源可以灵活调配、按需使用的重要途径。
4)智能化：一方面可以降低人力投入从而降低TCO，达到绿色环保目的；另一方面智能化方案可以通过智能处理直接降低资源的占用，实现绿色设计。

3.6.5 通信网络构建案例

1. 高可用网络构建分析

（1）网络接入层高可用性设计

高可用接入层具有下述特征：

(1)使用冗余引擎和冗余电源获得系统级冗余，为关键用户群提供高可靠性；
(2)与具备冗余系统的汇聚层采用双归属连接，获得默认网关冗余，支持在汇聚层的主备交换机间快速实现故障切换；
(3)通过链路汇聚提供带宽利用率，同时降低复杂度；
(4)通过配置802.1x，动态ARP检查及IP源地址保护等功能增加安全性，有效防止非法访问。

图17-20 高可用典型组网架构

接入层到汇聚层有4种连接方式，对比如下：

表 17-1 四种组网模型对比

（2）网络汇聚层高可用设计

汇聚层到核心层间采用OSPF等动态路由协议实现路由层面高可用保障。典型连接方式有两种，组网模型一为三角形连接方式，从汇聚层到核心层具有全冗余链路和转发路径；组网模型二为矩形

连接方式，从汇聚层到核心层为非全冗余链路，当主链路发生故障时，需要通过路由协议计算获得从汇聚到核心的其他路径。可见，组网模型一(即三角形连接方式)的故障收敛时间较小，不足的是，三角形连接方式要占用更多设备端口，建网成本较高。

（3）网络核心层高可用设计

从系统冗余性角度，应考虑部署双核心或多核心设备，以主备或负荷分担方式工作。

2.5G网络应用

5G网络在智能电网中的应用如图所示，通过5G网络将种类繁多数据巨大的设备，如电网智能感知设备(传统电源、新能源电源等)，电网中的输变电网设备、配电设备等，用户电表、电动汽车等连接到物联网(IoT)平台中，由IoT平台进行电网各个环节的数据采集和智能分析，从而为电网的高级应用(输电业务、配电业务、综合能源管理等业务部门)的科学决策提供有力的支撑。

图17-24 基于5G网络的智能电网架构

3.7 安全架构设计

3.7.1 安全架构概述

1. 信息安全面临的威胁

对于信息系统来说，威胁可以是针对物理环境、通信链路、网络系统、操作系统、应用系统以及管理系统等方面。

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

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

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

信息，对网络形成严重的安全威胁；

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

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

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

具体来讲，常见的安全威胁有以下几种。

(1)信息泄露：信息被泄露或透露给某个非授权的实体。
(2)破坏信息的完整性：数据被非授权地进行增删、修改或破坏而受到损失。
(3)拒绝服务：对信息或其他资源的合法访问被无条件地阻止。
(4)非法使用(非授权访问): 某一资源被某个非授权的人或以非授权的方式使用。
(5)窃听：用各种可能的合法或非法的手段窃取系统中的信息资源和敏感信息。
(6)业务流分析：通过对系统进行长期监听，利用统计分析方法对诸如通信频度、通信的信息流向、通信总量的变化等态势进行研究，从而发现有价值的信息和规律。
(7)假冒：通过欺骗通信系统(或用户)达到非法用户冒充成为合法用户，或者特权小的用户冒充成为特权大的用户的目的。黑客大多是采用假冒进行攻击。
(8)旁路控制：攻击者利用系统的安全缺陷或安全性上的脆弱之处获得非授权的权利或特权。
(9)授权侵犯：被授权以某一目的使用某一系统或资源的某个人，却将此权限用于其他非授权的目的，也称作“内部攻击”。
(10)特洛伊木马：软件中含有一个察觉不出的或者无害的程序段，当它被执行时，会破坏用户的安全。
(11)陷阱门：在某个系统或某个部件中设置了“机关”，使得当提供特定的输入数据时，允许违反安全策略。
(12)抵赖：这是一种来自用户的攻击，例如，否认自己曾经发布过的某条消息、伪造一份对方来信等。
(13)重放：所截获的某次合法的通信数据备份，出于非法的目的而被重新发送。
(14)计算机病毒：所谓计算机病毒，是一种在计算机系统运行过程中能够实现传染和侵害的功能程序。一种病毒通常含有两个功能：一种功能是对其他程序产生“感染”；另外一种或者是引发损坏功能或者是一种植入攻击的能力。

(15)人员渎职：一个授权的人为了钱或利益、或由于粗心，将信息泄露给一个非授权的人。
(16)媒体废弃：信息被从废弃的磁盘或打印过的存储介质中获得。
(17)物理侵入：侵入者通过绕过物理控制而获得对系统的访问。
(18)窃取：重要的安全物品，如令牌或身份卡被盗。
(19)业务欺骗：某一伪系统或系统部件欺骗合法的用户或系统自愿地放弃敏感信息。

2. 安全架构的定义和范围

安全架构是架构面向安全性方向上的一种细分，通常的产品安全架构、安全技术体系架构和审计架构可组成三道安全防线。

(1)产品安全架构：构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品。
(2)安全技术体系架构：构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各产品的安全防御能力。
(3)审计架构：独立的审计部门或其所能提供的风险发现能力，审计的范围主要包括安全风险在内的所有风险。

3.7.2 安全模型

信息系统的安全目标是控制和管理主体(含用户和进程)对客体(含数据和程序)的访问。

安全模型是准确地描述安全的重要方面及其与系统行为的关系，安全策略是从安全角度为系统整体和构成它的组件提出基本的目标。安全模型提供了实现目标应该做什么，不应该做什么，具有实践指导意义，它给出了策略的形式。如下图是模型的分类：

图18-3 安全模型的分类方法

1. 状态机模型

状态机模型描述了一种无论处于何种状态都是安全的系统。它是用状态语言将安全系统描述成

抽象的状态机，用状态变量表述系统的状态，用转换规则描述变量变化的过程。

状态机模型中一个状态是处于系统在特定时刻的一个快照。如果该状态所有方面满足安全策略的要求，则称此状态是安全的；一个安全状态模型系统，总是从一个安全状态启动，并且在所有迁移中保持安全状态，只允许主体以和安全策略相一致的安全方式访问资源。

2.Bell-LaPadula模型

Bell-LaPadula 模型使用主体、客体、访问操作(读、写、读/写)以及安全级别这些概念，当主体和客体位于不同的安全级别时，主体对客体就存在一定的访问限制。通过该模型可保证信息不被不安全主体访问。

图18-5 Bell-LaPadula模型基本原理图

Bell-LaPadula模型的安全规则如下：

(1)简单安全规则：安全级别低的主体不能读安全级别高的客体(No Read Up)；只能下读。
(2)星属性安全规则：安全级别高的主体不能往低级别的客体写(No Write Down)；只能上写。
(3)强星属性安全规则：不允许对另一级别进行读写；
(4)自主安全规则：使用访问控制矩阵来定义说明自由存取控制。其存取控制体现在内容相关和上下文相关。

3.Biba模型

Biba模型不关心信息机密性的安全级别，因此它的访问控制不是建立在安全级别上，而是建立在完整性级别上。

完整性的三个目标：保护数据不被未授权用户更改；保护数据不被授权用户越权修改(未授权更改)；维持数据内部和外部的一致性。

图18-6 Biba模型基本原理

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

(1)星完整性规则：表示完整性级别低的主体不能对完整性级别高的客体写数据；只能下写。
(2)简单完整性规则：表示完整性级别高的主体不能从完整性级别低的客体读取数据；只能上读。
(3)调用属性规则：表示一个完整性级别低的主体不能从级别高的客体调用程序或服务。

4. Clark-Wilson 模型

Clark-Wilson 模型是一种将完整性目标、策略和机制融为一体的模型。为了体现用户完整性，CWM 提出了职责隔离目标；为了保证数据完整性，CWM 提出了应用相关的完整性验证进程；为了建立过程完整性，CWM 定义了对于变换过程的应用相关验证。

图18-7 CWM模型基本原理图

(1)需要进行完整性保护的客体称之为CDI，不需要进行完整性保护的客体称之为UDI；
(2)完整性验证过程(IVP)：确认限制数据项处于一种有效状态，如果IVP检验CDI符合完整性约束，则系统处于一个有效状态；
(3)转换过程(TP)：将数据项从一种有效状态改变至另一种有效状态；
(4)为了确保对 CDI 的 TP 是有效的，则需要授权 User 做 TP 的认证；
(5)为了防止合法用户对 CDI 做非法或错误操作，将 TP 过程分为多个子过程，将每个子过程授权给不同的 User；
(6)但是如果TP的每个子过程被授权的User之间存在某种利益同盟，则可能存在欺骗。从而使得CDI的完整性得不到保护。

CWM的主要特征是：

(1)采用Subject/Program/Object三元素的组成方式。Subject要访问Object只能通过Program进行；
(2) 权限分离原则：将要害功能分为有 2 个或多个 Subject 完成，防止已授权用户进行未授权的修改；
(3)要求具有审计能力。

5. Chinese Wall 模型

Chinese Wall 模型(又名 Brew and Nash 模型)是应用在多边安全系统中的安全模型。也就是说，是指通过行政规定和划分、内部监控、IT 系统等手段防止各部门之间出现有损客户利益的利益冲突事件。

Chinese Wall 模型的安全策略的基础是客户访问的信息不会与当前他们可支配的信息产生冲突。在投资银行中，一个银行会同时拥有多个互为竞争者的客户，一个银行家可能为一个客户工作，但他可以访问所有客户的信息。因此，应当制止该银行家访问其他客户的数据。银行家可以选择为谁工作(DAC)，一旦选定，他就只能为该客户工作(MAC)。

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

(1)与主体曾经访问过的信息属于同一公司数据集合的信息，即墙内信息可以访问；
(2)属于一个完全不同的利益冲突组的可以访问；
(3)主体能够对一个客体进行写的前提是主体未对任何属于其他公司数据集进行过访问。

定理1：一个主体一旦访问过一个客体，则该主体只能访问位于同一公司数据集的客体或在不同利益组的客体。

定理2：在一个利益冲突组中，一个主体最多只能访问一个公司数据集。

比如，假设 Chinese Wall 安全策略包括三个信息存储模块：某家企业的单位信息(C)、该家企业的所有信息集合(CD)和该家企业与互为竞争关系企业的全部信息集合(COI)。那么，Chinese Wall 模型规定：

(1)每个C只能唯一对应一个CD;
(2)每个CD只能唯一对应一个利益冲突类COI；
(3)一个COI类却可以同时包含多个CD。

3.7.3 系统安全体系架构规划框架

安全技术体系架构是对组织机构信息技术系统的安全体系结构的整体描述。安全技术体系架构的目标是建立可持续改进的安全技术体系架构的能力。

1. 安全技术体系架构

根据网络中风险威胁的存在实体划分出5个层次的实体对象：应用、存储、主机、网络和物理。

2. 信息系统安全体系规划

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

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

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

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

3. 信息系统安全规划框架

图18-11 信息系统安全规划框架

（1）信息系统安全规划依托企业信息化战略规划

信息系统安全规划依托企业信息化战略规划，对信息化战略的实施起到保驾护航的作用。信息系统安全规划的目标应该与企业信息化的目标是一致的，而且应该比企业信息化的目标更具体明确、更贴近安全。

（2）信息系统安全规划需要围绕技术安全、管理安全、组织安全考虑

规划的内容基本上应涵盖：确定信息系统安全的任务、目标、战略以及战略部门和战略人员，并在此基础上制定出物理安全、网络安全、系统安全、运营安全、人员安全的信息系统安全的总体规划。

（3）信息系统安全规划以信息系统与信息资源的安全保护为核心

规划工作需要围绕着信息系统与信息资源的开发、利用和保护工作进行，要包括蓝图、现状、需求和措施4个方面。

(1)对信息系统与信息资源的规划需要从信息化建设的蓝图入手，知道企业信息化发展策略的总体目标和各阶段的实施目标，制定出信息系统安全的发展目标。
(2)对企业的信息化工作现状进行整体的、综合、全面的分析，找出过去工作中的优势与不足。
(3)根据信息化建设的目标提出未来几年的需求，这个需求最好可以分解成若干个小的方面，以

便于今后的实施与落实。

(4)要明确在实施工作阶段的具体措施与方法，提高规划工作的执行力度。

3.7.4 信息安全整体架构设计（WPDRRC模型）

人、管理和技术手段是信息安全架构设计的三大要素，而构成动态的信息与网络安全保障体系框架是实现系统的安全保障。

1.WPDRRC信息安全体系架构模型

WPDRRC(Waring/Protect/Detect/React/Restore/Counterattack)模型有6个环节和3大要素。

6个环节包括：预警、保护、检测、响应、恢复和反击，它们具有较强的时序性和动态性，能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。

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

图18-12WPDRRC模型示意

• W：预警主要是指利用远程安全评估系统提供的模拟攻击技术来检查系统存在的、可能被利用的薄弱环节，收集和测试网络与信息的安全风险所在，并以直观的方式进行报告，提供解决方案的建议，在经过分析后，分解网络的风险变化趋势和严重风险点，从而有效降低网络的总体风险，保护关键业务和数据。
• P：防护通常是通过采用成熟的信息安全技术及方法来实现网络与信息的安全。主要内容有加密机制，数字签名机制，访问控制机制，认证机制，信息隐藏和防火墙技术等。
• D：检测通过检测和监控网络以及系统，来发现新的威胁和弱点，强制执行安全策略。在这个过程中采用入侵检测、恶意代码过滤等技术，形成动态检测的制度，奖励报告协调机制，提高检测

的实时性。主要内容有入侵检测，系统脆弱性检测，数据完整性检测和攻击性检测等。

• R：响应是指在检测到安全漏洞和安全事件之后必须及时做出正确的响应，从而把系统调整到安全状态。为此需要相应的报警、跟踪、处理系统，其中处理包括了封堵、隔离、报告等能力。主要内容有应急策略、应急机制、应急手段、入侵过程分析和安全状态评估等。
• R：恢复灾难恢复系统是当前网络、数据、服务受到黑客攻击并遭到破坏或影响后，通过必要技术手段，在尽可能短的时间内使系统恢复正常。主要内容有容错、冗余、备份、替换、修复和恢复等。
• C：反击是指采用一切可能的高新技术手段，侦察、提取计算机犯罪分子的作案线索与犯罪证据，形成强有力的取证能力和依法打击手段。

2.信息安全体系架构设计

信息系统安全设计重点考虑两个方面：其一是系统安全保障体系；其二是信息安全体系架构。

（1）系统安全保障体系

系统安全保障体系是由安全服务、协议层次和系统单元等三个层面组成，且每个层都涵盖了安全管理的内容。系统安全保障体系设计工作主要考虑以下几点：

①安全区域策略的确定：根据安全区域的划分，主管部门应制定针对性的安全策略。如定时审计评估、安装入侵检测系统、统一授权、认证等；
②统一配置和管理防病毒系统：主管部门应当建立整体防御策略，以实现统一的配置和管理。网络防病毒的策略应满足全面性、易用性、实时性和可扩展性等方面要求；
③网络安全管理：在网络安全中，除了采用一些技术措施之外，加强网络安全管理，制定有关规章制度。

（2）信息安全体系架构

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

1)物理安全：保证计算机信息系统各种设备的物理安全是保障整个网络系统安全的前提。包括：环境安全、设备安全、媒体安全等。
2)系统安全：主要是指对信息系统组成中各个部件的安全要求。系统安全是系统整体安全的基础。它主要包括：网络结构安全、操作系统安全和应用系统安全。
3)网络安全：是整个安全解决方案的关键。它主要包括：访问控制、通信保密、入侵检测、网络安全扫描系统和防病毒等。
4)应用安全：主要是指多个用户使用网络系统时，对共享资源和信息存储操作所带来的安全问

题。它主要包括资源共享和信息存储两个方面。

5)安全管理：主要体现在三个方面。其一是制定健全的安全管理体制；其二是构建安全管理平台；其三是增强人员的安全防范意识。

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

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

3.7.5 网络安全体系架构设计

1.OSI的安全体系架构概述

OSI定义了7层协议，其中除第5层(会话层)外，每一层均能提供相应的安全服务。实际上，最适合配置安全服务的是在物理层、网络层、运输层及应用层上，其他层都不宜配置安全服务。

OSI开放系统互联安全体系的5类安全服务包括鉴别、访问控制、数据机密性、数据完整性和抗抵赖性。

OSI定义分层多点安全技术体系架构，也称为深度防御安全技术体系架构，它通过以下三种方式将防御能力分布至整个信息系统中。

1)多点技术防御：在对手可以从内部或外部多点攻击一个目标的前提下，多点技术防御通过对网络和基础设施、边界、计算环境这三个防御核心区域的防御达到抵御所有方式的攻击目的。
2)分层技术防御：即使最好的可得到的信息保障产品也有弱点，其最终结果将使对手能找到一个可探查的脆弱性，一个有效的措施是在对手和目标间使用多个防御机制。
3)支撑性基础设施：为网络、边界和计算环境中信息保障机制运行基础的支撑性基础设施，包括公钥基础设施以及检测和响应基础设施。

2. 认证框架

鉴别(Authentication)的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。鉴别有两种重要的关系背景：一是实体由申请者来代表，申请者与验证者之间存在着特定的通信关系(如实体鉴别)；二是实体为验证者提供数据项来源。

鉴别服务分为以下阶段：

在安装阶段，定义申请鉴别信息和验证鉴别信息。

修改鉴别信息阶段，实体或管理者申请鉴别信息和验证鉴别信息变更(如修改口令)。

在分发阶段，为了验证交换鉴别信息，把验证鉴别信息分发到各实体(如申请者或验证者)以供使用。

在获取阶段，申请者或验证者可得到为鉴别实例生成特定交换鉴别信息所需的信息，通过与可信第三方进行交互或鉴别实体间的信息交换可得到交换鉴别信息。

在传送阶段，在申请者与验证者之间传送交换鉴别信息。

在验证阶段，用验证鉴别信息核对交换鉴别信息。

在停活阶段，将建立一种状态，使得以前能被鉴别的实体暂时不能被鉴别。

在重新激活阶段，使在停活阶段建立的状态将被终止。

在取消安装阶段，实体从实体集合中被拆除。

3. 访问控制框架

访问控制(Access Control)决定开放系统环境中允许使用哪些资源、在什么地方适合阻止未授权访问的过程。

ACI(访问控制信息)是用于访问控制目的的任何信息，其中包括上下文信息。ADI(访问控制判决信息)是在做出一个特定的访问控制判决时可供 ADF 使用的部分(或全部)ACI。

ADF(访问控制判决功能)是一种特定功能，它通过对访问请求、ADI以及该访问请求的上下文使用访问控制策略规则而做出访问控制判决。AEF(访问控制实施功能)确保只有对目标允许的访问才由发起者执行。

涉及访问控制的有发起者、AEF、ADF和目标。

图18-19 基本访问控制功能示意图

图18-20 ADF示意图

4. 机密性框架

数据的机密性可以依赖于所驻留和传输的媒体。因此，存储数据的机密性能通过使用隐藏数据语义(如加密)或将数据分片的机制来保证。数据在传输中的机密性能通过禁止访问的机制、通过隐藏数据语义的机制或通过分散数据的机制得以保证(如跳频等)。这些机制类型能被单独使用或者组合使用。具体机制包括：通过禁止访问提供机密性、通过加密提供机密性、通过数据填充、虚假事件等。

5. 完整性框架

对于不同的媒体，数据完整性保护机制是有区别的，可概括为以下两种情况。

(1)阻止对媒体访问的机制。包括物理隔离的不受干扰的信道、路由控制、访问控制。
(2)用以探测对数据或数据项序列的非授权修改的机制。未授权修改包括未授权数据创建、数据删除以及数据重复。而相应的完整性机制包括密封、数字签名、数据重复(作为对抗其他类型违规的手段)、与密码变换相结合的数字指纹和消息序列号。

6. 抗抵赖框架

抗抵赖服务包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。

框架所描述的抗抵赖服务的目的是提供有关特定事件或行为的证据。

抗抵赖由4个独立的阶段组成：证据生成；证据传输、存储及恢复；证据验证和解决纠纷。如图所示。

图18-21 参与生成、传输、存储及恢复和证实阶段的实体

注：本图是示意图，并非定义。

3.7.6 数据库系统的安全设计

按照TCSEC标准，D类产品是基本没有安全保护措施的产品，C类产品只提供了安全保护措施，一般不称为安全产品。B类以上产品是实行强制存取控制的产品，也是真正意义上的安全产品。所谓安全产品均是指安全级别在B1以上的产品，而安全数据库研究原型一般是指安全级别在B1级以上的以科研为目的，尚未产品化的数据库管理系统原型。

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

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

(1)根据数据库完整性约束的类型确定其实现的系统层次和方式，并提前考虑对系统性能的影响。一般情况下，静态约束应尽量包含在数据库模式中，而动态约束由应用程序实现。
(2)实体完整性约束、引用完整性约束是关系数据库最重要的完整性约束，在不影响系统关键性能的前提下需尽量应用。用一定的时间和空间来换取系统的易用性是值得的。
(3)要慎用目前主流DBMS都支持的触发器功能，一方面由于触发器的性能开销较大；另一方面，触发器的多级触发难以控制，容易发生错误，非用不可时，最好使用Before型语句级触发器。
(4)在需求分析阶段就必须制定完整性约束的命名规范，尽量使用有意义的英文单词、缩写词、表名、列名及下画线等组合，使其易于识别和记忆。
(5)要根据业务规则对数据库完整性进行细致的测试，以尽早排除隐含的完整性约束间的冲突和对性能的影响。
(6)要有专职的数据库设计小组，自始至终负责数据库的分析、设计、测试、实施及早期维护。
(7)应采用合适的 CASE 工具来降低数据库设计各阶段的工作量。

数据库完整性的作用：

(1)数据库完整性约束能够防止合法用户使用数据库时向数据库中添加不合语义的数据。
(2)利用基于DBMS的完整性控制机制来实现业务规则，易于定义，容易理解，而且可以降低应用程序的复杂性，提高应用程序的运行效率。
(3)合理的数据库完整性设计，能够同时兼顾数据库的完整性和系统的效能。
(4)在应用软件的功能测试中，完善的数据库完整性有助于尽早发现应用软件的错误。
(5)数据库完整性约束可分为6类：列级静态约束、元组级静态约束、关系级静态约束、列级动态约束、元组级动态约束和关系级动态约束。

一个好的数据库完整性设计，首先需要在需求分析阶段确定要通过数据库完整性约束实现的业务规则。然后在充分了解特定DBMS提供的完整性控制机制的基础上，依据整个系统的体系结构和性能要求，遵照数据库设计方法和应用软件设计方法，合理选择每个业务规则的实现方式。最后，认真测试，排除隐含的约束冲突和性能问题。

3.7.7 系统架构的脆弱性分析

1. 概述

脆弱性分析主要是分析信息系统中产生脆弱性的根源、脆弱性可能造成的影响、如何利用脆弱性进行攻击、如何修补脆弱性、如何防止脆弱性被利用、如何探测目标系统的脆弱性、如何预测新的脆弱性的存在等一系列问题。

从技术角度而言，漏洞的来源主要有以下几个方面：软件设计时的瑕疵、软件实现中的弱点、软件本身的瑕疵、系统和网络的错误配置。

2. 软件脆弱性

（1）软件脆弱性定义

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

（2）软件脆弱性的特点和分类

软件脆弱性有其自身的特点，主要包括4个方面：

(1)脆弱性是软件系统中隐藏的一个弱点，本身不会引起危害，但被利用后会产生严重的安全后果；
(2)在软件开发过程中，自觉或不自觉引入的逻辑错误是大多数脆弱性的根本来源；
(3)与具体的系统环境密切相关，系统环境的任何差异都有可能导致不同的脆弱性问题；
(4)旧的脆弱性得到修补或纠正的同时可能引入新的脆弱性，因此脆弱性问题会长期存在。

（3）软件脆弱性的生命周期

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

(1)输入验证错误；(2)权限检查错误；(3)操作序列化错误；(4)边界检出错误；(5)软件设计时的缺陷；(6)其他错误。

产生破坏效果阶段：主要包括：

(1)非法执行代码；(2)非法修改目标对象；(3)访问数据对象；(4)拒绝服务攻击。

修补阶段：主要包括：

(1)删除伪造实体(如IP伪造、名字伪造等); (2)增加新的实体; (3)写该实体不正确的位置; (4)其他情况。
（4）软件脆弱性的分析方法

软件脆弱性分析可从三个方面考虑：

(1)分析软件故障现象，分析故障的技术本质、总结脆弱性模式；
(2)分析软件开发，发现安全管理和技术的薄弱环节，提高软件安全性；
(3)分析软件使用，发现其脆弱性，采取相应措施，避免脆弱性转化为安全故障。

软件脆弱性分析首先要明确分析对象，脆弱性分析对象可以分为两类：脆弱性数据和软件系统。

由于软件本身具有自身的性质和特点，针对软件的脆弱性分析，我们也需要考虑软件本身的各种特点。主要考虑软件结构和实现技术两个方面。

3.典型软件架构的脆弱性分析

（1）分层架构

分层架构的脆弱性主要表现在两个方面：

(1)层间的脆弱性。一旦某个底层发生错误，那么整个程序将会无法正常运行。
(2)层间通信的脆弱性。将系统隔离为多个相对独立的层，这就要求在层与层之间引入通信机制。本来“直来直去”的操作现在要层层传递，势必造成性能下降。

（2）C/S架构

C/S架构的脆弱性主要表现在以下几个方面：

(1)客户端软件的脆弱性。因为在用户计算机上安装了客户端软件，所以这个系统就面临着程序被分析、数据被截取的安全隐患。
(2)网络开放性的脆弱性。目前很多传统的C/S系统还是采用二层结构，也就是说所有客户端直接读取服务器端中的数据，在客户端包括了数据的用户名，密码等致命的信息，这样会给系统带来安全隐患。
(3)网络协议的脆弱性。C/S架构不便于随时与用户交流(主要是不便于数据包共享)，并且C/S架构软件在保护数据的安全性方面有着先天的弊端。由于C/S架构软件的数据分布特性，客户端所发生的火灾、盗抢、地震、病毒等都将成为可怕的数据杀手。

（3）B/S架构

B/S架构的脆弱性主要表现在：系统如果使用HTTP协议，B/S架构相对C/S架构而言更容易被病毒入侵，虽然最新的HTTP协议在安全性方面有所提升，但还是弱于C/S。

（4）事件驱动架构

事件驱动架构的脆弱性主要表现在：

(1)组件的脆弱性。组件削弱了自身对系统的控制能力，一个组件触发事件，并不能确定响应该事件的其他组件及各组建的执行顺序。
(2)组件间交换数据的脆弱性。组件不能很好地解决数据交换问题，事件触发时，一个组件有可能需要将参数传递给另一个组件，而数据量很大的时候，如何有效传递是一个脆弱性问题。
(3)组件间逻辑关系的脆弱性。事件架构使系统中各组件的逻辑关系变得更加复杂。
(4)事件驱动容易进入死循环，这是由编程逻辑决定的。
(5)高并发的脆弱性。虽然事件驱动可实现有效利用CPU资源，但是存在高并发事件处理造成的系统响应问题，而且，高并发容易导致系统数据不正确、丢失数据等现象。
(6)固定流程的脆弱性。因为事件驱动的可响应流程基本都是固定的，如果操作不当，容易引发安全问题。

（5）MVC架构

MVC架构的脆弱性主要表现在：

(1)MVC架构的复杂性带来脆弱性。MVC架构增加了系统结构和实现的复杂性。比如说一个简单的界面，如果严格遵循MVC方式，使得模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
(2)视图与控制器间紧密连接的脆弱性。视图与控制器是相互分离但确是联系紧密的部件，没有控制器的存在，视图应用是很有限的。反之亦然，这样就妨碍了它们的独立重用。
(3)视图对模型数据的低效率访问的脆弱性。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。

（6）微内核架构

微内核架构的脆弱性主要表现在：

(1)微内核架构难以进行良好的整体化优化。由于微内核系统的核心态只实现了最基本的系统操作，这样内核以外的外部程序之间的独立运行使得系统难以进行良好的整体优化。
(2)微内核系统的进程间通信开销也较单一内核系统要大得多。从整体上看，在当前硬件条件下，微内核在效率上的损失小于其在结构上获得的收益。
(3)通信损失率高。微内核把系统分为各个小的功能块，从而降低了设计难度，系统的维护与修

改也容易，但通信带来的效率损失是一个问题。

（7）微服务架构

微服务架构的脆弱性主要表现在：

(1)开发人员需要处理分布式系统的复杂结构。
(2)开发人员要设计服务之间的通信机制，通过写代码来处理消息传递中速度过慢或者不可用等局部实效问题。
(3)服务管理的复杂性，在生产环境中要管理多个不同的服务实例，这意味着开发团队需要全局统筹。

3.7.8 安全架构设计案例分析

1. 电子商务系统的安全性设计

认证、授权和审计(AAA)是运行于宽带网络接入服务器上的客户端程序。AAA提供了一个用来对认证、授权和审计三种安全功能进行配置的一致的框架，实际上是对网络安全的一种管理。

RADIUS 服务器负责接收用户的连接请求，完成验证并把用户所需的配置信息返回给 BAS 建立连接，从而可以获得访问其他网络的权限时，BAS 就起到了认证用户的作用。BAS 负责把用户之间的验证信息传递通过密钥的参与来完成。用户的密码加密以后才能在网上传递，以避免用户的密码在不安全的网络上被窃取。

高性能的 RADIUS 软件架构核心如图所示。

图18-24 RADIUS软件架构核心逻辑性

RADIUS软件架构分为三个层面：协议逻辑层、业务逻辑层和数据逻辑层。

协议逻辑层主要实现RFC框架中的内容，处理网络通信协议的建立、通信和停止方面的工作。在软件功能上，这个部分主要相当于一个转发引擎，起到分发处理的内容分发到不同的协议处理过程中，这一层的功能起到了协议与业务处理的分层处理的作用。

业务逻辑层的设计是 RADIUS 软件架构设计的核心部分，协议处理进程主要是对转发引擎发来

的包进行初步分析，并根据包的内容进一步分发到不同的业务逻辑处理进程。业务逻辑进程分为认证、计费和授权三种类型，不同的业务逻辑进程可以接收不同协议进程之间的信息并进行处理。转发进程与协议进程之间采用共享内存的方法，实现进程之间的通信。协议进程与业务逻辑处理进程之间采用进程加线程的实现方法。

数据逻辑层需要对来自业务逻辑处理线程统一管理与处理数据库代理池的数据，由数据库代理池统一连接数据库，以减少对数据库系统的压力。

2. 基于混合云的工业安全架构设计

下图给出了大型企业采用混合云技术的安全生产管理系统的架构，企业由多个跨区域的智能工厂和公司总部组成，公司总部负责相关业务的管理、协调和统计分析，而每个智能工厂负责智能产品的设计与生产制造。智能工厂内部采用私有云实现产品设计、数据共享和生产集成等，公司总部与智能工厂间采用公有云实现智能工厂间、智能工厂与公司总部间的业务管理、协调和统计分析等。

图18-25 基于混合云的安全生产管理系统架构

整个安全生产管理系统架构由四层组成，设备层、控制层、设计管理层和应用层。设备层主要是指用于智能工厂生产产品所需的相关设备；

控制层主要是指智能工厂生产产品所需要建立的一套自动控制系统，控制智能设备完成生产工作；

设计/管理层是指智能工厂各种开发、业务控制和数据管理功能的集合，实现数据集成与应用；

应用层主要是指在云计算平台上进行信息处理，主要涵盖两个核心功能，一是“数据”，应用层需要完成数据的管理和数据的处理，二是“应用”，仅仅管理和处理数据还远远不够，必须将这些数据与行业应用相结合，本系统主要包括定制业务、协同业务和产品服务等。

在设计基于混合云的安全生产管理系统中，需要重点考虑5个方面的安全问题。设备安全、网

络安全、控制安全、应用安全和数据安全。

3.8大数据架构设计

3.8.1 传统数据处理系统存在的问题

传统数据库的数据过载问题：传统应用的数据系统架构设计时，应用直接访问数据库系统。当用户访问量增加时，数据库无法支撑日益增长的用户请求的负载，从而导致数据库服务器无法及时响应用户请求，出现超时的错误。常用解决方法有：（1）增加异步处理队列（2）建立数据库水平分区（3）建立数据库分片或重新分片（4）引入读写分离技术（5）引入分库分表技术。

现代大数据处理技术主要有：（1）基于分布式文件系统Hadoop。（2）使用Map/Reduce或Spark数据处理技术。（3）使用Kafka数据传输消息队列及Avro二进制格式。

大数据的利用过程分为：采集、清洗、统计和挖掘4个过程。

3.8.2大数据处理系统架构分析

大数据带来的三大挑战：

1.如何利用信息技术等手段处理非结构化和半结构化数据。
2.如何探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模。
3. 数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响。

大数据处理系统架构特征：

1.鲁棒性和容错性
2.低延迟读取和更新能力
3.横向扩容
4.通用性
5.延展性
6.即席查询能力
7.最少维护能力
8.可调试性

3.8.3 Lambda 架构

Lambda架构设计目的在于提供一个能满足大数据系统关键特性的架构，包括高容错、低延迟、可扩展等。其整合离线计算与实时计算，融合不可变性、读写分离和复杂性隔离等原则。Lambda是用于同时处理离线和实时数据的，可容错的，可扩展的分布式系统。它具备强鲁棒性，提供低延迟和持续更新。

Lambda架构应用场景：机器学习、物联网、流处理。

1. Lambda 架构介绍

如图所示，Lambda架构可分解为三层，即批处理层、加速层和服务层。

图19-4 Lambda架构

(1)批处理层(Batch Layer)：存储数据集，Batch Layer在数据集上预先计算查询函数，并构建查询所对应的View。Batch Layer可以很好地处理离线数据，但有很多场景数据不断实时生成，并且需要实时查询处理。Speed Layer正是用来处理增量的实时数据。
(2)加速层(Speed Layer): Batch Layer 处理的是全体数据集，而 Speed Layer 处理的是最近的增量数据流。Speed Layer 为了效率，在接收到新的数据后会不断更新 Real-time View，而 Batch Layer 是根据全体离线数据集直接得到 Batch View。
(3)服务层(Serving Layer): Serving Layer 用于合并 Batch View 和 Real-time View 中的结果数据集到最终数据集。用于响应用户的查询请求。

2. Lambda 架构实现

如图所示，在这种 Lambda 架构实现中，Hadoop(HDFS)用于存储主数据集，Spark(或 Storm)可构成速度层(Speed Layer)，HBase(或 Cassandra)作为服务层，由 Hive 创建可查询的视图。

图19-9 技术选型

Hadoop是被设计成适合运行在通用硬件上的分布式文件系统。HDFS是一个具有高度容错性的系统，能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一些约束，以达到流式读取文件系统数据的目的。

Apache Spark 是专为大规模数据处理而设计的快速通用的计算引擎。Spark 中间输出结果可以保存在内存中，从而不再需要读写 HDFS，因此 Spark 能更好地适用于数据挖掘与机器学习等需要迭代的 Map Reduce 算法。

HBase-Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用 HBase 技术可在廉价 PCServer 上搭建起大规模结构化存储集群。

3. Lambda 架构的优缺点

Lambda 架构的优点：容错性好、查询灵活度高、易伸缩、易扩展。

Lambda架构的缺点：全场景覆盖带来的编码开销。针对具体场景重新离线训练一遍益处不大。
重新部署和迁移成本很高。

4. Lambda 与其他架构模式对比

（1）事件溯源(Event Sourcing)与Lambda架构

Event Sourcing 本质上是一种数据持久化的方式，其由三个核心观点构成：

(1)整个系统以事件为驱动，所有业务都由事件驱动来完成。
(2)事件是核心，系统的数据以事件为基础，事件要保存在某种存储上。
(3)业务数据只是一些由事件产生的视图，不一定要保存到数据库中。

Lambda架构中数据集的存储使用的概念与EventSourcing中的思想完全一致，二者都是在使用统一的数据模型对数据处理事件本身进行定义。这样在发生错误的时候，能够通过模型找到错误发生的原因，对这一事件进行重新计算以丢弃错误信息，恢复到系统应该的正确状态，以此实现了系统的容错性。

（2）CQRS与Lambda架构

CQRS架构分离了对于数据进行的读操作(查询)和写(修改)操作。其将能够改变数据模型状态的命令和对于模型状态的查询操作实现了分离。这是领域驱动设计的一个架构模式，主要用来解决数据库报表的输出处理方式。

Lambda架构中，数据的修改通过批处理和流处理实现，通过写操作将数据转换成查询时所对应的View。在Lambda架构中，对数据进行查询时，实际上是通过读取View直接得到结果，读出所需的内容。这实际上是一种形式的读写分离。

3.8.4 Kappa 架构

1. Kappa 架构介绍

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

图19-10 Kappa架构

如图所示，输入数据直接由实时层的实时数据处理引擎对源源不断的源数据进行处理，再由服务层的服务后端进一步处理以提供上层的业务查询。而中间结果的数据都是需要存储的，这些数据包括历史数据与结果数据，统一存储在存储介质中。

从使用场景上来看，Kappa架构与Lambda相比，主要有两点区别：

(1)Kappa不是Lambda的替代架构，而是其简化版本，Kappa放弃了对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求；
(2)Lambda直接支持批处理，因此更适合对历史数据分析查询的场景。

2. Kappa 架构的优缺点

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

Kappa的缺点：

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

3. 常见Kappa架构变形

（1）Kappa+架构

Kappa+是流式数据处理架构，它的核心思想是让流计算框架直接读HDFS里的数据仓库数据，一并实现实时计算和历史数据backfl计算，不需要为backfl作业长期保存日志或者把数据拷贝回消息队列。开发了ApacheHUDi框架来存储数据仓库数据，hudi支持更新、删除已有parquet数据，也支持增量消费数据更新部分。

如图所示，将不同来源的数据通过 Kafka 导入到 Hadoop 中，通过 HDFS 来存储中间数据，再通过 spark 对数据进行分析处理，最后交由上层业务进行查询。

图19-11 kappa+架构

（2）混合分析系统的Kappa架构

混合分析系统的Kappa架构：Lambda和Kappa架构都还有展示层的困难点，结果视图如何支持热点数据查询分析，一个解决方案是在Kappa基础上衍生数据分析流程。

在基于使用Kafka+Flink构建Kappa流计算数据架构，针对Kappa架构分析能力不足的问题，再利用Kafka对接组合Elastic-Search实时分析引擎，部分弥补其数据分析能力。但是Elastic Search也只适合对合理数据量级的热点数据进行索引，无法覆盖所有批处理相关的分析需求，这种混合架构某种意义上属于Kappa和Lambda间的折中方案。

3.8.5 Lambda 架构与 Kappa 架构的对比和设计选择

1. Lambda 架构与 Kappa 架构的特性对比

表 19-1 Lambda 架构和 Kappa 架构对比

2. Lambda 架构与 Kappa 架构的设计选择

根据两种架构对比分析，将业务需求、技术要求、系统复杂度、开发维护成本和历史数据处理能力作为选择考虑因素。而计算开销虽然存在一定差别，但是相差不是很大，所以不作为考虑因素。

（1）业务需求与技术要求：如果业务对于Hadoop、Spark、Strom等关键技术有强制性依赖，选择Lambda架构可能较为合适；如果处理数据偏好于流式计算，又依赖Flink计算引擎，那么选择Kappa架构可能更为合适。
（2）复杂度：如果项目中需要频繁地对算法模型参数进行修改，Lambda架构需要反复修改两套代码，则显然不如Kappa架构简单方便。同时，如果算法模型支持同时执行批处理和流式计算，或者希望用一份代码进行数据处理，那么可以选择Kappa架构。
（3）开发维护成本：Lambda架构需要有一定程度的开发维护成本，包括两套系统的开发、部署、测试、维护，适合有足够经济、技术和人力资源的开发者。而Kappa架构只需要维护一套系统，适合不希望在开发维护上投入过多成本的开发者。
（4）历史数据处理能力：有些情况下，项目会频繁接触海量数据集进行分析，比如过往十年内的地区降水数据等，这种数据适合批处理系统进行分析，应该选择Lambda架构。如果始终使用小规模数据集，流处理系统完全可以使用，则应该选择Kappa架构。

3.8.6大数据架构设计案例分析

1. Lambda 架构在某网奥运中的大数据应用

Lambda架构实时处理层采用增量计算实时数据的方式，可以在集群规模不变的前提下，秒级分析出当日概览所需要的信息。赛事回顾模块需要展现自定义时间段内的历史最高在线人数、逐日播放走势、直播最高在线人数和点播视频排行等海量数据的统计信息，由于奥运期间产生的数据通常不需要被经常索引、更新，因此要求采用不可变方式存储所有的历史数据，以保证历史数据的准确性。

Lambda架构的批处理层采用不可变存储模型，不断地往主数据集后追加新的数据，恰好可以满足对奥运数据的大规模统计分析要求。具体架构如下图：

图19-13 某网奥运中的Lambda架构

2. Lambda架构在某网广告平台的应用与演进

某网广告平台展示的数据指标包含两类：曝光类(包括曝光数、点击数、点击单价、花费)，转化类(包括转化下单数、转化下单金额、转化付款数、转化付款金额)。前一类的数据主要由流量方以接口的方式提供(比如对接的腾讯广点通平台)，后一类则是某网特有的数据，通过买家的浏览、下单、付款日志算出来。

1)第一版架构

第一版采用了典型的 Lambda 架构形式，架构图如图所示。

图19-14 某网广告平台中的Lambda架构

批处理层每天凌晨将Kafka中的浏览、下单消息同步到HDFS中，再将HDFS中的日志数据解析成Hive表，用Hive SQL/Spark SQL计算出分区的统计结果Hive表，最终将Hive表导出到MySQL中供服务层读取。另一方面，曝光、点击、花费等外部数据指标则是通过定时任务，调用第三方的API，每天定时写入另一张MySQL表中。

实时处理层则是用Spark Streaming程序监听Kafka中的下单、付款消息，计算出每个追踪链接维度的转化数据，存储在Redis中。

服务层则是一个 Java 服务，向外提供 http 接口。Java 服务读取两张 MySQL 表和一个 Redis 库的数据。

第一版的数据处理层比较简单，性能的瓶颈在Java服务层。服务层需要关联两张MySQL表，查询过程很复杂。

另一方面，实时数据只对接了内部的Kafka消息，没有实时的获取第三方的曝光、点击、浏览数据。

2)第二版架构

针对第一版的两个问题，在第二版对数据流的结构做了一些修改。在实时处理层做了一个常驻后台的Python脚本，不断调用第三方API的小时报表，更新当日的曝光数据表。

完成第二版改动之后，Java服务的计算压力明显下降。性能的瓶颈变成了查询Redis数据这一块。由于Redis里面的实时数据是业务无关的，仅统计了追踪链接维度的聚合数据。每次查询当日的转化数据，需要现在MySQL中查询出广告和跟踪链接的关系，找出所有的跟踪链接，再查询出这些跟踪链接的统计数据做聚合。

另一方面，离线计算的过程中涉及多次MySQL和Hive之间的导表操作，离线任务依赖链比较长，一旦出错，恢复离线任务的时间会比较久。

3)第三版架构

考虑到MySQL方便聚合、方便服务层读取的优点，在第三版中对Lambda架构做了一些改动，在数据层面只维护一张包含所有指标的MySQL表。MySQL表的sthday(统计日期)字段作为索引，sthday=当天的保存实时数据，st_day<当天的保存离线数据。

第三版只维护一张MySQL数据统计表，每天的离线任务会生成两张hive表，分别包含转化数据和曝光数据。这两张Hive表分别更新MySQL表的st_day。

在实时数据这块，常驻后台的Python脚本更新sthday=当天的数据的曝光类字段。Spark streaming程序在处理kafka中的实时下单消息时，不再统计数据到Redis，而是请求业务Java服务暴露出来的更新数据接口。在更新数据的接口中，找到当前下单的追踪链接所属的广告，更新MySQL中sthday=当天的数据的转化类字段。这样就把查询阶段的关联操作分散在了每条订单下单的处理过程中，解决了实时数据查询的瓶颈。最终的Java服务层也只需要读取一个MySQL表，非常简洁。

3. 某证券公司大数据系统

实时日志分析平台基于Kappa架构，使用统一的数据处理引擎Flink可实时处理全部数据，并将其存储到Elastic-Search与OpenTSDB中。实时处理过程如下：

图19-15 某证券大数据系统架构

(1)日志采集，即在各应用系统部署采集组件Filebeat，实时采集日志数据并输出到Kafka缓存。
(2)日志清洗与解析，即基于大数据计算集群的Flink计算框架，实时读取Kafka中的日志数据进行清洗和解析，提取日志关键内容并转换成指标，以及对指标进行二次加工形成衍生指标。
(3)日志存储，即将解析后的日志数据分类存储于Elastic-Search日志库中，各类基于日志的指标存储于OpenTSDB指标库中，供前端组件搜索与查询。
(4)日志监控，即通过单独的告警消息队列来保持监控消息的有序管理与实时推送。
(5)日志应用，即在充分考虑日志搜索专业需求的基础上，平台支持搜索栏常用语句保存，选择

日志变量自动形成搜索表达式，以及快速按时间排序过滤、查看日志上下文等功能。同时，基于可视化分析和全息场景监控可实时展现各种指标和趋势，并在预警中心查看各类告警的优先级和详细信息，进而结合告警信息关联查询系统日志内容来分析解决问题。此外，开发配置中心还提供了自定义日志解析开发功能，并支持告警规则、告警渠道配置。

4. 某电商智能决策大数据系统

实时智能决策大数据平台基于Kappa架构，使用统一的数据处理引擎Flink可实时处理流数据，并将其存储到Hive与Tair中，以供后续决策服务的使用。实时处理的过程如下：

图19-16 某电商智能决策大数据系统架构

一是数据采集，即B端系统会实时收集用户的点击，下单以及广告的曝光和出价数据并输出到Kafka缓存。

二是数据的清洗与聚合，即基于大数据计算集群Flink计算框架，实时读取Kafka中的实时流数据，过滤出需要参与计算的字段，根据业务需求，聚合指定时间端的数据并转换成指标。

三是数据存储，即将 Flink 计算得到数据存储到 Hive 日志库中，需要参与模型计算计算的字段存储到 Tair 分布式缓存中。当需要进行模型计算时，决策服务会从 Tair 中读取数据，进行模型的计算，得到新的决策参数和模型。决策服务基于微服务架构，客户端部署在业务方系统中，服务端主要用于计算决策参数和模型，当服务端计算得到新的参数，此时会通过 Zookeeper 通知部署到业务方系统的客户端，客户端此时会拉取新的参数并存储到本地，并且客户端提供了获取参数的接口，业务方可以无感知调用。

系统架构设计师学习QQ群：231352210 软件设计师学习QQ群：1169209218

诸葛老师QQ: 362842353

VIP 购买方式，淘宝搜索：软考诸葛老师

第4章 案例分析真题

4.1 2024上半年

（考生回忆版）

案例一：软件架构设计-系统架构评估（25分）

1.简述微服务架构对比单体架构和微服务架构微服务架构的优缺点。(7分)

答：微服务架构是一种分布式系统架构，将一个应用程序拆分为一组小型、独立的服务，每个服务都围绕特定的业务功能构建，并通过轻量级通信机制进行通信。相比之下，单体架构将整个应用程序作为一个单一的单元构建和部署。

微服务架构的优点：

• 灵活性和可扩展性：每个微服务都是独立的，可以独立部署和扩展，使系统更具弹性。
• 技术多样性：每个微服务可以使用不同的技术栈，使开发团队可以选择最适合其需求的技术。
• 易于理解和维护：微服务的小型化和聚焦性使得代码更易于理解、开发和维护。

微服务架构的缺点：

• 复杂性：微服务架构涉及到分布式系统，需要处理分布式事务、服务发现、服务治理等复杂问题。
• 部署和测试：由于微服务的数量增加，部署和测试变得更加复杂。
• 运维成本：微服务架构需要更多的运维工作，包括监控、日志收集、故障排查等。

2. 质量属性及其场景(质量效用树)，填空 6 个。(6 分)

答：考查质量效用树，如安全性，可用性，功能性，可修改性等。

3.用质量属性6要素描述e)和h)两条可用性的场景描述。(12分)

答：质量属性6要素描述：

• e)可连续运行时间不少于 $240 \mathrm{~h}$ , 断电或故障后 10s 内应重启
• 刺激源：断电或故障
• 刺激：系统故障或断电
  $\bullet$ 制品：系统
• 环境：运行环境
  $\bullet$ 响应：重启

$\bullet$ 响应度量：10秒内
$\bullet$ h)网络失效后，10s内应发起重新连接

• 刺激源：网络失效
• 刺激：网络失效
• 制品：系统
• 环境：网络环境
  $\bullet$ 响应：重新连接
  $\bullet$ 响应度量：10秒内

案例二：软件系统设计-UML建模（25分）

1.序列图的哪三种消息和概念。

答：序列图的三种消息和概念： $\bullet$ 同步消息 $\bullet$ 异步消息 $\bullet$ 返回消息

2.序列图补全填空。

（需要根据题目作答）

3.系统分析设计过程中两种交互图的选取原则

答：在UML中，交互图(Interaction Diagrams)主要用于描述在特定语境中对象之间的交互，它们可以在分析和设计阶段使用。交互图主要包括两种类型：序列图(Sequence Diagrams)和协作图(Collaboration Diagrams)。

• 序列图：强调消息的时间顺序，展示对象之间的动态合作关系，常用于分析阶段。
• 协作图：强调参与交互的对象以及它们如何相互关联，常用于设计阶段。

在分析阶段，你可能想要创建序列图来捕捉对象之间的动态合作，并且能够清晰地展示时序和并发。

在设计阶段，你可能想要创建协作图来定义交互模式，并且能够清晰地展示对象之间的静态关系和它们之间的关联。

4. 顺序图表示条件分支序列片段有哪些。

答：顺序图表示条件分支序列片段包括：

• Alt(Alternative)
• Opt(Option)
• Loop(循环)
• Break(中断)
• Par(并行)

区别总结：

• Alt: 用于条件分支, 有多个互斥的条件。
• Opt：用于可选行为，只有一个条件。
• Loop：用于循环操作，根据条件重复执行。
• Break：用于中断行为，根据条件跳出当前片段。
• Par：用于并行操作，多个消息序列同时执行。
• Critical：用于临界区，确保操作的原子性。
• Neg：用于不应发生的行为，表示错误情况。
• Ref: 用于引用其他序列图，实现模块化和重用。

案例三：数据库系统设计-分布式锁（25分）

1.基于MySQL实现分布式锁的缺点。(9分)

（答对5项即可）

答：

1）性能瓶颈：MySQL数据库本身可能成为性能瓶颈，特别是在高并发情况下，大量的锁请求和释放可能导致数据库性能下降。
2）单点故障：MySQL 单点的特性使得其成为系统的单点故障，如果数据库出现故障，将导致整个系统的分布式锁失效。
3) 锁粒度问题：MySQL 的锁粒度可能过大或者过小，过大的锁粒度会导致并发性能降低，而过小的锁粒度可能会增加锁冲突的概率，影响系统的并发性能。
4) 数据一致性问题：分布式系统中，不同的数据库节点之间的数据同步可能存在延迟或者不一

致的情况，这可能导致分布式锁的有效性受到影响。

5)扩展性差：随着系统规模的扩大，单个MySQL数据库可能无法满足系统的性能和容量需求，需要进行垂直或者水平扩展，这会增加系统的复杂性和成本。
6)容错性差：MySQL数据库本身的容错性可能不如专门设计的分布式锁方案，例如基于ZooKeeper或者Redis的分布式锁方案，因此在面对网络分区或者其他故障时可能无法提供可靠的锁服务。

2. 举一个产生Redis分布式锁死锁的场景。(10分)

（描述清楚即可）

答：

一个可能导致Redis分布式锁死锁的场景是：

假设有两个客户端同时请求获取同一把分布式锁，并且两个客户端的请求几乎同时到达Redis服务器。此时，两个客户端都成功地获取了锁，并开始执行各自的任务。然而，由于某些原因(例如网络延迟、服务器负载等)，其中一个客户端在执行任务时花费的时间较长，导致其持有锁的时间超过了预期。在此期间，另一个客户端一直在等待获取锁，因为它无法在锁被释放之前执行任务。

当第一个客户端最终完成任务并释放锁时，第二个客户端会立即获取到锁并开始执行任务。但此时第一个客户端可能又尝试获取锁以执行另一个任务，由于第二个客户端已经获取到了锁，因此第一个客户端将被阻塞等待获取锁，导致死锁的发生。

这种情况下，由于两个客户端的请求在一段时间内交替执行，每个客户端都等待另一个客户端释放锁，最终导致了死锁的产生。为避免这种情况，需要在设计分布式锁的使用场景时考虑合理的超时机制和重试策略，以及确保释放锁的操作能够及时执行。

3.填写Redis命令，基于ZSet。(6分)

答：

• 存入秒杀的分数命令：ZADD
• 获取分数范围的命令：ZRANGE
• 获取分数：ZSCORE

解析：Redis zset 扩展学习

在Redis中，ZSet(有序集合)是一种数据结构，用于存储带有分数(score)的成员(member)。

以下是针对ZSet的常用操作命令：

(1)ZADD key score member [score member …]

将一个或多个成员元素及其分数值加入到有序集合中。

(2) ZCARDkey

返回有序集合中的成员数量。

(3)ZSCORE key member

返回有序集合中指定成员的分数。

(4)ZRANGE key start stop [WITHSCORES]

返回有序集合中指定索引范围内的成员，可选择返回成员的分数。

(5)ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]

返回有序集合中分数范围内的成员，可选择返回成员的分数，并可指定返回结果的偏移量和数量。

(6) ZREM key member [member …]

移除有序集合中的一个或多个成员。

(7) ZINCRBY key increment member

将有序集合中指定成员的分数增加增量 increment。

(8) ZCOUNT key min max

计算有序集合中分数范围内的成员数量。

(9)ZREVRANGE key start stop [WITHSCORES]

返回有序集合中指定逆序索引范围内的成员，可选择返回成员的分数。

(10)ZREVRANGEBYSCORE key max min [WITHSCORES] [LIMIT offset count]

返回有序集合中指定逆序分数范围内的成员，可选择返回成员的分数，并可指定返回结果的偏移量和数量。

案例四：嵌入式系统设计-嵌入式系统（25分）

1.简要分析 SOME/IP 协议及其特点。(9 分)

答：SOME/IP是一种应用层协议，它允许在车辆内部网络中实现高效的服务交换和远程调用。这种协议支持车辆各组件之间的复杂通信需求，特别适用于具有高数据吞吐量的场景。基于TCP/IP，支持TCP和UDP。

特点：

服务导向架构(Service-Oriented Architecture，SOA)SOME/IP实现了一种服务导向架构，允许车辆的各个电子控制单元(ECUs)以服务提供者或服务消费者的身份互动。这种架构使得车辆内部的软件组件可以更加灵活地通信和交互。

远程过程调用(Remote Procedure Call，RPC)

通过RPC，SOME/IP支持跨网络的函数或过程调用，实现不同ECU之间的紧密协作。

高度可伸缩性和灵活性(Scalability and Flexibility)

SOME/IP协议的设计考虑到了未来车辆网络可能的扩展，支持从小型车辆到大型车队的不同规模应用。

SOME/IP与传统车载网络协议(如CAN，LIN等)的对比如下表所示：

2.填写DDS协议和SOME/IP协议到以下框图。(6分)

答：一般DDS用于框架模块内部之间通信，SOME/IP用于外部设备间通信。

3.规控AP模块的流程框图。(10分)

答：地图先定位，结合感知模块进行感知，对当前实时环境中的其他目标进行预测，然后规划路径，路径会考虑道路中其他参与者，有路径后交给控制决策车怎么走，然后控制信息传递给交互界面。

案例五：Web系统设计-系统设计（25分）

1.系统架构图填空。(11分)

解析：这道题来自华中科技大学的硕士论文。标准答案可能按照论文里的来。瓦片地图一般有两种。一般我们理解的瓦片地图是栅格瓦片。这块的瓦片数据没有说明是栅格瓦片还是矢量瓦片。如果是栅格瓦片HDFS应该优先使用。矢量瓦片可能是以JSON结构组装，用Hbase。瓦片数据和相关的存储方案在选择时确实需要根据数据类型(栅格瓦片或矢量瓦片)来决定。

1.栅格瓦片(RasterTiles):

• 描述：栅格瓦片是由像素组成的图像数据，通常用于地图、卫星图像等。

适用场景：适合存储在HDFS(Hadoop Distributed File System)中，因为HDFS擅长处理大文件和顺序读取。栅格瓦片通常是大文件，HDFS的设计优化了这种类型的数据存储和处理。

• 存储建议：使用HDFS存储栅格瓦片数据，因为HDFS提供了高吞吐量的读写性能，并且能够很好地扩展来处理大量的数据。

2. 矢量瓦片 (Vector Tiles):

• 描述：矢量瓦片是基于矢量数据的瓦片格式，通常以JSON、MVT(Mapbox Vector Tiles)等格式存储，包含点、线、多边形等地理信息。
• 适用场景：适合使用 HBase 存储，因为 HBase 是一个分布式、面向列的数据库，擅长处理大量的小文件和随机读写操作。矢量瓦片的数据结构(如 JSON)可以很好地映射到 HBase 的列族和列中。
• 存储建议：使用 HBase 存储矢量瓦片数据，因为 HBase 提供了低延迟的随机读写性能，并且可以高效地存储和查询结构化和半结构化数据。

总结：

• 格瓦片：优先使用HDFS存储，以利用其高吞吐量和大文件处理能力。
• 矢量瓦片：优先使用 HBase 存储，以利用其高效的小文件处理和低延迟随机读写能力。

2.MongoDB 如何存储非结构性数据的，MongoDB 矢量化存储的优点。(10 分)

MongoDB 是一个基于分布式文件存储的 NoSQL 数据库，它使用一种灵活的、面向文档的数据模型来存储非结构化数据。以下是 MongoDB 存储非结构化数据的方式及其矢量化存储(虽然 MongoDB 官方并没有直接使用“矢量化存储”这一术语，但我们可以理解为处理和存储复杂数据结构的能力)的一些优点：

MongoDB 存储非结构化数据的方式:

1. 文档存储：MongoDB 以 BSON(Binary JSON)格式存储数据，这是一种类 JSON 的二进制格式，支持更丰富的数据类型(比如 Date、ObjectId 等)，比传统的 JSON 更高效。每个文档可以包含任意数量的字段，字段值可以是数组、嵌套文档等多种复杂数据结构，非常适合存储半结构化和非结构化数据。
   2.灵活的数据模型：MongoDB不强制要求数据遵循固定的模式，同一个集合(相当于关系数据库中的表)中的文档可以有不同的字段和结构。这使得MongoDB能轻松适应不断变化的数据需求，特别适合存储那些模式不固定或经常演变的数据。
   3.动态模式：MongoDB的集合不需要预先定义结构，字段可以随时添加或删除，这为非结构化数据的存储提供了极大的灵活性。
   4.索引支持：尽管数据是非结构化的，MongoDB仍然支持对文档中的任何字段创建索引，包括嵌套字段，这大大提升了查询性能。

MongoDB 矢量化存储(处理复杂数据结构)的优点:

1.高效存储与查询：BSON(Binary JSON)格式不仅支持复杂数据类型，还能高效地存储和查询这些数据。通过利用索引，即使是嵌套文档和数组也能实现快速查询。
2. 简化数据模型：通过文档嵌套和数组，可以将相关数据聚合在一个文档中，减少了数据的连接操作，简化了数据模型，提高了查询效率。
3.易于扩展与演变：由于数据模型的灵活性，MongoDB能够轻松应对数据结构的变化，无需进行复杂的模式迁移，简化了系统升级和扩展的过程。
4.高性能：MongoDB使用内存映射文件技术，能够将热数据加载到内存中，提高读写性能。同时，支持水平扩展和分片，能够处理大量数据和高并发请求。
5.数据处理能力：对于非结构化数据的分析和处理，MongoDB提供了丰富的聚合框架，支持复杂的数据转换和分析操作，如聚合管道、地图Reduce等，便于从非结构化数据中提取有价值的信息。

3.使用热数据、温数据和冷数据存储的原因。(4分)

答：使用热数据、温数据和冷数据存储的原因及好处主要包括以下几点答出原因或者优点，任

意4点即可。

原因：

1.资源优化：不同数据的访问频率差异巨大，将数据按照热度分类可以更合理地分配存储资源。热数据通常需要快速访问，因此存储在高性能、高成本的媒介上；而冷数据访问较少，可以存储在低成本、低速的媒介上。
2.成本效率：通过区分数据的访问频率，企业可以将有限的预算投入到最关键的数据存储上，如使用SSD或RAM存储热数据，而冷数据则存储在磁带或蓝光光盘上，这样既能保证关键业务的性能，又能控制存储成本。
3.性能提升：将频繁访问的热数据放置在快速存储设备上，如SSD或内存，可以显著减少数据访问延迟，提高应用响应速度。而冷数据存储在低速设备上对整体系统性能影响较小。
4. 数据保护：对于冷数据，虽然访问频率低，但可能需要长期保存，使用耐久性高的存储介质可以确保数据的安全与持久。
5.扩展性和灵活性：随着数据量的增长，分层存储策略提供了更好的扩展性，可以根据数据增长和访问模式的变化灵活调整存储策略。

优点：

1. 提升效率：确保高访问频度的数据能够迅速被获取，提升用户体验和业务处理速度。
2. 降低成本：通过将不常访问的数据转移到成本较低的存储介质，减少整体存储成本。
   3.资源利用率最大化：高效利用存储资源，避免高性能存储资源被低访问频度数据占用。
   4.增强数据管理能力：便于数据生命周期管理，如数据归档、备份和恢复策略的实施。
   5.适应业务变化：灵活调整数据存储布局，快速响应业务需求变化，支持业务的持续创新与发展。

综上所述，依据数据热度进行分类存储是一种策略，旨在通过智能地分配存储资源，平衡成本与性能，确保关键业务数据的高效访问，同时合理管理数据生命周期，从而实现整体IT架构的优化。

4.2 2023下半年

(考生回忆版)

试题一(共25分)

阅读以下关于软件架构设计的叙述，回答问题1至问题3。

【说明】

某网作为某电视台在互联网上的大型门户入口，某一年成为某奥运会中国大陆地区的特权转播商，独家全程直播了某奥运会全部的赛事，积累了庞大稳定的用户群，这些用户在使用各类服务过程中产生了大量数据，对这些海量数据进行分析与挖掘，将会对节目的传播及商业模式变现起到重要的作用。

该奥运期间需要对增量数据在当日概览和赛事回顾两个层面上进行分析。

其中，当日概览模块需要秒级刷新直播在线人数、网站的综合浏览量、页面停留时间、视频的播放次数和平均播放时间等千万级数据量的实时信息，而传统的分布式架构采用重新计算的方式分析实时数据，在不扩充以往集群规模的情况下，无法在几秒内分析出重要的信息。

赛事回顾模块需要展现自定义时间段内的历史最高在线人数、逐日播放走势、直播最高在线人数和点播视频排行等海量数据的统计信息，由于该奥运期间产生的数据通常不需要被经常索引、更新，因此要求采用不可变方式存储所有的历史数据，以保证历史数据的准确性。

【问题1】（8分）

请根据 Lambda 架构和 Kappa 架构特点，填写以下表格。

【问题2】(9分)

下图1给出了某网奥运的大数据架构图，请根据下面的(a)～(n)的相关技术；判断这此技术属于架构图的哪个部分，补充完善下图1的(1)-(9)的空白处。

(a)Nginx；(b)Hbase；(c)Spark Streaming；(d)Spark；(e)MapReduce；(f)ETL；(g)MemSQL;

(h)HDFS；(i)Sqoop；(j)Flume；(k)数据存储层；(I)Kafka 数据采集层；(m)业务逻辑层；(n)

【问题3】(8分，每空2分)

大数据的架构包括了 Lambda 架构和 Kappa 架构，Lambda 架构分解为三层：即(门、(2)和(3)；Kappa 架构不同于 Lambda 同时计算流计算和批计算并合并视图，Kappa 只会通过流计算一条的数据链路计算并产生视图。

请问该系统的大数据架构是基于哪种架构搭建的大数据平台处理奥运会大规模视频网络观看数据。

试题二(共25分)

阅读以下关于软件系统设计与建模的叙述，在答题纸上回答问题1至问题3。

【说明】

背景不详，应该是某个信息系统说明，然后会有两种获取需求的方案，一种是使用UML里的用例图，另一种是使用SysML里的需求图。

根据学员回忆，预测，背景与问题无关，不影响作答。

【问题1】

请分别给出 SysML 建模的需求图与 UML 建模的用例图的定义，并说明二者的区别。

【问题2】

(非原题，缺图)请给出需求图的七种关系及其定义。某车企的混合动力SUV系统需求图如下图所示，请将选项中的内容填到图中(1)-(5)处。

A：质量需求B：功能需求

C：性能要求：环保

D：性能要求：表现

E：性能要求：排放

F：性能要求：燃油经济

【问题3】

用例图填空，很简单，历年考题较多

试题三（共25分）

数据库主从复制、读写分离架构；Redis 缓存数据库。

试题四（共25分）

Hibernet 架构、数据持久层、JWT。

JWT的优点：

无状态：JWT是无状态的，服务器不需要保存任何会话信息，可以轻松扩展和分布式环境下使用。

安全：JWT通过密钥对头部和载荷进行签名，保证了数据的完整性和安全性。

跨域支持：JWT可以跨域使用，可以在不同的域名和服务器之间使用。

简单易用：JWT使用简单，易于实现和维护。

JWT的缺点：

载荷信息不能太多：JWT的载荷信息不能太多，否则会导致JWT的长度过长，增加网络传输的负担。

安全性依赖于密钥：JWT的安全性依赖于密钥的保护，如果密钥泄露，则JWT的安全性将受到威胁。

无法撤销：一旦JWT生成后，无法撤销，除非修改密钥或者设置短期的过期时间。

图13-14Hibernate架构图

试题五（共25分）

数字孪生概念、技术选择、架构图填空。

4.3 2022下半年

试题一(共25分)

阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题1和问题2。

【说明】

某电子商务公司拟升级其会员与促销管理系统，向用户提供个性化服务，提高用户的粘性。在项目立项之初，公司领导层一致认为本次升级的主要目标是提升会员管理方式的灵活性，由于当前用户规模不大，业务也相对简单，系统性能方面不做过多考虑，新系统除了保持现有的四级固定会员制度外，还需要根据用户的消费金额、偏好、重复性等相关特征动态调整商品的折扣力度，并支持在特定的活动周期内主动筛选与活动主题高度相关的用户集合，提供个性化的打折促销活动。

在需求分析与架构设计阶段，公司提出的需求和质量属性描述如下：

(a)管理员能够在页面上灵活设置折扣力度规则和促销活动逻辑，设置后即可生效；
(b)系统应该具备完整的安全防护措施，支持对恶意攻击行为进行检测与报警；
(c)在正常负载情况下，系统应在0.3秒内对用户的界面操作请求进行响应；
(d)用户名是系统唯一标识，要求以字母开头，由数字和字母组合而成，长度不少于6个字符；
(e)在正常负载情况下，用户支付商品费用后在3秒内确认订单支付信息；

(f)系统主站点电力中断后，应在5秒内将请求重定向到备用站点；
(g)系统支持横向存储扩展，要求在2人天内完成所有的扩展与测试工作；
(h)系统宕机后，需要在10秒内感知错误，并自动启动热备份系统；
(i)系统需要内置接口函数，支持开发团队进行功能调试与系统诊断；
(j)系统需要为所有的用户操作行为进行详细记录，便于后期查阅与审计；
(k)支持对系统的外观进行调整和配置，调整工作需要在4人天内完成。

在对系统需求、质量属性描述和架构特性进行分析的基础上，系统架构师给出了两种候选的架构设计方案，公司目前正在组织相关专家对系统架构进行评估。

【问题1】(12分)

在架构评估过程中，质量属性效用树 (utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图1-1中(1)、(2)空白处，并选择题干描述的(a)(k)填入(3)(6)空白处，完成该系统的效用树。

图1-1 会员与促销管理系统效用树

【问题2】(13分)

针对该系统的功能，李工建议采用面向对象的架构风格，将折扣力度计算和用户筛选分别封装为独立对象，通过对象调用实现对应的功能：王工则建议采用解释器(interpreters)架构风格，将折扣力度计算和用户筛选条件封装为独立的规则，通过解释规则实现对应的功能。请针对系统的主要功能，从折扣规则的可能改性、个性化折扣定义灵活性和系统性能三个方面对这两种架构风格进行比较与分析，并指出该系统更适合采用哪种架构风格。

试题二(共25分)

阅读以下关于软件系统设计与建模的叙述，在答题纸上回答问题1至问题3。

【说明】

煤炭生产是国民经济发展的主要领域之一，其煤矿的安全非常重要。某能源企业拟开发一套煤矿建设项目安全预警系统，以保护煤矿建设项目从业人员生命安全。本系统的主要功能包括如下(a)~(h)所述。

(a)项目信息维护
(b)影响因素录入
(c)关联事故录入
(d)安全评价得分
(e)项目指标预警分析
(f)项目指标填报
(g)项目指标审核
(h)项目指标确认

【问题1】(9分)

王工根据煤矿建设项目安全预警系统的功能要求，设计完成了系统的数据流图，如图2-1所示。请使用题干中描述的功能(a)(h)，补充完善空(1)(6)处的内容，并简要介绍数据流图在分层细化过程中遵循的数据平衡原则。

图2-1 煤矿建设项目安全预警系统数据流图

【问题2】(9分)

请根据【问题1】中数据流图表示的相关信息，补充完善煤矿建设项目安全预警系统总体E-R

图(见图2-2)中实体(1)-(6)的具体内容，将正确答案填在答题纸上。

图2-2煤矿建设项目安全预警系统总体E-R图

【问题3】(7分)

在结构化分析和设计过程中，数据流图和数据字典是常用的技术手段，请用200字以内的文字简要说明它们在软件需求分析和设计阶段的作用。

试题三（共25分）

阅读以下关于嵌入式系统故障检测和诊断的相关描述，在答题纸上回答问题1至问题3。

【说明】

系统的故障检测和诊断是宇航系统提高装备可靠性的主要技术之一，随着装备信息化的发展，分布式架构下的资源配置越来越多、资源布局也越来越分散，这对系统的故障检测和诊断方法提出了新的要求，为了适应宇航装备的分布式综合化电子系统的发展，解决由于系统资源部署的分散性，造成系统状态的综合和监控困难的问题，公司领导安排张工进行研究。张工经过分析、调研提出了针对分布式综合化电子系统架构的故障检测和诊断的方案。

【问题1】（8分）

张工提出：宇航装备的软件架构可采用四层的层次化体系结构，即模块支持层、操作系统层、分布式中间件层和功能应用层。为了有效、方便地实现分布式系统的故障检测和诊断能力，方案建议将系统的故障检测和诊断能力构建在分布式中间件内，通过使用心跳或者超时探测技术来实现故障检测器。请用300字以内的文字分别说明心跳检测和超时探测技术的基本原理及特点。

【问题2】(8分)

张工针对分布式综合化电子系统的架构特征，给出了初步设计方案，指出每个节点的故障监测与诊断器主要负责监控系统中所有的故障信息，并将故障信息进行综合分析判断，使用故障诊断器分析出故障原因，给出解决方案和措施。系统可以给模块的每个处理机器核配置核状态监控器、给每个分区配置分区状态监控器、给每个模块配置模块状态监控器、给系统配置系统状态监控器，如图3-1所示。

图3-1系统故障检测和诊断原理

请根据下面给出的分布式综合化电子系统可使产生的故障(a)-(h)，判断这些故障分别属于哪类监控器检测的范围，完善表3-1的(1)一(8)的空白。

(a)应用程序除零
(b)看门狗故障
(c)任务超时
(d)网络诊断故障
(e)BIT检测故障
(f)分区堆栈溢出
(g)操作系统异常
(h)模块掉电

表 3-1 故障分类

【问题3】(9分)

张工在方案中指出，本系统的故障诊断采用故障诊断器实现，它可综合多种故障信息和系统状态，依据智能决策数据库提供的决策策略判定出故障类型和处理方法。智能决策数据库中的策略可以对故障开展定性或定量分析，通常，在定量分析中，普遍采用基于解析模型的方法和数据驱动的方法，张工在方案中提出该系统定量分析时应采用基于解析模型的方法。但是此提议受到王工的反对，王工指出采用数据驱动的方法更适合分布式综合化电子系统架构的设计。请用300字以内的文字，说明数据驱动方法的基本概念，以及王工提出采用此方法的理由。

试题四（共25分）

阅读以下关于数据库缓存的叙述，在答题纸上回答问题1至问题3。

【说明】

某大型电商平台建立了一个在线B2B商店系统，并在全国多地建设了货物仓储中心，通过提前备货的方式来提高货物的运送效率。但是在运营过程中，发现会出现很多跨仓储中心调货从而延误货物运送的情况。为此，该企业计划新建立一个全国仓储货物管理系统，在实现仓储中心常规管理功能之外，通过对在线B2B商店系统中订单信息进行及时的分析和挖掘，并通过大数据分析预测各地仓储中心中各类货物的配置数量，从而提高运送效率，降低成本。

当用户通过在线B2B商店系统选购货物时，全国仓储货物管理系统会通过该用户所在地址、商品类别以及仓储中心的货物信息和地址，实时为用户订单反馈货物起运地(某仓储中心)并预测送达时间。反馈送达时间的响应时间应小于1秒。

为满足反馈送达时间功能的性能要求，设计团队建议在全国仓储货物管理系统中采用数据缓存集群的方式，将仓储中心基本信息、商品类别以及库存数量放置在内存的缓存中，而仓储中心的其它商品信息则存储在数据库系统。

【问题1】(9分)

设计团队在讨论缓存和数据库的数据一致性问题时，李工建议采取数据实时同步更新方案，而张工则建议采用数据异步准实时更新方案。

请用200字以内的文字，简要介绍两种方案的基本思路，说明全国仓储货物管理系统应该来用哪种方案，并说明采取该方案的原因。

【问题2】(9分)

随着业务的发展，仓储中心以及商品的数量日益增加，需要对集群部署多个缓存节点，提高缓存的处理能力。李工建议采用缓存分片方法，把缓存的数据拆分到多个节点分别存储，减轻单个缓存节点的访问压力，达到分流效果。

缓存分片方法常用的有哈希算法和一致性哈希算法，李工建议采用一致性哈希算法来进行分片。请用200字以内的文字简要说明两种算法的基本原理，并说明李工采用一致性哈希算法的原因。

【问题3】(7分)

全国仓储货物管理系统开发完成，在运营一段时间后，系统维护人员发现大量黑客故意发起非法的商品送达时间查询请求，造成了缓存击穿，张工建议尽快采用布隆过滤器方法解决。请用200字以内的文字解释布隆过滤器的工作原理和优缺点。

试题五（共25分）

阅读以下关于Web系统架构设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某公司拟开发一套基于边缘计算的智能门禁系统，用于如园区、新零售、工业现场等存在来访、被访业务的场景。来访者在来访前，可以通过线上提前预约的方式将自己的个人信息记录在后台，被访者在系统中通过此请求后，来访者在到访时可以直接通过“刷脸”的方式通过门禁，无需做其他验证。此外，系统的管理员可对正在运行的门禁设备进行管理。

基于项目需求，该公司组建项目组，召开了项目讨论会。会上，张工根据业务需求并结合边缘计算的思想，提出本系统可由访客注册模块、模型训练模块、端侧识别模块与设备调度平台模块等四项功能组成，李工从技术层面提出该系统可使用Flask框架与SSM框架为基础来开发后台服务器，将开发好的系统通过Docker进行部署，并使用MQTT协议对Docker进行管理。

【问题1】(5分)

MQTT协议在工业物联网中得到广泛的应用，请用300字以内的文字简要说明MQTT协议。

【问题2】(14分)

在会议上，张工对功能模块进行了更进一步的说明：访客注册模块用于来访者提交申请与被访者确认申请，主要处理提交来访申请、来访申请审核业务，同时保存访客数据，为训练模块准备训练数据集；模型训练模块用于使用访客数据进行模型训练，为端侧设备的识别业务提供模型基础；端侧识别模块在边缘门禁设备上运行，使用训练好的模型来识别来访人员，与云端服务协作完成访客来访的完整业务；设备调度平台模块用于对边缘门禁设备进行管理，管理人员能够使用平台对边缘设备进行调度管理与状态监控，实现云端协同。

图5-1给出了基于边缘计算的智能门禁系统架构图，请结合HTTP协议和MQTT协议的特点，为图5-1中(1)(6)处选择合适的协议：并结合张工关于功能模块的描述，补充完善图5-1中(7)(10)处的空白。

图5-1基于边缘计算的智能门禁系统

【问题3】(6分)

请用300字以内的文字，从数据通信、数据安全和系统性能等方面简要分析在传统云计算模型中引入边缘计算模型的优势。

4.4 2021下半年

试题一（25分）

阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题1和问题2。

【说明】

某公司拟开发一套机器学习应用开发平台，支持用户使用浏览器在线进行基于机器学习的智能应用开发活动。该平台的核心应用场景是用户通过拖拽算法组件灵活定义机器学习流程，采用自助方式进行智能应用设计、实现与部署，并可以开发新算法组件加入平台中。在需求分析与架构设计阶段，公司提出的需求和质量属性描述如下：

（a）平台用户分为算法工程师、软件工程师和管理员等三种角色，不同角色的功能界面有所不同；
（b）平台应该具备数据库保护措施，能够预防核心数据库被非授权用户访问；

（c）平台支持分布式部署，当主站点断电后，应在20秒内将请求重定向到备用站点；
（d）平台支持初学者和高级用户两种界面操作模式，用户可以根据自己的情况灵活选择合适的模式；
（e）平台主站点宕机后，需要在15秒内发现错误并启用备用系统；
（f）在正常负载情况下，机器学习流程从提交到开始执行，时间间隔不大于5秒；
（g）平台支持硬件扩容与升级，能够在3人天内完成所有部署与测试工作；
（h）平台需要对用户的所有操作过程进行详细记录，便于审计工作；
（i）平台部署后，针对界面风格的修改需要在3人天内完成；
（j）在正常负载情况下，平台应在0.5秒内对用户的界面操作请求进行响应；
（k）平台应该与目前国内外主流的机器学习应用开发平台的界面风格保持一致；
（1）平台提供机器学习算法的远程调试功能，支持算法工程师进行远程调试。

在对平台需求、质量属性描述和架构特性进行分析的基础上，公司的架构师给出了三种候选的架构设计方案，公司目前正在组织相关专家对平台架构进行评估。

【问题1】（9分）

在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图1-1中(1)、(2)空白处，并从题干中的(a)-(l)中选择合适的质量属性描述，填入(3)-(6)空白处，完成该平台的效用树。

图1-1

【问题2】（16分）

针对该系统的功能，赵工建议采用解释器(interpreter)架构风格，李工建议采用管道-过滤器(pipe-and-filter)的架构风格，王工则建议采用隐式调用(implicit invocation)架构风格。请针对平台的核

心应用场景，从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析，并指出该平台更适合采用哪种架构风格。

试题二（25分）

阅读以下关于软件系统设计与建模的叙述，在答题纸上回答问题1至问题3。

【说明】

某医院拟委托软件公司开发一套预约挂号管理系统，以便为患者提供更好的就医体验，为医院提供更加科学的预约管理。本系统的主要功能描述如下：(a)注册登录，(b)信息浏览，(c)账号管理，(d)预约挂号，(e)查询与取消预约，(f)号源管理，(g)报告查询，(h)预约管理，(i)报表管理，(j)信用管理等。

【问题1】（6分）

若采用面向对象方法对预约挂号管理系统进行分析，得到如图2-1所示的用例图。请将合适的参与者名称填入图2-1中的(1)和(2)处，使用题干给出的功能描述(a)(j)，完善用例(3)(12)的名称，将正确答案填在答题纸上。

图2-1

【问题2】（10分）

预约人员(患者)登录系统后发起预约挂号请求，进入预约界面。进行预约挂号时使用数据库访问类获取医生的相关信息，在数据库中调用医生列表，并调取医生出诊时段表，将医生出诊时段反馈到预约界面，并显示给预约人员；预约人员选择医生及就诊时间后确认预约，系统反馈预约结果，并向用户显示是否预约成功。

采用面向对象方法对预约挂号过程进行分析，得到如图2-2所示的顺序图，使用题干中给出的

描述，完善图2-2中对象(1)，及消息(2)~(4)的名称，将正确答案填在答题纸上，请简要说明在描述对象之间的动态交互关系时，协作图与顺序图存在哪些区别。

图2-2

【问题3】（9分）

采用面向对象方法开发软件，通常需要建立对象模型、动态模型和功能模型，请分别介绍这3种模型，并详细说明它们之间的关联关系，针对上述模型，说明哪些模型可用于软件的需求分析？

试题三 (25分)

阅读以下关于嵌入式数据架构设计的相关描述，在答题纸上回答问题1至问题3。

【说明】

数据架构(Data architecture)是系统架构设计的主要工作之一。它主要用于描述业务数据以及数据间的关系。数据架构着重考虑“数据需求”，关注的是持久化数据的组织，数据架构的设计过程主要包括：数据定义、数据分布与数据管理。某公司为了适应宇航装备的持续发展，提升本公司的核心竞争力，改变原来事件驱动的架构设计模式。公司领导将新产品架构规划工作交给张工。张工经过分析、调研给出了本企业宇航产品的未来架构规划方案。

【问题1】(9分)

张工在规划方案中指出：宇航装备要实现以数据为中心的架构设计模式，就应改变传统的各个子系统独立设计方式，打破原宇航装备的生产关系。为了达到这个目标，我们首先要解决装备数据的共享、管理和存储等问题，做好顶层的数据架构规划工作。请用300字以内的文字说明数据定义、

数据分布与数据管理的具体内涵。

【问题2】(7分)

张工在规划方案中提出公司未来产品设计要遵从一种开放式的架构体系，并在此基础上完善数据架构的设计工作，形成一套规格化的数据模型语言。张工给出了基于FACE(Future Airborne Capability Environment)架构的新产品架构，其中，图3-1说明了数据模型语言在架构模型中作用。注意：题目不全。

试题四（25分）

阅读以下关于数据库设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某医药销售企业因业务发展，需要建立线上药品销售系统，为用户提供便捷的互联网药品销售服务、该系统除了常规药品展示、订单、用户交流与反馈功能外，还需要提供当前热销产品排名、评价分类管理等功能。

通过对需求的分析，在数据管理上初步决定采用关系数据库（MySQL）和数据库缓存（Redis）的混合架构实现。

经过规范化设计之后，该系统的部分数据库表结构如下所示。

供应商（供应商ID，供应商名称，联系方式，供应商地址）；

药品（药品ID，药品名称，药品型号，药品价格，供应商ID）；

药品库存（药品ID，当前库存数量）；

订单（订单号码，药品ID，供应商ID，药品数量，订单金额）。

【问题1】（9分）

在系统初步运行后，发现系统数据访问性能较差。经过分析，刘工认为原来数据库规范化设计后，关系表过于细分，造成了大量的多表关联查询，影响了性能。例如当用户查询商品信息时，需要同时显示该药品的信息、供应商的信息、当前库存等信息。

为此，刘工认为可以采用反规范化设计来改造药品关系的结构，以提高查询性能。修改后的药品关系结构为：

药品（药品ID，药品名称，药品型号，药品价格，供应商ID，供应商名称，当前库存数量）；

请用200字以内的文字说明常见的反规范化设计方法，并说明用户查询商品信息应该采用哪种反规范化设计方法。

【问题2】（9分）

王工认为，反规范化设计可提高查询的性能，但必然会带来数据的不一致性问题。请用200字以内的文字说明在反规范化设计中，解决数据不一致性问题的三种常见方法，并说明该系统应该采用哪种方法。

【问题3】（7分）

该系统采用了Redis来实现某些特定功能（如当前热销药品排名等），同时将药品关系数据放到内存以提高商品查询的性能，但必然会造成Redis和MySQL的数据实时同步问题。

（1）Redis 的数据类型包括 String、Hash、List、Set 和 ZSet 等，请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。
（2）请用200字以内的文字解释说明解决Redis和MySQL数据实时同步问题的常见方案。

试题五（25分）

阅读以下关于Web系统架构设计的教述，在答题纸上回答问题1至问题3。

【说明】

某公司拟开发一个智能家居管理系统，该系统的主要功能需求如下：1）用户可使用该系统客户端实现对家居设备的控制，且家居设备可向客户端反馈实时状态；2）支持家居设备数据的实时存储和查询；3）基于用户数据，挖掘用户生活习惯，向用户提供家居设备智能化使用建议。

基于上述需求，该公司组建了项目组，在项目会议上，张工给出了基于家庭网关的传统智能家居管理系统的设计思路，李工给出了基于云平台的智能家居系统的设计思路。经过深入讨论，公司决定采用李工的设计思路。

【问题1】（8分）

请用400字以内的文字简要描述基于家庭网关的传统智能家居管理系统和基于云平台的智能家居管理系统在网关管理、数据处理和系统性能等方面的特点，以说明项目组选择李工设计思路的原因。

【问题2】（12分）

请从下面给出的（a）～（j）中进行选择，补充完善图5-1中空（1）～（6）处的内容，协助李工完成该系统的架构设计方案。

图5-1

(a) Wi-Fi
（b）蓝牙
(c) 驱动程序
(d) 数据库
(e) 家庭网关
(f) 云平台
（g） 微服务
（h）用户终端

(i) 鸿蒙
(j) TCP/IP

【问题3】（5分）

该系统需实现用户终端与服务端的双向可靠通信，请用300字以内的文字从数据传输可靠性的角度对比分析TCP和UDP通信协议的不同，并说明该系统应采用哪种通信协议。

4.5 2020下半年

试题一（共25分）

阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题1和问题2。

【说明】

某公司拟开发一套在线软件开发系统，支持用户通过浏览器在线进行软件开发活动。该系统的主要功能包括代码编辑、语法高亮显示、代码编译、系统调试、代码仓库管理等。在需求分析与架构设计阶段，公司提出的需求和质量属性描述如下：

（a）根据用户的付费情况对用户进行分类，并根据类别提供相应的开发功能；
（b）在正常负载情况下，系统应在0.2秒内对用户的界面操作请求进行响应；
（c）系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御；
（d）系统主站点断电后，应在3秒内将请求重定向到备用站点；
（e）系统支持中文昵称，但用户名必须以字母开头，长度不少于8个字符；
（f）系统岩机后，需要在15秒内发现错误并启用备用系统；
（g）在正常负载情况下，用户的代码提交请求应该在0.5秒内完成；
（h）系统支持硬件设备灵活扩容，应保证在2人·天内完成所有的部署与测试工作；
（i）系统需要为针对代码仓库的所有操作情况进行详细记录，便于后期查阅与审计；
（j）更改系统的web界面风格需要在4人·天内完成；
（k）系统本身需要提供远程调试接口，支持开发团队进行远程排错。

在对系统需求、质量属性和架构特性进行分析的基础上，该公司的系统架构师给出了两种候选的架构设计方案，公司目前正在组织相关专家对候选系统架构进行评估。

【问题1】（13分）

针对该系统的功能，李工建议采用管道-过滤器（pipe and filter）的架构风格，而王工则建议采用仓库（repository）架构风格。请指出该系统更适合采用哪种架构风格，并针对系统的主要功能，从数据处理方式、系统的可扩展性和处理性能三个方面对这两种架构风格进行比较与分析，填写表1-1中的（1）～（4）空白处。

表 1-1 两种架构风格的比较与分析

续表

【问题2】（12分）

在架构评估过程中，质量属性效用树（utility tree）是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质呈属性名称填入图1-1中（1）、（2）空白处，并选择题干描述的（a）～（k）填入（3）～（6）空白处，完成该系统的效用树。

图1-1 在线软件开发系统效用树

从下列的4道试题（试题二至试题五）中任选2道解答。

试题二（共25分）

阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。

【说明】

某企业委托软件公司开发一套包裹信息管理系统，以便于对该企业通过快递收发的包裹信息进行统一管理。在系统设计阶段，需要对不同快递公司的包裹单信息进行建模，其中，邮政包裹单如图2-1所示。

图2-1 包裹单示意图

【问题1】（14分）

请说明关系型数据库开发中，逻辑数据模型设计过程包含哪些任务？该包裹单的逻辑数据模型中应该包含哪些实体？并给出每个实体的主键属性。

【问题2】（6分）

请说明什么是超类实体？结合图中包裹单信息，试设计一种超类实体，给出完整的属性列表。

【问题3】（5分）

请说明什么是派生属性，并结合图2-1的包裹单信息说明哪个属性是派生属性。

试题三（共25分）

阅读以下关于开放式嵌入式软件架构设计的相关描述，回答问题1至问题3。

【说明】

某公司一直从事宇航系统研制任务，随着宇航产品综合化、网络化技术发展的需要，公司的业务量急剧增加，研制新的软件架构已迫在眉睫。公司架构师王工广泛调研了多种现代架构的基础，建议采用基于FACE（Future Airborne Capability Environment）的宇航系统开放式软件架构，以实现宇航系统的跨平台复用，实现宇航软件高质量、低成本的开发。公司领导肯定了王工的提案，并指出公司要全面实施基于FACE的开放式软件架构，应注意每个具体项目在实施中如何有效实现从需求到架构设计的关系，掌握基于软件需求的软件架构设计方法，并做好开放式软件架构中各段间的接口标准化设计工作。

【问题1】（9分）

王工指出，软件开发中需求分析是根本，架构设计是核心，不考虑软件需求便进行软件架构设

计很可能导致架构设计的失败，因此，如何把软件需求映射到软件架构至关重要。请从描述语言、非功能性需求描述、需求和架构的一致性等三个方面，用300字以内的文字说明软件需求到架构的映射存在哪些难点。

【问题2】（10分）

图3-1是王工给出的FACE架构布局，包括操作系统、I/O服务、平台服务、传输服务和可移植组件等5个段；操作系统、I/O和传输等3个标准接口。请分析图3-1给出的FACE架构的相关信息，用300字以内的文字简要说明FACE5个段的含义。

图3-1 FACE架构

【问题3】（6分）

FACE架构的核心能力是可支持应用程序的跨平台执行和可移植性，要达到可移植能力，必须解决应用程序的紧糊合和封装的障碍。请用200字以内的文字简要说明在可移植性上，应用程序的紧耦合和封装问题的主要表现分别是什么，并给出解决方案。

试题四（共25分）

阅读以下关于数据库缓存的叙述，在答题纸上回答问题1至问题3。

【说明】

某互联网文化发展公司因业务发展，需要建立网上社区平台，为用户提供一个对网络文化产品（如互联网小说、电影、漫画等）进行评论、交流的平台。该平台的部分功能如下：

（a）用户帖子的评论计数器；
（b）支持粉丝列表功能；

（c）支持标签管理；
（d）支持共同好友功能等；
（e）提供排名功能，如当天最热前10名帖子排名、热搜榜前5排名等；
（f）用户信息的结构化存储；
（g）提供好友信息的发布/订阅功能。

该系统在性能上需要考虑高性能、高并发，以支持大量用户的同时访问。开发团队经过综合考虑，在数据管理上决定采用Redis+数据库（缓存+数据库）的解决方案。

【问题1】（10分）

Redis 支持丰富的数据类型，并能够提供一些常见功能需求的解决方案。请选择题干描述的 $(a) \sim$ (g) 功能选项，填入表 4-1 中（1）～（5）的空白处。

表 4-1 Redis 数据类型与业务功能对照表

【问题2】（7分）

该网上社区平台需要为用户提供 $7 \times 24$ 小时的不间断服务。同时在系统出现右机等故障时，能在最短时间内通过重启等方式重新建立服务。为此，开发团队选择了Redis持久化支持。Redis有两种持久化方式，分别是RDB（Redis Data Base）持久化方式和AOF（Append Only File）持久化方式。开发团队最终选择了RDB方式。

请用200字以内的文字，从磁盘更新频率、数据安全、数据一致性、重启性能和数据文件大小五个方面比较两种方式，并简要说明开发团队选择RDB的原因。

【问题3】（8分）

缓存中存储当前的热点数据，Redis为每个KEY值都设置了过期时间，以提高缓存命中率。为了清除非热点数据，Redis选择“定期删除 $+$ 惰性删除”策略。如果该策略失效，Redis内存使用率会越来越高，一般应采用内存淘汰机制来解决。

请用100字以内的文字简要描述该策略的失效场景，并给出三种内存淘汰机制。

试题五（共25分）

阅读以下关于Web系统架构设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某公司拟开发一款基于Web的工业设备监测系统，以实现对多种工业设备数据的分类采集、运行状态监测以及相关信息的管理。该系统应具备以下功能：

现场设备状态采集功能：根据数据类型对设备监测指标状态信号进行分类采集；

设备采集数据传输功能：利用可靠的传输技术，实现将设备数据从制造现场传输到系统后台；

设备监测显示功能：对设备的运行状态、工作状态以及报警状态进行监测并提供相应的图形化显示界面；

设备信息管理功能：支持设备运行历史状态、报警记录、参数信息的查询。同时，该系统还需满足以下非功能性需求：

（a）系统应支持大于100个工业设备的并行监测；
（b）设备数据从制造现场传输到系统后台的传输时间小于1s；
（c）系统应 $7\times 24$ 小时工作；
（d）可抵御常见XSS攻击；
（e）系统在故障情况下，应在0.5小时内恢复；
（f）支持数据审计。

面对系统需求，公司召开项目组讨论会议，制定系统设计方案，最终决定采用三层拓扑结构，即现场设备数据采集层、web监测服务层和前端web显示层。

【问题1】（6分）

请按照性能、安全性和可用性等三类非功能性需求分类，选择题干描述的（a）～（f)填入（1）～(3）。

表 5-1 非功能性需求归类表

【问题2】（14分）

该系统的Web监测服务层拟采用SSM开发。SSM框架的工作流程图如图5-1所示，完善图5-1中（1）～（7）处空白的内容。

图5-1 SSM框架工作流程图

(a) Connection Pool
(b) Struts2
(c) Persistent Layer
(d) Mybatis
(e) HTTP
(f）MVC
(g) Kafka
（h）ViewLayer
(i) JSP
（j）Controller Layer
（k）Spring

【问题3】（5分）

该工业设备检测系统拟采用工业控制领域中统一的数据访问机制，实现与多种不同设备的数据交互，请用200字以内的文字说明采用标准的数据访问机制的原因。

4.6 2019下半年

试题一（共25分）

阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题1和问题2。

【说明】

某电子商务公司为了更好地管理用户，提升企业销售业绩，拟开发一套用户管理系统。该系统的基本功能是根据用户的消费级别、消费历史、信用情况等指标将用户划分为不同的等级，并针对不同等级的用户提供相应的折扣方案。在需求分析与架构设计阶段，电子商务公司提出的需求、质量属性描述和架构特性如下：

（a）用户目前分为普通用户、银卡用户、金卡用户和白金用户四个等级，后续需要能够根据消费情况进行动态调整；
（b）系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御；
（c）在正常负载情况下，系统应在0.5秒内对用户的商品查询请求进行响应；
（d）在各种节假日或公司活动中，针对所有级别用户，系统均能够根据用户实时的消费情况动态调整折扣力度；
（e）系统主站点断电后，应在5秒内将请求重定向到备用站点；
（f）系统支持中文昵称，但用户名要求必须以字母开头，长度不少于8个字符；
（g）当系统发生网络失效后，需要在15秒内发现错误并启用备用网络；
（h）系统在展示商品的实时视频时，需要保证视频画面具有 $1024 \times 768$ 像素的分辨率，40帧/秒的速率；
（i）系统要扩容时，应保证在10人·月内完成所有的部署与测试工作；
（j）系统应对用户信息数据库的所有操作都进行完整记录；
（k）更改系统的Web界面接口必须在4人·周内完成；
（1）系统必须提供远程调试接口，并支持远程调试。

在对系统需求、质量属性描述和架构特性进行分析的基础上，该系统架构师给出了两种候选的架构设计方案，公司目前正在组织相关专家对系统架构进行评估。

【问题1】（13分）

针对用户级别与折扣规则管理功能的架构设计问题，李工建议采用面向对象的架构风格，而王工则建议采用基于规则的架构风格。请指出该系统更适合采用哪种架构风格，并从用户级别、折扣规则定义的灵活性、可扩展性和性能三个方面对这两种架构风格进行比较与分析，填写表1-1中的（1）～（3）空白处。

表 1-1 两种架构风格的比较与分析

【问题2】（12分）

在架构评估过程中，质量属性效用树（Utility Tree）是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图1-1中（1）、（2）空白处，并选择题干描述的（a）～（1）填入（3）～（6）空白处，完成该系统的效用树。

图1-1 会员管理系统效用树

注意：从试题二至试题五中，选择两题解答。

试题二（共25分）

阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。

【说明】

某软件企业为快餐店开发一套在线订餐管理系统，主要功能包括：

（1）在线订餐：已注册客户通过网络在线选择快餐店所提供的餐品种类和数量后提交订单，系统显示订单费用供客户确认，客户确认后支付订单所列各项费用。
（2）厨房备餐：厨房接收到客户已付款订单后按照订单餐品列表选择各类食材进行餐品加工。
（3）食材采购：当快餐店某类食材低于特定数量时自动向供应商发起采购信息，包括食材类型

和数量，供应商接收到采购信息后按照要求将食材送至快餐店并提交已采购的食材信息，系统自动更新食材库存。

（4）生成报表：每个周末利月末，快餐店经理会自动收到系统生成的统计报表，报表中详细列出了本周或本月订单的统计信息以及库存食材的统计信息。

现采用数据流图对上述订餐管理系统进行分析与设计，系统未完成的0层数据流图如图2-1所示。

图2-1

【问题1】（8分）

根据订餐管理系统功能说明，请在图2-1所示数据流图中给出外部实体E1～E4和加工P1～P4的具体名称。

【问题2】（8分）

根据数据流图规范和订餐管理系统功能说明，请说明在图2-1中需要补充哪些数据流可以构造出完整的0层数据流图。

【问题3】（9分）

根据数据流图的含义，请说明数据流图和系统流程图之间有哪些方面的区别。

试题三（共25分）

阅读以下关于嵌入式系统开放式架构相关技术的描述，在答题纸上回答问题1至问题3。

【说明】

信息物理系统（Cyber Physical Systems，CPS）技术已成为未来宇航装备发展的重点关键技术之

一。某公司长期从事嵌入式系统的研制工作，随着公司业务范围不断扩展，公司决定进入宇航装备的研制领域。为了做好前期准备，公司决定让王工程师负责编制公司进军宇航装备领域的战略规划。王工经调研和分析，认为未来宇航装备将向着网络化、智能化和综合化的目标发展，CPS将会是宇航装备的核心技术，公司应构建基于CPS技术的新产品架构，实现超前的技术战略储备。

【问题1】（9分）

通常 CPS 结构分为感知层、网络层和控制层，请用 300 字以内文字说明 CPS 的定义，并简要说明各层的含义。

【问题2】（10分）

王工在提交的战略规划中指出：飞行器中的电子设备是一个大型分布式系统，其传感器、控制器和采集器分布在飞机各个部位，相互间采用高速总线互连，实现子系统间的数据交换，而飞行员或地面指挥系统根据飞行数据的汇总决策飞行任务的执行。图3-1给出了飞行器系统功能组成图。

请参考图3-1给出的功能图，依据你所掌握的CPS知识，说明以下所列的功能分别属于CPS结构中的哪层，哪项功能不属于CPS任何一层。

1.飞行传感器管理
2.步进电机控制
3.显控
4.发电机控制
5.环控
6.配电管理
7.转速传感器
8.传感器总线
9.飞行员
10.火警信号探测

【问题3】（6分）

王工在提交的战略规划中指出：未来宇航领域装备将呈现网络化、智能化和综合化等特征，形成集群式的协同能力，安全性尤为重要。在宇航领域的CPS系统中，不同层面上都会存在一定的安全威胁。请用100字以内文字说明CPS系统会存在哪三类安全威胁，并对每类安全威胁至少举出两个例子说明。

试题四（共25分）

阅读以下关于分布式数据库缓存设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某初创企业的主营业务是为用户提供高度个性化的商品订购业务，其业务系统支持PC端、手机APP等多种访问方式。系统上线后受到用户普遍欢迎，在线用户数和订单数量迅速增长，原有的关系数据库服务器不能满足高速并发的业务要求。

为了减轻数据库服务器的压力，该企业采用了分布式缓存系统，将应用系统经常使用的数据放置在内存，降低对数据库服务器的查询请求，提高了系统性能。在使用缓存系统的过程中，企业碰到了一系列技术问题。

【问题1】（11分）

该系统使用过程中，由于同样的数据分别存在于数据库和缓存系统中，必然会造成数据同步或数据不一致性的问题。该企业团队为解决这个问题，提出了如下解决思路：

应用程序读数据时，首先读缓存，当该数据不在缓存时，再读取数据库；应用程序写数据时，先写缓存，成功后再写数据库；或者先写数据库，再写缓存。

王工认为该解决思路并未解决数据同步或数据不一致性的问题，请用100字以内的文字解释其原因。

王工给出了一种可以解决该问题的数据读写步骤如下：

读数据操作的基本步骤：

1.根据key读缓存；
2. 读取成功则直接返回；
3.若key不在缓存中时，根据key（a）；
4.读取成功后，（b）；
5.成功返回。

写数据操作的基本步骤：

1.根据key值写（c）；
2.成功后（d）；
3. 成功返回。

请填写完善上述步骤中（a）～（d）处的空白内容。

【问题2】（8分）

缓存系统一般以key/value形式存储数据，在系统运维中发现，部分针对缓存的查询，未在缓存系统中找到对应的key，从而引发了大量对数据库服务器的查询请求，最严重时甚至导致了

数据库服务器的宕机。

经过运维人员的深入分析，发现存在两种情况：

（1）用户请求的key值在系统中不存在时，会查询数据库系统，加大了数据库服务器的压力；
（2）系统运行期间，发生了黑客攻击，以大量系统不存在的随机key发起了查询请求，从而导致了数据库服务器的宕机。

经过研究，研发团队决定，当在数据库中也未查找到该key时，在缓存系统中为key设置空值，防止对数据库服务器发起重复查询。

请用100字以内文字说明该设置空值方案存在的问题，并给出解决思路。

【问题3】（6分）

缓存系统中的 key 一般会存在有效期，超过有效期则 key 失效；有时也会根据 LRU 算法将某些 key 移出内存。当应用软件查询 key 时，如 key 失效或不在内存，会重新读取数据库，并更新缓存中的 key。

运维团队发现在某些情况下，若大量的 key 设置了相同的失效时间，导致缓存在同一时刻众多 key 同时失效，或者瞬间产生对缓存系统不存在 key 的大量访问，或者缓存系统重启等原因，都会造成数据库服务器请求瞬时爆量，引起大量缓存更新操作，导致整个系统性能急剧下降，进而造成整个系统崩溃。

请用100字以内文字，给出解决该问题的两种不同思路。

试题五（共25分）

阅读以下关于web系统架构设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某公司拟开发一个物流车辆管理系统，该系统可支持各车辆实时位置监控、车辆历史轨迹管理、违规违章记录管理、车辆固定资产管理、随车备品及配件更换记录管理，车辆寿命管理等功能需求。其非功能性需求如下：

（1）系统应支持大于50个终端设备的并发请求；
（2）系统应能够实时识别车牌，识别时间应小于1s；
（3）系统应 $7\times 24$ 小时工作；
（4）具有友好的用户界面；
（5）可抵御常见SQL注入攻击；

（6）独立事务操作响应时间应小于3s；
（7）系统在故障情况下，应在1小时内恢复；
（8）新用户学习使用系统的时间少于1小时。

面对系统需求，公司召开项目组讨论会议，制订系统设计方案，最终决定基于分布式架构设计实现该物流车辆管理系统，应用Kafka、Redis数据缓存等技术实现对物流车辆自身数据、业务数据进行快速、高效的处理。

【问题1】（4分）

请将上述非功能性需求（1）～（8）归类到性能、安全性、可用性、易用性这四类非功能性需求。

【问题2】（14分）

经项目组讨论，完成了该系统的分布式架构设计，如图5-1所示。请从下面给出的（a）～（j）中进行选择，补充完善图5-1中（1）～（7）处空白的内容。

图5-1 物流车辆管理系统架构设计图

（a）数据存储层
（b）Struct2
（c）负载均衡层

(d) 表现层
（e）HTTP协议
（f）Redis数据缓存
（g）Kafka分发消息
（h）分布式通信处理层
（i）逻辑处理层
（j）CDN内容分发

【问题3】（7分）

该物流车辆管理系统需抵御常见的 SQL 注入攻击，请用 200 字以内的文字说明什么是 SQL 注入攻击，并列举出两种抵御 SQL 注入攻击的方式。

4.7 2018下半年

试题一(共25分)

阅读以下关于软件系统设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某文化产业集团委托软件公司开发一套文化用品商城系统，业务涉及文化用品销售、定制、竞拍和点评等板块，以提升商城的信息化建设水平。该软件公司组织项目组完成了需求调研，现已进入到系统架构设计阶段。考虑到系统需求对架构设计决策的影响，项目组先列出了可能影响系统架构设计的部分需求如下：

(a)用户界面支持用户的个性化定制；
(b)系统需要支持当前主流的标准和服务，特别是通信协议和平台接口；
(c)用户操作的响应时间应不大于3秒，竞拍板块不大于1秒；
(d)系统具有故障诊断和快速恢复能力；
(e)用户密码需要加密传输；
(f)系统需要支持不低于2GB的数据缓存；
(g)用户操作停滞时间超过一定时限需要重新登录验证；
(h)系统支持用户选择汉语、英语或法语三种语言之一进行操作。

项目组提出了两种系统架构设计方案：瘦客户端C/S架构和胖客户端C/S架构，经过对上述需求逐条分析和讨论，最终决定采用瘦客户端C/S架构进行设计。

【问题1】(8分)

在系统架构设计中，决定系统架构设计的非功能性需求主要有四类：操作性需求、性能需求、安全性需求和文化需求。请简要说明四类需求的含义。

【问题2】(8分)

根据表1-1的分类，将题干所给出的系统需求(a) $\sim$ (h)分别填入(1)(4)。

表 1-1 需求分类

【问题3】(9分)

请用100字以内文字说明瘦客户端C/S架构能够满足题干中给出的哪些系统需求。

试题二(共25分)

阅读以下关于软件系统建模的叙述，在答题纸上回答问题1至问题3。

【说明】

某公司欲建设一个房屋租赁服务系统，统一管理房主和租赁者的信息，提供快捷的租赁服务。本系统的主要功能描述如下：

1.登记房主信息。记录房主的姓名、住址、身份证号和联系电话等信息，并写入房主信息文件。
2.登记房屋信息。记录房屋的地址、房屋类型(如平房、带阳台的楼房、独立式住宅等)、楼层、租金及房屋状态(待租赁、已出租)等信息，并写入房屋信息文件。一名房主可以在系统中登记多套待租赁的房屋。
3.登记租赁者信息。记录租赁者的个人信息，包括：姓名、性别、住址、身份证号和电话号码等，并写入租赁者信息文件。
4. 安排看房。已经登记在系统中的租赁者，可以从待租赁房屋列表中查询待租赁房屋信息。租赁者可以提出看房请求，系统安排租赁者看房。对于每次看房，系统会生成一条看房记录并将其写入看房记录文件中。
5.收取手续费。房主登记完房屋后，系统会生成一份费用单，房主根据费用单交纳相应的费用。

6. 变更房屋状态。当租赁者与房主达成租房或退房协议后，房主向系统提交变更房屋状态的请求。系统将根据房主的请求，修改房屋信息文件。

【问题1】(12分)

若采用结构化方法对房屋租赁服务系统进行分析，得到如图2-1所示的顶层DFD。使用题干中给出的词语，给出图2-1中外部实体E1～E2、加工P1～P6以及数据存储D1～D4的名称。

图2-1 房屋租赁服务系统顶层DFD

【问题2】(5分)

若采用信息工程(Information Engineering)方法对房屋租赁服务系统进行分析，得到如图2-2所示的ERD。请给出图2-2中实体 $(1)\sim (5)$ 的名称。

图2-2 房屋租赁服务系统ERD

【问题3】(8分)

(1)信息工程方法中的“实体(asset)”与面向对象方法中的“类(class)”之间有哪些不同之处？

(2)在面向对象方法中通常采用用例(Use Case)来捕获系统的功能需求。用例可以按照不同的层次来进行划分，其中的 Essential Use Cases 和 Real Use Cases 有哪些区别？

请用100字以内文字解释说明上述两个问题。

试题三(共25分)

阅读以下关于嵌入式实时系统相关技术的叙述，在答题纸上回答问题1和问题2。

【说明】

某公司长期从事宇航领域嵌入式实时系统的软件研制任务。公司为了适应未来嵌入式系统网络化、智能化和综合化的技术发展需要，决定重新考虑新产品的架构问题，经理将论证工作交给王工负责。王工经调研和分析，完成了新产品架构设计方案，提交公司高层讨论。

【问题1】(14分)

王工提交的设计方案中指出：由于公司目前研制的嵌入式实时产品属于简单型系统，其嵌入式子系统相互独立，功能单一、时序简单。而未来满足网络化、智能化和综合化的嵌入式实时系统将是一种复杂系统，其核心特征体现为实时任务的机理、状态和行为的复杂性。简单任务和复杂任务的特征区分主要表现在十个方面。请参考表3-1给出的实时任务特征分类，用题干中给出的(a)～(t)20个实时任务特征描述，补充完善表3-1给出的空(1)～(14)。

(a)任务属性不会随时间变化而改变；
(b)任务的属性与时间相关；
(c)任务仪可以从非连续集中获取特征变量；
(d)任务变量域是连续的；
(e)功能原理不依赖于上下文；
(f)功能原理依赖于上下文；
(g)任务行为可以用step-by-step顺序分析方法来理解；
(h)许多任务在产生访问活动时相互间是并发处理的，很难用step-by-step方法分析；
(1)因果关系相互影响；
(j)行为特征依赖于大量的反馈机制；
(k)系统内构成、策略和描述是相似的；
(1)系统内存在许多不同的构成、策略和描述；
(m)功能关系是非线性的；
(n)功能关系是线性的；

(o)不同的子任务是相互独立的，任务内部仅存在少量的交互操作；
(p)不同的子任务有很高的交互操作，要把一个单任务的行为隔离开是困难的；
(q)域特征有非常整齐的原则和规则；
(r)许多不同的上下文依赖于规则；
(s)原理和规则在表面属性上很容易被识别；
(t)原理被覆盖、抽象，而不会在表面属性上被识别。

表 3-1 简单任务和复杂任务特征比较

【问题2】(11分)

王工设计方案中指出：要满足未来网络化、智能化和综合化的需求，应该设计一种能够充分表达嵌入式系统行为的、且具有一定通用性的通信架构，以避免复杂任务的某些特征带来的通信复杂性。通常为了实现嵌入式系统中计算组件间的通信，在架构上需要一种简单的架构风格，用于屏蔽不同协议、不同硬件和不同结构组成所带来的复杂性。

图3-1给出了一种“腰(Waistline)”型通信模式的架构风格。腰型架构的关键是基本消息通信(BMTS)，通常，BMTS的消息与时间属性相关，支持事件触发消息、速率约束消息和时间触发消息。请用400字以内的文字说明基于BMTS的消息通信网络的主要特征，说明三种消息的基本含义，并举例给出两种具有时间触发消息能力的网络总线。

图3-1 “腰”型通信模式架构风格

试题四(共25分)

阅读以下关于分布式数据库缓存设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业，创业初期为快速开展业务，该企业采用轻量型的开发架构(脚本语言+关系型数据库)研制了一套业务系统。业务开展后受到用户普遍欢迎，用户数和业务数量迅速增长，原有的数据库服务器已不能满足高度并发的业务要求。为此，该企业成立了专门的研发团队来解决该问题。

张工建议重新开发整个系统，采用新的服务器和数据架构，解决当前问题的同时为日后的扩展提供支持。但是，李工认为张工的方案开发周期过长，投入过大，当前应该在改动尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据，建议采用缓存工具MemCache来减轻数据库服务器的压力，这样开发量小，开发周期短，比较适合初创公司，同时将来也可以通过集群进行扩展。然而，刘工又认为李工的方案中存在数据可靠性和一致性问题，在宕机时容易丢失交易数据，建议采用Redis来解决问题。经过充分讨论，该公司最终决定采用刘工的方案。

【问题1】(9分)

在李工和刘工的方案中，均采用分布式数据库缓存技术来解决问题。请用100字以内的文字解释说明分布式数据库缓存的基本概念。

表4-1中对MemCache和Redis两种工具的优缺点进行了比较，请补充完善表4-1中的空 $(1)\sim (6)$

表 4-1 MemCache 与 Redis 能力比较

【问题2】(8分)

刘工认为李工的方案存在数据可靠性和一致性的问题，请用100字以内的文字解释说明。

为避免数据可靠性和一致性的问题，刘工的方案采用Redis作为数据库缓存，请用200字以内的文字说明基本的Redis与原有关系数据库的数据同步方案。

【问题3】(8分)

请用300字以内的文字，说明Redis分布式存储的两种常见方案，并解释说明Redis集群切片的几种常见方式。

试题五(共25分)

阅读以下关于Web系统设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某银行拟将以分行为主体的银行信息系统，全面整合为由总行统一管理维护的银行信息系统，实现统一的用户账户管理、转账汇款、自助缴费、理财投资、贷款管理、网上支付、财务报表分析等业务功能。但是，由于原有以分行为主体的银行信息系统中，多个业务系统采用异构平台、数据库和中间件，使用的报文交换标准和通信协议也不尽相同，使用传统的EAI解决方案根本无法实现新的业务模式下异构系统间灵活的交互和集成。因此，为了以最小的系统改进整合现有的基于不同技术实现的银行业务系统，该银行拟采用基于ESB的面向服务架构(SOA)集成方案实现业务整合。

【问题1】（7分）

请分别用200字以内的文字说明什么是面向服务架构(SOA)以及ESB在SOA中的作用与特点。

【问题2】(12分)

基于该信息系统整合的实际需求，项目组完成了基于SOA的银行信息系统架构设计方案。该系统架构图如图5-1所示。请从(a)～(j)中选择相应内容填入图5-1的 $(1)\sim (6)$ ，补充完善架构设计图。

(a)数据层
(b)界面层
(c)业务层
(d)bind
(e)企业服务总线ESB

(f)XML
(g)安全验证和质量管理
(h)publish
(i)UDDI
(j)组件层
(k)BPEI

图5-1 基于SOA的银行信息系统架构设计

【问题3】(6分)

针对银行信息系统的数据交互安全性需求，列举3种可实现信息系统安全保障的措施。

4.8 2017下半年

试题一(共25分)

阅读以下关于软件架构评估的叙述，在答题纸上回答问题1和问题2。

【说明】

某单位为了建设健全的公路桥梁养护管理档案，拟开发一套公路桥梁在线管理系统。在系统的需求分析与架构设计阶段，用户提出的需求、质量属性描述和架构特性如下：

(a)系统用户分为高级管理员、数据管理员和数据维护员等三类；
(b)系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御；

(c)正常负载情况下，系统必须在0.5秒内对用户的查询请求进行响应；
(d)对查询请求处理时间的要求将影响系统的数据传输协议和处理过程的设计；
(e)系统的用户名不能为中文，要求必须以字母开头，长度不少于5个字符；
(f)更改系统加密的级别将对安全性和性能产生影响；
(g)网络失效后，系统需要在10秒内发现错误并启用备用系统；
(h)查询过程中涉及的桥梁与公路的实时状态视频传输必须保证画面具有 $1024 \times 768$ 的分辨率，40帧/秒的速率；
(i)在系统升级时，必须保证在10人月内可添加一个新的消息处理中间件；
(k)系统主站点断电后，必须在3秒内将请求重定向到备用站点；
(h)如果每秒钟用户查询请求的数量是10个，处理单个请求的时间为30毫秒，则系统应保证在1秒内完成用户的查询请求；
(1)对桥梁信息数据库的所有操作都必须进行完整记录；
(m)更改系统的Web界面接口必须在4人周内完成；
(n)如果“养护报告生成”业务逻辑的描述尚未达成共识，可能导致部分业务功能模块规则的矛盾，影响系统的可修改性；
(o)系统必须提供远程调试接口，并支持系统的远程调试。在对系统需求、质量属性描述和架构特性进行分析的基础上，系统的架构师给出了三个候选的架构设计方案，公司目前正在组织系统开发的相关人员对系统架构进行评估。

【问题1】(12分)

在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请给出合适的质量属性，填入图1-1中(1)、(2)空白处；并选择题干描述的(a)～(o)，填入(3)～(6)空白处，完成该系统的效用树。

图1-1 公路桥梁在线管理系统效用树

【问题2】(13分)

在架构评估过程中，需要正确识别系统的架构风险、敏感点和权衡点，并进行合理的架构决策。请用300字以内的文字给出系统架构风险、敏感点和权衡点的定义，并从题干(a)~(o)中分别选出1个对系统架构风险、敏感点和权衡点最为恰当的描述。

试题二(共25分)

阅读以下关于软件系统设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某软件企业受该省教育厅委托建设高校数字化教育教学资源共享平台，实现以众筹众创的方式组织省内普通高校联合开展教育教学资源内容建设，实现全省优质教学资源整合和共享。该资源共享平台的主要功能模块包括：

(1)统一身份认证模块：提供统一的认证入口，为平台其他核心业务模块提供用户管理、身份认证、权限分级和单点登录等功能；
(2)共享资源管理模块：提供教学资源申报流程服务，包括了资源申报、分类定制、资料上传、资源审核和资源发布等功能；
(3)共享资源展示模块：提供教育教学共享资源的展示服务，包括资源导航、视频点播、资源检索、分类展示、资源评价和推荐等功能；
(4)资源元模型管理模块：依据资源类型提供共享资源的描述属性、内容属性和展示属性，包括共享资源统一标准和规范、资源加工和在线编辑工具、数字水印和模板定制等功能；
(5)系统综合管理模块：提供系统管理和维护服务，包括系统配置、数据备份恢复、资源导入导

出和统计分析等功能。

项目组经过分析和讨论，决定采用基于Java EE的MVC模式设计资源共享平台的软件架构，如图2-1所示。

图2-1 资源共享平台软件架构

【问题1】(9分)

MVC架构中包含哪三种元素，它们的作用分别是什么？请根据图2-1所示架构将JavaEE中JSP、Servlet、Service、JavaBean、DAO五种构件分别填入空(1)～(5)所示位置。

【问题2】(6分)

项目组架构师王工提出在图2-1所示架构设计中加入EJB构件，采用企业级JavaEE架构开发资源共享平台。请说明EJB构件中的Bean(构件)分为哪三种类型，每种类型Bean的职责是什么。

【问题3】(10分)

如果采用王工提出的企业级JavaEE架构，请说明下列(a)~(e)所给出的业务功能构件中，有状态和无状态构件分别包括哪些。

(a)Identification Bean(身份认证构件)
(b)ResPublishBean(资源发布构件）
(c)ResRetrieval Bean(资源检索构件)
(d)OnlineEditBean(在线编辑构件）
(e)StatisticsBean(统计分析构件）

试题三(共25分)

阅读以下关于机器人操作系统架构的描述，回答问题1至问题3。

【说明】

随着人工智能技术的发展，工业机器人已成为当前工业界的热点研究对象。某宇航设备公司为了扩大业务范围，决策层研究决定准备开展工业机器人研制新业务。公司将论证工作交给了软件架构师王工，王工经过分析和调研，从机器人市场现状、领域需求、组成及关键技术和风险分析等方

面开展了综合论证。论证报告指出：首先，为了保障本公司机器人研制的持续性，应根据领域需求选择一种适应的设计架构；其次，为了规避风险，公司的研制工作不能从零开始，应该采用国际开源社区所提供机器人操作系统(Robot Operating System，ROS)作为机器人开发的基本平台。

在讨论会上，架构师李工提出不同意见，他认为公司针对宇航领域已开发了某款嵌入式实时操作系统，且被多种宇航装备使用，可靠性较高。因此应该采用现有架构体系作为机器人的开发平台。会上王工说明了机器人操作系统与该款操作系统的差别，要沿用需要进行改造，投入较大。经过激烈讨论，公司领导同意了王工采用ROS的意见。

【问题1】（5分）

王工拟采用的ROS具有分布式进程框架，以点对点设计以及服务和节点管理器方式，使得执行程序可以各自独立地设计，松散地、实时地组合起来。这些进程可以按照功能包和功能包集的方式分组，因而可以容易地分享和发布。请用400字以内文字说明ROS与嵌入式实时操作系统的共同点，以及在实时性和任务通信方式两个方面的差异？

【问题2】(10分)

ROS为应用程序间通信提供了主题(Topic)、服务(Service)和动作(Action)三种消息通信方式，每种通信方式都有其特点。请将以下给出的三类通信的主要特点填入表3-1中(1)～(5)的空白处，将答案写在答题纸上。

(a)适合用于传输传感器信息(数据流)
(b)能够知道是否调用成功
(c)一对多模式
(d)有握手信号
(e)服务执行完会有反馈
(f)可以监控长时间执行的进程
(g)较复杂
(h)可能让系统过载(数据太多)
(i) 服务执行完之前，程序会等待
(j)建立通信较慢
(k)可能丢失数据

表 3-1 OS 三类通信的主要特点

【问题3】(10分)

ROS 的架构定义了 ROS 系统由多个各自独立的节点(组件)组成，并且各个节点之间可以通过发布/订阅(Publish/Subscribe)消息模型进行通信。图 3-1 给出一个简单机器人结构实例，请根据以下文字描述，补充图 3-1 中 $(1)\sim (5)$ 处空白，将答案写在答题纸上。

图3-1 一个简单机器人结构实例

机器人开始阶段，所有节点都要注册(Registration)到Master上，注册后，摄像头节点声明它要发布(Publish)一个叫作/image_data的消息。另外两个节点(图像处理处理节点和图像显示节点)声明它们需要订阅(Subscribe)这个/image data消息。因此，一旦摄像头节点收到相机发送的数据(Data)，就立即将数据/image_data直接发送到另外两个节点。

试题四(共25分)

阅读以下关于数据库设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某制造企业为拓展网上销售业务，委托某软件企业开发一套电子商务网站。初期仅解决基本的网上销售、订单等功能需求。该软件企业很快决定基于.NET平台和SOLServer数据库进行开发，但在数据库访问方式上出现了争议。王工认为应该采用程序在线访问的方式访问数据库；而李工认为本企业内部程序员缺乏数据库开发经验，而且应用简单，应该采用ORM(对象关系映射)方式。最终经过综合考虑，该软件企业采用了李工的建议。

随着业务的发展，该电子商务网站逐渐发展成一个通用的电子商务平台，销售多家制造企业的产品，电子商务平台的功能也日益复杂。目前急需对该电子商务网站进行改造，以支持对多种异构数据库平台的数据访问，同时满足复杂的数据管理需求。该软件企业针对上述需求，对电子商务网站的架构进行了重新设计，新增加了数据访问层，同时采用工厂设计模式解决异构数据库访问的问题。新设计的系统架构如图4-1所示。

图4-1 电子商务网站的体系架构

【问题1】(9分)

请用300字以内的文字分别说明数据库程序在线访问方式和ORM方式的优缺点说明该软件企业采用ORM的原因。

【问题2】(9分)

请用100字以内的文字说明新体系架构中增加数据访问层的原因。请根据图4-1所示，填写图中空白处 $(1)\sim (3)$ 。

【问题3】（7分）

应用程序设计中，数据库访问需要良好的封装性和可维护性，因此经常使用工厂设计模式来实现对数据库访问的封装。请解释工厂设计模式，并说明其优点和应用场景；请解释说明工厂模式在数据访问层中的应用。

试题五(共25分)

阅读以下关于Web系统架构设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某电子商务企业因发展良好，客户量逐步增大，企业业务不断扩充，导致其原有的B2C商品交易平台已不能满足现有业务需求。因此，该企业委托某软件公司重新开发一套商品交易平台。该企业要求新平台应可适应客户从手机、平板设备、电脑等不同终端设备访问系统，同时满足电商定期开展“秒杀”“限时促销”等活动的系统高并发访问量的需求。面对系统需求，软件公司召开项目组讨论会议，制定系统设计方案。讨论会议上，王工提出可以应用响应式Web设计满足客户从不同设备正确访问系统的需求。同时，采用增加镜像站点、CDN内容分发等方式解决高并发访问量带来的问题。李工在王工的提议上补充，仅仅依靠上述外网加速技术不能完全解决高用户并发访问问题，如果访问量持续增加，系统仍存在崩溃可能。李工提出应同时结合负载均衡、缓存服务器、Web应用服务器、分布式文件系统、分布式数据库等方法设计系统架构。经过项目组讨论，最终决定综合王工和李工的思路，完成新系统的架构设计。

【问题1】(5分)

请用200字以内的文字描述什么是“响应式Web设计”，并列举2个响应式Web设计的实现方式。

【问题2】(16分)

综合王工和李工的提议，项目组完成了新商品交易平台的系统架构设计方案。新系统架构图如图5-1所示。请从选项(a)～(j)中为架构图中(1)～(8)处空白选择相应的内容，补充支持高并发的Web应用系统架构设计图。

图5-1 新商品交易平台系统架构设计图

(a)Web应用层
(b)界面层
(c) 负载均衡层
(d)CDN内容分发
(e)主数据库
(f)缓存服务器集群
(g)从数据库
(h)写操作
(i)读操作
(j)文件服务器集群

【问题3】(4分)

根据李工的提议，新的B2C商品交易平台引入了主从复制机制。请针对B2C商品交易平台的特点，简要叙述引入该机制的好处。

4.9 2016下半年

试题一(共25分)

阅读以下关于软件架构设计的叙述，在答题纸上回答问题1至问题3。

【说明】

某软件公司为某品牌手机厂商开发一套手机应用程序集成开发环境，以提高开发手机应用程序的质量和效率。在项目之初，公司的系统分析师对该集成开发环境的需求进行了调研和分析，具体描述如下：

1. 需要同时支持该厂商自行定义的应用编程语言的编辑、界面可视化设计、编译、调试等模块，这些模块产生的模型或数据格式差异较大，集成环境应提供数据集成能力。集成开发环境还要支持以适配方式集成公司现有的应用模拟器工具。
   2.经过调研，手机应用开发人员更倾向于使用Windows系统，因此集成开发环境的界面需要与Windows平台上的主流开发工具的界面风格保持一致。
   3.支持相关开发数据在云端存储，需要保证在云端存储数据的机密性和完整性。
   4.支持用户通过配置界面依据自己的喜好修改界面风格，包括颜色、布局、代码高亮方式等，配置完成后无须重启环境。
   5.支持不同模型的自动转换。在初始需求中定义的机器性能条件下，对于一个包含50个对象的设计模型，将其转换为相应代码框架时所消耗时间不超过5秒。
   6.能够连续运行的时间不小于240小时，意外退出后能够在10秒之内自动重启。
   7.集成开发环境具有模块化结构，支持以模块为单位进行调试、测试与发布。
   8.支持应用开发过程中的代码调试功能：开发人员可以设置断点，启动调试，编辑器可以自动卷屏并命中断点，能通过变量监视器查看当前变量取值。
   在对需求进行分析后，公司的架构师小张查阅了相关的资料，认为该集成开发环境应该采用管道-过滤器(Pipe-Filter)的架构风格，公司的资深架构师王工在仔细分析后，认为应该采用数据仓储(Data Repository)的架构风格。公司经过评审，最终采用了王工的方案。

【问题1】(10分)

识别软件架构质量属性是进行架构设计的重要步骤。请分析题干中的需求描述，填写表1-1中(1)～(5)处的空白。

表 1-1 质量属性识别表

【问题2】(7分)

请在阅读题干需求描述的基础上，从交互方式、数据结构、控制结构和扩展方法4个方面对两种架构风格进行比较，填写表1-2中(1)~(4)处的空白。

表 1-2 两种架构的比较

【问题3】(8分)

在确定采用数据仓库架构风格后，王工给出了集成开发环境的架构图。请填写图1-1中(1)～(4)处的空白，完成该集成开发环境的架构图。

图1-1 集成开发环境架构图

试题二(共25分)

阅读以下关于软件系统建模的叙述，在答题纸上回答问题1至问题3。

【说明】

某软件公司计划开发一套教学管理系统，用于为高校提供教学管理服务。该教学管理系统基本的需求包括：

(1)系统用户必须成功登录到系统后才能使用系统的各项功能服务；
(2)管理员(Registrar)使用该系统管理学校(University)、系(Department)、教师(Lecturer)、学生(Student)和课程(Course)等教学基础信息；

(3)学生使用系统选择并注册课程，必须通过所选课程的考试才能获得学分；如果考试不及格，必须参加补考，通过后才能获得课程学分；
(4)教师使用该系统选择所要教的课程，并从系统获得选择该课程的学生名单；
(5)管理员使用系统生成课程课表，维护系统所需的有关课程、学生和教师的信息；
(6)每个月到了月底系统会通过打印机打印学生的考勤信息。

项目组经过分析和讨论，决定采用面向对象开发技术对系统各项需求建模。

【问题1】（7分）

用例建模用来描述待开发系统的功能需求，主要元素是用例和参与者。请根据题目所述需求，说明教学服务系统中有哪些参与者。

【问题2】(7分)

用例是对系统行为的动态描述，用例获取是需求分析阶段的主要任务之一。请指出在面向对象系统建模中，用例之间的关系有哪几种类型？对题目所述教学服务系统的需求建模时，“登录系统”用例与“注册课程”用例之间、“参加考试”用例与“参加补考”用例之间的关系分别属于哪种类型？

【问题3】(11分)

类图主要用来描述系统的静态结构，是组件图和配置图的基础。请指出在面向对象系统建模中，类之间的关系有哪几种类型？对题目所述教学服务系统的需求建模时，类 University 与类 Student 之间、类 University 和类 Department 之间、类 Student 和类 Course 之间的关系分别属于哪种类型？

试题三(共25分)

阅读以下关于嵌入式实时系统设计的描述，回答问题1至问题3。

【说明】

嵌入式系统是当前航空、航天、船舶及工业、医疗等领域的核心技术，嵌入式系统可包括实时系统与非实时系统两种。某宇航公司长期从事航空航天飞行器电子设备的研制工作，随着业务的扩大，需要大量大学毕业生补充到科研生产部门。按照公司规定，大学毕业生必须进行相关基础知识培训，为此，公司经理安排王工对他们进行了长达一个月的培训。

【问题1】（7分）

王工在培训中指出：嵌入式系统主要负责对设备的各种传感器进行管理与控制。而航空航天飞行器的电子设备由于对时间具有很强的敏感性，通常由嵌入式实时系统进行管控，请用300字以内文字说明什么是实时系统，实时系统有哪些主要特性。

【问题2】(8分)

实时系统根据应用场景、时间特征以及工作方式的不同，存在多种实时特性，大致有三种分类方法，即时间类别、时间需求和工作方式结构。根据自己所掌握的“实时性”知识，将图3-1给出的实时特性按三种分类方式，填写图3-1中(1)～(8)处空白。

备选答案：时限的危害程度；时间角色；弱；时间响应；固定；时限/反应时间；时间明确；输入/输出激励；时间触发；强；周期/零星/非周期；事件触发。

图3-1 实时特性分类树

【问题3】(10分)

可靠性是实时系统的关键特性之一，区分软件的错误(Error)、缺陷(Defect)、故障(Fault)和失效(Failure)概念是软件可靠性设计工作的基础。请简要说明错误、缺陷、故障和失效的定义；并在图3-2中标出错误、缺陷和失效出现阶段，说明缺陷、故障和失效的表现形式，填写图3-2中 $(1)\sim (6)$ 处的空白。

图3-2 错误、缺陷、故障和失效关系图

试题四(共25分)

阅读以下关于应用服务器的叙述，在答题纸上回答问题1至问题3。

【说明】

某电子产品制造公司，几年前开发建设了企业网站系统，实现了企业宣传、产品介绍、客服以及售后服务等基本功能。该网站技术上采用了Web服务器、动态脚本语言PHP。随着市场销售渠道变化以及企业业务的急剧拓展，该公司急需建立完善的电子商务平台。

公司张工建议对原有网站系统进行扩展，增加新的功能(包括订单系统、支付系统、库存管理等)，这样有利于降低成本、快速上线；而王工则认为原有网站系统在技术上存在先天不足，不能满足企业业务的快速发展，尤其是企业业务将服务全球，需要提供24小时不间断服务，系统在大负荷和长时间运行下的稳定性至关重要。建议采用应用服务器的Web开发方法，例如J2EE，为该企业重新开发新的电子商务平台。

【问题1】(7分)

王工认为原有网站在技术上存在先天不足，不能满足企业业务的快速发展，根据你的理解，请用300字以内的文字说明原系统存在哪几个方面的不足。

【问题2】(8分)

请简要说明应用服务器的概念，并重点说明应用服务器如何来保障系统在大负荷和长时间运行下的稳定性以及可扩展性。

【问题3】(10分)

J2EE平台采用了多层分布式应用程序模型，实现不同逻辑功能的应用程序被封装到不同的构件中，处于不同层次的构件可被分别部署到不同的机器中。请填写图4-1中(1)～(5)处的空白，完成J2EE的N层体系结构。

图4-1J2EE的N层体系结构示意图

试题五(共25分)

阅读以下关于Scrum敏捷开发过程的叙述，在答题纸上回答问题1至问题3。

【说明】

Scrum 是一个增量的、迭代的敏捷软件开发过程。某软件公司计划开发一个基于 Web 的 Scrum

项目管理系统，用于支持项目团队采用Scrum敏捷开发方法进行软件开发，辅助主管智能决策。此项目管理系统提供的主要服务包括项目团队的管理、敏捷开发过程管理和工件的管理。

Scrum 敏捷开发中，项目团队由 Scrum 主管、产品负责人和开发团队人员三种不同的角色组成，其开发过程由若干个 Sprint(短的迭代周期，通常为 $2 \sim 4$ 周)活动组成。

Product Backlog 是在 Scrum 过程初期产生的一个按照商业价值排序的需求列表，该列表条目的体现形式通常为用户故事。在每一个 Sprint 活动中，项目团队从 Product Backlog 中挑选最高优先级的用户故事进行开发。被挑选的用户故事在 Sprint 计划会议上经过细化分解为任务，同时初步估算每一个任务的预计完成时间，编写 Sprint Backlog。

在 Sprint 活动期间，项目团队每天早晨需举行每日站立会议，重新估算剩余任务的预计完成时间，更新 Sprint Backlog、Sprint 燃尽图和 Release 燃尽图。在每个 Sprint 活动结束时，项目团队召开评审会议和回顾会议，交付产品增量，总结 Sprint 期间的工作情况和问题。此时，如果 Product Backlog 中还有未完成的用户故事，则项目团队将开始筹备下一个 Sprint 活动迭代。

为完成Scrum项目管理系统，考虑到系统的智能决策需求，公司决定使用MVC架构模式开发该项目管理系统。具体来说，系统采用轻量级J2EE架构和SSH框架进行开发，使用MySQL数据库作为底层存储。

【问题1】(10分)

Scrum 项目管理软件需真实模拟 Scrum 敏捷开发流程, 请根据你的理解完成图 5-1 给出的 Scrum 敏捷开发状态图, 填写其中 $(1) \sim (5)$ 的内容。

图5-1 Scrum敏捷开发状态图

【问题2】(6分)

根据题于描述，本系统采用MVC架构模式，请从备选答案 $a\sim n$ 中分别选出属于MVC架构模型中的模型(Model)、视图(View)和控制器(Controller)的相关内容描述填入表5-1的空 $(1)\sim (3)$ 处。

备选答案：
表 5-1 架构模式中包含的内容

【问题3】(9分)

根据项目组给出的系统设计方案，将备选答案 $\mathrm{a} \sim 1$ 的内容填写在图5-2中的空(1)～(9)，完成系统架构图。

图5-2 系统架构图

备选答案：

第5章 案例分析真题答案解析

5.1 2024上半年

见真题即可。

5.2 2023下半年

试题一(共25分)

【问题1】

(1)2 (2)1 (3)高 (4)低 (5)必要时进行全量计算，计算开销相对较小 (6)满足实时性 (7)大 (8)弱

【问题2】

(1) $\mathrm{d}(2) = \mathrm{e}(3) = \mathrm{k}(4) = \mathrm{g}(5) = \mathrm{h}(6) = \mathrm{l}(7) = \mathrm{j}(8) = \mathrm{f}(9) = \mathrm{n}$ .

【问题3】

(1)批处理层 (2)加速层 (3)服务层

该系统的大数据架构是基于 Lambda 架构搭建的大数据平台处理奥运会大规模视频网络观看数据。

试题二(共25分)

【问题1】

需求图(REQ或req)：用于表述文字化的需求、需求间的关系，以及与之存在满足、验证等关系的其他模型元素。

用例图：从用户的角度提供系统或业务流程功能的概述。

这两者的主要区别在于，需求图更关注系统内部的功能和流程，以及这些功能和流程如何满足用户的需求；而用例图更关注用户如何使用系统，以及系统与用户的交互。简单来说，需求图更偏向于系统的功能和流程，而用例图更偏向于用户的使用体验。

【问题2】

(1)-(5): BCDEF

1)复合关系：复合需求可以包含需求层次结构中的子需求。复合需求可以声明系统应执行A和B，可以将其分解为系统应执行A和系统应进行B的子需求。
(2)派生关系：派生的需求通常对应于系统层次结构下一级的需求。一个简单的例子是车辆加速

需求，该需求被分析以导出发动机动力等方面的需求。

3)细化关系：细化关系可用于描述如何使用模型元素或元素集进一步细化需求。例如，可以使用用例或活动图来细化基于文本的功能需求。
4)满足关系：满足关系描述了设计或实现模型如何满足一个或多个需求。然后，系统建模者可以指定旨在满足要求的系统设计元素。
5)验证关系：验证关系定义了测试用例或其他模型元素如何验证需求。在 SysML 中，测试用例或其他元素可以用作表示任何标准检验方法的通用机制，分析，演示或测试。
6)复制关系：真正需要跨产品系列和项目重用需求。典型的方案是适用于产品和/或产品系列中重复使用的项目和要求的法定法规或合同要求。
7)追溯关系：追溯关系提供了需求和任何其他模型元素之间的通用关系。追溯关系对于将需求与源文档相关联或在规范树中的规范之间建立关系可能很有用。

试题3-试题5

题目不全，暂无

5.3 2022下半年

试题一(共25分)

【问题1】

参考答案：（1）安全性 （2）可修改性（3）e（4）j（5）h（6）k

答案解析：架构评估是软件开发过程的重要环节，在架构评估中的质量属性有：性能、可用性、可修改性、安全性、可靠性、易用性。质量属性效用树（Utility Tree）是对质量属性进行分类、权衡、分析的架构分析工具，它主要关注系统的性能、可用性、可修改性和安全性这四个方面的质量属性。本题中，（c）（e）属于性能；（b）（j）属于安全性；（f）（h）属于可用性；（g）（k）属于可修改性。

【问题2】

答案/答案解析：应该选择解释器架构风格。

折扣规则的可修改性：解释器风格比面向对象方式实现强。因为解释器风格折扣规则是独立的语法规则，由解释器可以对变化的规则进行解析，修改更容易。而面向对象相对固定，有变化时需要修改具体的类。

个性化折扣定义灵活性：解释器强于面向对象，解释器可以根据用户灵活解释执行规则，做到

千人千面。

系统性能：面向对象优于解释器。面向对象的实现相对固定，而解释器是运行期动态绑定执行。

（面向对象风格：效率高，质量高，易维护，灵活性稍差，性能好；解释器风格：可修改性高，个性化和灵活性强，性能较差。）

由于本项目的目标是提升灵活性，并且业务简单，系统性能方面不做过多考虑，因此建议采用解释器风格。

试题二(共25分)

【问题1】

参考答案：（1）f

(2）g

(3) h

（4）d

(5）b

(6) e

层间平衡：任何一张DFD子图边界上的输入/输出数据流必须与其父图对应加工的输入/输出数据流保持一致，数据流个数一致，方向一致；

图内平衡：对于每一个加工，要求既要有输入数据流，也要有输出数据流，避免出现黑洞、奇迹、灰洞。

答案解析：观察图2-1，（1）输入的是指标数据，输出的包含项目指标数据表，显然该功能是f；（2）由安全副经理操作并输入审核信息，由此可知该功能是g；同理，（3）的功能为h；再来看（5），由于输出为事故及影响参数表，可知（5）为b；（6）输出有指标预警分析表，可知该项功能为e；最后看（4），输入是预警分析的结果，推知因为d。

数据平衡原则有两个，一是父图与子图之间数据要平衡；二是每张子图内数据要平衡，避免奇迹（无入有出）、黑洞（有入无出）、灰洞（无法出）。

【问题2】

参考答案：(1)项目管理员 (2)项目经理 (3)项目指标 (4)项目信息 (5)影响因素 (6)关联事故。

答案解析：结合问题2，安全员填报的是项目指标表，因此（3）应该就是项目指标；又因为项目指标表由项目经理确认，因而（2）为项目经理；项目管理员需要维护三类信息，即项目信息、关联事故、影响因素参数，推知（1）为项目管理员，（4）、（5）、（6）为项目信息、关联事故、影响因素参数，注意此三者次序无关。

【问题3】

答案/答案解析：数据流图：在需求分析阶段建立系统的功能模型，完成需求分析。在设计阶段为模块划分与模块之间接口设计提供依据。

数据字典：在需求分析阶段为数据流图中的每个数据流、文件、加工，以及组成数据流或文件

的数据项做出说明。在设计阶段根据数据字典中的数据存储描述来建立数据库设计。

试题三(共25分)

【问题1】

答案/答案解析：顾名思义，心跳检测技术是节点以固定频率向其他节点发送心跳信息，表示自己存活。如果一段时间之后仍然没有收到来自此节点的心跳，就认定该节点已失效，其资源和服务就会被接管。优点是可以快速反应，缺点是容易产生误判。

超时探测技术是节点主动向被探测节点发出PING信号，被探测节点则在收到PING信号后回复一个ECHO信号，表示自己的健康状态良好，还可以附加一些状态信息。如果在预定的时间之后仍然收不到ECHO信号，则判定被探测节点失效。优点是可以获得更详细的探测结果，缺点是判断的周期较长。

【问题2】

参考答案：(1)(2)：be (3):f (4)(5)(6):adh (7)(8):g

答案解析：

看门狗电路是嵌入式系统必须具备的一种系统恢复能力。看门狗电路的基本功能是在系统发生软件问题和程序跑飞后使系统重新启动。其基本原理是看门狗计数器正常工作时自动计数，程序流程定期将其复位，如果系统在某处卡死或者跑飞，该定时器将溢出，并将进入中断处理，在设定时间间隔内，系统可保留关键数据，然后系统复位重启。

BIT检测：机内自检（Built-InTest，简称BIT）是嵌入式系统中用于检测硬件故障的一种技术。它通常在系统启动时自动运行，以确保所有关键硬件组件都处于正常工作状态。

【问题3】

答案/答案解析：数据驱动方法是一种问题求解方法。从初始的数据或观测值出发，运用启发式规则，寻找和建立内部特征之间的关系，从而发现一些定理或定律。通常也指基于大规模统计数据的自然语言处理方法。

在本题中，由于是分布式环境，需要综合多种故障信息和系统状态，依据智能决策数据库的决策策略判定，如果采用预先定制的解析模型，这个模型可能会非常复杂。因此采用数据驱动方法能通过已有的数据去训练模型，可以达到逐渐精细化，并兼容未来的变化。

试题四(共25分)

【问题1】

答案/答案解析：李工同步更新方案思路，更新数据时在同一事务内依此完成删除缓存，更新数据库，再写入缓存。张工异步准实时方案思路，当数据库数据更新时，不立即更新缓存数据，而是将需要更新的操作记录成日志，再逐步排队完成更新。

本项目数据量大，性能要求高，同步方案并发时的性能不可控，因此应采用张工提出的异步准实时方案较好。

【问题2】

答案/答案解析：Hash分片算法：就是对缓存的Key做哈希计算，然后对总的缓存节点个数取余。例如，我们部署了三个缓存节点组成一个缓存集群，当有新的数据要写入时，我们首先对这个缓存的Key做Hash算法生成Hash值（比如CRC32等），然后对Hash值模3，得到的结果就是要存入缓存节点的序号。特点：这个算法最大的优点就是简单易理解，缺点是当增加或者减少缓存节点时，缓存总的节点个数变化造成计算出来的节点发生变化，从而造成缓存失效不可用。

一致性哈希分片算法：是一种特殊的哈希算法，将整个哈希值空间映射成一个按顺时针方向组织的虚拟圆环，然后将缓存节点的IP地址或者主机名做Hash取值后，放置在这个圆环上。当需要确定某一个Key存放在到哪个节点上时，先对在这个Key做同样的Hash取值，然后根据Hash值的位置沿圆环顺时针查找，将数据分配到第一个遇到的缓存节点。用一致性Hash算法可以很好地解决增加和删减节点时，命中率下降的问题。

一致性哈希分片算法的优点：①可扩展性。在增加或减少节点时，数据存储的改变最少；②更好地适应数据的快速增长。

一致性Hash算法示意图

【问题3】

答案/答案解析：布隆过滤器本质上是一种数据结构，比较巧妙的概率型数据结构，特点是高效地插入和查询，告诉你“某个元素一定不存在或者可能存在”。布隆过滤器的原理是当一个元素被加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，只要看看这些点是不是都是1就大概知道集合中有没有它了；如果这些点有任何一个0，则被检元素一定不在；如果都是1，则被检元素很可能在。

优点：

. 占用内存小；
. 增加和查询元素的时间复杂度为：O(K)，(K 为哈希函数的个数，一般比较小)，与数据量大小无关；
. 哈希函数相互之间没有关系，方便硬件并行运算；
布隆过滤器不需要存储元素本身，在某些对保密要求比较严格的场合有很大优势；
数据量很大时，布隆过滤器可以表示全集，其他数据结构不能；

1. 使用同一组散列函数的布隆过滤器可以进行交、并、差运算缺点；
2. 有误判率，即存在假阳性(False Position)，不能准确判断元素是否在集合中(概率较小)；
   不能获取元素本身；
   一般情况下不能从布隆过滤器中删除元素；
   如果采用计数方式删除，可能会存在计数回绕问题。

试题五(共25分)

【问题1】

答案/答案解析：MQTT 是一个物联网传输协议，它被设计用于轻量级的发布/订阅式消息传输，旨在为低带宽和不稳定的网络环境中的物联网设备提供可靠的网络服务。MQTT 是专门针对物联网开发的轻量级传输协议。MQTT 协议针对低带宽网络，低计算能力的设备，做了特殊的优化，使得其能适应各种物联网应用场景。

【问题2】

参考答案：(1)HTTP (2)HTTP (3)MQTT (4)HTTP (5)HTTP (6)HTTP (7)端侧识

(8)模型训练模块 (9)设备调度平台模块 (10)访客注册模块

答案解析：根据MQTT的协议特征可知，只有（3）才适合，其他均为HTTP。

【问题3】

答案/答案解析：传统云计算模型中引入边缘计算模型的优势如下：

（1）速度：如果使用边缘计算，则物联网设备将在边缘数据中心或本地处理数据。因此，数据无需传输回中央服务器，速度优势明显；
（2）安全：边缘计算将在不同的数据中心和设备之间分配数据处理工作。黑客无法通过攻击一台设备来影响整个网络；
（3）可扩展性：通过购买具有足够计算能力的设备来扩展边缘网络。企业无需为其数据需求建立自己的私有或集中式数据中心；
（4）可靠性：所有的边缘数据中心和物联网设备都位于用户附近。因此，网络中断的可能性非常小。

5.4 2021下半年

试题一（25分）

【问题1】

参考答案：（1）性能 （2）可修改性 (3）e (4）j (5）h (6）i

答案解析：架构评估是软件开发过程的重要环节，在架构评估中的质量属性有：性能、可用性、可修改性、安全性、可靠性、易用性。质量属性效用树（Utility Tree）是对质量属性进行分类、权衡、分析的架构分析工具，它主要关注系统的性能、可用性、可修改性和安全性这四个方面的质量属性。本题中，（b）（h）属于安全性；（f）（g）属于性能；（c）（e）属于可用性；（g）（i）属于可修改性。

【问题2】

答案/答案解析：应该选择解释器架构风格。

从灵活性上解释器可以通过灵活的自定义规则实现规则的重组。

从可扩展性上解释器可以包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。可以通过新建规则实现可扩展性。

管道-过滤器风格具备高内聚低耦合、支持软件重用、扩展性好、支持并发等优点，但它有编写复杂、不适合处理交互应用等缺点。

隐式调用基于事件触发思想，具备支持软件重用、改进系统方便等优点，但它有构件放弃了对系统计算的控制、事件传递中的数据交换存在问题、语义依赖于被触发事件的上下文约束等缺点。

解释器通常包括解释引擎、代码存储区、记录解释引擎当前工作状态的数据结构、记录源代码

被解释执行进度的数据结构。它含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。优点：语法由很多类（每个规则对应一个类）表示，容易改变及扩展；缺点：如果语法规则数量太多，会增加系统复杂度，性能下降。

本题中，由于需要交互操作，显然管道-过滤器风格不合适；基于事件触发的隐式调用风格也不合适；只有解释器风格通过灵活自定义规则，具备较强的灵活性和可扩展性，适合本题中的机器学习应用。

试题二 (25 分)

【问题1】

参考答案：

（1）系统操作员（系统管理员）

（2）预约人（患者）

（3） （a）注册登录

(4) - (8) (c)、(f)、(h)、(i)、(j)

[注意：与次序无关]

（9）-（12）（b）、（d）、（e）、（g）

[注意：与次序无关]

答案解析：分析图2-1，该系统主要有两类使用者，一类是医院内部的操作人员，另一类是预约人员或患者，再结合题干描述的功能介绍，不难得出两类人员所使用的功能模块。

左边是系统操作者，使用功能包括：(a)注册登录、(c)账号管理、(f)号源管理、(h)预约管理、(j)信用管理。从字面上看，含有“**管理”的功能应该属于系统操作者。

右边是预约人员（患者），使用功能包括：(a)注册登录、(b)信息浏览、(d)预约挂号、(e)查询与取消预约、(g)报告查询。其中，(a)注册登录属于两者都需要的功能。

【问题2】

答案/答案解析：（1）预约人员（患者）（2）发起预约挂号请求（3）显示医生出诊时段（4）显示是否预约成功。

顺序图强调交互的消息时间顺序。

协作图强调接收和发送消息的对象的结构组织，强调通信的方式。

【问题3】

答案/答案解析：对象模型描述系统中对象的静态结构、对象之间的关系、属性和操作，主要用对象图来实现。

动态模型描述与时间和操作顺序有关的系统特征，例如，激发事件、事件序列、确定事件先后

关系的状态等，主要用状态图来实现。

功能模型描述一个计算如何从输入值得到输出值，它不考虑计算的次序，主要用DFD来实现。

功能模型指发生了什么，动态模型确定什么时候发生，而对象模型确定发生的客体。上述模型均可用于需求分析。

试题三（25分）

题目不全，暂无答案，待补充，根据考生回忆，本题不应该选。

试题四（25分）

【问题1】

答案/答案解析：常见的反规范技术有增加冗余列、增加派生列、重新组表、水平分割表和垂直分割表。

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

本题中用到了增加冗余列的方式。

【问题2】

答案/答案解析：解决数据不一致性问题的三种常见方法：批处理维护、应用逻辑和触发器。

（1）批处理维护：通过定期运行一批处理作业或存储过程对数据库进行修改，适用于对实时性要求不高的情况。
（2）应用逻辑：在同一事务中对所有涉及的表进行增、删、改操作。同一逻辑必须在所有的应用中使用和维护，容易遗漏，特别是在需求变化时，不易于维护。
(3) 触发器: 对数据的任何修改立即触发对数据库某些列的相应修改。触发器实时性好, 也易

于维护。

该系统应该采用触发器。

【问题3】

答案/答案解析：

（1）选择ZSet数据类型。

Redis 数据类型：

String：基本类型。可用于缓存层或计数器，如视频播放量、文章浏览量等。

Hash：代替string类型，节省空间。描述用户信息较为方便。

Set：无序集合，每个值不能重复。可用于去重、抽奖、初始化用户池等。

List：双向链表结构，可以模拟栈、队列等形式。可用于回复评论、点赞。

ZSet：有序集合、每个元素有一个分数。如首页推荐10个最热门的帖子。

（2）Redis和MySQL数据实时同步方案有下面三种：

①引用 Mysql 的事务，因为事务有一致性保证，事务提交成功后再更新缓存；

②在缓存里面引用一些访问控制位，数据库数据变化后，同步变更对应的访问控制位，然后从缓存查询时，率先判断该访问控制位，有变化就从数据库查，无变化直接从缓存返回数据；

③三是通过数据库中间件产品保证缓存和数据库数据时时同步。

试题五（25分）

【问题1】

答案/答案解析：在网关管理方面，基于云平台的智能家居管理系统可以将分散的智能家居网关数据集中起来，实现对智能家居网关的远程高效管理。

在数据处理方面，云端服务器对智能家居网数据进行备份存储，当家庭网关由于故障等原因导致数据丢失时，可以通过云端管理系统对网关数据进行恢复，从而提高数据的容灾性。

在系统性能方面，基于云服务平台的智能家居管理系统将数据信息存储在云端，减少了数据请求时间，提高了通信效率。

【问题2】

参考答案：（1）h（2）i（3）f（4）d（5）e（6）c

答案解析：分析图5-1可知，系统为典型的分层架构：

（1）层为用户交互层；（3）层为平台层；（5）层为通信网关层。
（1）层包含多种移动app操作系统，推知（2）为鸿蒙OS。
（3）层为云平台层，包含各种软件系统、数据库等。
（5）层为网关层，包含硬件系统及其驱动或通信协议。

【问题3】

答案/答案解析：TCP在IP协议提供的不可靠数据服务的基础上，采用了重发技术，为应用程序提供了一个可靠的、面向连接的、全双工的数据传输服务。TCP协议一般用于传输数据量比较少，且对可靠性要求高的场合。

UDP 是一种不可靠的、无连接的协议，可以保证应用程序进程间的通信，与 TCP 相比，UDP 是一种无连接的协议，它的错误检测功能要弱得多。

该系统应采用TCP协议。

5.5 2020下半年

试题一（25分）

【问题1】

参考答案：根据该系统的功能需求，采用仓库架构风格更合适。

（1）数据统一保存在中央数据仓库，数据处理流程相对独立，支持交互式处理。
（2）管道过滤器风格容易添加新的过滤器，可扩展性好。
（3）仓库风格不支持并行，效率低。
（4）仓库风格容错性和健壮性好。

答案解析：管道过滤器架构风格由一系列处理单元（过滤器）组成，每个单元的输出是下一个单元的输入。过滤器负责处理数据，管道负责数据传输。如Linux/Unix中的shell、传统的编译器就是管道过滤器风格。优点：①高内聚，过滤器是执行特定功能的处理服务，具有较强的内聚性；②低耦合，过滤器之间仅通过管道通信；③可重用，支持过滤器的重用；④能简单地实现并发或顺序系统；⑤可扩展性，容易添加新的过滤器；⑥灵活性，过滤器功能可重新定义，管道线路可改变。缺点：①管道中数据传输需要通用的标准；②难以支持基于事件的交互。

仓库风格是一种数据共享风格，主要有两类，一是传统的数据库，另一是黑板。数据库系统是由输入流中的事件来驱动信息处理，把执行结构存储到中央数据单元。黑板则由中央数据单元的当前状态来驱动系统运行，用来解决状态冲突并处理可能存在的不确定性知识源。黑板常用信号处理，如语音识别、模式识别、机器翻译、句法分析等。优点：①便于多客户共享大量数据，不必关心数据的产生、有谁提供、如何提供等；②便于将构件作为知识源添加到系统中来；③解决问题的多方法性；④具有可修改性和可维护性；⑤有可重用的知识源；⑥支持容错性和健壮性。缺点：①对共享数据结构，不同知识源要达成一致；②需要同步机制、加锁机制来保障数据的完整性和一致性，增大了系统设计的复杂度；③测试困难；④缺少对并行机的支持，效率低；⑤开发成本高。

题干的系统功能包括代码编辑、语法高亮显示、代码编译、系统调试、代码仓库管理等。这些功能相对独立，代码通过中央数据单元存储，各个功能彼此之间不依赖，采用仓库风格更合适。

【问题2】

参考答案：（1）安全性（2）可修改性（3）g（4）i（5）f（6）j

答案解析：架构评估是软件开发过程的重要环节，在架构评估中的质量属性有：性能、可用性、可修改性、安全性、可靠性、易用性。质量属性效用树（Utility Tree）是对质量属性进行分类、权衡、分析的架构分析工具，它主要关注系统的性能、可用性、可修改性和安全性这四个方面的质量属性。本题中，(b)(g)属于性能；(c)(i)属于安全性；(d)(f)属于可用性；(h)(j)属于可修改性。

试题二（25分）

【问题1】

参考答案/答案解析：逻辑模型设计也称为逻辑结构设计，其任务是将概念模型转化为某个特定的

DBMS上的逻辑模型。设计逻辑结构时，首先为概念模型选定一个合适的逻辑模型（例如，关系模型、网状模型或层次模型），然后将其转化为由特定DBMS支持的逻辑模型，最后对逻辑模型进行优化。逻辑设计的目的是将概念设计阶段设计好的E-R图转换为与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构。

该包裹单包含三类实体：收件人（主键：电话）、寄件人（主键：电话）、包裹单（主键：包裹单编号）。

【问题2】

参考答案/答案解析：某个实体类型中所有实体同时也是另一个实体类型中的实体，此时称前一实体为子类实体，后一实体为超类实体。

本题的超类实体为：包裹单（包裹单编号、收件人、寄件人）。

【问题3】

参考答案/答案解析：实体的某个属性可以从其他属性或其他数据推导出来，那么这个属性就是派生属性。本题中，资费总计=资费+挂号费+保价费+回执费，因此资费总计是一个派生属性。

试题三（25分）

【问题1】

参考答案/答案解析：存在的难点有：

①描述语言方面，需求由于更加贴近用户，其所用的描述语言可能会不够正规和标准，可能存在语义含糊不清、甚至歧义等情况；而软件架构所用的描述语言需要正规和标准，不允许存在含糊、歧义等情况。
②非功能性需求描述方面，需求阶段可能不太关注，或者描述的比较笼统；而架构阶段，则需要明确量化。
③需求和架构的一致性方面，需求与架构无法做到完全的一致和一一映射，例如某个需求在架构上是需要通过多种技术来实现，简言之，架构提供的能力是大于需求的。

【问题2】

参考答案/答案解析：FACE架构的五个部分及其含义是：

① 操作系统(OSS)：基础服务由操作系统提供。其余四个部分依赖于 OSS；
② I/O 服务(IOSS)：该段将接口标准化为 I/O 设备；
③平台服务(PSSS)：它提供平台服务，例如数据服务、日志记录、健康管理和图形(带有GPU接口)；

④ 传输服务(TSS)：该段提供通信服务；
⑤可移植组件(PCS)：这提供了功能或业务逻辑，如公共服务、可移植的组件等。

【问题3】

参考答案/答案解析：紧耦合主要表现为，一个模块高度依赖于另一个模块，当修改前者时，必须同时需要修改后者。解决方案为：为了提高系统的修改性和可移植性，应避免紧耦合，而应采用松耦合方式。

封装主要表现为：把业务逻辑封装在本模块中，不允许外部模块直接访问本模块的内部信息。解决方案为：模块设计尽量采用封装，外部模块只能通过该模块提供的接口予以调用。

试题四（25分）

【问题1】

参考答案：（1）a（2）b、g（3）c、d（4）f（5）e

答案解析：

Redis 支持丰富的数据类型如下，其中，前 5 种常见，后 4 种为新版本增加。

• string：最基本的数据类型，二进制安全的字符串，可以包含任何数据（图片或序列化对象），最大512M。应用场景：缓存、计数器、共享用户session、分布式锁、分布式系统的全局序列号等；
• list：按照添加顺序保持顺序的字符串列表，应用场景：栈、队列、阻塞队列、最新列表等；
• set：无序的字符串集合，不存在重复的元素，应用场景：用户标签、好友/关注/粉丝/感兴趣的人集合、随机展示、黑/白名单、抽奖小程序等；
• sortedset：已排序的字符串集合，不允许重复，应用场景：标签、共同好友/喜好、统计网站的独立IP、统计点赞/取消点赞、排行榜；
• hash: key-value 对的一种集合，特别适合用于存储对象，应用场景：存储对象、电商购物车等；
• bitmap：更细化的一种操作，以bit为单位；
• hyperloglog: 基于概率的数据结构。为 V2.8.9 新增;
• geo：地理位置信息储存起来，并对这些信息进行操作，为###V3.2新增；
• stream：流，相当于消息队列的topic，为V5.0新增。

【问题2】

参考答案：RDB与AOF相比较，具备下述特点：

（1）磁盘更新频率：RDB更新频率比AOF低。
（2）数据安全：AOF可以保证数据不丢失，比RDB更安全。
（3）数据一致性：RDB间隔一段时间存储，可能发生数据丢失和不一致；AOF通过append模式写文件，即使发生服务器岩机，也可通过redis-check-aof工具解决数据一致性问题。
（4）重启性能：RDB比AOF更高。
（5）数据文件大小：RDB文件比AOF小。

由于RDB数据恢复更快，能在最短时间内重新建立服务，因此团队最终选择了RDB。

答案解析：RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。RDB的优点：

• 体积更小：RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
• 性能更高：生成RDB文件的时候，Redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
• 恢复更快：RDB在恢复大数据集时的速度比AOF的恢复速度要快。RDB的缺点：①可能丢失数据；②耐久性差。

AOF是Redis将每一个写命令都通过write函数追加到文件中，通俗的理解就是日志记录。AOF优点：

• AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次 fsync 操作，最多丢失 1 秒钟的数据。
• AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
• AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
• 日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用 flushall 命令清空了所有数据，只要这个时候后台

rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

AOF缺点：①AOF日志文件比RDB快照文件更大；②性能AOF比RDB低；③数据恢复时无法一模一样地恢复出来。

【问题3】

参考答案/答案解析：有两种场景：①不管定期删除还是惰性删除，都是一种不完全精确的删除策略，始终还是会存在已经过期的 key 无法被删除的场景；②内存被挤满了。

Redis内存淘汰机制：

• volatile-lru，针对设置了过期时间的key，使用LRU（Least Recently Used，最近很少使用）算法进行淘汰。
• allkeys-lru，针对所有key使用LRU算法进行淘汰。
• volatile-lfu，针对设置了过期时间的key，使用LRU（Least Frequently Used，最不经常使用）算法进行淘汰。
• allkeys-lfu，针对所有key使用LRU算法进行淘汰。
• volatile-random，从所有设置了过期时间的key中使用随机淘汰的方式进行淘汰。
• allkeys-random，针对所有的key使用随机淘汰机制进行淘汰。
• volatile-ttl，针对设置了过期时间的key，越早过期的越先被淘汰。
• noeviction，不会淘汰任何数据，当使用的内存空间超过max memory值时，再有写请求来时返回错误。

试题五（25分）

【问题1】

参考答案：（1）a、b（2）d、f（3）c、e

答案解析：非功能性需求一般关注可用性、可修改性、性能、安全性、可测试性、易用性等。本题中（a）（b）属于性能；（c）（e）属于可用性；（d）（f）属于安全性。

【问题2】

参考答案：（1）a（2）c（3）d（4）k（5）j（6）h（7）i

答案解析：SSM（Spring+Spring MVC+MyBatis）框架集由 Spring、MyBatis 两个开源框架整合而成（Spring MVC 是 Spring 中的部分内容），常作为数据源较简单的 web 项目的框架。

【问题3】

参考答案/答案解析：标准的数据访问机制提供了不同标准间的数据访问机制，屏蔽了不同通信协议之间的差异，为上层应用程序提供统一的访问接口，可以容易地实现应用程序对不同总线协议设备

的互操作，使得从低层的开发中脱离出来。它独立于平台，确保实现来自多个厂商的设备之间信息的无缝传输，具有语言无关性、代码重用性、易于集成性等优点。当硬件升级或修改时只需改动硬件接口部分即可，不会影响上层应用程序。例如，工业自动化领域常用OPC。

5.6 2019下半年

试题一（25分）

本题主要考查考生对于软件架构风格的理解与掌握，以及对软件质量属性的理解、掌握和应用。在解答该问题时，应认真阅读题干中给出的场景与需求描述，分析需求与架构风格的对应关系，并需要理解每个需求描述了何种质量属性，根据质量属性描述对其归类。

【问题1】

参考答案：该系统更适合采用基于规则的虚拟机架构风格。

（1）根据用户级别建立用户级别-折扣规则矩阵，在系统启动时加载并支持运行过程中动态更新，灵活性好；
（2）加入新的用户级别和折扣规则时需要增加相应的类来扩展，可通过系统重启、动态反射或动态加载扩展，扩展性较差；
（3）可根据类型判断或策略模式直接获得用户级别对应的折扣规则对象实时计算，性能很好。答案解析：面向对象设计模式中的策略模式和虚拟机中的基于规则的架构风格是动态规则场景中两种组常用的解决方案。从灵活性、可扩展性和性能方面综合比较来看，基于规则的虚拟机风格在灵活性和可扩展性两个方面均具备较大优势，而从性能方面会比面向对象处理速度差一些。

【问题2】

参考答案：（1）安全性（2）可修改性（3）h（4）j（5）e（6）k

答案解析：质量属性效用树时对质量属性进行分类、权衡、分析的架构分析工具，主要关注系统的性能、可用性、可修改性和安全性四个方面。根据对相关质量属性的定义和含义，题干中：(c)在正常负载情况下，系统应在0.5秒内对用户的商品查询请求进行响应和(h)系统在展示商品的实时视频时，需要保证视频画面具有1024*768像素的分辨率，40帧/秒的速率，描述的是系统的性能属性；(e)系统主站点断电后，应在5秒内将请求重定向到备用站点和(g)当系统发生网络失效后，需要在15秒内发现错误并启用备用网络，描述的是系统的可用性属性；(i)系统要扩容时，应保证在10人·月内完成所有的部署与测试工作和(k)更改系统的Web界面接口必须在4人·周内完成，描述的是系统的可修改性属性；(b)系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御和(j)

系统应对用户信息数据库的所有操作都进行完整记录，描述的是系统的安全性属性。

试题二（25分）

本题考查系统过程建模的相关知识。

数据流图(Data Flow Diagram, DFD)从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。为了表达数据处理过程的数据加工情况，用一个数据流图往往是不够的。层次结构的数据流图按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。

层次结构数据流图一般分为：顶层数据流图，中层数据流图和底层数据流图。中层数据流图中最高层次一般从0开始，最高层级的中层数据流图即是0层数据流图，0层数据流图主要目的是将顶层流图的系统分解为若干子系统，并决定每个子系统间的数据接口和活动关系。

【问题1】

参考答案：E1客户，E2厨房，E3快餐店经理，E4供应商；

P1 订餐，P2 备餐，P3 生成报表，P4 采购食材

答案解析：外部实体，是指系统之外的人员、事物或组织。外部实体指出系统的边界，即系统输入数据的发源地或系统所产生的数据的目标去处，如题目中的客户、厨房、供应商和快餐店经理均属于外部实体。

加工，又称处理或过程，描述输入数据流到输出数据之间的变换，也就是输入数据流经过什么处理过程后变成了输出数据。作用是把输入数据加工成所要的输出数据。每个加工都有一个名字和编号，加工的名字一般采用动宾结构短语，偶尔使用动词，如题目中提交订单、支付订单费用、加工餐品、采购食材、生成报表等均属于加工。

【问题2】

参考答案：

1）E1–>P1 餐品订单
2）P1–>P2 餐品订单
3）D1–>P3订单汇总
4）P3->E3统计报表

答案解析：外部实体、加工、数据存储和数据流四要素在数据流程图中常见的错误：

外部实体作为数据来源和数据去处，常见错误主要集中在孤立的外部实体和实体命名方面。孤

立外部实体既没有输入任何数据给系统，系统也没有为其提供任何数据，而实体命名一般采用代表人群、事物或组织名称的名词。

加工常见的错误集中在加工的输入和输出，常见的错误包括有输入而没有输出的加工，有输出而没有输入的加工，输入和输出不守恒的加工。

同样的数据存储常见的错误也集中在输入和输出，包括有输入无输出的存储，有输出无输入的存储和输入输出不守恒的存储。

而数据流的常见错误主要集中在命名方面，数据流名称应该是数据流中传递的数据内容，不要使用处理、传递、变换相关的内容来命名数据流。

【问题3】

参考答案：

（1）数据流图中的处理过程可并行；系统流程图在某个时间点只能处于一个处理过程。
（2）数据流图展现系统的数据流；系统流程图展现系统的控制流。
（3）数据流图展现全局的处理过程，过程之间遵循不同的计时标准；系统流程图中处理过程遵循一致的计时标准。

答案解析：

外部实体、加工、数据存储和数据流四要素在数据流程图中常见的错误：

外部实体作为数据来源和数据去处，常见错误主要集中在孤立的外部实体和实体命名方面。孤立外部实体既没有输入任何数据给系统，系统也没有为其提供任何数据，而实体命名一般采用代表人群、事物或组织名称的名词。

加工常见的错误集中在加工的输入和输出，常见的错误包括有输入而没有输出的加工，有输出而没有输入的加工，输入和输出不守恒的加工。

同样的数据存储常见的错误也集中在输入和输出，包括有输入无输出的存储，有输出无输入的存储和输入输出不守恒的存储。

而数据流的常见错误主要集中在命名方面，数据流名称应该是数据流中传递的数据内容，不要使用处理、传递、变换相关的内容来命名数据流。

试题三（25分）

本题主要考查 CPS 系统的定义、架构层次结构和安全性质量属性。

信息物理系统（CPS，Cyber-Physical Systems）是一个综合计算、网络和物理环境的多维复杂系统，通过3C（Computation、Communication、Control）技术的有机融合与深度协作，实现大型工程

系统的实时感知、动态控制和信息服务。CPS实现计算、通信与物理系统的一体化设计，可使系统更加可靠、高效、实时协同，具有重要而广泛的应用前景。

【问题1】

参考答案：

信息物理系统作为计算进程和物理进程的统一体，是集成计算、通信与控制于一体的下一代智能系统，通过人机交互接口实现和物理进程的交互，使用网络化空间以远程的、可靠的、实时的、安全的、协作的方式操控一个物理实体。

感知层主要是由传感器、控制器和采集器等设备组成，主要是通过传感器获取环境的信息数据，定时发送给服务器，并接收服务器处理结果数据后进行相应的控制器变化；网络层是连接信息世界和物理世界的桥梁，主要实现数据传输，为系统提供实时的网络服务，保证网络分组的实时可靠；控制层根据感知层的认知结果，根据物理设备传回来的数据进行相应的分析，将分析结果通过客户端以可视化的界面呈现给客户。

答案解析：

信息物理系统(Cyber-Physical Systems，CPS)作为计算进程和物理进程的统一体，是集成计算、通信与控制于一体的下一代智能系统。信息物理系统通过人机交互接口实现和物理进程的交互，使用网络化空间以远程的、可靠的、实时的、安全的、协作的方式操控一个物理实体。

信息物理系统包含了将来无处不在的环境感知、嵌入式计算、网络通信和网络控制等系统工程，使物理系统具有计算、通信、精确控制、远程协作和自治功能。它注重计算资源与物理资源的紧密结合与协调，主要用于一些智能系统上如设备互联，物联传感，智能家居，机器人，智能导航等。

信息物理系统主要分为3个部分，分别是感知层、网络层和控制层，感知层主要是由传感器、控制器和采集器等设备组成。感知层中的传感器作为信息物理系统中的末端设备，主要采集的是环境中的具体信息感知层主要是通过传感器获取环境的信息数据，并定时地发送给服务器，服务器接收到数据之后进行相应的处理，再返回给物理末端设备相应的信息，物理末端设备接收到数据之后要进行相应的变化；网络层主要是连接信息世界和物理世界的桥梁，主要实现的是数据传输，为系统提供实时的网络服务，保证网络分组的实时可靠；控制层主要是根据认知层的认知结果，根据物理设备传回来的数据进行相应的分析，将相应的结果返回给客户端以可视化的界面呈现给客户。

【问题2】

参考答案：

感知层：2，4，7，10

网络层：8

控制层：1，3，5，6

非CPS：9

答案解析：

根据 CPS 感知层、网络层、控制层定义，2 步进电机控制和 4 发电机控制属于控制器，7 转速传感器和 10 火警信号探测属于传感器，因此 2，4，7，10 归类为感知层设备；8 传感器总线属于数据传输通讯链路设备，归类为网络层设备；3 显控属于飞行器任务级功能，1 飞行传感器管理属于飞行器平台级功能，5 环控和 6 配电管理属于飞行器平台级下的功能组件，因此 1，3，5，6 归类为控制层；而 9 飞行员属于系统使用者，不属于 CPS 系统。

【问题3】

参考答案：

1.感知层威胁

信息窃听：通过搭线或电磁泄漏造成数据隐私泄露；

感知破坏：未经授权对感知层信息篡改、增删或破坏。

2.网络层威胁

拒绝服务：发送大量请求迫使服务器停止接受新请求；

选择性转发：恶意节点接收数据后有选择性的转发，破坏数据完整性。

3.控制层威胁

非授权访问：未经授权情况下不合理进入系统执行恶意操作；

恶意代码：注入对系统造成不良影响的恶意代码，对系统造成破坏。

答案解析：

感知执行层安全威胁：

感知执行层主要由各种物理传感器等组成，是整个物理信息系统中信息的来源。为了适应多变的环境，网络节点多布置在无人监管的环境中，因此易被攻击者攻击。常见的针对感知执行层的攻击方式有：

1）感知数据破坏：攻击者未经授权，对感知层获取的信息进行篡改、增删或破坏等；
2）信息窃听：攻击者通过搭线或利用传输过程中的电磁泄露获取信息，造成数据隐私泄露等问题；
3）节点捕获：攻击者对部分网络节点进行控制，可能导致密钥泄露，危及整个系统的通信安全。数据传输层安全威胁：
数据传输层一般要接入网络，而接入网络本身就会给整个物理信息系统带来威胁。一方面，作

为链接感知层和控制层的数据传输的通道，其中传输的信息易成为攻击者的目标；另一方面，由于接入网络，数据传输层易受到攻击。数据传输层的主要安全威胁如下：

1)拒绝服务攻击：攻击者通过先向服务器发送大量请求，使得服务器缓冲区爆满而被迫停止接受新的请求，使系统崩溃从而影响合法用户的使用；
2）选择性转发：恶意节点在接收到数据后，不全部转发所有信息，而是将部分或全部关键信息在转发过程中丢掉，破坏了数据的完整性；
3）方向误导攻击：恶意节点在接收到数据包后，对其源地址和目的地址进行修改，使得数据包沿错误路径发送出去，造成数据丢失或网络混乱。

应用控制层安全威胁：

应用控制层中数据库中存放着大量用户的隐私数据，因此在这一层中一旦发生攻击就会出现大量隐私泄漏的问题。针对应用层的主要威胁有：

1）用户隐私泄漏：用户的所有的数据都存储在应用控制层中的数据库中，其中包含用户的个人资料等隐私的数据都存放在数据库中，一旦数据库被攻陷，就会导致用户的隐私产生泄漏，造成很严重的影响；
2）恶意代码：恶意代码是指在运行过程中会对系统造成不良影响的代码库，攻击者一般会将这些代码嵌入到注释中，脚本一旦在系统中运行，就会对系统造成严重的后果；
3）非授权访问：对于一个系统来说，会有各种权限的管理者，比如超级管理员，对该系统有着最高的操作权限，一般管理员对该系统有部分的操作权限。非授权访问指的就是攻击者在未经授权的情况下不合理的访问本系统，攻击者欺骗系统，进入到本系统中对本系统执行一些恶意的操作就会对本系统产生严重的影响。

试题四（25分）

本题主要考查分布式架构中数据库和缓存双写一致性的架构策略和方案。

Redis是企业级系统高性能、高并发、高可用架构中非常重要的一个环节。Redis主要解决了关系型数据库并发量低的问题，有助于缓解关系型数据库在高并发场景下的压力，提高系统的吞吐量。而在Redis的实际使用过程中，难免会遇到缓存与数据库双写时数据不一致的问题，这是架构策略必须要考虑的问题。

【问题1】

参考答案：

在高并发条件下存在不同线程间网络延迟不同的情况，且缓存和数据库数据不同写入请求的速

度也存在差异，并且缓存和数据库删除和写入均存在失败的可能性，这些会导致解决思路无法解决数据同步和不一致性问题。

(a)读数据库，
(b)写缓存
(c)数据库
(d)更新缓存key值/删除缓存key值/使缓存key值失效。

答案解析：

在缓存和数据库双写过程中：

如果是先修改数据库，再删除缓存的方案，当删除缓存失败时数据库中是新数据，缓存中是旧数据，出现数据不一致。

如果先删除缓存，再修改数据库。缓存读不到数据，查数据库更新缓存的时候就拿到了最新的库存数据。

如果删除缓存成功了，而修改数据库失败了，那么数据库中依旧是旧数据，缓存中是空的，那么数据不会不一致。

【问题2】

参考答案：

存在问题：空值缓存需要更多的键，浪费内存空间。

解决思路：查询缓存前，对key值进行过滤，只允许系统中存在的key进行后续操作（例如采用key的 bitmap进行过滤）。

答案解析：

缓存穿透是指缓存和数据库中都没有的数据，而用户或攻击者不断发起请求会导致缓存数据库压力过大。缓存穿透的常规策略有：

1.接口层增加校验，如用户鉴权校验，键校验；
2. 缩短无效键有效时间，以防止攻击用户的暴力攻击。

【问题3】

参考答案：

1.搭建高可用Redis集群，正式部署前提前进行数据预热，在大并发访问前加载缓存键并尽量均匀分布缓存过期时间；
2.将热点数据设置为永不过期，开启Redis的持久化功能，当Redis启动时，从磁盘恢复数据到缓存中。

答案解析：

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至宕机。缓存雪崩的常见策略有：

1. 缓存数据的过期时间随机设置，防止同一时间大量数据过期现象发生；
   2.在分布式缓存数据库部署条件下，将热点数据均匀分布在不同的缓存数据库中；
   3.热点数据设置为永不过期。

试题五（25分）

本题考查高性能、高并发、高可用的分布式系统架构设计实践相关知识。

在当前的技术环境下，高性能、高并发、高可用的三高架构设计是众多技术企业需要在日常工作中经常面对的常见架构需求。这些需求的常见架构策略有：分层、冗余、分隔、异步通信、分布式、安全、自动化、集群、缓存、微服务等。

【问题1】

参考答案：

性能：（1）、（2）、（6）

安全性：（5）

可用性：（3）、（7）

易用性：（4）、（8）

答案解析：

质量属性归类，是需求分析和架构设计阶段的主要工作之一。根据对相关质量属性的定义和含义，题干中：(1)系统应支持大于50个终端设备的并发请求，(2)系统应能够实时识别车牌，识别时间应小于1s，(6)独立事务操作响应时间应小于3s，描述的是系统的性能属性；(5)可抵御常见SQL注入攻击，描述的是系统的安全性属性；(3)系统应7*24小时工作，(7)系统在故障情况下，应在1小时内恢复，描述的是系统的可用性属性；(4)具有友好的用户界面，(8)新用户学习使用系统的时间少于1小时，描述的是系统的易用性属性。

【问题2】

参考答案：（1）d（2）e（3）i（4）h（5）g（6）f（7）a

答案解析：三层架构就是为了符合”高内聚，低耦合“思想，把各个功能模块划分为表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）三层架构。

由于在高并发环境下，由于无法及时完成同步处理，请求往往会发生堵塞而直接导致无数的行

锁表锁，甚至最后请求会堆积过多触发连接数超过上限的错误。通过使用消息队列可以异步处理请求，从而缓解系统的压力。该案例中采用Kafka分布式消息队列。

缓存是分布式系统中的重要组件，主要解决高并发，大数据场景下，热点数据访问的性能问题。提供高性能的数据快速访问。本案例中采用Redis键值数据库缓存。

【问题3】

参考答案：

SOL注入攻击，就是通过把SOL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

可以通过以下方式抵御 SQL 注入攻击：

1、使用 Prepared Statement
2、使用存储过程
3、验证输入/过滤输入
4、专业的安全产品

答案解析：

SQL注入即是指应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。

SQL注入的主要防范措施包括：

分级管理：对用户进行分级管理，严格控制用户的权限。

参数校验：编写 SQL 时禁止直接传值入 SQL，必须通过设置参数传递变量值。参数过滤：对参数值预过滤敏感内容，如 and, or, select, 分号，双引号等。安全参数：使用编程语言中提供的数据库操作安全参数的强制执行检查特性。漏洞扫描：利用 SQL 漏洞扫描工具及时扫描系统存在的相应漏洞。

被访数据输入必须经过严格的验证才能进入系统，拒绝未通过验证的输入直接和不：对数据库敏感信息进行加密，传统加密方法包括对称加密、非对称加密和不可逆加密。

5.7 2018下半年

试题一

本题考查软件系统架构设计相关知识。

此类题目要求考生能够理解影响软件系统架构设计的系统需求，掌握需求的类型和具体需求对于系统架构设计选择的影响。在系统后期设计和实现阶段，非功能性需求指标需要进一步细化，系统非功能性需求对于系统架构设计的影响变得越来越重要。系统架构设计决策包括基于服务器、基于客户端、瘦客户端服务器、胖客户端服务器等不同类型。主要影响架构设计的需求包括操作性需求(技术环境需求、系统集成需求、可移植性需求、维护性需求)、性能需求(速度需求、容量需求、可信需求)安全性需求(系统价值需求、访问控制需求、加密/认证需求、病毒控制需求)、文化需求(多语言需求、个性化定制需求、规范性描述需求、法律需求)等。系统架构设计师在系统架构设计阶段，需要有针对性的对系统非功能性需求进行分析，综合确定系统的架构设计决策。

【问题1】

参考答案：

(1)操作性需求：指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求。
(2)性能需求：针对系统性能要求的指标，如吞吐率、响应时间和容量等。
(3)安全性需求：指为防止系统崩溃和保证数据安全所需要采取的保护措施的要求，为系统提供合理的预防措施。
(4)文化需求：指使用本系统的不同用户群体对系统提出的特有要求。

答案解析：本问题考查考生对影响系统架构设计决策的非功能性需求分类的理解和掌握情况。操作性需求是指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求；性能需求是针对系统性能要求的指标，如吞吐率、响应时间和容量等；安全性需求指为防止系统崩溃和保证数据安全所需要采取的保护措施的要求，为系统提供合理的预防措施；文化需求是指使用本系统的不同用户群体对系统提出的特有要求。

【问题2】

参考答案：

(1)(b)、(d)
(2)(c)、(f)
(3)(e)、(g)
(4)(a)、(h)

答案解析：本问题考查考生对具体系统需求类别的掌握情况。“用户界面支持用户的个性化定制”和“系统支持用户选择汉语、英语或法语三种语言之一进行操作”分别对应于个性化定制需求和多语言需求，属于文化需求类别；“系统需要支持当前主流的标准和服务，特别是通信协议和平台接口”和“系

统具有故障诊断和快速恢复能力”分别对应于可移植性需求和维护性需求，属于操作性需求类别；“用户操作的响应时间应不大于3秒，竞拍板块不大于1秒”和“系统需要支持不低于2GB的数据缓存”分别对应于速度需求和容量需求，属于性能需求类别；“用户密码需要加密传输”和“用户操作停滞时间超过一定时限需要重新登录验证”分别对应于加密/认证需求和访问控制需求，属于安全性需求。

【问题3】

参考答案：瘦客户端C/S架构能够更好地满足系统需求中的(a)、(b)、(d)和(h)。

答案解析：本问题考查考生对非功能性需求影响架构设计决策的掌握情况。在非功能性需求中，“用户界面支持用户的个性化定制”“系统需要支持当前主流的标准和服务，特别是通信协议和平台接口”“系统具有故障诊断和快速恢复能力”“系统支持用户选择汉语、英语或法语三种语言之一进行操作”等需求决定系统设计中适合采用瘦客户端服务器架构。

试题二

本题主要考查软件系统建模方法的基本知识及其应用，包括三种模型驱动的开发方法：结构化方法、信息工程方法以及面向对象方法。

【问题1】

参考答案：

外部实体：E1：房主E2：租赁者

顶层加工：P1：登记房主信息 P2：登记房屋信息 P3：登记租赁者信息 P4：查询待租赁房屋信息 P5：安排租赁者看房 P6：变更房屋状态

数据存储：D2：租赁者信息文件 D1：房主信息文件 D3：房屋信息文件 D4：看房记录文件

答案解析：

本问题考查结构化方法中结构化分析阶段的模型数据流图(DFD)。数据流图中的基本图形元素包括数据流(data flow)、加工(process)、数据存储(data store)和外部实体(external agent)。其中，数据流、加工和数据存储用于构建软件系统内部的数据处理模型；外部实体表示存在于系统之外的对象，用来帮助用户理解系统数据的来源和去向。

问题要求将图2-1中缺失的外部实体、数据存储和加工补充完整。

外部实体可以是和系统交互的人或角色，以及和系统交互的外部系统或服务。根据题目中的描述，与本系统进行交互的角色是房主和租赁者。根据E1和P1之间的数据流“房主信息”，结合题目描述可知，E1表示的是房主，E2表示的是租赁者。

题目的描述中已经明确给出了系统的6个功能，需要将这些功能与加工 $\mathrm{P1}\sim \mathrm{P6}$ 进行对应，这

需要借助于各个加工的输入输出数据流进行分析。根据E1和P1之间的数据流“房主信息”可知，这条数据流符合“登记房主信息”功能的描述，因此可以确定P1是“登记房主信息”，同时可以确定D1是“房主信息文件”。

E1和P2之间的数据流“房屋信息”“费用单”，这些都与房屋登记相关，因此P2是“登记房屋信息”。同时可以确定，D3对应的是“房屋信息文件”。同理，根据数据流及题干描述，可以推断出：P3对应“登记租赁者信息”、P4对应“查询待租赁房屋信息”、P5对应“安排租赁者看房”以及P6对应“变更房屋状态”。

【问题2】

参考答案：

(1)房主

(2)房屋

(3)房屋类型

(4)租赁者

(5)看房安排

答案解析：

本问题考查信息工程方法中的模型E-R图。E-R图中包含两个主要元素：实体和联系。实体是现实世界中可以区别于其他对象的“事件”或“物体”。本题要求补充图2-2中的实体。

根据题目描述和实体之间的联系可知，(1)和(2)分别对应房主和房屋，两者之间的联系为“房主拥有房屋”。同理可以推断出， $(3)\sim (5)$ 分别是实体“房屋类型”“租赁者”和“看房安排”。

【问题3】

参考答案：

(1)信息工程方法中的“实体”描述的是数据以及该数据的相关属性。面向对象方法中的“类”是数据和行为的封装体。
(2)Essential Use Cases 和 Real Use Cases 是按照开发阶段来进行划分的。Essential Use Cases 是在面向对象分析阶段使用的，Real Use Cases 是在面向对象设计阶段使用的。

Essential Use Cases 描述的是用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。

Real Use Cases 描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。

答案解析：

本问题考查面向对象方法中的基本概念。

信息工程方法中的“实体”描述的是数据以及该数据的相关属性。面向对象方法中的“类”是数据和行为的封装体。

Essential Use Cases 和 Real Use Cases 是按照开发阶段来进行划分的。Essential Use Cases 是在面向对象分析阶段使用的，Real Use Cases 是在面向对象设计阶段使用的。Essential Use Cases 描述的

是用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。

Real Use Cases 描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。

试题三

近年来，微电子技术发展带动了计算机领域技术不断更新，嵌入式系统已从单一架构向着满足网络化、智能化和综合化要求的新架构方向发展，开放、组件和智能已成嵌入式系统主要特征，嵌入式系统的广泛使用、使得其承载任务变得愈加繁重、结构变得愈加复杂、软件变得愈加庞大。其嵌入式实时产品已将由简单型系统演变到复杂型系统，从而在嵌入式实时系统中引发出了简单任务(simple task)和复杂任务(complex task)的区分。本题主要考查考生对嵌入式系统的新型架构知识的掌握程度，通过概念区分和实例分析，进一步考查考生对新知识的掌握能力以及对问题分析和总结能力。

本题目要求考生根据自己已从事过或将要从事的嵌入式系统的软件架构的有关相关知识，认真阅读题目对技术问题的描述，经过分析、分类和概括等方法，从中分析出题干或备选答案给出的术语间的差异，正确回答问题1到问题2所涉及的各类技术要点。

【问题1】

参考答案：

(1)(c)

(2)(d)

(3)(0)

(4)(p)

(5)(g)

(6)(h)

(7)(k)

(8)(1)

(9)(i)

(10)(j)

(11)(n)

(12)(m)

(13)(e)

(14)(f)

答案解析：

嵌入式系统是以应用为中心、以计算机技术为基础、软硬件可剪裁、适用应用系统对功能、可靠性、成本、体积、功耗严格要求的专用计算机系统。在过去嵌入式系统一般是为某个应用系统专门定制生产的，其系统特征是相互独立，功能单一、时序简单，我们通常称过去嵌入式系统为简单系统。而随着当前网络化、智能化和综合化需求的推进，嵌入式系统结构发生了重大变化，其通用性、开放性、标准化和组件化已成潮流，一台嵌入式系统不再承担单一功能，而是要赋予嵌入式系统处理众多事物，因而，系统结构的复杂性增加，处理任务的机理、状态和行为复杂性增加，我们通常称现在的嵌入式系统为复杂系统。简单系统中运行任务为简单任务，复杂系统中运行任务为复杂任务。

简单任务和复杂任务的特征区分主要表现以下十个方面：

(1)静态/动态特性：简单任务的时序关系是确定不变的，不会随时间偏移而变化。而随着复杂系统任务多样化发展，复杂任务将会随着时间、状态变化而变化。

(2)连续性/非连续性：简单任务仅仅考虑变量的随机性，而不考虑数据的继承性。而复杂任务由于受环境影响，其变量域需要考虑时间上连续特性，及数据的继承关系。
(3)系统间的独立性：简单任务由于功能单一，仅仅需要考虑内部任务间交联关系，具备独立性。而复杂任务间有很高的交互操作，要把一个任务的行为隔离开是非常困难的。
(4)顺序/并行性：简单任务由于功能单一、时序简单，通常情况下任务是顺序执行的，缺少并行性。而复杂任务功能、状态复杂，其属性与的时间紧密相关，必然存在许多并行执行因子，并行性强。
(5)单一/混合性：简单任务由于功能单一，其内部算法、执行策略都是单一的、不会随状态变迁而改变。而由于复杂任务的多样化，其任务内会存在不同构型、策略和算法，甚至对于不同状态任务需要综合考虑影响因子后方能决策，其混合性比较强。
(6)工作原理：简单任务执行时仅仅考虑上下因果关系，无须考虑结果。而复杂任务必须考虑根据上下文反馈信息来决策处理流程。
(7)线性/非线性：简单任务执行的功能一般呈现线性关系，功能间的上下关系是线性的。而复杂任务必须考虑根据多个上下文功能的结果决策处理流程，是非线性的。
(8上下文相关性：简单任务由于功能简单并呈现线性特征，其功能原理必然与上下文无关。而复杂任务属于非线性特征，其功能原理必然与上下文相关。
(9)规律/不规律：简单任务的特征是规则整齐，原则清晰。而复杂任务由于上下文相关，其规则与上下文存在关系，缺少规律性。
(10)表面属性：简单任务对外特征明显，比较好识别。而复杂任务由于其多样化，其外表特征被覆盖或抽象，对外表现不明显，不好识别。考生可根据以上分析，充分理解了复杂任务的特征后，便可进行简单任务和复杂任务的特征判断。

【问题2】

参考答案：

BMTS是将从一个计算组件传输消息到另外一个或多个接收组件，这样的传输具有高可靠、低延迟和微小抖动等特点。

(1)事件触发消息(Event-triggered messages): 此类消息是在发送端出现某重要事件发生时产生的偶发消息。建立消息间不存在最小时间(minimum time)。此类消息从发送到接收之间的延迟是不能确定的。在发送产生时，BMTS可能要处理许多消息，要么在发送者或消息被丢失时做相应处理。
(2)速率约束消息(Rate-constrained messages): 此类消息是偶发性产生的，而不考虑发送者承诺消息不超出最大消息速率。在给定的故障假设条件内，BMTS 承诺不超过最大的传输时延(latency)。抖

动依赖于网络负载或最坏情况下的传输时延和最小传输时延的范围。

(3)时间触发消息(Time-triggered messages): 此类消息是指发送者和接受者遵循一个精确的时间片周期完成消息的发送与接收。在给定的故障假设条件内，BMTS 承诺消息将被在指定的时间片、确定的抖动条件下发送或接收消息。具有时间触发消息能力的网络总线：TTE 总线、FC 总线、AFDX 总线。

答案解析：

图3-1给出“腰”型通信模式架构风格是安全攸关系统比较流行的一种架构风格。此架构风格通过对数据通信方式的抽象，将复杂任务的非线性、并发、动态、上下文紧密相关等特征进行分解，解决了系统不同协议、不同硬件和不同结构混合组成所带来的复杂性问题。基本消息通信(BMTS)服务是将复杂软件的通信协议与执行机制分离，用最少的服务解决计算组件间的传输消息，这样的传输具有高可靠、低延迟和微小抖动等特点。BMTS支持事件触发消息、速率约束消息和时间触发消息等三种基本消息传输。

(1)事件触发消息(Event-triggered messages): 此类消息是在发送端出现某重要事件发生时产生的偶发消息。建立消息间不存在最小时间(minimum time)。此类消息从发送到接收之间的延迟是不能确定的。在发送产生时，BMTS可能要处理许多消息，要么在发送者或消息被丢失时做相应处理。
(2)速率约束消息(Rate-constrained messages): 此类消息是偶发性产生的，而不考虑发送者承诺消息不超出最大消息速率。在给定的故障假设条件内，BMTS 承诺不超过最大的传输时延(latency)。抖动依赖于网络负载或最坏情况下的传输时延和最小传输时延的范围。
(3)时间触发消息(Time-triggered messages): 此类消息是指发送者和接受者遵循一个精确的时间片周期完成消息的发送与接收。在给定的故障假设条件内，BMTS 承诺消息将被在指定的时间片、确定的抖动条件下发送或接收消息。当前，具有时间触发消息能力的网络总线：TTE 总线、FC 总线、AFDX 总线。

试题四

本题考查数据库缓存的概念，以及数据库缓存方案的设计过程。

【问题1】

参考答案：

分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。

(1)丰富/多种数据结构；

(2)不支持；
(3)客户端哈希分片/一致性哈希；
(4)不支持；
(5)私有内存池/内存池；
(6)不支持。

答案解析：

常见的信息系统经常将数据保存到关系数据库中，应用软件对关系数据库进行数据读写，响应用户需求。但随着数据量增大、访问的集中，就会出现关系数据库的负担加重，数据库响应恶化，显示延迟等重大影响。

分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。

目前市场上常见的数据库缓存系统是MemCache和Redis。两种工具的优缺点如下表所示。

MemCache与Redis能力比较

【问题2】

参考答案：

李工采用的方案中，采用MemCache作为缓存系统，但MemCache无法进行持久化，数据不能备份，只能用于缓存使用，数据全部存在于内存，一旦重启数据会全部丢失。刘工的方案中，采用Redis作为数据库缓存，解决了该问题。

刘工的方案中，保留原有关系数据库，将Redis仅作为缓存，即热点数据缓存在Redis中，核心业务的结构化数据存储在原有关系数据库中。需要解决热点数据在原关系数据库和Redis的数据同步问题，由于Redis只作为缓存，因此给出原关系数据库到Redis的同步方案即可。该方案的基本操作如下。

1.读操作。读缓存Redis，如果数据不存在，从原关系数据库中读数据，并将读取后的数据值写入到Redis；
2.写操作。写原关系数据库，写成功后，更新或者失效掉缓存Redis中的值。

答案解析：

本问题考查两种工具对数据可靠性和一致性的支持，并考查方案的设计能力。

MemCache 无法进行持久化，数据不能备份，只能用于缓存使用，数据全部存在于内存，一旦重启数据会全部丢失。Redis 支持数据的持久化。因此李工的方案存在数据可靠性和一致性问题，而刘工的方案解决了该问题。

刘工的方案中，采用Redis作为缓存，使得一份数据同时存储在缓存和关系数据库中，因此必须给出一个数据同步的方案。刘工的方案中，保留原有关系数据库，将Redis仅作为缓存，即热点数据缓存在Redis中，核心业务的结构化数据存储在原有关系数据库中。由于Redis只作为缓存，因此给出原关系数据库到Redis的同步方案即可。该方案的基本操作如下。

1.读操作。读缓存Redis，如果数据不存在，从原关系数据库中读数据，并将读取后的数据值写入到Redis；
2.写操作。写原关系数据库，写成功后，更新或者失效掉缓存Redis中的值。

【问题3】

参考答案：

Redis分布式存储的常见方案有：

1.主从(Master/Slave)模式；
2.哨兵(Sentinel)模式
3.集群(Cluster)模式。

Redis 集群切片的常见方式有：

1. 客户端实现分片。分区逻辑在客户端实现，采用一致性哈希来决定Redis节点。
   2.中间件实现分片。在应用软件和Redis中间，例如Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
2. 客户端服务端协作分片。Redis Cluster 模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务。

答案解析：

Redis为单点方案，使用时必须提供分布式存储的集群拓展能力。Redis分布式存储的常见方案有主从(Master/Slave)模式、哨兵(Sentinel)模式、集群(Cluster)模式。

Redis 集群切片的常见方式有：

(1)客户端实现分片方式，分区逻辑在客户端实现，采用一致性哈希来决定Redis节点。
(2)中间件实现分片方式，即在应用软件和Redis中间，例如Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
(3)客户端服务端协作分片方式，Redis Cluster 模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务。

试题五

本题考查Web系统架构设计相关知识及如何在实际问题中综合应用。

此类题目要求考生认真阅读题目对现实系统需求的描述，结合Web系统设计相关知识、实现技术等完成Web系统分析设计。

【问题1】

参考答案：

面向服务的体系架构(SOA)是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。SOA能帮助企业系统架构设计者以更迅速、更可靠、更高重用性设计整个业务系统架构，基于SOA的系统能够更加从容地面对业务的急剧变化。

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

答案解析：

本问题考查考生对于Web应用系统常用体系架构相关的掌握程度。SOA和ESB是Web应用系统架构的基础。其中，面向服务的体系架构(SOA)是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。SOA能帮助企业系统架构设计者以更迅速、更可靠、更高重用性设计整个业务系统架构，基于SOA的系统能够更加从容地面对业务的急剧变化。

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

【问题2】

参考答案：

(1)(c) (2)(i) (3)(h) (4)(e) (5)(g) (6)(j)

答案解析：

通过阅读题目中银行信息系统的实际需求可知，在信息整合的过程中，银行使用企业服务平台构建全行应用系统的整合平台。在纵向上，连接总分行各个系统；在横向上，连接各业务应用系统和业务系统等。企业服务平台采用分级部署的方式，包括两个部分：一部分是部署在总行系统间的企业服务平台；另一部分是部署在分行系统间的企业服务平台。这两个企业服务平台之间互联互通，形成企业应用集成的总体框架。

银行信息系统的SOA架构模型中，通过ESB进行连接整合，能很好地支撑各业务流程。在操作客户关系管理中，客户信息是分散在各个业务子系统中，是不能共享的，通过基于ESB的体系架构整合后，可以实现全方位的客户管理。客户经理可以通过整合后的客户关系管理系统一次性地查阅目标客户的基本信息、产品账户信息、地址联系信息、事件信息、资源信息、关系信息、风险信息，统计分析信息等，这就真正实现了以客户为中心的转变过程，摆脱了从前以账户为中心的局部模式。

因此，基于对系统需求的分析和面向服务的体系结构的知识，考生可从选项中选择相应选项，完成系统架构设计，包括系统分层设计、各层构件、连接件设计等。

基于SOA的银行信息系统完整架构设计图如图5-2所示。

图5-2 基于SOA的银行信息系统完整架构设计

【问题3】

参考答案：

XML加密模块、WS-Security、防火墙系统、安全检测、网络扫描。

答案解析：

SOA环境中，需要解决的安全问题包括(1)机密性：机密性又称为保密性，是指非法非授权用户访问数据，导致数据机密泄漏。在传输层和消息层对机密性的需求是不同的，可以依靠数据加密来保证数据机密性。(2)完整性：是指数据的正确性、一致性和相容性。保证数据的完整性可以通过数字签名来实现。(3)可审计性：审计是一种事后监视的措施，跟踪系统的访问活动，发现非法访问，达到安全防范的目的。不同的系统可能需要不同的审计等级。(4)认证管理：实际指的是服务请求者和服务提供者两者在服务调用的时候互相认证对方的身份，防止非授权非法实体来获取服务，是系统安全的第一道安全屏障。(5)授权管理：授权管理的目的是阻止Web服务的未授权使用。(6)身份管理：在SOA架构中，身份管理和传统系统中的身份管理比较相像。服务请求者和服务提供者两者的身份对两者来说是至关重要的，否则就会存在非法用户在服务请求者和服务提供者之间进行消息传递，太容易导致数据的泄密和篡改。

综上，为了保障系统的安全性，可通过XML加密模块、WS-Security、防火墙系统、安全检测、网络扫描等安全性策略。

5.8 2017下半年

试题一

本题考查软件架构评估方面的知识与应用，主要包括质量属性效用树和架构分析两个部分。

此类题目要求考生认真阅读题目对系统需求的描述，经过分类、概括等方法，从中确定软件功能需求、软件质量属性、架构风险、架构敏感点、架构权衡点等内容，并采用效用树这一工具对架构进行评估。

【问题1】

参考答案：

答案解析：

在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。质量属性效用树主要关注性能、可用性、安全性和可修改性等四个用户最为关注的质量属性，考生需要对题干的需求进行分析，逐一找出这四个质量属性对应的描述，然后填入空白处即可。经过对题干进行分析，可以看出：

(a)系统用户分为高级管理员、数据管理员和数据维护员等三类(系统功能需求);
(b)系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御(描述了安全性质量属性);
(c)正常负载情况下，系统必须在0.5秒内对用户的查询请求进行响应(描述性能质量属性);
(d)对查询请求处理时间的要求将影响系统的数据传输协议和处理过程的设计(一个质量属性会对多个设计决策造成影响，是敏感点);
(e)系统的用户名不能为中文，要求必须以字母开头，长度不少于5个字符(系统功能需求);
(f)更改系统加密的级别将对安全性和性能产生影响(一个质量属性会影响多个质量属性，是权衡点);
(g)网络失效后，系统需要在10秒内发现错误并启用备用系统(描述可用性质量属性);
(h)查询过程中涉及的桥梁与公路的实时状态视频传输必须保证画面具有 $1024 \times 768$ 的分辨率，40帧/秒的速率(描述性能质量属性)；
(i)在系统升级时，必须保证在10人月内可添加一个新的消息处理中间件(描述可修改性质量属性)；
(j)系统主站点断电后，必须在3秒内将请求重定向到备用站点(描述可用性质量属性);
(k)如果每秒钟用户查询请求的数量是10个，处理单个请求的时间为30毫秒，则系统应保证在1秒内完成用户的查询请求(描述性能质量属性)；
(1)对桥梁信息数据库的所有操作都必须进行完整记录(描述安全质量属性);
(m)更改系统的Web界面接口必须在4人周内完成(描述可修改性质量属性);
(n)如果“养护报告生成”业务逻辑的描述尚未达成共识，可能导致部分业务功能模块规则的矛盾，影响系统的可修改性(这是一个潜在的架构风险)；
(o)系统必须提供远程调试接口，并支持系统的远程调试(描述可测试性质量属性)。

【问题2】

参考答案：

系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。敏感点是指为了实现某种特定的质量属性，一个或多个系统组件所具有的特性。权衡点是指影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性。题干描述中，

(n)描述的是系统架构风险；
(d)描述的是敏感点；
(f)描述的是权衡点。

答案解析：

首先需要理解架构风险、敏感点和权衡点的概念，然后需要对题干的描述进行分析，选出对架构风险、敏感点和权衡点的描述。

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

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

权衡点是指影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性。

试题二

本题考查软件系统架构设计相关知识及应用。

此类题目要求考生能够理解软件系统架构设计模式，掌握常用系统架构设计的模型和方法。MVC(模型-视图-控制器)设计模式是一种目前广泛流行的软件设计模式，已经成为JavaEE平台上推荐的设计模式。MVC用一种业务逻辑、数据界面显示分离的方法组织代码，将业务逻辑聚集到一个构件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC强制性地将一个应用的输入、处理和输出流程按照视图、控制器和模型的方式进行分离，形成了控制器、模型和视图三个核心模块。该题目针对高校数字化教育教学资源共享平台的系统需求，主要考查考生对于MVC设计模型和JavaEE架构的掌握情况。

【问题1】

参考答案：

MVC架构包含的三种元素是：模型、视图、控制器。模型负责提供操作数据对象；视图负责提供用户操作界面；控制器负责按照输入指令和业务逻辑操作数据对象，并产生输出。

(1)JSP

(2)Servlet

(3)JavaBean

(4)Service

(5)DAO

答案解析：

本问题考查考生对MVC设计模式中各个元素的理解和掌握情况。

MVC模式包含的三种元素是：模型、视图、控制器。模型负责提供操作数据对象；视图负责提供用户操作界面；控制器负责按照输入指令和业务逻辑操作数据对象，并产生输出。在图2-1中所设计JavaEE软件架构中，与浏览器直接通过HTTP交互的是视图层构件，包括JSP和Servlet，而Servlet一般用来接收用户输入消息，执行业务逻辑操作后转发用户请求，JSP负责组织消息内容并为用户产生响应页面的HTML数据流。对于复杂业务逻辑需要交给控制器构件来完成，Servlet将请求消息转发给后端负责业务逻辑处理的JavaBean进行处理，JavaBean利用数据访问Service所返回的数据响应客户请求。一般对于持久化存储的数据，Service需要调用数据访问持久层的数据模型(DAO)来实现数据的获取和修改。

【问题2】

参考答案：

EJB构件中的Bean分为：

(1)Session Bean(会话构件)负责处理客户与服务端交互的业务逻辑；
(2)Entity Bean(实体构件)表示数据库中存在的业务实体；
(3)MessageDrivenBean(消息驱动构件)用于接收异步JMS消息。

答案解析：

本问题考查考生对JavaEE软件架构的掌握情况。

Java EE架构中的构件主要包括客户端构件和服务端构件，客户端构件包括JSP、Servlet、HTML和客户端显示资源等，服务端构件主要是企业级Java构件EJB，EJB构件中的Bean按照其功能可以分为：(1)Session Bean(会话构件)负责处理客户与服务端交互的业务逻辑；(2)Entity Bean(实体构件)表示数据库中存在的业务实体；(3)Message Driven Bean(消息驱动构件)用于接收异步JMS消息。

【问题3】

参考答案：(1)有状态构件：(a)、(d)；(2)无状态构件：(b)、(c)、(e)。

答案解析：

本问题考查考生对Java EE架构中会话构件(Session Bean)的掌握情况。

会话构件负责维护客户端与服务端的交互状态，按照是否跨方法调用保存客户端与服务端的交互状态可以分为有状态(Stateful)会话构件和无状态(Stateless)会话构件，前者在交互过程中需要保存客户端与服务端交互的中间状态数据，一般在实现类中有自身的属性用于存储中间状态数据，无状态会话构件则不需要保存客户端与服务端的交互状态数据，客户端每次发起的请求相互独立，不会对服务端状态产生影响，因此服务端类不需要保存中间状态数据。身份认证构件完成初次身份认证后需要在服务端记录客户端的身份信息，在线编辑构件需要在操作过程中记录前一次编辑的操作结

果，所以两者需要设计为有状态会话构件。资源发布、资源检索和统计分析构件对客户端多次请求均保持一致处理过程和结果，所以应设计为无状态会话构件。

首先理解有无状态的含义，就看前后请求之间是否有关联和依赖。然后身份认证构件是有状态的，比如里面的单点登录，实现这个功能必须在服务端记录客户之前登录的身份信息（前后登录有关联和依赖）。在线编辑构件是有状态的，在编辑过程中，编辑器会将编辑的内容发送到服务端保存，以便下次打开的时候展示出之前编辑的内容（前后编辑有关联和依赖）。资源发布构件是无状态的，前后两次资源发布没什么关联和依赖。资源检索构件是无状态的，前后两次检索没什么关联和依赖，如 $\mathrm{id} = 1$ 和 $\mathrm{id} = 2$ 的检索， $\mathrm{id} = 2$ 的检索不需要依赖 $\mathrm{id} = 1$ 的检索结果吧。统计分析构件是无状态的，和搜索类似，两次统计（如求count）之间无关联和依赖。这个题靠个人经验和理解。

试题三

随着微电子、计算机和计算方法等技术的突飞猛进的发展，人工智能、物联网和机器人已成为当前工业界和科技界广泛讨论的热门话题。机器人技术最先已从科学研究领域走向了工程化实用，而机器人操作系统则是机器人中的关键部件，它管理着机器人的各种行为、状态和资源分配等。

本考题重点考查考生对当前比较流行的技术的掌握程度，区分传统操作系统知识与机器人操作系统的差异，请考生认真阅读题目对机器人操作系统问题的描述，经过分析、概括等方法，从中分析出题干或备选答案给出含义，正确回答问题中涉及的各类技术要点。

【问题1】

参考答案：

共同点：ROS和嵌入式实时操作系统都属于嵌入式操作系统中的不同类型，它们在核心操作系统功能、硬件抽象、底层驱动、程序间消息传递等方面存在共同点。

从实时性方面看，嵌入式实时操作系统关注的是：当外界事件或者数据产生时，能够接受并以足够快的速度予以处理，其处理的结果又能在规定的时间之内来控制生产过程或对处理系统做出快速响应；ROS 关注的是：采用点对点设计方法、以服务和节点管理器方式构建系统，便于代码复用，使得执行程序可以各自独立地设计，松散地、实时地组合起来。虽然 ROS 集成了实时代码，但它本身并不具备实时性。

从任务通信方面看，嵌入式实时操作系统主要关注单节点内采用信号、事件、消息队列和共享存储等方式实现任务间的通信；ROS是一种多节点跨平台模块化通信机制。它用节点(Node)的概念表示一个任务，不同节点之间通过事先定义好的格式(包括主题(Topic)、服务(Service)、动作(Action))来实现消息通信的。

答案解析：

机器人操作系统是近年来在嵌入式操作系统领域发展起来的一种操作系统，它提供类似于操作系统所提供的功能，包括硬件抽象描述、底层驱动程序管理、公用功能的执行、程序间的消息传递、程序算法包管理，它也提供一些工具程序和库用于获取、建立、编写和运行多机整合的程序。机器人操作系统还提供了库和工具来帮助软件开发者创建机器人的应用程序。

机器人操作系统与传统嵌入式实时操作系统的设计目标存在着很大区别，传统嵌入式实时操作系统仅仅关注的是：当外界事件或者数据产生时，能够接受并以足够快的速度予以处理，其处理的结果又能在规定的时间之内来控制生产过程或对处理系统做出快速响应；而机器人操作系统主要设计目标是便于机器人研发过程中的代码复用，因此，机器人操作系统是一种分布式的进程框架，使得执行程序可以各自独立地设计，松散地、实时地组合起来。这些进程可以按照功能包和功能包集的方式分组，可以很容易地分享和发布。机器人操作系统的主要特点可归结为以下几点：

(1)点对点设计：通过点对点设计以及服务和节点管理器等机制可以分散由于计算机视觉和语音识别等功能带来的实时计算压力，这种设计能够适应服务机器人遇到的挑战。
(2)不依赖编程语言。机器人操作系统应支持多种编程语言。C++、Python和Lisp语言。为了支持多语言编程，机器人操作系统一般采用一种中立的接口定义语言来实现各模块之间的消息传递。
(3)精简与集成：机器人操作系统一般不修改用户的main函数。所以代码可以被其他的机器人软件使用，它可以很容易和其他的机器人软件平台集成。
(4)便于测试：机器人操作系统很容易集成调试和分解调试。
(5)规模：机器人操作系统适用于大型运行系统和大型程序开发。

通过以上说明，考生完全可以分析出：机器人操作系统是以点对点设计方法、以服务和节点管理器方式构建系统，便于代码复用，使得执行程序可以各自独立地设计，松散地、实时地组合起来等能力为其工作机理。与传统的操作系统存在着本质差异。

【问题2】

参考答案：

表 3-1 OS 三类通信的主要特点

答案解析：

机器人操作系统通常采用了多节点跨平台模块化通信机制。它用节点(Node)的概念表示个任务，不同节点之间通过事先定义好的格式来实现消息通信的，应用程序间具备主题(Topic)、服务(Service)和动作(Action)三类通信。

(1)主题：消息通过一个带有发布和订阅功能的传输系统来传送。一个节点通过把消息发送到一个给定的主题来发布一个消息。主题是用于识别消息内容的名称。一个节点对某一类的数据感兴趣，它只需要订阅相关的主即可，一个主题可能同时有许多的并发主题发布者和主题订阅者，一个节点可以发布和订阅多个主题。一般来说，主题发布者和主题订阅者不知道对方的存在。发布者将信息发布在一个全局工作区内，当订阅者发现该信息是它所订阅的，就可以接收到这个信息。
(2)服务：发布/订阅模式是一种很弹性的通信范式。但是其多对多的传输方式是一种不适合于请求/回复交互的方式。请求/回复交互方式经常被用于分布式系统中。请求/回复通过服务来进行，其中服务被定义为一对消息结构：一个用于请求，一个用于回复。一个提供节点提供了某种名称的服务，一个客户通过发送请求信息并等待响应来使用服务。机器人客户端通常把这种交互表现为像一个远程程序调用。但是，基于服务的通信方式存在初期建立通信时，建立速度较慢。
(3)动作(action)是ROS提供应用程序间通信的一直较简单的方式，一般用于对某个事件、某个进程以及某个数据状态的监控，如：它可以监控长时间执行的进程。但是，从动作机制上看，设立监控机制比较复杂，需要应用程序间有握手信号。

【问题3】

参考答案：

(1)注册(Registration)

(2)数据(Data)

(3)发布(Publish)

(4)订阅(Subscribe)

(5) 订说 (Subscribe)

答案解析：

ROS架构是由多个各自独立的节点(组件)组成，并且各个节点之间可以通过发布/订阅(publish/subscribe)消息模型进行通信。例如，我们将一个特定传感器的驱动模块作为一个ROS节点，其将传感器数据发布(publish)到消息流。这些消息可能会被某些节点获取到，例如滤波器、记录器、更高级系统中的应用如导航、路径查找等节点。

通常，ROS启动于ROS Master。Master允许其他ROS中不同软件片(节点)查找对方或与对方交流。那样，我们就不必指定“发送传感器数据到IP为127.0.0.1的电脑”，我们只需要简单地告诉Node1发送消息到Node2。就是说，ROS节点间的数据通信都是以透明方式进行的。

问题3给出了一个简单机器人结构实例，就是考查考生对发布/订阅技术在ROS系统中的应用掌握程度。设想有一部相机安装在机器人上，我们希望可以从相机中或者笔记本上看到图像，同时让机器人也可以看到这些图像。

结构实例定义一个 Camera Node，用于和相机通信(驱动)，一个 Image Processing Node 运行在机器人上处理图像数据，一个 Image Display Node 用于将图像显示在屏幕上。开始阶段，所有节点(Node)都要注册到 Master 上。Master 可以认为是一个查询表，各个节点可以查询它要把消息发送到哪个节点。注册到 ROS Master 后，Camera Node 声明它要 Publish 一个 Topic 叫作/image data。另外两个节点(Image Processing Node and Image Display Node)声明他们 Subscribe 这个 Topic /image_data。因此，一旦 Camera Node 收到 Camera 发送的数据，就立即将数据/image data 直接发送到另外两个节点。

如果 Image Processing Node 想主动获取 Camera Node 收到的数据，ROS 定义了 Services 用于解决这个问题。节点可以在 ROS Master 上注册一个特定的 service，就像注册它的消息(topic)一样。在我们的例子中，Image Processing Node 第一次请求/image_data，Camera Node 将收集 Camera 的数据，然后发送给 Image Processing Node。

考生在理解了上述描述的基础上，就可以很容易补充图3-1中(1)～(5)处给出空白，显然，Image Display Node需要先向Master“注册(1)”，而摄像头是将“数据(2)”传输到Camera Node；Camera Node收到数据后向外部节点进行图像数据消息“发布(3)”，最后，Image Processing Node和Image Display Node想要接收图像数据信息，必须实现开展“订阅(4)(5)”活动。

试题四

本题考查数据库访问接口/数据访问层的基本概念，以及针对实际问题进行相应设计。

数据库访问接口是指应用程序与数据库之间的连接部分，能够有效降低应用程序与数据库之间连接的开发和维护难度，使得数据库迁移的工作量大大降低。在层次体系架构中，经常将其称为数

据访问层。

此类题目要求考生认真阅读题目对现实问题的描述，在了解数据库访问接口基本概念的前提下，针对具体问题，设计合理的数据库访问接口，并能够给出具体的设计理由。

【问题1】

参考答案：

在线访问方式：在程序中通过数据库提供的程序接口直接访问数据。其优点是灵活，性能高。缺点是需要程序员对数据库有较深了解，同时数据模型的变更会导致相应程序的变更，数据库迁移困难。

ORM方式：是一种工具或平台，能够提供应用程序中的数据与关系数据库中的记录之间的相互转换，使得程序无须考虑记录，仅考虑对象。优点是简化程序开发，降低了对程序员关于数据库的知识要求，使得程序员可以仅关注于业务逻辑；缺点是不太容易处理复杂查询语句，性能比直接使用SQL要差。

根据题干说明，原电子商务平台功能简单，没有复杂业务功能，数据访问仅需要提供基本功能即可；软件企业的程序开发人员缺乏数据库开发经验；ORM的方式的数据接口简单清晰，开发周期短，因此采用ORM方式是较好的选择。

答案解析：

数据访问层常见的访问方式有5种，分别是在线访问、DAO(Data Access Object)、DTO(Data Transfer Object)、离线数据模式、对象/关系映射(Object/Relation Mapping, ORM)。

在线访问是最基本的数据访问模式，也是最常用的。应用程序通过数据库提供的程序接口直接访问数据。其优点是灵活，性能高。缺点是需要程序员对数据库有较深了解，同时数据库的变更会导致相应程序的变更，数据库迁移困难。

ORM 是一种工具或平台，能够提供应用程序中的数据与关系数据库中的记录之间的相互转换，使得程序无须考虑记录，仅考虑对象。优点是简化程序开发，降低了对程序员关于数据库的知识要求，使得程序员可以仅关注于业务逻辑；缺点是不太容易处理复杂查询语句，性能比直接使用 SQL 要差。

根据题干说明，原电子商务平台功能简单，没有复杂业务功能，数据访问仅需要提供基本功能即可；软件企业的程序开发人员缺乏数据库开发经验；ORM方式的数据接口简单清晰，开发周期短，因此采用ORM方式是较好的选择。

【问题2】

参考答案：

根据题干说明，新的电子商务平台业务复杂，而且需要访问异构的数据源，也就是说需要访问不同类型的数据库。因此，需要增加新的数据库访问层来封装对数据库的访问，使得在应用程序设计时，不会因为数据库种类的不同而受到影响，尽量做到数据库无关。

(1)业务构件/业务组件；(2)DAL接口/数据访问接口；(3)DAL工厂/数据访问工厂。

答案解析：

数据在线访问模式提高了数据访问的性能，但同时导致了业务逻辑层与数据访问的职责混乱，一旦要求支持的数据库发生变化，或者需要修改数据访问的逻辑，由于没有清晰的分层，会导致项目做大的修改。而随着硬件系统性能的提高，以及充分利用缓存、异步处理等机制，分层式结构所带来的性能影响可以忽略不计。

根据题干说明，新的电子商务平台业务复杂，而且需要访问异构的数据源，也就是说需要访问不同类型的数据库。因此，需要增加新的数据库访问层来封装对数据库的访问，使得在应用程序设计时，不会因为数据库种类的不同而受到影响，尽量做到数据库无关。变化后的体系结构如图4-2所示。

图4-2

【问题3】

参考答案：

工厂设计模式定义了创建对象的接口，允许子类决定实例化哪个类，而且允许请求者无须知道要被实例化的特定类，这样可以在不修改代码的情况下引入新类。

优点是：(1)没有了将应用程序类绑定到代码中的要求，可以使用任何实现了接口的类；(2)允许子类提供对象的扩展版本。

工厂设计模式的应用场景有：(1)类不能预料它必须创建的对象的类；(2)类希望其子类指定它要创建的对象。

在数据访问层定义采用工程模式，定义统一的操纵数据库的接口，然后根据数据库的不同，由类工厂来决定实例化哪个类。在具体类中实现特定的数据库访问类。这样，就可以实现由客户端指定或根据配置文件来选择访问不同的数据库，从而实现应用程序与数据库无关。

答案解析：

在应用程序设计中，需要对数据库访问进行良好的封装，使其具有良好的可维护性，尽量使得应用程序与数据库无关。本题中，应用系统需要访问异构数据源，在应用程序中会存在多种数据访问接口。因此在实际开发中，需要对这些访问接口再做一次封装，这样可以减少操作数据库的步骤，减少代码编写量。工厂设计模式是使用的主要方法。

工厂设计模式定义了创建对象的接口，允许子类决定实例化哪个类，而且允许请求者无须知道要被实例化的特定类，这样可以在不修改代码的情况下引入新类。优点是：没有了将应用程序类绑定到代码中的要求，可以使用任何实现了接口的类；允许子类提供对象的扩展版本。工厂设计模式的应用场景有：类不能预料它必须创建的对象的类；类希望其子类指定它要创建的对象。

在数据访问层定义采用工程模式，定义统一的操纵数据库的接口，然后根据数据库的不同，由类工厂来决定实例化哪个类。在具体类中实现特定的数据库访问类。这样，就可以实现由客户端指定或根据配置文件来选择访问不同的数据库，从而实现应用程序与数据库无关。

试题五

本题考查Web系统架构设计相关知识及如何在实际问题中综合应用。

此类题目要求考生认真阅读题目对现实系统需求的描述，结合Web系统设计相关知识、实现技术等完成Web系统分析设计。

【问题1】

参考答案：

响应式Web设计(Responsive Web Design)的理念是：页面的设计与开发应当根据用户行为以及设备环境(系统平台、屏幕尺寸、屏幕定向等)进行相应的响应和调整。无论用户正在使用笔记本还是iPad，页面都应该能够自动切换分辨率、图片尺寸及相关脚本功能等，以适应不同设备；即页面应该有能力去自动响应用户的设备环境。响应式网页设计就是一个网站能够兼容多个终端，而不是为每个终端做一个特定的版本。减小为不断到来的新设备做专门的版本设计和开发的工作量。

响应式Web设计具体的实现方式包括媒体查询(media query)、流式布局(弹性布局、动态布局)、液态图片(弹性图片)等。

答案解析：

响应式Web设计(Responsive Web design)的理念是：页面的设计与开发应当根据用户行为以及设备环境(系统平台、屏幕尺寸、屏幕定向等)进行相应的响应和调整。

无论用户正在使用笔记本还是iPad，页面都应该能够自动切换分辨率、图片尺寸及相关脚本功能等，以适应不同设备；即页面应该有能力去自动响应用户的设备环境。响应式网页设计就是一个网站能够兼容多个终端，而不是为每个终端做一个特定的版本。减小为不断到来的新设备做专门的版本设计和开发的工作量。

响应式Web设计具体的实现方式包括媒体查询(media query)、流式布局(弹性布局、动态布局)、液态图片(弹性图片)等。

【问题2】

参考答案：(1)(d)；(2)(c)；(3)(f)；(4)(a)；(5)(e)；(6)(h)；(7)(g)；(8)(i)。

答案解析：

根据题目说明，综合王工和李工的建议，新构建的电子商务平台应采用增加镜像站点、CDN内容分发，同时结合负载均衡、缓存服务器、Web应用服务器、分布式文件系统、分布式数据库等方法完成系统架构设计。因为根据上述方法的特性和应用场景，可完成题目中给出的5层系统架构图。下面逐一进行分析。

内容分发采取了分布式网络缓存结构，通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的Cache服务器内，通过DNS负载均衡的技术，判断用户来源就近访问Cache服务器取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度，如同提供了多个分布在各地的加速器，以达到快速、可冗余地为多个网站加速的目的。

【问题3】

参考答案：

避免数据库单点故障：主服务器实时、异步复制数据到从服务器，当主数据库宕机时，可在从数据库中选择一个升级为主服务器，从而防止数据库单点故障。

提高查询效率：根据系统数据库访问特点，可以使用主数据库进行数据的插入、删除及更新等

写操作，而从数据库则专门用来进行数据查询操作，从而将查询操作分担到不同的从服务器以提高数据库访问效率。

答案解析：

分布式数据库系统是在集中式数据库系统的基础上发展起来的，是计算机技术和网络技术结合的产物。分布式数据库系统适合于单位分散的部门，允许各个部门将其常用的数据存储在本地，实施就地存放本地使用，从而提高响应速度，降低通信费用。分布式数据库系统与集中式数据库系统相比具有可扩展性，通过增加适当的数据冗余，提高系统的可靠性。在集中式数据库中，尽量减少冗余度是系统目标之一。其原因是冗余数据浪费存储空间，而且容易造成各副本之间的不一致性，而为了保证数据的一致性，系统要付出一定的维护代价，减少冗余度的目标是用数据共享来达到的。而在分布式数据库中却希望增加冗余数据，在不同的场地存储同一数据的多个副本，其原因是提高系统的可靠性、可用性当某一场地出现故障时，系统可以对另一场地上的相同副本进行操作，不会因一处故障而造成整个系统的瘫痪；提高系统性能系统可以根据距离选择离用户最近的数据副本进行操作，减少通信代价，改善整个系统的性能。

主从复制、数据分割、数据分片等是实现分布式数据库的主要手段和核心技术。其中，主从复制可以避免数据库单点故障，主服务器实时、异步复制数据到从服务器，当主数据库宕机时，可在从数据库中选择一个升级为主服务器，从而防止数据库单点故障。同时，提高查询效率：根据系统数据库访问特点，可以使用主数据库进行数据的插入、删除及更新等写操作，而从数据库则专门用来进行数据查询操作，从而将查询操作分担到不同的从服务器以提高数据库访问效率。

5.9 2016下半年

试题一

本题主要考查考生对于软件质量属性的理解、掌握和应用。在解答该问题时，需认真阅读题干中给出的场景与需求描述，分析该需求描述了何种质量属性，根据质量属性描述对其归类，并需要理解架构风险、敏感点和权衡点这些概念。

【问题1】

参考答案：

(1)f

(2)性能

(3)d

(4)g

(5)b

答案解析：

识别软件架构质量属性是进行架构设计的重要步骤。根据对相关质量属性的定义和含义，其中

“支持不同模型的自动转换。在初始需求中定义的机器性能条件下，对于一个包含50个对象的设计模型，将其转换为相应代码框架时所消耗时间不超过5秒”，这描述的是系统的性能属性；“能够连续运行的时间不小于240小时，意外退出后能够在10秒之内自动重启”描述的则是系统的可用性；“支持用户通过配置界面依据自己的喜好修改界面风格，包括颜色、布局、代码高亮方式等，配置完成后无须重启环境”描述的是系统的可修改性；“集成开发环境具有模块化结构，支持以模块为单位进行调试、测试与发布”描述的是系统的可测试性；“经过调研，手机应用开发人员更倾向于使用Windows系统，因此集成开发环境的界面需要与Windows平台上的主流开发工具的界面风格保持一致”描述的是系统的易用性。

【问题2】

参考答案：

(1)工具之间无直接交互，通过数据仓储间接交互
(2)流式数据
(3)数据驱动
(4)与数据仓储进行数据适配

答案解析：

对不同的架构设计决策是架构师必须具有的基本能力，根据题干要求：

(1)从交互方式方面看，管道-过滤器风格具有顺序结构或有限的循环结构；采用数据仓储风格时，工具之间无直接交互，通过数据仓储间接交互。
(2)从数据结构方面看，管道-过滤器风格具有数据驱动的特征，数据到来后就进行计算；数据仓储风格以文件或模型为主要数据结构。
(3)从控制结构方面看，管道-过滤器风格具有顺序结构或有限的循环结构；数据仓储风格则以业务功能驱动。
(4)从扩展方法方面看，管道-过滤器风格主要采用适配器方式实现扩展性；数据仓储风格中，每个工具需要与数据仓储进行数据适配。

【问题3】

参考答案：

(1)模型/数据库
(2)代码编辑工具
(3)数据格式转换器
(4)模拟器

答案解析：

本题目主要考查数据仓储风格的实际设计与应用。结合风格定义，从图中可以看出：位于核心位置的组件(1)应该是数据库/模型。根据题干描述，可以直接接入数据库的组件(2)应该是代码编辑工具。(3)和(4)对应题干描述“……集成环境应提供数据集成能力。集成开发环境还要支持以适配方式集成公司现有的应用模拟器工具”，因此应该分别填入数据格式转换器和模拟器。

试题二

本题考查面向对象系统建模的相关知识。

此类题目要求考生能够理解面向对象系统建模的基本概念和方法，并在应用系统开发中结合系统需求，利用面向对象建模技术构建系统的需求模型、分析模型和设计模型。UML是面向对象系统的标准建模语言，是一种定义良好、易于表达、功能强大的建模语言。UML在支持面向对象分析与设计的基础上，能够支持从需求分析开始的软件开发全过程。在UML建模过程中，通过建立系统用例模型和静态模型，搭建系统体系结构。用例模型属于系统的高级视图，按照面向对象的原则将系统要实现的行为划分为用例，并基于用例按照交互关系和时间产生顺序图；在用例模型的基础上抽象出系统的类，明确各模块之间的关系按照合适的粒度构建系统类图。对于复杂的交互过程，需要补充状态图、活动图和协作图等系统模型，对系统内部处理细节进行建模。该题目针对教学管理系统需求，主要考查考生对于用例图和类图进行系统建模的掌握情况。

【问题1】

参考答案：

参与者：学生、教师、管理员、时间、打印机。

答案解析：

本问题考查考生对用例建模中“参与者”元素的理解。参与者是为了完成一个事件而与系统交互的实体，参与者可以表示与系统接口的任何事物和任何人。这可以包括人(不仅仅是最终用户)、外部系统和其他组织，参与者位于建模的系统的外部。在识别参与者时，要注意参与者是与系统交互的所有事物，该角色的承担者除了人之外，还可以是其他系统和硬件设备，甚至是系统时钟。按照题目中给出的系统需求说明，从需求(3)、(4)、(5)中可以得到由人承担的参与者包括学生、教师、管理员；需求(6)可以得到的参与者是时间(系统时钟)和打印机。

【问题2】

参考答案：

用例之间的关系：泛化(Generalization)、包含(Include)和扩展(Extend)。

用例“登录系统”与用例“注册课程”之间的关系是包含(Include)关系；用例“参加考试”与用例“参加补考”之间的关系是扩展(Extend)关系。

答案解析：

本题考查考生对用例及其用例之间关系的理解。用例是系统中执行的一系列动作，这些动作生成特定参与者可见的价值结果。用例表示系统所提供的服务，它定义了系统是如何被参与者所使用的，描述了参与者为了使用系统所提供的某一个完整功能而与系统之间发生的交互过程。用例之间的关系主要有泛化(Generalization)、包含(Include)和扩展(Extend)。

(1)当可以从两个或多个用例中提取公共行为时，可以使用包含关系来表示。
(2)如果一个用例混合了两种或两种以上不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。
(3)当多个用例共同拥有一个类似的结构和行为的时候，可以将它们的共性抽象成父用例，其他的用例作为泛化关系中的子用例。

在题目要求中，用例“登录系统”是用例“注册课程”和其他用例执行的公共行为，两者是包含(Include)关系。用例“参加补考”是用例“参加考试”的一种分支和特殊场景，两者之间的关系是扩展(Extend)关系。

【问题3】

参考答案：

类之间的关系：关联(Association)、聚集(Aggregation)、组合(Composition)、泛化(Generalization)、依赖(Dependence)。

类 University 与类 Student 之间的关系是聚集(Aggregation)关系；类 University 和类 Department 之间的关系是组合(Composition)关系；类 Student 和类 Course 之间的关系是关联(Association)关系。

答案解析：

本题考查考生对类图及类之间关系的理解。类图主要用来描述系统的静态结构，是组件图和配置图的基础。每个用例对应一个类图，描述参与这个用例实现的所有概念类，而用例的实现主要通过交互图来表示。当确定类之后，要识别类与类之间的关系，主要包括关联(Association)、聚集(Aggregation)、组合(Composition)、泛化(Generalization)和依赖(Dependence)。

(1) 关联提供了类之间的结构关系，将多个类的实例连接在一起。
(2)依赖关系表示一个类的变化可能会影响另一个类。
(3)泛化关系描述了一般事物与该事物中的特殊种类之间的关系。
(4)聚集关系表示类之间整体与部分的关系，其含义是部分可能同时属于多个整体，两者生命周期

期可以不相同。

(5)组合关系表示类之间的整体与部分关系，部分只能属于一个整体，两者具有相同的生存周期。

在题目要求中，类 University 与类 Student 之间的关系是整体与部分关系，而且具有不同的生存周期，所以是聚集(Aggregation)关系。类 University 和类 Department 之间的关系是整体与部分的关系，两者具有相同的生存周期，所以是组合(Composition)关系。类 Student 和类 Course 之间为连接关系，所以属于关联(Association)关系。

试题三

本题考查嵌入式实时系统的基本概念和主要特征，在掌握基本概念基础上，针对安全关键系统的可靠性需求，区分错误、缺陷、故障和失效含义以及所处的场景。

此类题目要求考生根据自己已掌握的有关嵌入式系统的知识，认真阅读题目对实时性问题的描述，经过分析、分类和概括等方法，从中分析出题干或备选答案给出的术语间的差异，正确回答问题1到问题3所涉及的各类技术要点。

【问题1】

参考答案：

1.实时系统

一个实时系统是指计算的正确性不仅取决于程度的逻辑正确性，也取决于结果产生的时间，如果系统的时间约束条件得不到满足，系统将会出错。

或：

实时系统是指能及时响应外部事件的请求，在规定的时间内完成对该事件的处理，并控制所有实时任务协调一致运行的系统。

2.实时系统的主要特性

(1)时间敏感性

(2)并发性

(3)数值计算

(4)复杂性

(5)效能

(6) 可靠性

(7)安全性

(8)预测性

(9)交互作用

答案解析：

嵌入式系统是深埋于专用设备或系统中，对设备或系统的各类传感器进行管理与控制的系统，根据专用设备或系统的应用领域的不同，通常分为实时系统和非实时系统。比如大的可以是飞机、飞船、舰艇、机床等，小的可以是家用电器、手机、电子门锁等。一般来讲，设备运行对于时间特性具备一定敏感性的系统可称之为“实时系统”。因此，实时系统是“指计算的正确性不仅取决于程序的逻辑正确性，也取决于结果产生的时间，如果系统的时间约束条件得不到满足，系统将会出错。”(牛

津计算机字典)，或者“指能及时响应外部事件的请求，在规定的时间内完成对该事件的处理，并控制所有实时任务协调一致运行的系统。”上述两个定义均说明了任务正确的运行不仅与运算结果有关，而且也与运行时限有关。

实时系统的主要特征一般体现在以下8个方面：

(1)时间敏感性：任何实时系统对响应时间是极其关注的，要保证在所有条件下适当的时间产生适当的输出，在设计和实现方面是相当困难的。
(2)并发性：实时系统一般由处理器和一些公共外部相互作用的设备组成，这种结构隐含着天然的并行特征。
(3)数值计算：一般实时系统均采用了控制技术实现信息反馈与控制，因此处理器必须支持高速度、高精度和向量、浮点计算能力。
(4)复杂性：实时系统的核心是对外部真实事件的响应，而系统必须迎合这些外部事件的组合，这样就带来设计上的复杂性。因此，实时系统要使用语言或环境将这些复杂性分解为可有效管理的较小规模的组件、抽象数据结构、类和对象等。
(5)效能：实时系统是时间攸关的系统，其执行效率与其他系统相比尤为重要，有些情况，为了提高系统效能，往往要用低级程序设计语言(即汇编语言)控制和操作硬件接口或中断。因此，系统需要应答时间往往在毫秒或纳秒级，适当采用低级语言设计是非常必要的。
(6)可靠性和安全性：一般实时系统都是应用于生死攸关系统的(如飞机、高铁等)，一个系统的失效可能引起上亿元的经济损失，有些失效是不能挽回的。因此，实时系统的可靠性至关重要。在军事领域，我们必须在设计和执行系统时考虑系统失效的控制算法，尽可能地减少人为操作错误所引起的失效。预防被外部非法入侵而带来的关键数据泄漏和系统失效。
(7)预测性：实时系统是一种确定性要求极高的系统，要求对系统每一时刻的运行的行为、状态和结果都是可预计的。尤其是在系统发生错误后，其可能影响的系统失效也是可预测到的，并设计了系统失效后处理方法，如备份、手工操作等。
(8)交互作用：实时系统的本质是对外部事件的处理，必然带来了交互作用，并且系统还应根据外部事件的不同因素，自动适应环境的变化，因此，实时系统的智能化、自适应化是交互作用主要体现。

【问题2】

参考答案：

(1)强 (2)时间明确 (3)时间响应 (4)时限/反应时间

(5)输入/输出激励 (6)周期/零星/非周期 (7)时间触发 (8)事件触发

注：(2)、(3)可互换，(4)、(5)、(6)可互换，(7)、(8)可互换

答案解析：

实时系统是一种时间敏感性的系统，根据不同的应用环境和条件的不同，其时间敏感性要求各有差异，因此实时系统还可根据时间类别、时间需求和工作方式的不同，分类出不同的实时系统。比如按时间类别的时限要求程度不同，我们一般将具备毫秒级或纳秒级时限要求的系统称之为“强实时系统”，而将具备秒级以上的时限要求的系统称之为“弱实时系统”。本问题共给出了8个参考答案，主要考查考生在理解了时间类别、时间需求和工作方式三种场景分类的含义基础上，将8个参考答案分门别类地归纳到不同类型中。

针对按“时间类别”分类主要是以用户对时间敏感程度的高低划分。可归纳为“时限的危害程度”和“时间角色”两种类型，时限的危害程度可由“强实时”“弱实时”和“固定实时”三种；而时间角色可由“时间明确”和“时间响应”两种；

针对按“时间需求”分类主要是以系统对时间响应需求的紧迫程度划分。可归纳为“时限/反应时间”“输入/输出激励”和“周期/零星/非周期”三种；

针对按“工作方式”分类主要以系统对时间工作方式的触发条件划分。可归纳为“时间触发”和“事件触发”两类。

【问题3】

参考答案：

错误缺陷、故障和失效的定义：

(1)错误(error): 是指开发人员在开发过程中出现的失误、疏忽和错误。
(2)软件缺陷(defect): 是指代码中能引起一个或一个以上失效的错误的编码(步骤、过程、数据定义等)。
(3)软件故障(fault): 是指软件在运行过程中出现的一种不希望或不可接受的内部状态, 通常是由于软件缺陷在运行时引起并产生的错误状态。
(4)软件失效(failure): 是指程序的运行偏离了需求, 是动态运行的结果, 软件执行遇到软件中的缺陷时可能会导致软件的失效。错误、缺陷、故障和失效关系图填空:

(1)存在
(2)引起
(3)用户经历
(4)在开发过程中
(5)在产品中

(6)在运行时

答案解析：

系统可靠性是嵌入式实时系统的关键特性之一，安全攸关系统的设计必须关注系统的可靠性设计，要提高系统的健壮性必然要清楚错误(Error)、缺陷(Defect)、故障(Fault)和失效(Failure)基本概念和存在的环境与场景。

软件错误(Error)是指开发人员在开发过程中出现的失误、疏忽和错误而导致的设计缺陷；软件缺陷(Defect)是指代码中能引起一个或一个以上失效的错误编码，包括了步骤、过程、数据定义等方面；软件故障(Fault)是指软件在运行过程中出现的一种不希望或不可接受的内部状态，通常是由于软件缺陷在运行时引起并产生的错误状态；软件失效(Failure)是指程序的运行偏离了需求，是动态运行的结果，软件执行遇到软件中的缺陷时可能会导致软件的失效。

基于上述的定义，考生就不难回答图3-2所空缺的内容。

“错误”是“开发人员”在“开发过程中”产生；

“缺陷”是“在产品中”固有“存在”的；

“故障”是系统“在运行时”所“引起”；

“失效”是系统“在运行时”由“用户经历”感觉到的。

试题四

本题考查Web应用开发的知识及应用，主要是Web服务器端的架构知识，属于比较基础的题目。

【问题1】

参考答案：

原有基于Web服务器的脚本语言的解决方案，其实质是在Web服务器端放入一个通用的脚本语言解释器，负责脚本语言的解释执行。其存在的不足有：

1. 脚本语言嵌入在 HTML 文件中，使得 I/O、业务逻辑、数据处理等程序代码混杂在一起，使得开发、维护困难；
   2.系统采用Web服务器实现业务逻辑，系统的扩展性差，并发能力差，系统一旦繁忙，缺乏有效的手段进行扩充：
   3.系统缺乏有效的维护、管理工具。

答案解析：

本问题考查Web服务端的脚本开发知识。原有的Web服务器扩展接口的方式过于底层，对开发者的素质要求很高，往往需要懂得底层编程方法，了解HTTP协议，调试也很困难。因此开发者使

用一些脚本语言来进行Web开发，包括ASP、PHP等。其实质是在Web服务器端放入一个通用的脚本语言解释器，负责解释各种不同的脚本语言文件，其最大的优点是简化了开发流程，降低了对程序开发人员的要求。但是该方法也存在一些明显的缺点，主要包括：脚本语言嵌入在HTML文件中，使得I/O、业务逻辑、数据处理等程序代码混杂在一起，使得开发、维护困难；系统采用Web服务器实现业务逻辑，系统的扩展性差，并发能力差，系统一旦繁忙，缺乏有效的手段进行扩充；系统缺乏有效的维护、管理工具。

【问题2】

参考答案：

应用服务器是指通过各种协议把商业逻辑暴露给客户端的程序。它提供了访问商业逻辑的途径以供客户端应用程序使用。应用服务器为实现Web应用程序和系统资源的访问机制提供了一种简单、可管理的方式。它是一个开发、部署、运行、管理和维护的平台，可以提供软件“集群”功能，让多个不同的异构服务器协同工作、相互备份，满足企业级应用所需要的可用性、高性能、可靠性和伸缩性。

应用服务器通过分布式体系来保障系统在大负荷和长时间运行下的稳定性以及可扩展性：

(1)当系统处理能力不够时，通过简单增加硬件来解决，提供水平可扩展性；
(2)动态调整不同主机间的负载可以最大限度地利用资源，提供单机稳定性：
(3)动态调整主机工作职能，没有单点故障。

答案解析：

本问题考查应用服务器技术的基本概念。应用服务器技术是脚本语言开发技术之后出现的一种Web应用开发技术。应用服务器是指通过各种协议把商业逻辑暴露给客户端的程序。它提供了访问商业逻辑的途径以供客户端应用程序使用。应用服务器为实现Web应用程序和系统资源的访问机制提供了一种简单、可管理的方式。它是一个开发、部署、运行、管理和维护的平台，可以提供软件“集群”功能，让多个不同的、异构服务器协同工作、相互备份，满足企业级应用所需要的可用性、高性能、可靠性和伸缩性。

应用服务器通过分布式体系来保障系统在大负荷和长时间运行下的稳定性以及可扩展性：当系统处理能力不够时，通过简单增加硬件来解决，提供水平可扩展性；动态调整不同主机间的负载可以最大限度地利用资源，提供单机稳定性；动态调整主机工作职能，当系统中某台机器出现故障时，它的工作可由其他机器承担，不会影响系统整体的运行，没有单点故障。

【问题3】

参考答案：

(1)Applet
(2)Servlet
(3)EJB容器
(4)Sessionbean或会话bean
(5)Entitybean或实体Bean

答案解析：

本问题考查J2EE平台的基本架构，

典型的J2EE架构如下图所示：

J2EE是针对Web Service、业务对象、数据访问和消息传送的一组规范。这组应用编程接口确定了Web应用与驻留它们的服务器之间的通信方式。J2EE注重两件事，一是建立标准，使Web应用的部署与服务器无关；二是使服务器能控制构件的生命周期和其他资源以便能够处理扩展、并发、事务处理管理和安全性问题。J2EE规范定义了以下几种构件：应用客户端、EJB构件、Servlets和JSP、Applet构件。J2EE采用的是多层分布式应用模型，意味着应用逻辑将根据功能分成几个部分，用户可以在相同或不同的服务器上安装不同应用构件组成J2EE应用。

试题五

本题考查Web系统架构设计的相关知识。此类题目要求考生认真阅读题目，根据实际系统的需求描述，进行Web系统架构的设计。

【问题1】

参考答案：

(1)制定 Product Backlog
(2)Sprint 计划会议
(3)每日站立会议
(4)Product Backlog 中还有未完成的用户故事

(5)已交付 Product Backlog 中的所有用户故事

答案解析：

本问题考查对Web系统的动态行为进行建模的相关知识。

状态图(State chart Diagram)主要用于描述一个对象在其生存期间的动态行为，表现为一个对象所经历的状态序列，引起状态转移的事件(Event)，以及因状态转移而伴随的动作(Action)。一般可以用状态机对一个对象的生命周期建模，状态图用于显示状态机(State Machine Diagram)，重点在于描述状态图的控制流。

因此，基于题目描述的Scrum敏捷开发流程，对该Scrum项目管理系统中动态行为进行建模，(1)(2)(3)对应的状态应为“制定ProductBacklog”“Sprint计划会议”“每日站立会议”，(4)(5)对应的使状态发生改变的事件为“ProductBacklog中还有未完成的用户故事”“已交付ProductBacklog中的所有用户故事”。

【问题2】

参考答案：

(1)b，c，d，h，k，l，m，n

(2)a，f (3)e，j

注：各空中的项没有次序要求

答案解析：

本问题考查MVC架构模式在Web系统设计中的应用。MVC是一种目前广泛流行的软件体系结构，该架构模式的三个基本组件包括模型(Model)、视图(View)和控制器(Controller)。

模型(Model)用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。Model有对数据直接访问的权利，例如对数据库的访问。Model不依赖View和Controller，也就是说，Model不关心它会被如何显示或是如何被操作。但是Model中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此Model的View必须事先在此Model上注册，从而，View可以了解在数据Model上发生的改变。视图(View)能够实现数据有目的的显示。在View中一般没有程序上的逻辑。为了实现View上的刷新功能，View需要访问它监视的数据模型(Model)，因此应该事先在被它监视的数据那里注册。控制器(Controller)起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据Model上的改变。

基于MVC架构模式的思想，Scrum敏捷开发管理系统中各元素分别对应于MVC中的Model、View、Controller如下表所示。

【问题3】

参考答案：

(1)d或f

(2)f或d

(3)h

(4)e

(5)a

(6)k

(7)j

(8)b

(9)c

注：(1)、(2)答案可互换，但不能重复选择。

答案解析：

本题目考查层次式的Web系统设计方案和各层的具体实现技术的相关知识。

根据题干中的描述，该项目管理系统基于MVC架构设计，采用轻量级J2EE架构和SSH框架进行开发，使用MySQL数据库作为底层存储。在图5-2给出的系统架构图的基础上，可以分析出该Scrum敏捷开发管理系统的层次系统架构包括5层，依次为视图层、Web层、Service层、DAO、Hibernate持久层和基于Mysql实现的数据库服务。

在视图层中，SiteMesh 和 jQuery 是用户界面设计开发中的常用框架。SiteMesh 是一个 Web 页面布局、装饰以及与现有 Web 应用集成的框架，有助于在由大量页面构成的项目中创建一致的页面布局和外观、一致的导航条、一致的布局方案等。jQuery 是一个快速、简洁的 JavaScript 框架，它封装 JavaScript 常用的功能代码，提供一种简便的 JavaScript 设计模式，优化 HTML 文档操作、事件处理、动画设计和 Ajax 交互，jQuery 具有独特的链式语法和短小清晰的多功能接口，具有高效灵活的 CSS 选择器，并且可对 CSS 选择器进行扩展，拥有便捷的插件扩展机制和丰富的插件。

在Web层中，Strust2框架有效地支持了MVC架构中控制业务逻辑与表现层中的交互。Struts2是轻量级的MVC框架，在Struts2中当Web容器收到请求(http Servlet Request)，它将请求传递给一个标准的过滤链包括Action Context Clean Up过滤器。经过Other filters(SiteMesh等)，需要调用Filter Dispatcher核心控制器，然后它调用Action Mapper确定请求哪个Action，Action Mapper返回一个收集Action详细信息的Action Mapping对象。Filter Dispatcher将控制权委派给Action Proxy，Action Proxy调用配置管理器(Configuration Manager)从配置文件中读取配置信息(struts.xml)，然后创建Action Invocation对象。Action Invocation在调用Action之前会依次调用所用配置拦截器(InterceptorN)，一旦执行结果返回结果字符串，Action Invocation负责查找结果字符串对应的(Result)，然后执行这个Result，Result会调用一些模版(JSP)来呈现页面。拦截器(Interceptor N)会再被执行，顺序和Action执行之前相反。最后响应(http Servlet Response)被返回在web.xml中配置的那些过滤器和核心

控制器(Filter Dispatcher)。

系统架构设计师学习QQ群：231352210

软件设计师学习QQ群：1169209218

诸葛老师QQ: 362842353

VIP购买方式，淘宝搜索：软考诸葛老师