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

一、防疫码系统主要模块

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

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

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

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

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

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

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

二、系统容量规划：

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

1.容量规划

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

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

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

2.限流管控

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

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

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

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

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

1.用户身份验证模块

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

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

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

2.用户行程查询模块

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

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

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

3.红/黄/绿码的显示

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

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

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

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

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