1、 实验 6 构件与分布式设计一、实验目的1. 了解基于用例的软件体系结构设计/重构过程；2. 了解和运用软件体系结构风格/模式来提高应用的可扩展性、可伸缩性和可用性；3. 掌握在设计文档支持下进行应用系统重构的开发技术。二、相关知识1 原系统在软件体系结构设计上的不足1.1 原系统的页面处理流程原系统的页面处理流程如图 1 所示。进行用户验证响应用户动作 ，处理输入数据跳转到其它页面是否需要跳转 ?重新装载用于显示的数据生成 H T M L 代码收到 H T T P 请求结束图 1 原网上相册系统的页面处理流程1.2 适应业务功能变化的可扩展性考虑到网上相册系统可能的业务变化，对原系统需进行的
2、相应修改/扩充评估如下： 业务模型类（即分析类）增加新字段。此时需要在 WebForm 上增加新的输入域；在类型化 DataSet 中的相应 DataTable 中增加新字段并重新进行代码生成和编译；修改并编译相应 WebForm 后端代码；修改 CategoryController 和 PhotoController 类；修改CategoryModel 和 PhotoModel 类；在相应数据库表中增加新字段并修改存储过程。综上所述，需要对原有 Web、Controller、Model、Utils 组件进行修改和重编译，并修改原有的数据库层； 增加新的业务模型类。此时不仅需要在 Web、Co
3、ntroller、Model、Utils 组件和数据库层中增加新的代码，还需对原有的部分页面控制器代码（包括 WebForm 后端代码和CategoryController、PhotoController 类）进行修改；综上所述，原网上相册系统仅是简单地应用三层风格和（基于页面控制器的）MVC 模式，未针对可能的业务变化进行有针对性的体系结构设计。具体说来，主要有以下缺点可以进行改进： 每个页面的后端代码中均需要调用 Utils.User 类的方法进行用户验证； 由于应用基于页面控制器的 MVC 模式，涉及输入处理和流程控制的部分业务逻辑分散在 Web 组件中的 WebForm 后端代码和 C
4、ontroller 组件中的CategoryController/PhotoController 类中，不便于封装可能变化的部分； 有关相片和相夹的业务逻辑之间本质上耦合程度较高，但确划分到两个控制器类和两个模型类中，反而影响了可扩展性； CategoryController/PhotoController 类与 CategoryModel/PhotoModel 类分别划分到Controller 组件和 Model 组件中，但其之间的耦合仍较高； WebForm 后端代码中含有较多的输入聚合、输入验证、输入处理和用于显示的数据装载等逻辑，其中有较多的重复/类似代码难以重用。1.3 提高性能和可
5、伸缩性的要求Web 应用最重要的性能是 Web 服务器的处理吞吐量，最常见的是使用每秒处理的请求数来进行衡量。主要的性能和可伸缩性改进方法包括：降低 Web 服务器的处理负荷（将部分处理负荷交由客户端或数据库服务器去完成） ，以及应用负载均衡群集。原系统中，Web 服务器和数据库服务器部署于同一台服务器上，虽然减少了部分网络传输开销，但单台服务器同时作为 Web 服务器和数据库服务器，会导致对服务器的处理能力要求过高，难以适应较大的访问量；原系统中，使用 InProc 方式的 Session 对象来完成跨 HTTP 请求的状态管理，导致系统无法部署于通常的负载均衡群集上。另外，增加缓存系统也可
6、大幅度提高应用的性能。原系统基本未使用任何系统的缓存方式来提高系统的性能。1.4 提高可靠性的要求Web 应用中，提高可靠性的最基本的方案是应用负载均衡群集 /故障转移群集。其中，数据库服务器通常可使用故障转移群集（多机热备系统） ，Web 服务器通常使用负载均衡群集。原系统中 Web 服务器和数据库服务器均未应用任何群集技术。2 改进策略针对以上问题，列出可能的改进策略如下： 用户验证交由独立的 HttpModule 完成，并应用策略模式，不但令 WebForm 后端代码中无需加入用户验证代码，也使得系统可以灵活地配置用户验证策略，提高了系统的可测试性（因使用 ACT 进行压力测试时，真实的
7、用户验证逻辑将大大增加测试脚本的复杂性，不便于利用录制的方式生成测试脚本） 。 将 Model 组件中的 CategoryModel 和 PhotoModel 类的功能合并，提高内聚性； 将输入验证功能交由 WebForm 上的 Validator 控件实现； 将原由页面控制器完成的每个页面的输入处理/数据装载逻辑进一步分解成粒度较小的 Action 类，并应用反射工厂模式和 Command-Chain 模式，使之可以在配置文件中针对各个页面进行配置； 将原先分散在不同的 WebForm 后端代码中的聚合客户端提交数据的逻辑改由前端控制器根据配置信息完成，既减少了重复代码，又提高了可测试性；
8、将原有的与相片/相夹相关的业务逻辑代码（包括 action 类、Model 类）均划分到一个 Photo 组件中。新增加的业务模型类同样根据业务概念之间的内聚性划分为不同的组件； 应用 IoC 模式，由前端控制器将 Action 类装载的（用于显示的）数据以数据集方式传递给 x 相应 WebForm，使得 Web 组件与业务逻辑组件之间完全解耦，配合使用数据绑定技术，使得增加新的业务模型类时，无需修改 WebForm 后端代码，避免了对 Web 组件的重编译（只需修改.aspx 文件即可） ；新增加的页面既可以放入 Web 组件中，也可以划分到新的表示层组件中； 改进跨 HTTP 请求的状态管
9、理。具体可以有以下几种方案：将状态保存在客户端，这可以方便地通过将状态信息保存在 ViewState 中实现，此方案的缺点是大大增加了网络传输开销，不适于状态信息数据量较大的情况；使用 State Server 来保存Session 对象，此方案的缺点是同样不适于状态信息数据量较大的情况，且引入了故障单点，不利于系统可靠性的提高；使用 SQL Server 来保存 Session 对象，此方案的缺点是必须使用 SQL Server 数据库平台，不利于系统跨数据库平台的移植；自定义的跨 HTTP 请求状态管理方案，此方案需要自行编写状态管理代码，增加了工作量，但效果较好；将 Http 请求处理改
10、为无需跨 HTTP 请求进行状态管理，此方案对于某些系统的重构可能不易实现，但本系统功能较为简单，不难做到； 在数据访问层或表示层增加缓存机制，提高系统的性能。类似于状态管理方案，缓存机制也必须考虑能否部署于群集系统中； 数据库服务器使用两台服务器、两台光纤交换机和一台双端口磁盘阵列服务器建立一个双机热备系统，以提高数据库服务器的可靠性； Web 服务器使用两台或多台服务器构成一个基于 DNS 的负载均衡群集，一方面可提高系统的性能和可伸缩性，同时亦可提高 Web 服务器的可靠性。3 补充知识3.1 数据库双机热备方案数据库双机热备有两种典型的方式，一种是比较标准的，两台服务器通过一个共享的存
11、储设备(一般是共享的磁盘阵列或存储区域网 SAN)，并且安装群集软件和支持群集的数据库管理系统，实现双机热备，称为共享方式。另一种方式是通过纯软件的方式，一般称为纯软件方式或镜像方式(Mirror)。对于共享方式，数据库放在共享的存储设备上。当一台服务器提供服务时，直接在存储设备上进行读写。而当系统切换后，另一台服务器也同样读取该存储设备上的数据。对于纯软件的方式，通过镜像软件，将数据可以实时复制到另一台服务器上，这样同样的数据就在两台服务器上各存在一份，如果一台服务器出现故障，可以及时切换到另一台服务器。共享方式的优点是：1. 可充分利用磁盘阵列/SAN 存储容量大、IO 性能高、安全性好的
12、特点，在提高数据库服务器可靠性的同时，亦提高其性能。2. 便于集中管理和维护。3. 利用硬件和系统软件完成，可靠性好，管理、维护方便。纯软件方式的优点是：1. 避免了磁盘阵列的单点故障：对于双机热备，本身即是防范由于单个设备的故障导致服务中断，但磁盘阵列恰恰又形成了一个新的单点。2. 节约投资：不需购买昂贵的磁盘阵列。3. 不受距离的限制：两台服务器不需受 SCSI 电缆的长度限制（光纤通道的磁盘阵列也不受距离限制，但投资较大） 。这样，可以更灵活地部署服务器，包括通过物理位置的距离来提高安全性。软件教学实验室中，使用两台服务器、两台光纤交换机和一台双端口磁盘阵列服务器建立了一个全冗余双机热备
13、系统，如图 2 所示。其上安装了 SQL Server 数据库管理系统。两台服务器上的 SQL Server 数据库管理系统共同以 IP 地址 192.168.59.14 对外界提供服务。全冗余的光纤网络结构保证了数据库服务器、交换机和磁盘阵列访问端口均有一倍的冗余，即其中任何一个环节发生一个故障，均不会影响 Web 服务器对数据库的正常访问中断。F C S w i t c hF C S w i t c hD L 3 6 0D L 3 6 0D S 4 3 0 0图 2 双机热备示意图 3.2 Web 服务器群集方案对于规模较大的企业级 Web 应用，访问量较大，一台服务器难以满足用户的访问需
14、求。为了解决这个问题，通常是部署多台内容相同的服务器，组成一个负载均衡群集来对客户端的 Http 请求提供服务。在负载均衡的思路下，每台服务器都具有同等的地位，可以单独对外提供服务而无须其他服务器的辅助。通过负载分担技术，将外部发送来的请求按一定规则分配到对称结构中的某一台服务器上，而接收到请求的服务器都独立回应客户机的请求。 提供服务的一组服务器组成了一个应用服务器群集 (cluster)，并对外提供一个统一的地址。当一个服务请求被发至该集群时，根据一定规则选择一台服务器，并将服务转定向给该服务器承担，即将负载进行均衡分摊。 通过应用负载均衡技术，使应用服务超过了一台服务器只能为有限用户提供
15、服务的限制，可以利用多台服务器同时为大量用户提供服务。当某台服务器出现故障时，负载均衡服务器会自动进行检测并停止将服务请求分发至该服务器，而由其他工作正常的服务器继续提供服务，从而保证了服务的可靠性。负载均衡实现的方法有几种： 最简单的是通过 DNS。通过在 DNS 服务器中，对同一个域名分配多个 IP 地址，当客户机使用域名访问 Web 服务器时，在域名解析阶段，DNS 服务器轮流返回不同的 IP地址，将 Http 请求引导至不同 IP 的 Web 服务器上; 如图 3 所示。图 2 基于 DNS 的 Web Farm Windows Server 2003 支持网络负载均衡 (NLB)，它
16、在群集中各个结点之间平衡传入的 Internet 协议 (IP) 通讯。网络负载均衡可以让客户端用一个逻辑 Internet 名称和虚拟IP 地址（又称群集 IP 地址）访问群集。如图 4 所示。图 4 基于 NLB 的 Web Farm 反向代理负载均衡。使用代理服务器可以将请求转发给内部的 Web 服务器，使用这种加速模式显然可以提升静态网页的访问速度。因此也可以让代理服务器将请求均匀转发给多台内部 Web 服务器之一上，从而达到负载均衡的目的。软件教学实验室中使用基于 DNS 的方式建立了一个 Web 负载均衡群集。在 DNS 服务器中，为域名 www.sl.szu.edu 配置了两个
17、IP 地址：172.0.0.90 和 172.0.0.62。当浏览器访问该域名时，DNS 服务器会将 Http 请求轮流引导至这两个 Web 服务器上。三、实验内容1. 根据“网上相册”系统的用例说明文档、架构设计文档（设计指南）和源代码，对该应用的体系结构进行分析；2. 对“网上相册”系统进行重构设计，改善其性能、可扩展性和可伸缩性，并使该应用可以部署于 Web Farm（即由多台 Web 服务器组成的机群，将访问负载平衡分配到各台机器）上；3. 使用 microsoft Application Center Test 工具对重构前和重构后的“网上相册”系统进行测试，验证你的体系结构重构效果；4. 增加“好友管理” 、 “查看好友的相片”和“相片查询 Web 服务”功能，并依此分析“网上相册”系统在重构前和重构后的可维护性的变化。
