zoukankan      html  css  js  c++  java
  • [转]网站访问量剧增时解决方案

       某网络公司是新成立的B2B企 业。当时,我是技术主管,担任这家公司网络平台的架构、开发和管理的工作。在技术部同事的日夜奋战下,不到一个月我们的网络运营系统就全面上市了。之后三 个月的运行过程中,系统除了修改当时需求不明确的地方外,运行相对稳定。当时的日访问量已经达到100万,Aleax排名在20万名。

    我们的工作越来越轻松,每天就是检查各站点是否正常,看着访问量不断增加。同时,我们也不忘未雨绸缪,开始向老板提出新的服务器方案。但公司当时决定把大量的资金投入到广告上,基本不考虑我们的方案。

    直到有一天,技术部电话突然成了热线……

    日均访问量5000万

    那天,我刚到公司就接到业务部电话说网站打不开了。又过一会儿,老板也打来电话问我们的网站怎么打不开。没过几分钟,老板再次打来电话说:“杨工,我们目前在各大门户网站、搜索网站投入了大量广告,赶紧找到网站打不开的原因,否则一天巨额的广告费就损失了。”

    经过技术部同事的努力,网站很快恢复了正常。但不一会儿所有部门又都打来电话说网站打开什么都没有。技术部的工程师打开来看,的确如此。我心想:“这是怎么回事?刚才不是已经恢复了吗?”

    这次,我先让网站正常运行起来,然后查看早上的系统日志。结果发现,早上网站一直是 停止的,最后的日志是早上六点多的。可以肯定,它从六点到上班都不是正常服务的。进行Windows的TCP/IP连接分析和服务状态分析后我们得知,在 这几天网站每天总的页面访问量均达到了5000万。

    网站宕机的原因终于弄清了,那就是大量的广告投入使每天网站的总页面浏览量超过5000万。这完全不在技术方案的预料中,而且公司的大量广告投入技术部事先也不知道。这让我们措手不及。

    那几天我们上班不做别的,就8小时盯着服务器,一发现应用服务器内存/连接过高时, 就重起服务。这样基本上可以在3~5秒钟之内完成服务的重起,网站基本保持不中断。但可怕的是8小时之外,当所有人都下班了,要是服务停止,基本上就要等 到第二天才有人知道。那几天,每天晚上基本上老板都会打电话来说网站打不开,要求马上处理。由于晚上访问的人数相对要少些,基本上是重启一次就可以坚持到 第二天早上。就这样一天一天地过去,我们对服务器的管理非常被动。我们一边采用定时检查服务的方法来维持系统的运行,一边讨论解决方案。

    公司重要的营销计划,只要与IT系统有关系,就都要与IT部门提前沟通,否则后果会很严重。

    第一步:重新规划

    经过讨论,我们决定对网站软、硬件结构进行重新规划,主要采用细分频道、前端缓存技 术、负载均衡、静态页面等技术。我们经过仔细分析发现,公司网站的基础架构的确存在一些先天的不足,比如:所有频道都在同一应用程序服务器中运行;只有一 台Web服务器,没有做负载均衡;所有页面数据均在访问时从数据库中产生;项目本身需求不明确,对网站的进程没有明确等。这些都是导致系统没法应对突发其 来的高访问量的直接原因。

    针对这些不足,我们分别采取了以下措施:首先,采用多应用程序服务器、分频道的方 式,分散网站的频道到不同的应用程序服务器中,减轻同一应用程序服务器的压力。其次,在所有应用程序服务器前端加了缓存服务器和负载均衡器,达到分流的目 的。另外,我们通过生成静态页面,把以前在访问时才调用的数据库中的数据全部生成HTML文件。这主要是考虑内容系统,静态页面可以让缓存服务器达到更好 的缓存效果,同时也能大大减轻数据库、应用程序的压力。新方案的实施仅用了一周时间,我们就把以前的网站分成了几个频道,并加了负载均衡和缓存,这大大增 加了网站的稳定性。网站宕机的频率越来越小,整个技术部又恢复了以前的平静。

    但是,无论多稳定的系统总是会有出问题的时候。为保证公司系统正常运营,我们在8 小时内间隔性地查看各服务器的工作状态,比如不定时地查看各服务器的CPU使用率、内存使用、磁盘空间、应用服务器工作状态、APACHE的服务状态、 Oracle会话数、Oracle死锁会话等。

    但是随着公司业务的增加,服务器也开始迅速地增加,后来达到了四十多台。要一台一台地检查这些系统的运行状态就得一台一台地登录其中进行详细查询,这种被动的服务器管理使得我们的服务器运维成本越来越高。

    在充满机会的时代,今天的小公司没准就是明天的巨人。所以,IT系统规划不能只满足当前需要,而是要着眼于未来,考虑长远,适应业务快速发展的需求。

    第二步:集中管控

    当时,网站普遍存在的问题是异常情况出现后,直接负责人不能即时发现。即使直接负责 人有时发现了异常,由于受到时空的限制(比如无互联网、外出等)也不能即时处理服务器的故障,使得服务器出现故障后不能即时恢复。这些故障如果出现在核心 系统中还可能导致更严重的经济损失。比如,如果是制造企业的MIS系统出现故障而没有能及时发现和处理,每一小时损失可能就是上百万元。

    工程师定时登录服务器查询各服务器的状态、性能、服务运行状态固然是一种维护服务 器稳定运行的有效方法,但是人为被动地去查询总是不方便的。因为首先,人不可能24小时不间断地检查服务器的运行状态;其次,当服务器越来越多时,每一次 检查都将占用一上午甚至更长的时间,运维时间成本将不堪重负;同时,24小时值班监视服务器,人力成本也越来越高。

    技术部多次讨论,设想如果能开发一套监控管理系统就好了,但是人力紧张,远水救不了近火。

    如果采用一个平台来集中监控和管理所有服务器,以上问题将都不存在,同时网络运维人 员也不再用24小时值班和定时查询服务器的运行状态了。集中监控系统将代替运维工程师实时监控所有服务器的运行状态和各种性能参数,并在不正常时以短信、 电子邮件等方式向直接负责人实时报警,使得服务器的离线时间、异常时间减到最少。

    最终,我们选用了上海哲涛科技研发的SUM(服务器集中监控与管理平台)来实现服务器(异构)和网络设备的集中监控。通过SUM,运维管理人员只需要登录系统就会立即查看到哪些设备正常工作、哪些设备的哪些性能有异常。

    去年国庆节,技术部用手机查看服务器运行状况,发现网站的访问量真高,不过网站运行一切正常。即使宕机也不怕了,因为用手机就可以重起服务器了。

    技术人员会想自己做工具,这既可满足个人的虚荣心,又可以在短期节约成本。但从长期成本和系统稳定性来看,还是买一个工具合算。

  • 相关阅读:
    Apache Ant 1.9.1 版发布
    Apache Subversion 1.8.0rc2 发布
    GNU Gatekeeper 3.3 发布,网关守护管理
    Jekyll 1.0 发布,Ruby 的静态网站生成器
    R语言 3.0.1 源码已经提交到 Github
    SymmetricDS 3.4.0 发布,数据同步和复制
    beego 0.6.0 版本发布,Go 应用框架
    Doxygen 1.8.4 发布,文档生成工具
    SunshineCRM 20130518发布,附带更新说明
    Semplice Linux 4 发布,轻量级发行版
  • 原文地址:https://www.cnblogs.com/qqflying/p/1635823.html
Copyright © 2011-2022 走看看