一财网|从核酸检测到健康码,为什么系统总是“崩了”?( 二 )


此外 , 还要对系统各环节下的全链路全方位测压 , 以保证系统上线足够高的可靠性和稳定性 。
应急层面上看 , 系统要有足够的弹性伸缩能力 。 在访问出现激增的特殊情况时 , 能够快速扩容 , 满足相应的访问需求 , 比如进行容器化的设计保证底层基础设施具备良好的弹性伸缩能力 。
除去访问容量冗余角度上的考虑 , 还要考虑对于整体系统层面的全流程监控设计 , 如网络访问情况 , 健康码接口访问统计 , 日峰值出现时段等指标 。 这不仅为实时大屏提供了相应的数据指标支撑 , 同时也为团队验证系统容量设计 , 监控保障系统稳定运行 , 以及后续实现资源动态扩缩容提供了决策依据 。
【一财网|从核酸检测到健康码,为什么系统总是“崩了”?】即便考虑再周全 , 这世上当然没有完美无缺的系统 , 特别是在计算资源本身就是有限的情况下 。 业内人士提到需要配套合理的开发流程和运营管理流程来有效的支撑软件系统的持续升级和健康运行 。 比如在总体系统设计上 , 针对关键软件服务和数据配备应急资源和环境进行分级 。 平时这部分资源可用于一些创新业务或非关键性业务 , 一旦有临时性的业务需求如全员核酸时 , 可以及时将这部分应急资源用于业务扩容来支撑 。
这有些类似于12306系统将订票和查询余票业务分开 , 在各个子系统按需进行扩缩容的设计 , 同样 , 也不建议在关键高并发的健康码查询路径上关联过多的非关键业务 , 不同业务采用微服务等新型软件开发方式来开发 , 结合容器云等技术来实现动态的按需扩缩容 , 同时保证各个业务之间不互相影响 , 如上传核酸报告、查询核算报告、查询健康码等业务要分开 。
“在某些关键业务失灵后能够快速地从备份系统恢复数据并支持业务重新上线 , 这样即使某个业务短暂出现问题 , 我们可以通过灾备系统来快速恢复业务和数据 , 这样老百姓的等待时间可以从一天缩减到几分钟 。 ”这位业内人士说 。 (宁佳彦 )

推荐阅读