数字化校园平台基础架构的设计与实现

《数字化校园平台基础架构的设计与实现》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、数字化校园平台基础架构的设计与实现　　摘要：数字化校园系统是高校信息化的重要应用平台，它深刻改变了高校管理、教学和发展模式。本文分析数字化校园的应用现状，通过负载均衡技术努力提高数字化校园平台的可用性。　　关键词：数字化校园；负载均衡；基础架构　　中图分类号：TP18文献标志码：A文章编号：1673-8454（2013）15-0063-02　　一、引言　　随着数字化校园平台的正式发布和运行，用户对平台的访问量急速增加，性能和可用性逐渐成为困扰高校数字化校园平台正常运行的瓶颈。本文通过构建高可用和高

2、性能的数字化校园平台基础架构，并在运行阶段不断完善设计方案，最终为数字化校园平台的性能和稳定起到了优化系统和软件程序所不能达到的作用，为全校带来了综合效率的显著提升。　　二、数字化校园平台基础架构的设计　　数字化校园是对校园内的教学、科研、管理和生活服务等有关的信息资源进行收集、处理、整合、存储、传输和应用的平台，因此数字化校园平台是使用最频繁的、访问量最大的系统。用户首先访问此系统，通过认证后才能使用数字化校园的各种应用，一旦承载数字化校园的基础设备出现问题，不能提供服务，整个学校的信息化应用就

3、会处于瘫痪状态。综上，数字化校园平台应该具有以下特点：　　（1）高可用性：将服务停止时间降低到最低甚至是提供不间断服务；　　（2）可扩展性：随着业务量的增加，系统应具备良好的伸缩能力；　　（3）可管理性：系统和服务处于实时的监控下；　　（4）高性能：数字化校园平台用户总量为2万、在线用户数为不低于2500人、并发用户数为不低于700人，保证7×24小时运行，最大延时不超过3秒；　　（5）安全性：运用结构及主机的安全策略。　　为了提高数字化校园的可用性和可靠性，需要对数字化校园平台进行分析并结合学校

4、自身的特点设计出符合要求的基础架构。如图1所示，将平台的基础架构分成三层：第一层包括负载均衡和测试服务器，可以将访问频繁，用户量大的对象采用合理的方式负载到多个服务器上，同时区分内外网保证系统安全；第二层包括应用服务器、认证服务器、数据清洗服务器和监控服务器，多服务器配置提升可用性和可扩展性；第三层则为数据库服务器。　　三、数字化校园平台基础架构的实现　　1.服务器选型　　根据TPC-C的计算原则：以单台服务器性能进行计算，即确保单台服务器工作的时候可以满足系统正常运行的需要。对数字化校园数据库服

5、务器和应用服务器进行TPC-C计算。　　假设系统同时在线用户数为2500人；平均每个用户每分钟发出2次业务请求；系统发出的业务请求中，更新、查询、统计各占1/3；平均每次更新业务产生3个事务；平均每次查询业务产生7个事务；平均每次统计业务产生9个事务；一天内忙时的处理量为平均值的5倍；经验系数为1.6；考虑服务器保留30%的冗余。服务器需要的处理能力为：TPC-C=在线用户数×每分钟业务请求×（更新、查询和统计产生的事务）/3×忙时处理量×经验系数/冗余系数则应用服务器的处理性能估算为：TPC-C

6、=2500×2×（3+8+9）/3×5×1.6/0.7=380，952tpmC。　　数据库服务器关系到整个系统的稳定运行，考虑到高可靠性和高可用性，并注重设备的可扩展性和性价比，系统将配置两台TPC-C值不小于38万的高性能数据库服务器。并将应用服务器和认证服务器各配置2台，既分担了访问压力也规避了单点故障。　　2.负载均衡　　负载均衡器根据负载均衡策略把客户端请求分发到服务器群中最合适的服务器上，实际上负载均衡器只对新会话进行负载均衡。对于需要进行会话保持的客户端请求，负载均衡器则交给会话模式和

7、应用层会话保持机制来处理。　　基于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况，我们采用轮询调度算法。它是假设所有服务器的处理性能都相同，而且不关心每台服务器的当前连接数和响应速度，通过把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N（内部服务器个数），然后重新开始循环。　　3.数字化校园压力测试及性能评估　　（1）本次性能评估与验证过程中用例选取的原则如下：　　①数字化校园平台日常运行中，使用频率较高的功能模块；　　②数字化校园平台日常运行中，业务容易产生相

8、对大并发量的功能模块；　　③用户比较重视其性能（如事务响应时间）的功能模块。　　（2）测试结果及评估　　从图2的汇总信息可见本次测试运行一次，最大运行用户数是500，总的流量（网络吞吐量）约25G，平均流量约每秒35M，总的点击率约2，524，834次，平均点击率是每秒3，444，521次。　　从图3的事务汇总信息可见本次测试共通过了9087个事务，失败38个，失败率0.004%。提交事务的平均响应时间为0.231秒。　　从图4响应时间分布图中我们可以看到：在500人并发的情况下，