5.5 封装和中间层思想
在功能块层次,如果使用JSP,基于纯面向对象语言Java的面向对象思想,类似数据库连接,会话管理等基本功能都已经封装成类了。如果使用PHP,则需要在脚本代码中显式的封装,将每一个功能块封装成一个函数,一个文件或者一个类。
在更高的层次,可以将网站分为表示层,逻辑层,持久层,分别进行封装,做到当某一层架构发生变化时,不会影响到其他层。比如新浪播客在一次升级的时候,将持久层的数据库由原来的集中式改为分布式架构,因为封装了数据库连接及所有操作[附录2],做到了不修改任何上层代码,平稳的实现了过渡。近来流行的MVC架构,将整个网站拆分成Model(模型/逻辑)、View(视图/界面)、Controller(控制/流程)三个部分,而且有很多优秀的代码框架可供选择使用, 像JSP的Structs,Spring,PHP的php.MVC, Studs 等。使用现成的代码框架,可以使网站开发事半功倍。
6 扩容、容错处理
6.1 扩容
一个大型网站,在设计架构的时候,必须考虑到以后可能的容量扩充。新浪播客在设计时充分地考虑了这一点。对于视频分享类网站来说,视频存储空间消耗是巨大的。新浪播客在主存储服务器上,采用配置文件形式指定每一个存储盘柜上存储的视频文件的ID范围。当前台服务器需要读取一个视频的时候,首先通过询问主存储服务器上的接口获得该视频所在的盘柜及目录地址,然后再去该盘柜读取实际的视频文件。这样如果需要增加存储用的盘柜,只需要修改配置文件即可,前台程序丝毫不受影响。
新浪播客采用MySQL数据库集群,在逻辑层封装了所有的数据库连接及操作。当数据库存储架构发生改变的时候,如增加一台主库,将某些数据表独立成库,增加读取数据用的从库等,都只需要修改封装了的数据库操作类,上层代码不用修改。
新浪播客的前台页面服务器使用F5公司的硬件第四层交换机,网通,电信分别导向不同的虚拟IP,每一个虚拟IP后面又有多个服务器提供服务。当访问流量增大的时候,可以很方便往虚拟IP后面增加服务器,分担压力。
6.2 容错
对于商业性网站来说,可用性是非常重要的。7*24的访问要求网站具有很强的容错能力。错误包括网络错误,服务器错误以及应用程序错误。
2006年12月27日台湾东部外海发生里氏7.6级地震,造成途径台湾海峡的多条海底电缆中断,导致许多国外网站,像MSN, NBA, Yahoo!(英文主站)等国内无法访问,但也有例外,以Google为代表的在国内建设有分布式数据节点的很多网站却仍然可以访问。虽然说地震造成断网是不可抗原因,但如果在这种情况下网站仍然可以访问,无疑能给网站用户留下深刻的印象。这件事情给大型商业网站留下的教训是:网站需要在用户主要分布区域保持数据存在,以防止可能的网络故障。
对于服务器错误,一般采取冗余设计的方法来避免。对于存储服务器(主要是负责写入的服务器),可以使用RAID(冗余磁盘阵列);对于数据库(主要是负责写入的主库),可以采用双主库设计[30];对于提供服务的前台,则可以使用第四层交换的集群,由多台服务器同时提供服务,不仅分担了流量压力,同时还可以互相作为备份。
在应用层程序中,也要考虑“用户友好”的出错设计。典型例子如HTTP 404 出错页面,程序内部错误处理,错误返回提示等,尽可能的做到人性化。
7 总结及展望
7.1 总结
对于一个高并发高流量的网站来说,任何一个环节的瓶颈都会造成网站性能的下降,影响用户体验,进而造成巨大的经济损失。在全互联网层面,应该使用分布式设计,缩短网站与用户的网络距离,减少主干网上的流量,以及防止在网络意外情况下网站无法访问的问题。在局域网层面,应该使用服务器集群,一方面可以支撑更大的访问量,另一方面也作为冗余备份,防止服务器故障导致的网站无法访问。在单服务器层面,应该配置操作系统,文件系统及应用层软件,均衡各种资源的消耗,消除系统性能瓶颈,充分发挥服务器的潜能。在应用层,可以通过各种缓存来提升程序的效率,减少服务器资源消耗(图6)。另外,还需要合理设计应用层程序,为以后的需求变更,扩容做好准备。
图6 典型高并发高流量网站的架构
在每一个层次,都需要考虑容错的问题,严格消除单点故障,做到无论应用层程序错误,服务器软件错误,服务器硬件错误,还是网络错误,都不影响网站服务。
7.2展望
当前Linux环境下有著名的LAMP(Linux+Apache+MySQL+PHP/PERL/PYTHON)网站建设方案,但只是针对一般的中小网站而言。对于高并发高流量的大型商业网站,还没有一个完整的,性价比高的解决方案。除去服务器,硬盘,带宽等硬件投资外,还需要花费大量的预算和时间精力在软件解决方案上。
随着互联网的持续发展,Web2.0的兴起,在可以预见的未来里,互联网的用户持续增多,提供用户参与的网站不断增加,用户参与的内容日益增长,越来越多的网站的并发量,访问量会达到一个新的高度,这就会促使越来越多的个人,公司以及研究机构来关注高并发高流量的网站架构问题。就像Web1.0成就了无数中小网站,成就了LAMP一样,Web2.0注定也会成就一个新的,高效的,成本较低的解决方案。这个方案应该包括透明的第三方CDN网络加速服务,价格低廉的第四层甚至更高层网络交换设备,优化了网络性能的操作系统,优化了读写性能,分布式,高可靠的文件系统,揉合了内存,硬盘等各个级别缓存的HTTP服务器,更为高效的服务器端脚本解析器,以及封装了大部分细节的应用层设计框架。
技术的进步永无止境。我们期待互联网更为美好的明天