前言
成都，2022年9月第一天，封小区了，核酸检测在各个小区内进行。于是，下午5点过，我们小区的检查开始了。与以前一样，通过扫健康码进行登记，但是，登记系统很慢……
社区工作人员说，全市大概有一万多小区同时开始。我们小区人不多，只开了一条线。
粗略估计一下，算上大的小区可能有多条线，全市估计不会超过五万条线并行，而这些都是人手工操作，按照50,000 TPS估计系统负载应该合理。
有人在网上“爆料”：这个是XXX公司做的，用了很宽的表、没有分表分库、Load Balance 方案问题，或者其它各种不合理的设计，或者还有其它非技术因素。本文只是基因我自身的技术背景，对这种应用场景给出一种技术方案。
范围
本方案基于边缘计算。
本方案没有讨论拼肌肉的技术方案。
架构设计
方案基于边缘计算，在移动边缘部署边缘应用，负责收集其所覆盖的基站下的用户数据，也就是核酸检测人员（大白）终端所需要的功能，主要是被检查人员信息上报；另一方面，核心应用部署于Internet（专网和电信核心网也可行），负责收集来自边缘应用的数据。
边缘应用
边缘应用主要包含以下功能：
· 收集检查人员终端所提交登记数据：接收检查人员终端发送的登记数据，并存入本地数据库。
· 提交登记数据到核心应用：定期、或事件触发将本地数据提交到核心应用。此功能不是数据同步，或只是单向同步，因为边缘应用保存的都可以看作是临时数据，并不需要将核心应用数据同步会边缘应用。
· 查询该终端登记信息—我看到检查人员每次都获取列表，确认是否登记成功：该功能可能需要从核心应用读取数据。
核心应用
核心应用主要包含以下功能：
· 收集边缘应用发送数据：
· 返回全量数据或终端请求范围数据。
· 为后续的实验室检测提供数据。
数据提交
提交触发
数据提交触发有以下方案：
定时
定时、批量将边缘应用数据发送至核心应用。 简单 当各边缘应用同时发起提交时，核心应用会有性能压力。
事件触发
当个发生某个事件时触发，如：登记满100条数据、人工触发。 发生各边缘并发概率降低。 人工触发会引入新功能，而且会迷惑最终用户（检测人员）。并发风险仍然存在。
令牌式
可以是以上两种的结合，发起数据发送时，先向核心应用请求令牌，获取令牌后发送。 避免了并发风险。 复杂。有长期获取不到令牌的情况。
CAP分析
本方案可以看作是分布式系统，那么就需要对CAP （Consistence、Availability和Partition Tolerance）进行讨论。各终端之间并没有数据交叠，所以，只涉及边缘应用与核心应用的问题。
· 一致性（Consistence）：数据是单向从边缘应用发送到核心应用，当终端尝试获取本终端（应该不会有获取其它终端登记数据的需求）全量数据时，核心应用返回的可能缺少还未同步数据；而边缘应用可能未包含历史数据。
· 可用性（Availability）：终端写操作在边缘应用，边缘应用需要保证可用性，这取决定于边缘计算本身的部署方案；同样，读操作依赖于核心应用部署方案。核酸采集之后，需要人工将样本送取检验，使用登记数据已经很晚了，所以，基本不存在可以用性问题。
· 分区容错性（Partition Tolerance）：以边缘应用数据增量覆盖核心应用数据，基本无挑战。
后记
这只是一个方案的讨论，其实，50,000TPS的系统通过常规方案，或者在现有架构下就容易达到，边缘计算方案可能是“高射炮打蚊子”了。
边缘计算常常会强调可以实现低时延，而这里却是对一个“长时延”的应用，也很有意思。
今天，很多小朋友等着测核酸，因为学校要求每天都要有检测报告。
11点后，核酸检测慢慢停了，明天继续，讨论也在继续，且让锅飞一会儿。
