今天上午8:30左右,不少用户集中反映,“粤省事”小程序里的“粤康码”打不开了。
在亮码的过程中,页面会出现“信号不佳”的提示,或是直接呈现黑白二维码,表示“亮码失败”。
下方的“核酸检测”和“疫苗接种”两栏都注明“升级维护,请稍后再试”。
图左为正常访问;图右为亮码失败
#粤康码#、#粤康码崩了#等词条迅速登上微博热搜。
事发六小时后,热搜词条仍然在榜
上午10:00之后,情况逐渐得到缓解。也有网友向雷峰网表示,自己的粤康码在十点左右还是黑白,但在十点半左右已经可以正常打开。
今日午间,当市民再度打开“粤省事”小程序里的“粤康码”,页面会首先显示公告称:
8:31,监测到流量增大;
9:04,部分缓解;
9:56,完全恢复顺畅运行。
而在粤康码崩溃的90分钟里,微信小程序“深i您”、“穗康码”,以及由国家政务服务平台提供服务的支付宝健康码,均可正常使用。
微信小程序“深i您”界面
“应该只有‘粤省事’这个渠道出了问题。‘深i您’和‘穗康码’都分别注明了‘粤康码(深圳/广州)’的字样,但一样可以正常打开。”有网友评论道。
公开资料显示,数字广东公司是粤康码系统以及全省数字政府建设的运营中心。“粤省事”移动政务服务平台,由腾讯与广东省合作开发。
在1月7日到1月9日的三天时间里,深圳新增四例本土确诊病例,深圳多区同时展开大规模核酸筛查。深圳以及广东其他市县的不少公共场所,都新增了入场前先亮健康码和核酸证明的防疫要求。
而今天(1月10日)正是深圳“0107疫情”发生之后的第一个工作日,不少上班族正是在进入地铁和办公园区的时候,发现粤康码打不开了。
这次故障的主要原因,多位业内人士表示,应该还是与高并发访问有关。
官方声明中提到:
今早的访问量峰值一度高达140万次/分钟。
而根据广州日报的报道,2021年5-6月广东曾爆发过一轮疫情,在此期间,粤康码进行过系统调优升级:
促使网关每分钟可承载的访问量从原来的10万+提升至60万+,每天的调用量从原来的10亿+提升至80亿+。
有业内人士指出,从两组数字的对比来看,粤康码系统今早确实显著承压。
“遇到高峰浪涌,爆服务器负载属于正常现象。”资深信息安全专家吴先生向雷峰网解释,就算有弹性资源自动扩容机制,生效也需要时间,扩容期间的请求还是会卡在队列里。
整个扩容流程大致是:浪涌到阈值——触发告警——触发扩容请求——分配资源——挂载镜像——服务启动——负载均衡器转发流量。
他强调,“扩容的每一步都是秒级反应,但第一步到最后一步之间,这段时间的请求,在重新请求之前都卡着。如果浪涌太快,需要连续申请资源,还是会卡不少时间。”
举个例子:
假设队伍负载是100(100进100出)一旦溢出,假设每次扩容20%,扩容用时10秒;
某一秒的峰值到达130,触发告警;
10秒后扩容至120,不够则继续扩容;
但在这10秒内,超出能力的请求数量可能已经累积了300个,响应还是很慢,只能等着队列超时后重新分配,或者卡进去。
这还不包括“卡了之后重新请求——造成流量异常上升”的情况。
也就是说,即便扩容只需要十秒钟,但就在这十秒钟之内,问题还在不断堆积;自动扩容后的能力,也未必能应对十秒之后的新情况。
这种“访问量激增导致亮码失败”的情况,可以通过提前扩容来应对吗?
“很难,除非准确预测流量曲线。”吴先生说。
某灾备厂商告诉雷峰网,此次崩溃,可能与项目方“只做了数据级容灾、没做应用级容灾”有关。
但多位技术专家也给出了相反的看法,指出应用级灾备是“高投入、价值低频且难以度量”,在大多数时候“相当于服务能力成倍冗余”。
应用级容灾确实更能确保业务的连续性,但不同于云服务弹性扩容,这需要长期占用固定投资,且资源平时无法通过灵活应用产生其他价值。
我们可以把弹性扩容看作是搭帐篷,用途多变,启用和收回也十分灵活;而应用级灾备就像是直接建造一处特定用途的楼房,确实稳定坚固,但成本高出不少,因此有专家认为,“建设应用级容灾并不是理想的解决办法。”
此次粤康码无法正常访问,也让许多人联想到不久前西安一码通的两轮崩溃。不少各地网友表示,自己所在地的健康码也出现过亮码缓慢的情况。
钛媒体的报道中指出,西安一码通是“一起因流量过载、系统架构应对高并发不足,最终导致防火墙拦截数据无法返回的系统性故障。”也有技术专家表示,相信西安一码通存在一定的系统架构设计硬伤,没有充分考虑扩容的情况。
有业内人士强调,粤康码、西安一码通的亮码失败,确实都与高并发访问有关,但无论是何地的健康码,实际情况都不可一概而论,不意味着西安一码通的根本问题也出现在了其他地区健康码身上。
但需要注意的是,健康码因高并发而亮码缓慢、甚至崩溃的背后,不只是容灾、扩容这些相对浅层的技术问题。
“健康码是一个融合多系统的产品,不是某个单一软件公司可以覆盖的。”IT咨询专家阿鲲(化名)向雷峰网(公众号:雷峰网)分析称,健康码系统目前的关联方应该包括:
信通院整合的三大运营商(定位及轨迹);
各地的疾控中心(核酸检测结果,疫苗接种结果);
产品前端(微信、支付宝小程序);
产品的运营(实际健康码的加工和生成,数据整合,日常运营等)
其他关联方,如云服务、防火墙的提供商。
整体架构上,应当是有一个后台和一个前端,都架在政务云上:
后台采集各渠道数据,包括定位轨迹,核酸,疫苗等,统一加工后生成健康码;
前端对接各渠道,从前端获取客户身份信息,到后台查询健康码,并生成码值展示。
一个看似简单的健康码,内部涉及的产品和运营方太多,协调难度相当大;而且技术能力参差不齐,容易被木桶的短板所拖累。
“就算各方负责的部分都没问题,合起来也可能会有一堆毛病,就像一个人四肢健全却无法正常行走。”另一位技术专家强调。
而项目牵头者、实施方都有可能对健康码的定位理解不准确,“项目是按政务系统来做的,但这是面向全网C端的大流量架构——理论上是to G,实际上应该是to G to C。”阿鲲说。
再加上健康码的特殊性,项目上线时间紧迫,往往未能经过完整压测;上线后又面临巨大的运营压力,腾不出人手和资源进行优化。因此系统的整体架构耦合太强,健壮性不够。
同时他也强调,全国各地各自为战,数据未整合,且各地的数据、架构都不同,导致每个省各显神通,也和当地的信息化基础设施密切相关,没有统一的标准方案。
健康码的真正考验,是顶层设计能力和协同一致能力,是项目内部各方、项目与其他数字基础设施的协调。在疫情联防联控成为日常所需的今天,这将会是每个城市长久面对的考题。