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

1.

• 1.1 用户执行读写操作时，响应时间均变得很慢；
• 1.2 随着系统功能的扩充，原有数据格式发生变化，又出现新的数据格式，维护困难；
• 1.3 数据容量很快超过系统原有的设计上限，数据库扩容困难；
• 1.4 软件系统不断出现宕机，整个系统可用性较差。

分析产生以上问题的原因

• 1.1 用户响应时间慢。大型社交网络系统要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求.关系数据库应付上万次 SQL 查询还勉强可以，但是应付上万次 SQL 写数据请求，硬盘I/O就已经无法承受了。特别是涉及到多表连接操作，会导致响应变慢。
• 1.2 数据格式变化。大型社交网络系统随着用户的使用，会不断地增加新的功能，导致原有数据格式发生变化，甚至出现新的数据格式。但关系数据库中采用元组方式组织数据，难以使用新型数据格式，难以维护。
• 1.3 数据容量超过设计上限。对于大型社交网络系统，往往会在很短时间内产生海量数据。关系数据库多采用中央数据存储，使得数据容量受限于前期设计的上限，很难实现数据容量的横向扩展。
• 1.4 系统可用性差：关系数据库采用中央数据存储，容易成为系统的性能瓶颈，单点故障很容易导致系统崩溃，负载过高往往导致系统出现宕机现象。

NoSQL数据库处理以上问题的优势

• 1.1 NoSQL 数据库支持高并发数据访问，性能较高。
• 1.2 NoSQL 数据库的数据存储结构松散，能够灵活支持多种类型的数据格式。
• 1.3 数据库能够支持海量数据的存储，且易于横向扩展。
• 1.4 数据库基于分布式数据存储，不存在单点故障和性能瓶颈，系统 可用性高。

NoSQL数据库处理以上问题的劣势

• 1.1 数据库的现有产品不够成熟，大多数产品处于初创期。
• 1.2 数据库并未形成一定的标准，产品种类繁多，缺乏官方支持。
• 1.3 数据库不提供对 SQL 的支持，学习和应用迁移成本较高。
• 1.4 数据库支持的特性不够丰富，现有产品提供的功能比较有限。

2.

设计模式按照其应用模式可以分为三类：创建型、结构型和行为型

• 2.1 创建型模式主要用于创建对象，为设计类实例化新对象提供指南。
• 2.2 结构型模式主要用于处理类或对象的组合，对类如何设计以形成更大的结构提供指南。
• 2.3 行为型模式主要用于描述类或对象的交互以及职责的分配，对类之间交互以及分配责任的方式提供指南。

创建型、结构型和行为型对应的设计模式

• 2.1 创建型：构造器模式(Builder)、原型模式(Prototype)。
• 2.2 结构型：适配器模式(Adapter)、外观模式(Facade)、代理模式(Proxy)。
• 2.3 行为型：命令模式(Command)、中介模式(Mediator)、状态模式(State)、策略模式(Strategy)。

3.开放式架构

• 3.1 可移植性。各种计算机应用系统可在具有开放架构特性的各种计算机系统间进行移植，不论这些计算机是否同种型号、同种机型。
• 3.2 可互操作性。如计算机网络中的各结点机都具有开放架构的特性，则该网上各结点机间可相互操作和资源共享。
• 3.3 可剪裁性。如某个计算机系统是具有开放架构特性的，则在该系统的低档机上运行的应用系统应能在高档机上运行，原在高档机上运行的应用系统经剪裁后也可在低档机上运行。
• 3.4 易获得性。在具有开放架构特性的机器上所运行的软件环境易于从多方获得，不受 某个来源所控制。

构件管理支持、互操作支持以及公共服务支持三个方面说明现有分布式基础设施为构 建分布式系统所提供的基本支撑

• (1) 构件管理支持：现有分布式基础设施一般通过构件容器为构件提供基本的运行环境； 具体功能一般包括管理构件的实例及其生命周期、管理构件的元信息等。 +
• (2) 互操作支持：现有分布式基础设施均提供了高层通信协议以屏蔽节点的物理特性以及各节点在处理器、操作系统、程序设计语言等方面的异构性；基于互操作支持，开发人员在开发与调用分布式对象时，均不需自己编写处理底层通信的代码。
• (3) 公共服务支持：现有分布式基础设施通常将针对分布式软件的通用支持集成于一身，以公共服务的形式提供给应用程序；其提供的常见公共服务包括命名服务、事务服务、安全服务、持久性服务等。

4.

请用 200 字以内的文字解释什么是软件架构风格，并从集成开发环境与用户的交互方式、集成开发环境的扩展性、集成开发环境的数据管理三个方面说明为什么最终采用了李工的设计方案。

软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成 构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。从集成开发环境与用户的交互方式看，用户通常采用交互式的方式对脚本语言进行编辑、解释执行与调试。在这种情况下，采用以数据存储为中心的架构风格能够很好地支持交互式数据处理，而管道-过滤器架构风格则对用户的交互式数据处理支持有限。

从集成开发环境的扩展性来看，系统核心需求要求实现各种编辑、语法检查、解释执行 等多种功能的灵活组织、配置与替换。在这种情况下，采用以数据存储为中心的架构风格， 以数据格式解耦各种功能之间的依赖关系，并可以灵活定义功能之间的逻辑顺序。管道-过 滤器架构风格同样以数据格式解耦数据处理过程之间的依赖关系，但其在数据处理逻辑关系 的灵活定义方面较差。 从集成开发环境的数据管理来看，集成开发环境需要支持脚本语言、语法树(用于检查语法错误)、可视化模型、调试信息等多种数据类型，并需要支持数据格式的转换。以数据存储为中心的架构将数据存储在统一的中心存储器中，中心存储器能够表示多种数据格式，并能够为数据格式转换提供各种支持。管道-过滤器架构风格通常只能支持有限度的数据格式，并且在数据格式转换方面的灵活性较差。