UCloud优刻得:防疫码不崩溃,关键模块一定要稳!

疫情爆发已两年有余,数字化防疫早已深入工作生活的每个角落。“请出示您的健康码”,成为人们日常听到的高频词语。承载了千千万万甚至上亿人群防疫码查询的IT系统如何稳定、高效、安全的运行,便成了各地精准防疫的重点课题。下面是UCloud优刻得根据近两年对部分城市和地区防疫码的服务经验,总结的一些实践建议:

一、防疫码系统主要模块

“点击手机小程序、输入手机号、输入验证码、展示健康码”这看似简单的动作,其实在防疫码系统内是拆分为多个步骤执行的,包括:

»用户身份验证:通过短信动态验证、人脸识别验证等形式,落实一人一码。

»号码段验证:通过手机号识别归属运营商,便于运营商短信自动化同步用户。

»用户行程信息查询:根据运营商提供的用户行程情况,结合国家卫健委疫情风险数据,提供更为清晰的行程信息。

»//绿码的显示:依托来自于卫健、公安、通管等部门汇聚的数据,经过防控规则和数据建模,分析评估后,测算出红色、黄色、绿色三种风险状态。

»疫苗/核酸信息的查询:根据卫健等部门提供的信息,便于用户即时查看接种记录及疫苗信息。

从以上步骤可以看出,防疫码功能看似简单,其实背后涉及到许多模块,需要多部门信息高频调用(跨部门信息高频率互通),再加上人们早晚高峰出行的集中性,因此系统具有高复杂度、高并发性、高依赖度的特点。同时由于疫情爆发的突发性,绝不是通过固定部署几台服务器就能够满足未来不确定的需求。因此灵活方便、即时扩展、算力丰富的云平台便成了部署防疫码系统一个极佳的选择。

二、系统容量规划:

云平台虽然可以对IT资源快速进行横向扩容,但一昧地堆资源,并不能有效提升系统的稳定性。所以,系统各个模块构建合理的容量规划才是稳定之基。

1.容量规划

整套系统的容量规划,除了基于每日用户访问量峰值来建模进行估算外,同时也需对整体访问链路中涉及到的各类模块分别进行计算评估,比如:互联网带宽、负载均衡链接数、应用服务并发数、数据库连接池等。

UCloud优刻得:防疫码不崩溃,关键模块一定要稳!

UCloud优刻得:防疫码不崩溃,关键模块一定要稳!

与很多人的认知不同,其实,每个模块的容量规划并不是越大越好,这主要是因为各模块之间存在依赖关系,一个模块容量过大,可能会导致该调用链路上的其他模块服务雪崩。

举个例子,上图中的数据库类似餐厅大厨,假定只能同时服务5个用户。应用集群如同餐厅,能同时容纳100人。如果用户以20人/分钟的速度进入餐厅,由于前面的用户还未就餐完毕,后续的用户不断涌入,最终会导致超出餐厅的同时服务能力,整个系统也就崩溃了。

2.限流管控

鉴于防疫码的高并发访问场景,为了保障防疫码系统的正常运转。必要时还需用到一些限流措施。

限流的目的不仅是为了控制访问的总并发量,而且还要尽量让访问的流量来的更均衡,这样才不会让系统的负载大起大落,因此又称为"流量整形" 。

常见的限流手段包括互联网入口处针对单个运营商级别的网络限流,或者负载均衡器上的新建连接数和并发连接数的流控,以及应用服务的参数调整等。

限流虽说是有损的,比如它会造成部分用户的请求失败,但在用户重试的情况下,若干次尝试后,请求便会成功。限流引起的重试确实会对用户体验造成影响,但相比较于应用集群的崩溃而言,是可以接受的。

三、防疫码模块的关键点:

1.用户身份验证模块

在日常生活中,进入某办公楼会先检查对方的证件,确定身份后才能进入。防疫码也有着类似的用户身份验证场景。常用验证方法有两种:手机短信验证和人脸识别验证。

其中手机短信验证大致过程为:用户请求发送短信验证码,应用集群调用第三方短信平台发送验证码给用户,验证码和用户信息(手机号)可存放到缓存中,并设置验证码失效时间。当用户接收到短信,输入验证码即可完成身份验证。

一般而言,应用集群对这类信息不需要进行持久化存储,建议使用缓存产品如Redis等。而且,用户身份验证的超时机制很关键,当用户发现验证失败时会频繁发起验证,在高峰期这个过程会形成雪崩效应,加剧系统的负荷,不控制的话,有可能造成系统处理能力下降,累计下来,会造成系统崩溃。

2、用户行程查询模块:

行程查询是防疫码系统的关键模块,首先系统核验用户所属的运营商,再利用运营商的接口来查询行程信息。在高峰时期会有大量的查询,这也是系统容易造成崩溃的地方。

防疫码系统是通过互联网访问各大运营商数据,依赖于互联网传输的质量,在实际使用过程中,网络的拥塞可能会造成接口超时的情况,系统超时设置也要特别注意,超时重试时间不宜过短,避免频繁重试加剧系统的负载。如果可以和运营商互联专线,也能更好地解决网络拥塞的情况,但专线的价格较高,成本会有一定上升。

整个请求链路上很可能设置防火墙设备,由于防火墙的问题,可能造成系统访问异常,但只要做一些基本的压力测试就能发现这类问题,同时解决防火墙的问题也不复杂。

3.红/黄/绿码的显示

大部分防疫码都是依托国家及当地公共管理机构的数据,并结合行程信息和当地政府的防疫措施,经过数据建模,分析评估后,从而展现出红色、黄色、绿色三种风险状态码。

部分地区防疫政策系统构建于防疫码系统之外,因此相应的容量规划也需要参考防疫码每日最高访问量进行设计。

4.疫苗/核酸信息的查询

疫苗和核酸信息的查询服务,目前以纸质为主,一般不会对整体系统压力造成影响。但目前来看部分地域的系统化查询已经在逐步落实,后续需对相应的容量规划进行评估,同时控制好信息查询的超时设置。

当前疫情防控形势仍比较严峻,防疫码的稳定运行对于疫情防控至关重要。基于多年来的云计算运营技术和经验,UCloud优刻得希望通过本次技术分享,为防疫工作提供一定的参考和助力,更好地发挥出云计算的社会价值。

(免责声明:本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时,应及时向本网站提出书面权利通知或不实情况说明,并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后,将会依法尽快联系相关文章源头核实,沟通删除相关内容或断开相关链接。 )