从技术角度谈谈鹿晗恋情公布这个事儿...

StuQ · 公众号 · · 2017-10-09 19:30

正文

请到「今天看啥」查看全文

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

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

不可预测性的技术方案

不这么办，那怎么办？相信我们都能想得到，弹性伸缩嘛，混合云方案。好，回答正确。不过这里再往深里问个问题，弹性，弹的到底是什么？（先默认思考半分钟，再往下看）

弹性，弹的到底是什么？从目的看弹性弹的是服务能力，也就是弹性弹上去的一定是可以提供访问服务的能力，所以现在很多人一提弹性就是资源弹性，这是不准确的，资源拿到手了，但是提供不了业务服务能力又有什么用呢？

资源可以依赖各种私有云和公有云，特别是公有云上获取资源是非常方便的，但是服务能力的获取，就要看自身的架构水平和运维能力了，说具体点就是，是不是能快速部署、快速发布、快速服务上下线等等，这个才是弹性伸缩的核心和关键所在。

总结一句话就是，打铁还需自身硬！！

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

通过系统监控或舆情监控，发现热点事件，甚至提前预判可能有事件发生，启动扩容流程；
但是扩容前，或者扩容过程中，就已经有超大的流量涌入，这时的目标应该是保证系统在承诺容量内不挂，同时，将容量外的请求限流，将非核心功能降级。这个时候的核心一定是，系统不能挂。
快速扩容，但是扩容哪些应用和部件？每个应用和部件扩容多少？扩容顺序是什么？扩容自动化是不是可执行？这个就需要事先有对应的应急预案，并且演练过（没演练过就是耍流氓），出问题真的是能一键扩容就扩上去。