关于一码通系统高并发访问的一些思考
针对前几天某省份健康码和核算检测系统出现并发性的问题，总结了一下自己的想法：
在需求方面，梳理了以下三个点：
（1）在一个页面展示某个人的健康码状态和最近若干次的核算检测结果，每个人的健康码状态由大数据系统定期生成，核酸检测结果也是在每次结果出来时由核酸检测系统录入；
（2）健康码和核算检测结果的展示为高频读取操作，在每个人进入商场、地铁、公交、小区等地方都需要展示；
（3）健康码状态生成与核酸检测及结果录入属于平时低写入、高可靠类需求，只有在大数据系统计算出健康码或有核酸检测时才会写入，但写入结果要确保可靠。
在上述政企类需求中，一般对数据安全要求较高，很多核心业务和数据都需要部署在自己的私有云上。但是对于对健康码和核算检测结果展示属于高并发类的需求，只要做好对数据的安全控制，是可以将部分读业务部署在公有云的，因此，我的想法是：充分利用公有云的弹性扩展能力和私有云的安全要求，采用公私云结合的方式来设计整体系统。
1、架构设计
在安全性方面，除了常用的安全机制外，存储在查询系统中的数据均是加密数据，而且是每个用户一个独立秘钥，数据在从发送至公有云之前加密，在用户读取之后进行解密，数据本身在公有云以及整个公网传输过程中全程加密；另外，用户标识不可使用用户身份证，而是系统产生的内部ID。
在性能方面，架构设计时将整个系统分为查询系统和数据生成系统两部分，查询系统应对个人的高频访问，部署在公有云中，例如阿里云，腾讯云等；充分利用公有云的弹性资源；数据生成系统用于健康生成及核酸检测与结果的录入，主要部署在私有云或私有机房中；查询与数据生成两类系统之间通过同步机制完成数据同步，实现两类系统之间的隔离；在用户端可选支持多域名选择策略，多云同时提供服务，不同用户可基于选择策略可接入不同厂商的公有云中。如下图1所示：
图1、公私混合云的系统架构
在该混合架构中，数据同步采用实时同步和定时同步两种机制协同的方式，实时同步主要针对某个用户的健康码发生变化、产生了新的核酸检测结果等场景；定时同步可每天将全量用户更新至查询系统中。根据过往的经验，再可靠的实时同步都是不可信的，最终都得加上全量同步来兜底。其架构如下图2所示：
图2、查询系统内部架构
在查询系统中，包含接入网关、查询微服务、Redis缓存集群、可选的备份数据库和数据同步客户端。接入网关获取请求的用户ID，并将同一用户的数据路由至同一查询服务；在查询微服务中，采用两级缓存机制，在两级缓存中，查询服务内部缓存2小时内的用户数据，当有新请求过来时首先查询内存缓存，如果内存缓存中不存在，则访问Redis缓存集群，查询微服务通过过期逐出和超量逐出机制删除微服务内存中的数据；Redis集群可采用其原生的Cluster也可以在查询服务中自己实现集群管理。数据同步服务客户端用于接收同步数据，并将其放入缓存；如果采用数据库作为数据备份，则Redis主从均无需开启持久化，否则将从实例开启持久化；在该架构中，整个数据访问全部由缓存提供数据服务，不使用数据库，以便最大程度提升数据访问效率。其架构如图3所示：
图3 查询服务设计思路
上述数据在程序内部或Redis缓存中均采用键值对方式存储，其中：
- Key为用户标识，用户标识是在登录成果后由账号及权限系统返回，不是用户的身份证；
- Value是一个加密后生成的字符串，加密对象为JSON对象，包含以下信息：
（1）健康码的状态；
（2）每次核酸检测结果的信息，例如：
1）检测时间：UNIX时间戳；
2）检测结果：1：阴性；2：阳性；
3）检测单位：限制单位字符串长度不可超过250个字符；
上述思路也可以扩展至单独访问核算检测结果，例如：核酸检测结果列表单独显示时，也可以采用该思路实现。
二、资源预估
本文所述架构在公有云中的资源申请估算情况如下：
以如下数据量为例：每个用户2KB，key为8字节纯数字，按照用户量3千万；访问QPS：10万/秒。
所需Redis缓存10个Redis实例，采用主从部署，每个实例16G内存；计算方法为：
（1）直接缓存空间：2KB* 3000 0000 = 60GB;
（2）单个Redis缓存承担12GB数据，Redis实例内存16GB；
（3）主实例数：5个，备份实例数5个；
所需查询微服务的配置及数量：2核4G内存 ，20个；网关微服务：4核4G内存，10个；账号权限系统及LB另算，数据库可选配置。
三、运维机制
在上线生产环境之后，应增加相应的运维机制，包括
（1）弹性扩容策略，在公有云中配置微服务、网络的自动扩容策略；对于网络流量，公有云可提供按量收费，采用这种方式比较好。
（2）告警机制，在公有云要配置各微服务实例、缓存、网络的告警机制，在压力增加时及时告知相关研发及运维人员，短信告警最好设置多级，例如CPU利用率持续30分钟超过70告警一次，持续10分钟超过80%告警一次，持续5分钟超过90%一次；
（3）日巡检机制，每日巡检各服务的运行状态、异常日志，并每周分析系统资源使用趋势，以便对资源做提前扩容；另外，尽量依靠人工扩容，不要依赖平台的自动弹性扩容机制。