文/本刊记者 傅宇凡
北京邮电大学正是在学生和老师吐槽的压力中,重新改造选课系统,优化数据库及应用服务器,彻底让选课“大塞车”成为历史。
2014年初,北京邮电大学校领导转发的学生吐槽:“选课系统经常崩溃,效率低。”批示要求:“查找原因,尽快改进”。此后,校教务处与网络中心合作,改造学校旧有的选课系统。
追根溯源
2013年,北邮教务管理系统采用了4台虚拟机,一台数据库服务器,一台应用服务器,开启4个端口,加上4台虚拟机,一共设置了8个网站入口,然而,每学年学生选课时,依然是大堵车。
北邮教务处徐老师介绍说:“就像地铁一样,进站台的人多了,但实际上每次发车的车次是有限的,所以登上数据库服务器,选课数据保存成功还是有限。”
“CPU虽然老了一些,但配置还算高,就是一到选课的时候,效果特别差。”北邮网络中心网络部王振华分析认为,选课系统在数据库服务器和应用服务器两方面均存在瓶颈。
当时经过压力测试,发现,在600个用户进行选课的时候,数据库服务器和应用服务器的压力均未产生瓶颈,而当达到800个用户的时候开始有失败产生,应用服务器的CPU空闲率较低,说明在大批量选课的时候应用服务器是存在瓶颈的。另外,原有数据库硬件配置低,存在性能瓶颈。
如何解决这个问题,王振华重点考虑改造系统架构,了解了一些高并发网站的结构。“高并发问题,并不是仅仅负载均衡器就能解决的,而是需要对动态的、静态的部分进行分离,四层分离,有可能七层分离,甚至于数据库要做集群。”
并且,高并发的网站,千万级规模的架构,也并不符合北邮的现实情况。这些大型网站要考虑负载均衡器、缓存服务器、应用服务器、数据库集群,内外部的负载均衡,传统SQL的集群,针对一些消费类的内容做SQL的消费队列等等。“北邮选课的规模还达不到这样的级别。”王振华说。
在分析过主要的原因及相关的高并发网站之后,王振华着手设计和调整架构:第一,简化结构适应校园网特点,第二,使用虚拟化简化Web应用服务器管理;第三,与其它业务系统共享资源。
效果评估
调整之后的北京邮电大学选课系统于2014年5月上线,顺利渡过了2014年6月和2015年1月的选课,没有再接到学生的抱怨。“实际上选课的高峰期,我们最关心的就是前半个小时,如果平稳过渡了,说明这个高峰期顺利就渡过去了。”北邮教务处徐老师介绍。
选课系统上线前,北邮还对其中的20台虚拟机进行了压力测试,对北邮教务系统的登录、选课、查询方案完成情况、查询成绩、老师录入成绩进行压力测试。经过测试,发现该系统在1000用户并发时均能保证响应时间在0.36秒左右,登录功能在1000并发时响应时间在5秒左右,塞车的问题、成绩数据丢失的问题不复存在。
选课系统是集中性很强的一个应用,而虚拟机的部署,也让更多的业务系统能够灵活地得到应用,“以SAAS的方式提供给用户,那是最理想的。这样,老师只需要关心空间租用和业务布置,这是一个更大的资源池,能更好地调配学校的资源,甚至能提供不同学校利用,各个学校选课的时间一错峰,大资源池大家租就可以了,不需要再购买硬件设备。”王振华展望未来时说。