一个2高1弹的核酸检测系统，如果是我会这样设计

核酸检测系统的要求

高可用：不能挂了。

高性能：不能缓慢。排队【聚集】时，时间太长，有潜在的聚集感染风险。

支持弹性伸缩：查询核酸结果的时间并不均匀，会存在流量热点，系统的能力要能水涨船高，流量越多，系统的处理能力也越强。国家资源能节省还是要节省的。

核酸系统系统架构

根据使用过程，可以分为toC端系统，和toB端系统。

toC端系统的用户是查询核酸天数的公民。

toB端系统的用户是核酸检测点的手机和对检测结果进行分析的组织。

进行这样拆分的着眼点是对弹性伸缩的诉求不同。两个系统面向的用户不同，提供的能力不同，qps不同，对系统能力水平扩展的诉求不同。

核酸检测点和核酸检测组织使用的系统，为什么不进行拆分。qps虽差别，但在同一个量级。核酸检测点的数量与每天检查核酸状态的数量相比，不在一个量级。从2高一弹的视角看，这两个可一起变化。

在业务上看这两个耦合度更高，两者配合才能完成一次核酸状态测定。

核酸系统各系统边界

核酸系统数据构架

核酸toB系统，属于后台系统。主要职责是存储数据并管理数据。使用MySql这种关系型数据库就可以满足要求。面向核酸检测点的服务在交互和性能上还是要花些心思来设计一下。

核酸toC系统，属于前台系统。主要职责是获取最新的数据并分发。为提供高性能和高可用的服务，需要将toB系统中的数据根据前端展示的需要重新构建查询模型，即数据异构。toC系统看到的是一个个的宽表。

更新核酸状态，使用了binlog来完成。因为核酸的检测结果，并不要求实时更新。

查询核酸状态和更新核酸状态，是两件事，不需要耦合在一起。将这两个操作放在不同的上下文中，由模块来承载，在扩展性上更好。譬如如果后面识别到更新逻辑对系统资源的要求更高，那么可以把更新模块拆到另外一个服务上。这种情况下，只需要将更新模块拆出来即可。

下图中使用三级数据架构，在架构有些复杂，技术积累比较弱时，可能会引发其它技术侧的问题，可以根据情况调整为两层：Redis集群+MySql宽表。

为什么使用了三层数据存储？高可用、高性能。

核酸系统数据架构

核酸toC系统数据服务流程图

核酸状态查询流程

核酸toC端系统业务架构

toC端系统业务架构

代码架构

使用MVC三层架构就可以了。

业务域不复杂，在后面半年或一年，没有识别到有必须的新特性需要增加。

技术点剖析

• 如何实现弹性

目前有两个工具可以用。

业务域层：使用K8s来进行弹性伸缩。K8s的一个最大的亮点，就是复制，原生支持，且复制成本很低。如果说没有K8s，感觉就像清朝的冷兵器与外国入侵者的热武器之间进行PK，你不能我落后，我有理吧。

数据存储层：可以使用支持弹性的存储系统，数据库可以使用PolarDB

• 核酸查询中用到的图片如何处理？

生成图片属于耗时、耗CPU的动作。这种情况要异步后台处理。

图片尽可能要小。

图片要存放到oss上。

图片要使用cdn。

• 网络出问题怎么处理？

也不知道。要问网络工程师

网络物理故障