【51CTO.com原创稿件】引用51CTO开发者QQ交流群中对“鹿晗关晓彤公布恋情，是如何把新浪微博的服务器搞垮的”这个话题的深入讨论，特整理出从开发者和运维工程师的角度来应对服务器遇到流量峰值的处理措施。以下内容来自群里小伙伴们的观点分享。
10月8日，在十一长假的最后一天，微博搜索工程师丁振凯发微博 “埋怨”鹿晗，称：“服务器稳定了，岳父喊我喝酒去了，都是鹿晗干的好事！”起因是当红流量小生鹿晗发了一条“大家好，给大家介绍一下，这是我女朋友@关晓彤”的微博，全世界的女鹿饭同时失恋造成了微博服务器的宕机。
到底是什么毁了程序员的婚礼？
关于这场浩劫的原因这几天一直众说纷纭。微博官方的说法是因为单条微博转发、评论次数太多了造成数据库崩溃。很显然这是不全面的，微博这个级别的数据量放在平时也不是传统的分布式架构就能抗住的。况且鹿晗的这条微博既不是有史以来被转发最多的，也不是有史以来收到评论最多的一条微博。
51CTO开发者交流群昵称为Java-阿飞-南京的小伙伴提出了问题出在算法上，自动扩容的算法没有写好，或者干脆没把希望寄托在算法上而是全靠人肉运维却赶上了休假。这种说法是认可度最高的，但群友Android-小孔-合肥却不敢苟同：算法不是不好，而是太好了，因为没写好算法的化，服务器延迟几秒，此事就不了了之了；但如果服务器反应非常灵敏，那么很快就会不堪重负。
云计算-恩威-成都则把锅甩给了运营商：节假日期间中国电信IDC全网封网，停止了一切工程施工、系统割接、网络和数据调整等工作导致了运维无法到位。
最后51CTO开发者交流群的群友们还有几种开玩笑的说法：Android-jqorz-合肥说是微博的运维妹子是女鹿饭，一吃醋就故意让服务器出故障；而从事安全行业的小新（安全-小新-北京）则说是鹿晗的黑粉有懂技术的，在这个节骨眼上捣鬼。言者无意，听者有心，安全问题也是网络运维的重要环节，况且以国内网民的数量来看，任何吸引全国网民访问的事件都是一场大规模的DDOS攻击。
微博用什么避免此次事故
国内运维人员应对流量峰值的传统方法有提前申请足够甚至冗余的设备和降级非核心及周边的业务两种，但不可避免带来成本高昂、业务负载饱和度不一、扩缩容流程繁琐等问题。
微博目前应对流量峰值的机制是新浪微博混合云DCP项目，能根据容量情况进行自动的弹性伸缩。首先建立统一的设备资源管理池，然后将服务部署在基于 Docker 的云化架构上；在业务上需要尽心对传统业务进行微服务化、消息化等改造；在平台上，需要打通持续集成平台以及实现多租户隔离、弹性伸缩、故障自愈等能力。最后用统一的监控平台实现人肉运维紧急支援。
目前DCP 已经具备 20 分钟内弹性扩容千台服务器规模的能力，即公有云要满足10分钟内完成上千台服务器的创建与交付，同时私有云平台则在接下来的10分钟内完成服务器的初始化、服务调度、上线等全流程。这就保证了当流量峰值来临时DCP平台可以迅速调度部署公有云服务器解决私有云短时间无法迅速扩容服务器的问题。同时公有云的按量弹性需求也可以降低大量成本，事实上此次事故中靠人工临时增加的服务器也在几个小时后退订了。
微博混合云平台DCP可以说是万无一失，但到了史无前例、并且恰好赶在假期的流量峰值面前却仍然因为没有可行的、立竿见影的预案执行，最后还是用临时靠人工增加服务器数量的笨方法解决了问题。所以自动化运维工作仍然任重而道远。
大数据时代的运维要从这个灾难中学到什么
随着网民数量的剧增和大数据时代的到来，这次的峰值将在不久的将来变成家常便饭，几小时之内紧急增加1000台临时服务器很明显指标不治本，运维人员要从这个灾难中学到什么呢？
应对流量峰值要从集群、负载均衡和分布式三个方面入手：
所谓集群，就是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。集群有两大特性——可扩展性、高可用性都是为失效转移这一目标服务的。
所谓负载均衡，就是把任务分摊到多个操作单元上进行执行，是一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性的方法。
所谓分布式，就是将数据分散的存储于多台独立的机器设备上、利用多台存储服务器分担存储负荷、利用位置服务器定位存储信息的技术。分布式与集群的区别在于分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
