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

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

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

最后

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

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