江苏龙网

  1. 首页 > 人文 > >

健康码|粤康码“崩溃”的90分钟：到底发生了什么？( 二 )


也就是说 ， 即便扩容只需要十秒钟 ， 但就在这十秒钟之内 ， 问题还在不断堆积；自动扩容后的能力 ， 也未必能应对十秒之后的新情况 。
2、应对之法：不只是扩容问题
这种“访问量激增导致亮码失败”的情况 ， 可以通过提前扩容来应对吗？
“很难 ， 除非准确预测流量曲线 。”吴先生说 。
某灾备厂商告诉雷峰网 ， 此次崩溃 ， 可能与项目方“只做了数据级容灾、没做应用级容灾”有关 。
但多位技术专家也给出了相反的看法 ， 指出应用级灾备是“高投入、价值低频且难以度量” ， 在大多数时候“相当于服务能力成倍冗余” 。
应用级容灾确实更能确保业务的连续性 ， 但不同于云服务弹性扩容 ， 这需要长期占用固定投资 ， 且资源平时无法通过灵活应用产生其他价值 。
我们可以把弹性扩容看作是搭帐篷 ， 用途多变 ， 启用和收回也十分灵活；而应用级灾备就像是直接建造一处特定用途的楼房 ， 确实稳定坚固 ， 但成本高出不少 ， 因此有专家认为 ， “建设应用级容灾并不是理想的解决办法 。”
此次粤康码无法正常访问 ， 也让许多人联想到不久前西安一码通的两轮崩溃 。不少各地网友表示 ， 自己所在地的健康码也出现过亮码缓慢的情况 。
钛媒体的报道中指出 ， 西安一码通是“一起因流量过载、系统架构应对高并发不足 ， 最终导致防火墙拦截数据无法返回的系统性故障 。”也有技术专家表示 ， 相信西安一码通存在一定的系统架构设计硬伤 ， 没有充分考虑扩容的情况 。
有业内人士强调 ， 粤康码、西安一码通的亮码失败 ， 确实都与高并发访问有关 ， 但无论是何地的健康码 ， 实际情况都不可一概而论 ， 不意味着西安一码通的根本问题也出现在了其他地区健康码身上 。
但需要注意的是 ， 健康码因高并发而亮码缓慢、甚至崩溃的背后 ， 不只是容灾、扩容这些相对浅层的技术问题 。
“健康码是一个融合多系统的产品 ， 不是某个单一软件公司可以覆盖的 。”IT咨询专家阿鲲（化名）向雷峰网分析称 ， 健康码系统目前的关联方应该包括：
信通院整合的三大运营商（定位及轨迹）；
各地的疾控中心（核酸检测结果 ， 疫苗接种结果）；
产品前端（微信、支付宝小程序）；
产品的运营（实际健康码的加工和生成 ， 数据整合 ， 日常运营等）
其他关联方 ， 如云服务、防火墙的提供商 。
整体架构上 ， 应当是有一个后台和一个前端 ， 都架在政务云上：
后台采集各渠道数据 ， 包括定位轨迹 ， 核酸 ， 疫苗等 ， 统一加工后生成健康码；
前端对接各渠道 ， 从前端获取客户身份信息 ， 到后台查询健康码 ， 并生成码值展示 。
一个看似简单的健康码 ， 内部涉及的产品和运营方太多 ， 协调难度相当大；而且技术能力参差不齐 ， 容易被木桶的短板所拖累 。
“就算各方负责的部分都没问题 ， 合起来也可能会有一堆毛病 ， 就像一个人四肢健全却无法正常行走 。”另一位技术专家强调 。
而项目牵头者、实施方都有可能对健康码的定位理解不准确 ， “项目是按政务系统来做的 ， 但这是面向全网C端的大流量架构——理论上是to G ， 实际上应该是to G to C 。”阿鲲说 。
再加上健康码的特殊性 ， 项目上线时间紧迫 ， 往往未能经过完整压测；上线后又面临巨大的运营压力 ， 腾不出人手和资源进行优化 。因此系统的整体架构耦合太强 ， 健壮性不够 。
同时他也强调 ， 全国各地各自为战 ， 数据未整合 ， 且各地的数据、架构都不同 ， 导致每个省各显神通 ， 也和当地的信息化基础设施密切相关 ， 没有统一的标准方案 。
健康码的真正考验 ， 是顶层设计能力和协同一致能力 ， 是项目内部各方、项目与其他数字基础设施的协调 。在疫情联防联控成为日常所需的今天 ， 这将会是每个城市长久面对的考题 。


推荐阅读


上一篇：智能手机|荣耀MagicUI 6.0发布：AI全场景智慧进化 功耗直降95%

下一篇：Windows|Win11优化设备管理器：更新驱动的默认路径终于不再是软驱A盘了