【系统架构设计师-2018年】案例分析-答案及详解

试题一（25分）

阅读以下关于软件系统设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某文化产业集团委托软件公司开发一套文化用品商城系统，业务涉及文化用品销售、定制、竞拍和点评等板块，以提升商城的信息化建设水平。该软件公司组织项目组完成了需求调研，现已进入到系统架构设计阶段。考虑到系统需求对架构设计决策的影响，项目组先列出了可能影响系统架构设计的部分需求如下：
（a）用户界面支持用户的个性化定制；
（b）系统需要支持当前主流的标准和服务，特别是通信协议和平台接口；
（c）用户操作的响应时间应不大于3秒，竞拍板块不大于1秒；
（d）系统具有故障诊断和快速恢复能力；
（e）用户密码需要加密传输；
（f）系统需要支持不低于2G的数据缓存；
（g）用户操作停滞时间超过一定时限需要重新登录验证；
（h）系统支持用户选择汉语、英语或法语三种语言之一进行操作。
项目组提出了两种系统架构设计方案：瘦客户端C/S架构和胖客户端C/S架构，经过对上述需求逐条分析和讨论，最终决定采用瘦客户端C/S架构进行设计。

【问题1】（8分）
在系统架构设计中，决定系统架构设计的非功能性需求主要有四类：操作性需求、性能需求、安全性需求和文化需求。请简要说明四类需求的含义。

【问题2】（8分）
根据表1-1的分类，将题干所给出的系统需求（a ） ~（ h ）分别填入（1）~（4）。

【问题3】（9分）
请用100字以内文字说明痩客户端C/S架构能够满足题干中给出的哪些系统需求。

答案解析
【问题1】

本题考查软件系统架构设计相关知识。
此类题目要求考生能够理解影响软件系统架构设计的系统需求，掌握需求的类型和具体需求对于系统架构设计选择的影响。在系统后期设计和实现阶段，非功能性需求指标需要进一步细化，系统非功能性需求对于系统架构设计的影响变得越来越重要。系统架构设计决策包括基于服务器、基于客户端、瘦客户端服务器、胖客户端服务器等不同类型。主要影响架构设计的需求包括操作性需求（技术环境需求、系统集成需求、可移植性需求、维护性需求)、性能需求（速度需求、容量需求、可信需求)、安全性需求（系统价值需求、访问控制需求、加密/认证需求、病毒控制需求)、文化需求（多语言需求、个性化定制需求、规范性描述需求、法律需求） 等。系统架构设计师在系统架构设计阶段，需要有针对性的对系统非功能性需求进行分析，综合确定系统的架构设计决策。
本问题考查考生对影响系统架构设计决策的非功能性需求分类的理解和掌握情况。操作性需求是指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求；性能需求是针对系统性能要求的指标，如吞吐率、响应时间和容量等；安全性需求指为防止系统崩溃和保证数据安全所需要采取的保护措施的要求，为系统提供合理的预防措施；文化需求是指使用本系统的不同用户群体对系统提出的特有要求。

参考答案：
(1) 操作性需求：指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求。
(2) 性能需求：针对系统性能要求的指标，如吞吐率、响应时间和容量等。
(3) 安全性需求：指为防止系统崩溃和保证数据安全所需要采取的保护措施的要求，为系统提供合理的预防措施。
(4) 文化需求：指使用本系统的不同用户群体对系统提出的特有要求。

【问题2】

本问题考査考生对具体系统需求类别的掌握情况。“用户界面支持用户的个性化定制”和“系统支持用户选择汉语、英语或法语三种语言之一进行操作”分别对应于个性化定制需求和多语言需求，属于文化需求类别；“系统需要支持当前主流的标准和服务，特别是通信协议和平台接口”和“系统具有故障诊断和快速恢复能力”分别对应于可移植性需求和维护性需求，属于操作性需求类别；“用户操作的响应时间应不大于3秒，竞拍板块不大于1秒”和“系统需要支持不低于2GB的数据缓存”分别对应于速度需求和容量需求，属于性能需求类别；“用户密码需要加密传输”和“用户操作停滞时间超过一定时限需要重新登录验证”分别对应于加密/认证需求和访问控制需求，属于安全性需求。

参考答案：
(1) ( b )、( d )
(2) ( c )、( f )
(3) ( e )、( g )
(4) ( a )、( h )

【问题3】

本问题考查考生对非功能性需求影响架构设计决策的掌握情况。在非功能性需求中，“用户界面支持用户的个性化定制”“系统需要支持当前主流的标准和服务，特别是通信协议和平台接口”“系统具有故障诊断和快速恢复能力”“系统支持用户选择汉语、英语或法语三种语言之一进行操作”等需求决定系统设计中适合采用瘦客户端服务器架构。

参考答案：瘦客户端C/S架构能够更好地满足系统需求中的（a）、（b）、(d)和（h）。

试题二（25分）

阅读以下关于软件系统建模的叙述，在答题纸上回答问题1至问题3。
【说明】
某公司欲建设一个房屋租赁服务系统，统一管理房主和租赁者的信息，提供快捷的租赁服务。本系统的主要功能描述如下：

1. 登记房主信息。记录房主的姓名、住址、身份证号和联系电话等信息，并写入房主信息文件。
2. 登记房屋信息。记录房屋的地址、房屋类型（如平房、带阳台的楼房、独立式住宅等）、楼层、租金及房屋状态（待租赁、已出租）等信息，并写入房屋信息文件。一名房主可以在系统中登记多套待租赁的房屋。
3. 登记租赁者信息。记录租赁者的个人信息，包括：姓名、性别、住址、身份证号和电话号码等，并写入租赁者信息文件。
4. 安排看房。已经登记在系统中的租赁者，可以从待租赁房屋列表中查询待租赁房屋信息。租赁者可以提出看房请求，系统安排租赁者看房。对于每次看房，系统会生成一条看房记录并将其写入看房记录文件中。
5. 收取手续费。房主登记完房屋后，系统会生成一份费用单，房主根据费用单交纳相应的费用。
6. 变更房屋状态。当租赁者与房主达成租房或退房协议后，房主向系统提交变更房屋状态的请求。系统将根据房主的请求，修改房屋信息文件。

【问题1】（12分）
若采用结构化方法对房屋租赁服务系统进行分析，得到如图2-1所示的顶层DFD。使用题干中给出的词语，给出图2-1中外部实体E1~ E2、加工P1~ P6以及数据存储D1~D4的名称。

【问题2】（5分）
若采用信息工程（Information Engineering）方法对房屋租赁服务系统进行分析，得到如图2-2所示的ERD。请给出图2-2中实体（1）~ （5）的名称。

【问题3】（8分）
（1）信息工程方法中的“实体（entity）” 与面向对象方法中的“类（class）”之间有哪些不同之处？
（2）在面向对象方法中通常采用用例（Use Case）来捕获系统的功能需求。用例可以按照不同的层次来进行划分，其中的Essential Use Cases和Real Use Cases有哪些区别?

答案解析
【问题1】

本题主要考查软件系统建模方法的基本知识及其应用，包括三种模型驱动的开发方法：结构化方法、信息工程方法以及面向对象方法。
本问题考査结构化方法中结构化分析阶段的模型数据流图（DFD)。数据流图中的基本图形元素包括数据流（data flow)、加工（process)、数据存储（data store)和外部实体（external agent)。其中，数据流、加工和数据存储用于构建软件系统内部的数据处理模型；外部实体表示存在于系统之外的对象，用来帮助用户理解系统数据的来源和去向。
问题要求将图2-1中缺失的外部实体、数据存储和加工补充完整。
外部实体可以是和系统交互的人或角色，以及和系统交互的外部系统或服务。根据题目中的描述，与本系统进行交互的角色是房主和租赁者。根据E1和P1之间的数据流“房主信息”，结合题目描述可知，E1表示的是房主，E2表示的是租赁者。
题目的描述中已经明确给出了系统的6个功能，需要将这些功能与加工P1~P6进行对应，这需要借助于各个加工的输入输出数据流进行分析。根据E1和P1之间的数据流“房主信息”可知，这条数据流符合“登记房主信息”功能的描述，因此可以确定P1是“登记房主信息”，同时可以确定D1是“房主信息文件”。
E1和P2之间的数据流“房屋信息”“费用单”，这些都与房屋登记相关，因此P2是“登记房屋信息”。同时可以确定，D3对应的是“房屋信息文件”。同理，根据数据流及题干描述，可以推断出：P3对应“登记租赁者信息”、P4对应“查询待租赁房屋信息”、P5对应“安排租赁者看房”以及P6对应“变更房屋状态”。

参考答案：
外部实体:
E1：房主
E2：租赁者
顶层加工:
P1：登记房主信息
P2：登记房屋信息
P3：登记租赁者信息
P4：查询待租赁房屋信息
P5：安排租赁者看房
P6：变更房屋状态
数据存储：
D1：房主信息文件
D2：租赁者信息文件
D3：房屋信息文件
D4：看房记录文件

【问题2】

本问题考查信息工程方法中的模型ER图。ER图中包含两个主要元素：实体和联系。实体是现实世界中可以区别于其他对象的“事件”或“物体”。本题要求补充图2-2中的实体。
根据题目描述和实体之间的联系可知，(1)和(2)分别对应房主和房屋，两者之间的联系为“房主拥有房屋”。同理可以推断出，(3)~(5)分别是实体“房屋类型”“租赁者”和“看房安排”。

参考答案：
(1)房主
(2)房屋
(3)房屋类型
(4)租赁者
(5)看房安排

【问题3】

本问题考查面向对象方法中的基本概念。
信息工程方法中的“实体”描述的是数据以及该数据的相关属性。面向对象方法中的“类”是数据和行为的封装体。
Essential Use Cases和Real Use Cases是按照开发阶段来进行划分的。Essential Use Cases是在面向对象分析阶段使用的，Real Use Cases是在面向对象设计阶段使用的。Essential Use Cases描述的是用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。
Real Use Cases描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。

参考答案：
(1) 信息工程方法中的“实体”描述的是数据以及该数据的相关属性。面向对象方法中的“类”是数据和行为的封装体。
(2) Essential Use Cases和Real Use Cases是按照开发阶段来进行划分的。Essential Use Cases是在面向对象分析阶段使用的，Real Use Cases是在面向对象设计阶段使用的。
Essential Use Cases描述的是用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。
Real Use Cases描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。

试题三（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方法分析；
（I）因果关系相互影响；
（j）行为特征依赖于大量的反馈机制；
（k）系统内构成、策略和描述是相似的；
（l）系统内存在许多不同的构成、策略和描述；
（m）功能关系是非线性的；
（n）功能关系是线性的；
（o）不同的子任务是相互独立的，任务内部仅存在少量的交互操作；
（p）不同的子任务有很高的交互操作，要把一个单任务的行为隔离开是困难的；
（q）域特征有非常整齐的原则和规则；
（r） 许多不同的上下文依赖于规则；
（s） 原理和规则在表面属性上很容易被识别；
（t） 原理被覆盖、抽象，而不会在表面属性上被识别。

表3-1 简单任务和复杂任务特征比较如下：

【问题2】（11分）
王工设计方案中指出：要满足未来网络化、智能化和综合化的需求，应该设计一种能够充分表达嵌入式系统行为的、且具有一定通用性的通信架构，以避免复杂任务的某些特征带来的通信复杂性。通常为了实现嵌入式系统中计算组件间的通信，在架构上需要一种简单的架构风格，用于屏蔽不同协议、不同硬件和不同结构组成所带来的复杂性。图3-1给出了一种“腰（Waistline）"型通信模式的架构风格。腰型架构的关键是基本消息通信（BMTS），通常BMTS的消息与时间属性相关，支持事件触发消息、速率约束消息和时间触发消息。
请说明基于BMTS的消息通信网络的主要特征和上述三种消息的基本含义，并举例给出两种具有时间触发消息能力的网络总线。

图3-1 “腰”型通信模式架构风格

答案解析
【问题1】

近年来，微电子技术发展带动了计算机领域技术不断更新，嵌入式系统已从单一架构向着满足网络化、智能化和综合化要求的新架构方向发展，开放、组件和智能已成嵌入式系统主要特征，嵌入式系统的广泛使用、使得其承载任务变得愈加繁重、结构变得愈加复杂、软件变得愈加庞大。其嵌入式实时产品已将由简单型系统演变到复杂型系统，从而在嵌入式实时系统中引发出了简单任务（simple task)和复杂任务（complex task)的区分。本题主要考查考生对嵌入式系统的新型架构知识的掌握程度，通过概念区分和实例分析，进一步考查考生对新知识的掌握能力以及对问题分析和总结能力。
本题目的要求考生根据自己已从事过或将要从事的嵌入式系统的软件架构的有关相关知识，认真阅读题目对技术问题的描述，经过分析、分类和概括等方法，从中分析出题千或备选答案给出的术语间的差异，正确回答问题1到问题2所涉及的各类技术要点。
嵌入式系统是以应用为中心、以计算机技术为基础、软硬件可剪裁、适用应用系统对功能、可靠性、成本、体积、功耗严格要求的专用计算机系统。在过去嵌入式系统一般是为某个应用系统专门定制生产的，其系统特征是相互独立，功能单一、时序简单，我们通常称过去嵌入式系统为简单系统。而随着当前网络化、智能化和综合化需求的推进，嵌入式系统结构发生了重大变化，其通用性、开放性、标准化和组件化已成潮流，一台嵌入式系统不再承担单一功能，而是要赋予嵌入式系统处理众多事物，因而，系统结构的复杂性增加，处理任务的机理、状态和行为复杂性增加，我们通常称现在的嵌入式系统为复杂系统。简单系统中运行任务为简单任务，复杂系统中运行任务为复杂任务。
简单任务和复杂任务的特征区分主要表现以下十个方面：
(1) 静态/动态特性：简单任务的时序关系是确定不变的，不会随时间偏移而变化。而随着复杂系统任务多样化发展，复杂任务将会随着时间、状态变化而变化。
(2) 连续性/非连续性：简单任务仅仅考虑变量的随机性，而不考虑数据的继承性。而复杂任务由于受环境影响，其变量域需要考虑时间上连续特性，及数据的继承关系。
(3) 系统间的独立性：简单任务由于功能单一，仅仅需要考虑内部任务间交联关系，具备独立性。而复杂任务间有很高的交互操作，要把一个任务的行为隔离开是非常困难的。
(4) 顺序/并行性：简单任务由于功能单一、时序简单，通常情况下任务是顺序执行的，缺少并行性。而复杂任务功能、状态复杂，其属性与的时间紧密相关，必然存在许多并行执行因子，并行性强。
(5)单一/混合性：简单任务由于功能单一，其内部算法、执行策略都是单一的、不会随状态变迁而改变。而由于复杂任务的多样化，其任务内会存在不同构型、策略和算法，甚至对于不同状态任务需要综合考虑影响因子后方能决策，其混合性比较强。
(6) 工作原理：简单任务执行时仅仅考虑上下因果关系，无须考虑结果。而复杂任务必须考虑根据上下文反馈信息来决策处理流程。
(7) 线性/非线性：简单任务执行的功能一般呈现线性关系，功能间的上下关系是线性的。而复杂任务必须考虑根据多个上下文功能的结果决策处理流程，是非线性的。
(8) 上下文相关性：简单任务由于功能简单并呈现线性特征，其功能原理必然与上下文无关。而复杂任务属于非线性特征，其功能原理必然与上下文相关。
(9) 规律/不规律：简单任务的特征是规则整齐，原则清晰。而复杂任务由于上下文相关，其规则与上下文存在关系，缺少规律性。
(10) 表面属性：简单任务对外特征明显，比较好识别。而复杂任务由于其多样化，其外表特征被覆盖或抽象，对外表现不明显，不好识别。
考生可根据以上分析，充分理解了复杂任务的特征后，便可进行简单任务和复杂任务的特征判断。

参考答案：
(1) ©
(2) ( d )
(3) ( o )
(4) ( p )
(5) (g)
(6) (h)
(7) (k)
(8) (l)
(9) (i)
(10) (j)
(11) (n)
(12) (m)
(13) (e)
(14) (f)

【问题2】

图3-1给出“腰”型通信模式架构风格是安全攸关系统比较流行的一种架构风格。此架构风格通过对数据通信方式的抽象，将复杂任务的非线性、并发、动态、上下文紧密相关等特征进行分解，解决了系统不同协议、不同硬件和不同结构混合组成所带来的复杂性问题。基本消息通信（BMTS)服务是将复杂软件的通信协议与执行机制分离，用最少的服务解决计算组件间的传输消息，这样的传输具有高可靠、低延迟和微小抖动等特点。BMTS支持事件触发消息、速率约束消息和时间触发消息等三种基本消息传输。
(1) 事件触发消息（Event-triggered messages):此类消息是在发送端出现某重要事件发生时产生的偶发消息。建立消息间不存在最小时间（minimumtime)。此类消息从发送到接收之间的延迟是不能确定的。在发送产生时，BMTS可能要处理许多消息，要么在发送者或消息被丢失时做相应处理。
(2) 速率约束消息（Rate-constrainedmessages):此类消息是偶发性产生的，而不考虑发送者承诺消息不超出最大消息速率。在给定的故障假设条件内，BMTS承诺不超过最大的传输时延（latency)。抖动依赖于网络负载或最坏情况下的传输时延和最小传输时延的范围。
(3) 时间触发消息（Time-triggered messages)：此类消息是指发送者和接受者遵循一个精确的时间片周期完成消息的发送与接收。在给定的故障假设条件内，BMTS承诺消息将被在指定的时间片、确定的抖动条件下发送或接收消息。
当前，具有时间触发消息能力的网络总线：TTE总线、FC总线、AFDX总线。

参考答案：
BMTS是将从一个计算组件传输消息到另外一个或多个接收组件，这样的传输具有高可靠、低延迟和微小抖动等特点。
(1) 事件触发消息（Event-triggered messages):此类消息是在发送端出现某重要事件发生时产生的偶发消息。建立消息间不存在最小时间（minimum time)。此类消息从发送到接收之间的延迟是不能确定的。在发送产生时，BMTS可能要处理许多消息，要么在发送者或消息被丢失时做相应处理。
(2) 速率约束消息（Rate-constrained messages):此类消息是偶发性产生的，而不考虑发送者承诺消息不超出最大消息速率。在给定的故障假设条件内，BMTS承诺不超过最大的传输时延（latency)。抖动依赖于网络负载或最坏情况下的传输时延和最小传输时延的范围。
(3) 时间触发消息（Time-triggered messages)：此类消息是指发送者和接受者遵循一个精确的时间片周期完成消息的发送与接收。在给定的故障假设条件内，BMTS承诺消息将被在指定的时间片、确定的抖动条件下发送或接收消息。
具有时间触发消息能力的网络总线：TTE总线、FC总线、AFDX总线。

试题四（25分）

阅读以下关于分布式数据库缓存设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业，创业初期为快速开展业务，该企业采用轻量型的开发架构（脚本语言+关系型数据库）研制了一套业务系统。业务开展后受到用户普遍欢迎，用户数和业务数量迅速增长，原有的数据库服务器已不能满足高度并发的业务要求。为此，该企业成立了专门的研发团队来解决该问题。
张工建议重新开发整个系统，采用新的服务器和数据架构，解决当前问题的同时为日后的扩展提供支持。但是，李工认为张工的方案开发周期过长，投入过大，当前应该在改动尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据，建议采用缓存工具MemCache来减轻数据库服务器的压力，这样开发量小，开发周期短，比较适合初创公司，同时将来也可以通过集群进行扩展。然而，刘工又认为李工的方案中存在数据可靠性和一致性问题，在宕机时容易丢失交易数据，建议采用Redis来解决问题。在经过充分讨论，该公司最终决定采用刘工的方案。

【问题1】（9分）
在李工和刘工的方案中，均采用分布式数据库缓存技术来解决问题。请用100字以内的文字解释说明分布式数据库缓存的基本概念。
表4-1中对MemCache和Redis两种工具的优缺点进行了比较，请补充完善表4-1中的空（1）~（6）。

【问题2】（8分）
刘工认为李工的方案存在数据可靠性和一致性的问题，请说明原因。
为避免数据可靠性和一致性的问题，刘工的方案采用Redis作为数据库缓存，请用200字以内的文字说明基本的Redis与原有关系数据库的数据同步方案。

【问题3】（8分）
请用300字以内的文字，说明Redis分布式存储的两种常见方案，并解释说明Redis集群切片的几种常见方式。

答案解析
【问题1】

本题考査数据库缓存的概念，以及数据库缓存方案的设计过程。
常见的信息系统经常将数据保存到关系数据库中，应用软件对关系数据库进行数据读写，响应用户需求。但随着数据量增大、访问的集中，就会出现关系数据库的负担加重:，数据库响应恶化，显示延迟等重大影响。
分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。
目前市场上常见的数据库缓存系统是MemCache和Redis。
李工采用的方案中，采用MemCache作为缓存系统，但MemCache无法进行持久化，数据不能备份，只能用于缓存使用，数据全部存在于内存，一旦重启数据会全部丢失。刘工的方案中，采用Redis作为数据库缓存，解决了该问题。
刘工的方案中，保留原有关系数据库，将Redis仅作为缓存，即热点数据缓存在Redis中，核心业务的结构化数据存储在原有关系数据库中。需要解决热点数据在原关系数据库和Redis的数据同步问题，由于Redis只作为缓存，因此给出原关系数据库到Redis的同步方案即可。该方案的基本操作如下。

• 1.读操作。读缓存Redis,如果数据不存在，从原关系数据库中读数据，并将读取后的数据值写入到Redis;
• 2.写操作。写原关系数据库，写成功后，更新或者失效掉缓存Redis中的值。

参考答案：
分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。
(1) 丰富/多种数据结构；
(2) 不支持；
(3) 客户端哈希分片/一致性哈希;
(4) 不支持；
(5) 私有内存池/内存池；
(6) 不支持。

【问题2】

本问题考查两种两种工具对数据可靠性和一致性的支持，并考查方案的设计能力。

参考答案：
MemCache无法进行持久化，数据不能备份，只能用于缓存使用，数据全部存在于内存，一旦重启数据会全部丢失。Redis支持数据的持久化。因此李工的方案存在数据可靠性和一致性问题，而刘工的方案解决了该问题。
刘工的方案中，采用Redis作为缓存，使得一份数据同时存储在缓存和关系数据库中，因此必须给出一个数据同步的方案。刘工的方案中，保留原有关系数据库，将Redis仅作为缓存，即热点数据缓存在Redis中，核心业务的结构化数据存储在原有关系数据库中。由于Redis只作为缓存，因此给出原关系数据库到Redis的同步方案即可。该方案的基本操作如下。
1.读操作。读缓存Redis,如果数据不存在，从原关系数据库中读数据，并将读取后的数据值写入到Redis;
2.写操作。写原关系数据库，写成功后，更新或者失效掉缓存Redis中的值。

【问题3】

Redis为单点方案，使用时必须提供分布式存储的集群拓展能力。Redis分布式存储的常见方案有主从(Master/Slave)模式、哨兵(Sentinel)模式、集群(Cluster)模式。
Redis集群切片的常见方式有：
(1) 客户端实现分片方式，分区逻辑在客户端实现，采用一致性哈希来决定Redis节点。
(2) 中间件实现分片方式，即在应用软件和Redis中间，例如Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
(3) 客户端服务端协作分片方式，Redis Cluster模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务。

参考答案：
Redis分布式存储的常见方案有：
1、主从（Master/Slave)模式；
2、哨兵（Sentinel)模式；
3、集群（Cluster)模式。
Redis集群切片的常见方式有：
4、客户端实现分片。分区逻辑在客户端实现，采用一致性哈希来决定Redis节点。
5、中间件实现分片。在应用软件和Redis中间，例如Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
6、客户端服务端协作分片。Redis Cluster模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务。

试题五（25分）

阅读以下关于Web系统设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某银行拟将以分行为主体的银行信息系统，全面整合为由总行统一管理维护的银行信息系统，实现统一的用户账户管理、转账汇款、自助缴费、理财投资、贷款管理、网上支付、财务报表分析等业务功能。但是，由于原有以分行为主体的银行信息系统中，多个业务系统采用异构平台、数据库和中间件，使用的报文交换标准和通信协议也不尽相同，使用传统的EAI解决方案根本无法实现新的业务模式下异构系统间灵活的交互和集成。因此，为了以最小的系统改进整合现有的基于不同技术实现的银行业务系统，该银行拟采用基于ESB的面向服务架构（SOA）集成方案实现业务整合。

【问题1】（7分）
请分别用200字以内的文字说明什么是面向服务架构（SOA）以及ESB在SOA中的作用与特点。

【问题2】（12分）
基于该信息系统整合的实际需求，项目组完成了基于SOA的银行信息系统架构设计方案。该系统架构图如图5-1所示：

请从（a）~ （j）中选择相应内容填入图5-1的（1）~ （6），补充完善架构设计图。
（a）数据层
（b）界面层
（c）业务层
（d）bind
（e）企业服务总线ESB
（f）XML
（g）安全验证和质量管理
（h）publish
（i）UDDI
（j）组件层
（k）BPEL

【问题3】（6分）
针对银行信息系统的数据交互安全性需求，列举3种可实现信息系统安全保障的措施。

答案解析
【问题1】

本题考查Web系统架构设计相关知识及如何在实际问题中综合应用。
此类题目要求考生认真阅读题目对现实系统需求的描述，结合Web系统设计相关知识、实现技术等完成Web系统分析设计。u2003
本问题考査考生对于Web应用系统常用体系架构相关的掌握程度。SOA和ESB是Web应用系统架构的基础。其中，面向服务的体系架构（SOA)是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。SOA能帮助企业系统架构设计者以更迅速、更可靠、更高重用性设计整个业务系统架构，基于SOA的系统能够更加从容地面对业务的急剧变化。
企业服务总线（ESB)是由中间件技术实现的全面支持面向服务架构的基础软件平台，支持异构环境中的服务以及基于消息和事件驱动模式的交互，并且具有适当的服务质量和可管理性。

参考答案：
面向服务的体系架构（SOA)是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。SOA能帮助企业系统架构设计者以更迅速、更可靠、更高重用性设计整个业务系统架构，基于SOA的系统能够更加从容地面对业务的急剧变化。
企业服务总线（ESB)是由中间件技术实现的全面支持面向服务架构的基础软件平台，支持异构环境中的服务以及基于消息和事件驱动模式的交互，并且具有适当的服务质量和可管理性。

【问题2】

通过阅读题目中银行信息系统的实际需求可知，在信息整合的过程中，银行使用企业服务平台构建全行应用系统的整合平台。在纵向上，连接总分行各个系统；在横向上，连接各业务应用系统和业务系统等。企业服务平台采用分级部署的方式，包括两个部分：一部分是部署在总行系统间的企业服务平台；另一部分是部署在分行系统间的企业服务平台。这两个企业服务平台之间互联互通，形成企业应用集成的总体框架。
银行信息系统的SOA架构模型中，通过ESB进行连接整合，能很好地支撑各业务流程。在操作客户关系管理中，客户信息是分散在各个业务子系统中，是不能共享的，通过基于ESB的体系架构整合后，可以实现全方位的客户管理。客户经理可以通过整合后的客户关系管理系统一次性地查阅目标客户的基本信息、产品账户信息、地址联系信息、事件信息、资源信息、关系信息、风险信息，统计分析信息等，这就真正实现了以客户为中心的转变过程，摆脱了从前以账户为中心的局部模式。
因此，基于对系统需求的分析和面向服务的体系结构的知识，考生可从选项中选择相应选项，完成系统架构设计，包括系统分层设计、各层构件、连接件设计等。
基于SOA的银行信息系统完整架构设计图如图5-2所示。

参考答案：
(1) ( c )
(2) ( i )
(3) ( h )
(4) ( e )
(5) ( g )
(6) ( j )

【问题3】

SOA环境中，需要解决的安全问题包括

• （1）机密性：机密性又称为保密性，是指非法非授权用户访问数据，导致数据机密泄漏。在传输层和消息层对机密性的需求是不同的，可以依靠数据加密来保证数据机密性。
• （2）完整性：是指数据的正确性、一致性和相容性。保证数据的完整性可以通过数字签名来实现。
• （3）可审计性：审计是一种事后监视的措施，跟踪系统的访问活动，发现非法访问，达到安全防范的目的。不同的系统可能需要不同的审计等级。
• （4）认证管理：实际指的是服务请求者和服务提供者两者在服务调用的时候互相认证对方的身份，防止非授权非法实体来获取服务，是系统安全的第一道安全屏障。
• （5）授权管理：授权管理的目的是阻止Web服务的未授权使用。
• （6）身份管理：在SOA架构中，身份管理和传统系统中的身份管理比较相像。服务请求者和服务提供者两者的身份对两者来说是至关重要的，否则就会存在非法用户在服务请求者和服务提供者之间进行消息传递，太容易导致数据的泄密和篡改。

综上，为了保障系统的安全性，可通过XML加密模块、WS-Security、防火墙系统、安全检测、网络扫描等安全性策略。

参考答案：
XML加密模块、WS-Security、防火墙系统、安全检测、网络扫描。