系统架构师谈网站的高可用性

Server 林涛 2769℃ 0评论

很多因素都会导致网站发生故障,从而影响网站的高可用性,比如服务器硬件故障、软件系统故障、IDC机房故障、程序上线前测试未发现的Bug、遭受分布式攻击、突发访问人数剧增等。

一套良好的网站系统架构,应该尽可能地避免只有一台服务器、一个数据库、一套软件节点等单点故障的存在。单点故障一旦发生,将直接导致网站服务不可用,恢复正常服务所需的时间也比较长,甚至还可能无法恢复。负载均衡集群、双节点热备、分布式处理等都可以用来解决单点故障,比如提供相同业务的Web服务器、MySQL数据库从库,都可以构建负载均衡集群。一旦集群中的一台服务器、一个服务出现故障,自动实时摘除,对用户来说是不可感知的,不会影响到整个网站的访问,可以为运维工程师留下足够的时间去排查和解决故障。

对于重要的MySQL数据库主库,我们习惯于从硬件层和软件层来实现热备,避免单点。越是复杂的设备,发生故障的概率越大。在磁盘没有损坏的情况下,应用程序导致服务器宕机的概率,远高于简单的磁盘阵列宕机的概率。所以,从硬件层解决的话,可以在两台服务器上安装相同的数据库版本、进行相同的配置,用SAS或SCSI线连接一台磁盘阵列,将数据库数据文件存放到盘阵上。正常情况下用服务器A挂载盘阵分区,启动MySQL,绑定虚拟IP;如果服务器A宕机,则用服务器B挂载盘阵分区,启动MySQL,接管虚拟IP。从软件层解决的话,则可以借助DRBD等软件做镜像。

IDC机房发生故障的概率较小,但如果发生的话,影响面也是最大的。如果所有服务器都托管在一个IDC机房,一旦该机房遭遇长时间流量攻击、断电、断网、地方政策性封网等,通常只能联系IDC去处理,除此之外束手无策,解决时间也比较长。如果成本允许,将网站服务器分布在两个以上的IDC机房,当某个IDC发生故障时,可以临时切换DNS域名解析来优先恢复服务。

虽然程序代码上线前,经过了测试人员的严格测试,但测试环境和生产环境毕竟有差异,所以一些会急剧影响性能、正常服务的Bug往往在程序上线之后,才会被发现,这就要求我们在发现Bug后,能够迅速回滚到上一正常版本。我们在SVN的基础上,开发了Web代码发布系统,会将每个发布版本之间的文件变更记录下来,一键实现程序代码在多台Web服务器上的发布和回滚。

遭遇DDOS分布式拒绝服务攻击,使用防火墙来对付半连接、假IP,还算比较容易。而那种专挑复杂动态应用程序URL进行的分布式CC攻击,来源为真实IP、真实HTTP请求,具有模拟正规浏览器User-Agent、单个IP的每秒请求数不高、有成千上万个攻击源等特征,很难与正常访问区分开,比较难对付。但是,正常通过浏览器访问一个URL,会加载该URL中引入的JavaScript脚本、CSS样式、图片等文件。遇到CC攻击,需要及时分析日志,找出访问量异常上涨的URL,然后用事先写好的shell脚本找出哪些IP的请求只访问了该URL,而不加载该URL引入的文件,对这些IP进行自动封锁。

系统架构设计时,需要事先考虑到高于目前访问量多少倍的突发访问。对于网游站点来说,访问量受广告集中时间段投放、线上活动的影响较大,带宽峰值时间不固定,对于静态内容,可以使用商业CDN,按实际使用量计费。对于动态内容,如果遇到突发访问人数剧增,超过现有服务器处理能力,最简单的临时处理办法就是增加服务器。上架新服务器需要时间,但是,同一个IDC机房内,可以借助其他业务的服务器,在不同端口开启一组新进程,加入到原有负载均衡池中。另外,可以临时关闭一些Web中的次要功能,来减少服务器消耗。

 

张宴:金山游戏运营技术中心技术经理。曾任金山游戏观望逍遥网家透视、新浪播客系统工程师。在web、数据库、视频、负载均衡、搜索引擎、数据挖掘、网游运营等领域有丰富的架构设计、项目管理、程序开发和系统运维经验。

如需转载请注明: 转载自26点的博客

本文链接地址: 系统架构师谈网站的高可用性

转载请注明:26点的博客 » 系统架构师谈网站的高可用性

喜欢 (0)
发表我的评论
取消评论

表情