前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >从技术角度谈谈鹿晗这个事儿

从技术角度谈谈鹿晗这个事儿

作者头像
赵成
发布2018-08-09 09:47:02
1.3K0
发布2018-08-09 09:47:02
举报
文章被收录于专栏:Forrest随想录

关于鹿晗事件拖垮微博这件事,分享下我的理解。只做客观分析,不吹,不喷,不黑,因为这个事情绝对不是像网上传的,什么微博架构烂、技术不行、可扩展性差、控制预算成本所以节省服务器、或者是运维要背锅等等,绝对不是这么不痛不痒的几句风凉话就能简单解释清楚的。

1、系统压力的可预测性

可预测性,简单点解释,像电商每年大促618、双11、双12等等,这些峰值和压力是相对可预测的,因为峰值就是出现在某几个固定的时间点,这个是可以预见到的,我们所做的所有准备工作和容量评估的目标,都是针对这几个固定时间点的。

峰值压力可预测,就意味着可以提前做一些用户访问模型进行压测验证,发现系统中的瓶颈,然后调优和扩容,调整完成之后,继续压测,继续调整,直至系统容量达到原来设定的目标。而且,在大促前,系统已经扩容至应对峰值状态的容量,而且不允许再随意变更,最后就是等着用户流量过来,所以可预测的场景下,这个过程就会相对从容很多。

用户流量来了,在峰值那个时间点上,通常用户流量是远远大于系统容量的,这个时候要做的不是扩容,而是限流降级,只要能让系统在承诺的容量内运行,多余的流量暂时限制掉,等这一波流量过了,用户自然会访问进来。所以双11也好,618也好,你0点那个峰值去访问天猫或者京东,很大概率上都会提示你小二正忙,请稍后再试,但这不是代表天猫和京东挂了,而是其采取的一种保护措施而已,所以,大促预案非常完善,也要演练很多轮。

但是这个时候,通常是不会允许随随便便做扩容的,因为单个点上做了扩容,容量加大了,但是依赖方没有做相应的扩容,就更容易出现问题,所以,大厂技术再牛逼,也不会赶在大促峰值那个点上去做什么扩容和变更,除非是真的挂了,或者长时间业务无法恢复。

2、系统压力的不可预测性

不可预测,就更为复杂,社交类业务就具有这种明显的特征,比如微博、朋友圈、空间等等,说人话就是,比如这次鹿晗的事情,还有之前王宝强事件、乔任梁事件等等,这些事情什么时候发生你完全不知道,而且极有可能是大V的即兴发挥。而且每种场景特点还不一样,比如乔任梁事件,用户可能会更多的评论和转发,点赞肯定不多。但是鹿晗这个事,就可能会既有点赞,又有转发和评论,同时还连带着关晓彤的微博一起疯狂。但是到底是什么样子,会吸引多少用户流量进来,在它发生之前,谁也不知道。所以,这个是不可预测的。

对于不可预测性的场景,就要有电商大促所采取的不一样的技术方案,前面讲到,电商大促一定是会提前做好准备,但是微博没法提前准备,只能随时准备着,因为不知道什么时候会出现突发地热点事件(注意,是突发)。

但是任何一家公司都不可能在线上放着成百上千万money的设备在那里始终Ready做冗余,对于微博这次事件,按照微博CEO分享的数据说是扩容了1000台服务器上去,这个成本如果是固定资产,就要几千万,这还不算增加的网络设备数量,机柜费用,以及运维成本。放心,任何一家公司都不会这么干。所以,那些说微博控制成本精简费用不给服务器导致系统挂了的,可以洗洗睡了。

3、不可预测性的技术方案

不这么办,那怎么办?相信我们都能想得到,弹性伸缩嘛,混合云方案。

好,回答正确。不过这里再往深里问个问题,弹性,弹的到底是什么?(先默认思考半分钟,再往下看)

弹性,弹的到底是什么?从目的看弹性弹的是服务能力,也就是弹性弹上去的一定是可以提供访问服务的能力,所以现在很多人一提弹性就是资源弹性,这是不准确的,资源拿到收了,但是提供不了业务服务能力又有什么用呢? 资源可以依赖各种私有云和公有云,特别是公有云上获取资源是非常方便的,但是服务能力的获取,就要看自身的架构水平和运维能力了,说具体点就是,是不是能快速部署、快速发布、快速服务上下线等等,这个才是弹性伸缩的核心和关键所在。 总结一句话就是,打铁还需自身硬!!

所以,出现问题就得要最短的时间内扩容上去,这个就极度考验技术积累和功底了,对于这次事件,我YY下微博的大致处理过程应该是这样的:

1、通过系统监控或舆情监控,发现热点事件,甚至提前预判可能有事件发生,启动扩容流程;

2、但是扩容前,或者扩容过程中,就已经有超大的流量涌入,这时的目标应该是保证系统在承诺容量内不挂,同时,将容量外的请求限流,将非核心功能降级。这个时候的核心一定是,系统不能挂。

3、快速扩容,但是扩容哪些应用和部件?每个应用和部件扩容多少?扩容顺序是什么?扩容自动化是不是可执行?这个就需要事先有对应的应急预案,并且演练过(没演练过就是耍流氓),出问题真的是能一键扩容就扩上去。

4、关注扩容是否有效果,业务是否恢复,不行就再考虑是否有预案支持,如果扩容都没有效果了,那说明实际面对场景下的访问模型,已经大大超过软硬件架构设计的扩容和支撑能力了,这个时候通常的做法就是继续限流降级,优先保住系统不挂,然后静静地等待粉丝们的热情降下去。

这里关于软硬件架构设计出现容量瓶颈,再多说一点,因为这是个极其无比蛋疼的问题。比如瓶颈出现在DB了,DB一般可能是做了分库分表的,但是如果发现分的不够多,这个时候动DB就不现实了,重新分散数据,重新做路由配置,这就是极不现实的事情,除非用了想TiDB这样可以随时水平扩展的数据库。再比如带宽问题,如果发现交换机的带宽已经打满了,你说这个时候扩容交换机,就更不现实了。

以上这些,从今天的表现看,可以很负责任的说,微博技术团队做地比国内绝大多数公司都要超前和先进,至少微博服务不是完全不可用,只有鹿晗和关晓彤相关的访问有问题,说明故障隔离做地还可以;虽然慢了点,但是多点击两次还是能打开,说明限流降级措施也做了,但效果有待提升;最后,通过增加服务器扩容的方式解决了问题,1000台服务器扩上去,这不是个简单的事情。

为什么说不简单,我再说一个我举了N多遍的例子,一个应用从获取到资源,到部署到机器上,然后服务上线提供服务,这个过程能不能完全人工无介入,全程自动化?可能很多公司这一步都还做不到。

如果能做到自动化,短时间内,1000台服务扩上去,效率是否足够高,成功率是否足够高?这些都是很有挑战性的。

所以,从纯技术层面,我觉得微博今天做地还不错。当然,之前我也听过不少的微博技术分享,也跟微博工程师做过很多交流,也大致了解微博在这块做的事情,所以这里客观分析,不吹不黑。

4、那为什么还会挂

但是,你说做的不错,上面都做到了,那为什么还会挂?这里就有个非常关键和要命的点,不管是可预测还是不可预测的事件,我们前面也不断的提到的,就是用户访问模型,这个东东是个极不确定的因素,非技术问题,但却又是稳定性保障的关键因素。

还是举个栗子,微博的访问模型我没有研究过,我说个电商的可能会更好理解一些,思路上是差不多的,拿大促用户下单这个逻辑来说,一个用户在购物车勾选商品去结算:

是同时下1个商品的订单,还是5个商品订单,还是10个商品订单?每个商品购买数量是1个、2个还是3个?购买数数量有没有限制?这些商品涉及1个卖家,还是3个卖家,还是8个卖家?卖家必然有不同的优惠折扣,是买二送一,还是满100送20?30?50?,还是满一定额度之后是否包邮?全站促销是否有全站优惠,是否有时间段限制?优惠之间是否有优先级和互斥逻辑?优先使用支付宝,还是微信,还是银行卡支付等等等等。

以上这些是我随手敲出来的,还只是针对一个用户的,用户数量几十万,上百万之后,不同模型再配置个比例,再加上用户访问首页、详情、搜索的情况,场景更复杂,更可怕的是,实际场景比这要复杂N多倍。所以,这里主要想表达的就是,整个业务模型中的变量因素非常多,且不确定,但是一个因素的变化,就有可能带来容量模型不一样,比如1个商品,1个卖家,1个优惠策略,对DB产生的QPS是20,TPS是10,但是这其中的因素稍微一变化,产生的QPS和TPS就是翻倍的,而这一点评估不到位,大促时的用户场景跟预估的偏差过大,系统可能就会挂掉。

对于稳定性而言,用户访问模型才是做容量规划和保障的关键,这个摸不准,光有技术是没用的。但是这个地方难就难在,你不知道海量用户在那一个时刻真实的访问行为是怎么样的,所以就更加需要我们要能够深入业务,理解业务。而前面提到的工具和平台等技术手段反而是明确的(但是真正能做的很好的也没几个)。对于微博来说,这个问题表现的就更突出,比如今天的鹿晗事件:

a、谁也不知道鹿晗会突然发这条微博,关键是还同时艾特了同样是大V的关晓彤;

b、鹿晗是超级大V,可能有专门的热点应对方案,但是关晓彤今天之前估计谁也预计不到也会产生这个效果,热点方案是否足够有效;

c、其他超级大V也过来凑热闹,比如邓超,粉丝数超6千万的超级大V,产生的效应就是叠加的;

d、两个人大量的涨粉,还有大量衍生出来的各种传闻谣言等;

e、国庆期间没啥大事很消停,可能有很多用户都不咋用微博,但是这个事情一出来,可能N久不用微博的人都开始上来凑热闹了,有可能通过搜索进来,有可能通过分享进来,有可能通过关注进来,其它留言、点赞、转发就不用说了。实际情况会更复杂,我没研究过就不瞎说了。

不过可以肯定的是,这个模型一定是跟平时正常时期的热点访问模型不一样的,对于微博技术团队来说极有可能是没有遇到过这样的访问模型,今天突发,自然也就是没有对应的立马见效的预案执行,或者执行了没有马上见到效果,只能摸索着尝试。

关于稳定性保障,可以看天猫双11稳定性保障那本书,介绍的比较详细,上面提到的压测、容量评估、预案等等都有涉及,还是很不错的。

最后

不管怎么样,任何时候出现技术问题,技术团队都不会推卸责任,不管是能力问题还是经验问题,但是这个时候就看整个氛围的宽容程度,是否能够给技术团队足够空间和容忍度,这一点对于技术团队发展非常重要。

容量和稳定性问题,有时候不是简简单单成本和钱的问题,甚至这个东西拿钱是换不来的,业务体量和复杂度到了一定程度,就是靠工程师的水平和能力,以及对业务的深入理解,再就是一点点的经验积累和痛苦经历磨练,相信这样的故障过后,微博的技术水平又会被磨练出一个更高的水平,也期望见到更多这方面的分享。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-10-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Forrest随想录 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1、系统压力的可预测性
  • 2、系统压力的不可预测性
  • 3、不可预测性的技术方案
    • 4、那为什么还会挂
      • 最后
      相关产品与服务
      弹性伸缩
      弹性伸缩(Auto Scaling,AS)为您提供高效管理计算资源的策略。您可设定时间周期性地执行管理策略或创建实时监控策略,来管理 CVM 实例数量,并完成对实例的环境部署,保证业务平稳顺利运行。在需求高峰时,弹性伸缩自动增加 CVM 实例数量,以保证性能不受影响;当需求较低时,则会减少 CVM 实例数量以降低成本。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档