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

阅读数:1 2020 年 3 月 18 日 20:12

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

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

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 稳定性保障那本书,介绍的比较详细,上面提到的压测、容量评估、预案等等都有涉及,还是很不错的。

最后

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

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

本文转载自成哥的世界公众号。

原文链接: https://mp.weixin.qq.com/s/26rTkXmdjVf0OW75Cm4b2Q

评论

发布