今天上午8:30左右，许多用户报告“广东省”小程序中的“粤康码”无法打开。
在高亮显示过程中，页面会出现“信号差”提示，或直接显示黑白二维码，表示“高亮显示失败”。
下面的“核酸测试”和“疫苗接种”列显示“升级维护，请稍后再试”。
左边是正常访问；右边是亮码故障
#粤康码、#粤康码破产等条目迅速登上微博热搜索。
事件发生6小时后，热门搜索条目仍在列表中
上午10点以后，局势逐渐缓和。一些网民告诉雷峰，他们的粤康码在10:00左右仍然是黑白的，但它可以在10:30左右正常开放。
今天中午，当公众再次打开“广东省”小程序中的“粤康码”时，该页面将首先显示一条通知，上面写着：
8:31.检测到流量增加；
9:04，部分缓解；
9时56分，完全恢复平稳运行。
在粤康码崩溃后的90分钟内，国家政府服务平台提供的微信小程序“深度我有”、“穗康码”和支付宝健康码都可以正常使用。
微信小程序“深度我有”界面
"只有“广东省”频道应该有问题“深圳游”和“穗康代码”分别标有“粤康码（深圳/广州）”字样，但可以正常打开。”一些网友评论道。
公开信息显示，数字广东公司是粤康码系统的运营中心，也是全省数字政府建设的中心。”“广东省事”移动政务服务平台由腾讯与广东省共同开发。
1为什么会崩溃？或高并发池
在1月7日至1月9日的三天内，深圳新增了4例本地确诊病例，同时在深圳多个地区进行了大规模核酸筛查。深圳等广东市县的许多公共场所在入场前都增加了照明卫生规范和核酸证书的防疫要求。
今日(一月十日)是深圳发生"0107疫症后的第一个工作日。许多上班族发现粤康码在进入地铁和办公区时无法开门。
许多业内人士表示，这一失败的主要原因仍应与高并发访问有关。
官方声明提到：
今早的高峰访问次数高达140万次/分钟。
据《广州日报》报道，2021年5月至6月，广东爆发了一轮疫情。在此期间，粤康码进行了系统优化升级：
将网关每分钟的访问量从原来的100000+提升到600000+，每天的通话量从原来的10亿+提升到80亿+。
业内人士指出，从这两组数字的对比来看，粤康码的系统今天上午确实承受着巨大的压力。
"高级信息安全专家吴先生（NicholasTse）向雷峰（JetLi）解释说，即使有自动弹性资源扩展机制，也需要一段时间才能生效，扩展过程中的请求仍然会卡在队列中。
整个扩容过程大致如下：激增到阈值-触发警报-触发扩容请求-分配资源-装载映像-服务启动-负载均衡器转发流量。
他强调,"容量扩展的每一步都是第二个响应，但从第一步到最后一步的请求在重新请求之前都会被卡住。如果激增太快，你需要不断申请资源，这仍然需要很多时间。”
例如：
假设队列负载为100（100in，100out），一旦溢出，假设每次扩容需要20%，扩容需要10秒；当一秒的峰值达到130时，会触发报警；10秒后，扩容到120，如果不够，容量扩展将继续；但是，在这10秒钟内，超过容量的请求数可能已累积300个，响应速度仍然非常缓慢。您只能等待队列超时、重新分配或卡住。这不包括“刷卡后重新请求-导致流量异常增加”的情况。
换言之，即使扩容只需10秒钟，问题仍在这10秒钟内累积；自动扩容后的容量可能无法应对10秒钟后的新情况。
2如何应对：这不仅仅是容量扩张
我们能否通过提前扩容来应对这种“流量激增导致亮码失效”的局面？
"除非准确预测流量曲线，否则这是很困难的。”吴先生说。
一家灾难恢复制造商告诉雷峰，崩溃可能与项目方的“仅数据级灾难恢复，而非应用程序级灾难恢复”有关。
然而，许多技术专家也给出了相反的观点，指出应用级灾难恢复“投资高、价值低、难以衡量”，在大多数情况下“相当于服务能力的多重冗余”。
应用级容灾可以更好地保证业务连续性，但不同于云服务弹性扩容，需要长期占用固定投资，资源无法通过灵活的应用产生其他价值。
我们可以把弹性扩容想象成一个帐篷，具有多变的用途和灵活的使用和回收。应用程序级灾难恢复类似于为特定目的直接构建一个建筑物，这确实是稳定可靠的，但成本要高得多。因此，一些专家认为，“构建应用程序级灾难容忍度并不是一个理想的解决方案。”
粤康码这次无法正常参观，这也让很多人想起了不久前西安一脉通的两轮坍塌。来自世界各地的许多网民表示，他们所在地的健康代码也一直是明亮而缓慢的。
钛媒体报道称，西安易脉通是“由于流量过载和系统架构对高并发响应不足而导致的系统故障，一些技术专家也表示，他们认为西安易脉通在系统架构设计上存在一些硬伤，没有充分考虑扩容。
业内人士强调,，粤康码和西安易脉通光明代码的失败确实与高并发访问有关，但无论健康代码在哪里，实际情况都无法概括，这并不意味着西安易脉通的根本问题也出现在其他地区的健康代码中。
但是，应该注意的是，灾难恢复和容量扩展等相对肤浅的技术问题并不是由于高并发性导致健康代码缓慢甚至崩溃的唯一原因。
"健康码是一种集成多个系统的产品，一家软件公司无法覆盖。”IT咨询专家阿鲲（化名）向雷峰分析，目前健康码系统的关联方应包括：
ICT研究所整合的三家运营商（定位和跟踪）；
当地疾病预防控制中心（核酸检测结果、疫苗接种结果）；
产品前端（微信、支付宝小程序）；
产品操作（实际健康代码的处理和生成、数据集成、日常操作等）
其他相关方，如云服务和防火墙提供商。
就整体架构而言，应该有一个背景和一个前端，两个都设在政务部云上：
后台从各种渠道采集数据，包括定位轨迹、核酸、疫苗等，统一处理后生成健康代码；
前端连接各种渠道，从前端获取客户身份信息，后台查询健康码，生成码值显示。
一个看似简单的健康代码，内部涉及的产品和操作人员太多，协调起来非常困难；而且其技术能力参差不齐，很容易被桶的短板拖累。
“即使各方的责任方都没有问题，但在一起可能会有很多问题，就像一个四肢健全但不能正常行走的人一样。”另一位技术专家强调。
项目负责人和实施者可能无法准确理解健康规范的定位。阿鲲说：“该项目是根据政府系统进行的，但这是整个网络C端的一个大流量架构——理论上是从g到g，实际上是从g到C。”。
另外，由于卫生规范的特殊性，项目上线时间紧迫，经常不进行完整的压力测试；上线后，面临巨大的运营压力，无法节省人力资源进行优化。因此，系统的整体架构耦合性太强，鲁棒性不够。
同时他也强调,，全国各地各自为战，数据不整合，数据和架构不同，导致各省各显神通，这也与当地的信息基础设施密切相关，没有统一的标准方案。
健康代码的真正考验是顶层设计和协调的能力，以及项目内各方与项目和其他数字基础设施之间的协调。在疫情联合防控成为日常需要的今天，这将是每个城市长期面临的一个考验。
