西安一码通打不开是怎么回事(西安一码通打不开怎么办)

今日(1月4日)9时左右,网友反映西安一码通出现故障无法打开。

西安一码通再出故障,官方回应:访问量太大,正在限流,将逐步恢复

记者从西安大数据管理局了解到,目前一码通链接访问量太大,正在采取限流措施,后续逐步开放。请大家有序排队,耐心等待。

西安抗疫仍在进行中,在广泛要求48小时有效核酸政策发布以来,西安“一码通”出现了系统故障。

具体故障包括,健康码无法打开,页面点击二维码后出现空白;核酸报告系统出现问题,结果无法显示;恢复的过程中出现中国电信手机网络可打开健康码,而中国移动不可以等。

对于西安“一码通”出现的故障问题,西安高新区一小区的10余位“一线大厂”技术咖对问题进行了探讨与交流,从前端、后端、测试等方面,对可能出现的多类问题及原因予以分析及推测,并给出多项建议。

其中几位人士接受了21世纪经济报道记者采访,对这些专业技术及行业术语进行了详细解释,便于更多业内外人士了解情况,促进“一码通”正常运维及防疫保障工作。

21世纪经济报道记者就此致电西安市大数据资源管理局多个业务部门,但电话无人接听。

 

问题推测:性能过载、架构设计、容灾备份

 

技术咖们经过讨论认为,限流是主要问题之一。

市民在长时间无法刷出健康码的情况下,多次退出刷新重试,新的流量到达服务器,导致服务器压力变大、承受负载增加。他们认为,西安“一码通”系统可能没做好限流措施。

紧接着是服务器问题。无论是企业和个人在租用服务器的时候都会受到峰值承受限制,一旦超过服务器的承受能力,就会导致服务器瘫痪,应用程序暂停,网站无法访问。造成服务器瘫痪的原因是在同一段时间内访问人数多,造成高流量的突进,超出了服务器的承受范围。这一点,与西安市大数据局局长刘军在新闻发布会上给出的回答接近。

类似的推想还有性能过载问题及场景问题。他们认为,这是典型的性能过载场景,或许内因是数据库瓶颈点以及网络链接数瓶颈点,但外因都是过载导致。

他们分析,或许西安“一码通”是个门户,核酸等“卡片”的数据是从各子系统引过来的服务器宕机。

上班高峰期,市民共同访问,导致服务器瞬时访问流量飙升,数据库性能跟不上,最终整个西安“一码通”服务挂了,可能之前设计的时候没有考虑过这种场景。

设计漏洞方面,也许没有考虑高流量高负载的情况,导致测试不充分;产品设计未考虑千万级的并发访问,交付前未进行同等级的压力测试。

此外,或许还涉及架构问题。

西安“一码通”功能影响“核酸检测”服务,说明模块间从界面到数据调用互相影响,可能不是微前端、微服务架构。

西安高新区一小区业主、IT行业前端人员李女士在接受21世纪经济报道记者采访时表示,西安“一码通”页面与核酸检测页面是有关联的,正常情况下这两大业务已经很大。“一码通”里面不仅承载了本身的数据,而且有核酸检测数据。按道理来说,两个模块是不应该互相影响的,关联性应该不是很高,其实可以分成两个不同的模块,分离开来降低它们之间的粘性。这样做的好处是,两块互不影响。假如数据仍有关联,可以把关联度降到最低,即使一个服务出现问题,另一个还能独立运行。

技术咖们认为,界面上出现情况,可能意味着不仅仅是“一码通”与核酸检测这两个模块之间的问题,或许后端与前端的架构有问题,可能不是微前端、微服务架构,没有做到很好的分离。

他们还探讨了域名解析系统不同、容灾备份不足等方面。例如,对于中国电信网络信号可以打开,中国移动网络信号无法打开的情况,这或是由于不同运营商依赖的DNS(域名解析)系统不同,由于西安“一码通”系统为电信相关公司参与,因此DNS指向新的IIP生效最快。

他们认为,在目前国内外疫情仍然严峻的背景下,西安“一码通”相关系统的容灾备份建设仍不够充分,存在未进行故障隔离和流控处理,运维预案和弹性伸缩能力不足等问题。

 

未来“一码通”如何优化完善?

 

技术咖们给出的产品建议是,进行业务剥离,将小程序内业务关联度比较高的模块独立化。

在系统建议上,他们给出了快速响应短期建议和项目稳定长期建议。

短期建议中,可以进行页面优化,友好提醒用户耐心等待。当出现不能显示查询结果的时候,为避免公众猜测,应当在页面做出友好提示,而不是“繁忙、无响应”等。

同时,访问节流,短时间内多次请求可做防抖机制。既然核酸结果是24小时(或更长或更短)内不变,建议可做缓存机制。24小时间隔后再次访问强制刷新,接口可带时间戳参数。

项目稳定长期建议,则包括了更多的专业用语。例如数据模型,尽可能结构关系单一,快速响应回调;沉淀组件并复用,减少项目体积;建立中台,减少直接请求后台数据;崩溃预警,可让相关开发人员快速上线响应等。

在系统设计方面,技术咖们给出的建议包括架构设计、云原生、中间件选型、分级管理、内容分发网络缓存、网络可用性等建议。

例如,以分级管理而言,IT业内人士、后端人员张远(化名)对21世纪经济报道记者介绍,分级管理方面,可以根据业务重要性进行分级管理,核心应用和服务优先使用更好的硬件,在服务部署上进行必要的隔离,避免故障的连锁反应。

“低优先级的服务,可通过启动不同的线程或部署在不同的虚拟机上进行隔离,而高优先级的服务则需要部署在不同的物理机上。”张远说。

再如安全提升方面,他建议,可以提升西安“一码通”系统机房安全等级,以应对各种极端情况,“建议参考银行一类业务系统建设标准。也可以关闭不用的端口,减少不必要的暴露。”

另外,在高可用设计方面,他们也给出了诸多专业建议。例如,数据冗余问题,以关系数据库为例,可采取读写分离,极端故障可以进行主从切换实现故障恢复。

测试方面,建议添加高性能自动化测试、压力测试,并且在发布前做预防机制。进行服务演练,经常开展各种应急演练、灾备演练工作,提高问题处理效率及验证灾备系统可用性。

尽管具体原因运营方并未详尽公布,但是技术咖们依然愿意对西安“一码通”问题提出分析与建议,将各类可能的环节考虑周全,供业内外参考,为西安抗疫贡献力量。

本文链接:https://www.dzdvip.com/28387.html 版权声明:本文内容均来源于互联网。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 395045033@qq.com,一经查实,本站将立刻删除。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注