2018年系统架构师软考案例分析考点

1.操作性需求、性能需求、 安全性需求和文化需求

• 统性能需求(Performance Requirements)：指响应时间、吞吐量、准确性、有效性、资源 利用率等与系统完成任务效率相关的指标。可靠性、可用性等指标可归为此类。
• 安全性需求(Security Requirements)：系统向合法用户提供服务并阻止非授权用户使用服 务方面的系统需求。
• 操作性需求(Operational Requirements)：与用户操作使用系统相关的一些需求。
• 文化需求(Cultural Requirements)：带有文化背景因素的系统需求。

2.瘦客户端与胖客户端

• 2.1 无论胖还是瘦，要做到用户界面的个性化应该都没有问题，而且难说哪种更强。毕 竟瘦的只是把业务逻辑从客户端放到了服务器上。
• 2.2 胖客户端，在客户端的运算能力强一些。瘦客户端可以在服务端面用集群做支持。
• 2.3 瘦客户端将业务逻辑迁移到应用服务器上，所以有故障只要修复服务器上的内容， 而胖客户端要更新所有客户端，工作量大，所以此情况下瘦客户端有优势。
• 2.4 胖客户端的后端是数据库，没有业务逻辑，此时要做加密传输没有基础，但瘦客户 端可以做到。
• 2.5 胖客户端做到 2G 数据缓存很容易，而瘦客户端不现实。

3.实体(entity),抽象用例(Essential Use Cases) 和 基础用例(Real Use Cases)

• 3.1 实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作。
• 3.2 Essential Use Cases(抽象用例)，Real Use Cases(基础用例)，这两者的区别为：基 础用例是实实在在在与用户需求有对应关系的用例，是从用户需求获取的渠道得到的，而抽 象用例是从基础用例中抽取的用例的公共部分，是为了避免重复工作，优化结构而提出的用 例。

3.BMTS 的消息通信网络主要特征

能适配不同的传输介质，以及适配不同的协议，屏蔽不同协议之间的差异，简化通信过程降低系统复杂度。

• 3.1 事件触发消息：以事件作为触发方式，事件发生便触发相应消息。
• 3.2 速率约束消息：传输速率固定的消息。
• 3.3 时间触发消息：以时间作为触发方式，到达时间点便触发相应消息。
• 3.4 具有时间触发消息能力的网络总线：航空电子全双工交换式以太网(AFDX)，时间触发 以太网(TTE)。

4.Memcache

Memcache 不支持数据持久化操作，所以掉电数据会全部丢失，而且无法直接恢复，这 存在 可靠性间题 Memcache 不支持事务，所以操作过程中可能产生数据的不一致性。

同步方案：读取数据时，先读取 Redis 中的数据，如果 Redis 没有，则从原数据库中读 取，并同步更新 Redis 中的数据。写回时，写入到原数据库中，并同步更新到 Redis 中。

5.Redis 分布式存储

• 5.1 主从方案
• 5.2 Cluster 方案

6.Redis 集群切片

• 6.1 客户端分片：在客户端通过 key 的 hash 值对应到不同服务器
• 6.2 对数据根据 key 散列到不同的 slot 上，不同 slot 对应不同的服务器

7.面向服务架构(SOA)以及 ESB 在 SOA 中的作用与特点

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

• 7.1 支撑 SOA 的关键是其消息传递架构-企业服务总线（ESB)。ESB 用于实现企业应 用不同消息和信息的准确、高效和安全传递。
• 7.2 面向服务的元数据管理：他必须了解被他中介的两端，即服务的请求以及请求者对 服务的要求，以及服务的提供者和他所握供的服务的描述；
• 7.3 通信：服务的发布/订阋、响应/请求、同步/异步消息、路由和寻址等；
• 7.4 服务交互：服务接口定义，服务实现的置换，服务消息模型，服务目录和发现等；
• 7.5 服务安全：认证和授权、不可否认和机密性、安全标准的支持等。

8.实现信息系统安全保障的措施

• 8.1 釆用挑战/应答的认证机制，防止重放攻击。
• 8.2 釆用加密技术保证信息在网络传输过程的安全。
• 8.3 釆用数字签名技术保证信息传输过程的完整性和不可否认。