今天上午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。”阿鲲说。
再加上健康码的特殊性，项目上线时间紧迫，往往未能经过完整压测；上线后又面临巨大的运营压力，腾不出人手和资源进行优化。因此系统的整体架构耦合太强，健壮性不够。
同时他也强调，全国各地各自为战，数据未整合，且各地的数据、架构都不同，导致每个省各显神通，也和当地的信息化基础设施密切相关，没有统一的标准方案。
健康码的真正考验，是顶层设计能力和协同一致能力，是项目内部各方、项目与其他数字基础设施的协调。在疫情联防联控成为日常所需的今天，这将会是每个城市长久面对的考题。
