视点·观察|粤康码“崩溃”的90分钟:到底发生了什么?( 二 )


促使网关每分钟可承载的访问量从原来的10万+提升至60万+,每天的调用量从原来的10亿+提升至80亿+ 。
有业内人士指出,从两组数字的对比来看,粤康码系统今早确实显著承压 。
“遇到高峰浪涌,爆服务器负载属于正常现象 。”资深信息安全专家吴先生向雷峰网解释,就算有弹性资源自动扩容机制,生效也需要时间,扩容期间的请求还是会卡在队列里 。
整个扩容流程大致是:浪涌到阈值——触发告警——触发扩容请求——分配资源——挂载镜像——服务启动——负载均衡器转发流量 。
他强调:“扩容的每一步都是秒级反应,但第一步到最后一步之间,这段时间的请求,在重新请求之前都卡着 。如果浪涌太快,需要连续申请资源,还是会卡不少时间 。”
举个例子:
假设队伍负载是100(100进100出)一旦溢出,假设每次扩容20%,扩容用时10秒;某一秒的峰值到达130,触发告警;10秒后扩容至120,不够则继续扩容;但在这10秒内,超出能力的请求数量可能已经累积了300个,响应还是很慢,只能等着队列超时后重新分配,或者卡进去 。这还不包括“卡了之后重新请求——造成流量异常上升”的情况 。
也就是说,即便扩容只需要十秒钟,但就在这十秒钟之内,问题还在不断堆积;自动扩容后的能力,也未必能应对十秒之后的新情况 。
2、应对之法:不只是扩容问题
这种“访问量激增导致亮码失败”的情况,可以通过提前扩容来应对吗?
“很难,除非准确预测流量曲线 。”吴先生说 。
某灾备厂商告诉雷峰网,此次崩溃,可能与项目方“只做了数据级容灾、没做应用级容灾”有关 。
但多位技术专家也给出了相反的看法,指出应用级灾备是“高投入、价值低频且难以度量”,在大多数时候“相当于服务能力成倍冗余” 。
应用级容灾确实更能确保业务的连续性,但不同于云服务弹性扩容,这需要长期占用固定投资,且资源平时无法通过灵活应用产生其他价值 。
我们可以把弹性扩容看作是搭帐篷,用途多变,启用和收回也十分灵活;而应用级灾备就像是直接建造一处特定用途的楼房,确实稳定坚固,但成本高出不少,因此有专家认为,“建设应用级容灾并不是理想的解决办法 。”
此次粤康码无法正常访问,也让许多人联想到不久前西安一码通的两轮崩溃 。不少各地网友表示,自己所在地的健康码也出现过亮码缓慢的情况 。
钛媒体的报道中指出,西安一码通是“一起因流量过载、系统架构应对高并发不足,最终导致防火墙拦截数据无法返回的系统性故障 。”也有技术专家表示,相信西安一码通存在一定的系统架构设计硬伤,没有充分考虑扩容的情况 。

推荐阅读