开发一个不会崩溃的核酸系统很难吗？在这篇文章中，勇哥把自己想象成一个核酸系统架构师，谈谈他对核酸系统的理解。1厘清系统边界作为架构师，首先需要厘清系统边界。核酸检测核心流程：医护人员打开核酸系统手机应用，输入试管码；医护人员扫描居民健康码；医务人员采集咽拭子标本；中心将检测结果提交至核酸系统，核酸系统将核酸结果同步至健康码系统。当成都核酸系统崩溃时，流程被阻断在第一步和第二步。我们在本文中提到的核酸系统是指医护人员使用的系统。核酸检测系统会将检测结果同步至健康码系统。健康码系统面向大众，属于高频场景。对于成都市民来说，这两个制度与他们的关系最为密切。核酸系统：核酸医务人员使用，东软开发维护；天府健康通：供大众使用，由腾讯开发维护。2核酸系统的软件由政府购买（TOG），由公众使用（TOC）。核酸系统是一个多方协同的系统。它不仅与政府直接相关，还涉及多个制造商。一个系统项目的背后，除了系统集成商，还有多个分包商。比如西安的一马通，曾经集聚了电信、东软、美林、安恒等公司。因为这个系统的覆盖面很广，当成都核酸系统崩溃的时候，我们需要静下心来，组织起来。我们先从基础设施层的角度来分析。很多互联网公司会把服务部署在阿里云或者腾讯云上，部署简单，可以动态扩展。那么核酸系统部署在哪里呢？如果核酸系统是以SAAS的形式部署（东软自建机房，或者东软采用阿里云/腾讯云服务），那么成都核酸崩盘肯定离不开东软。但东软随后发布公告：系统上线后发现出现响应延迟和卡顿现象。东软第一时间组织专家组和公司技术人员驻守现场，会同成都相关部门对事故原因展开调查。加强安全防护，确保系统运行。据技术专家判断，目前系统响应延迟、卡顿现象与核酸检测系统软件无关。9月3日午夜前后，经过网络调整，系统运行平稳，效率大幅提升。当天一共采集了1200万份样本。如果核酸系统没有问题，会不会是网络问题？成都核酸系统崩溃时，医护人员以为是信号问题，举起手机捕捉信号，而排队的市民则可以刷抖音，上头条。9月3日下午4时32分，四川省通信管理局发文称，“全市通信网络运行平稳，各核酸检测点移动网络覆盖良好，未出现网络拥堵故障现象。“我们基本可以做出判断：成都核酸系统部署在政务云，即政府部门提供基础设施，应用开发商将软件部署在政务云机房。会计系统崩溃可能原因：政务云机房问题、网络问题（负载均衡、带宽、防火墙），或者机房服务器故障；核酸系统软件问题核酸检测软件承载能力有限，软件死机。3应用层设计的核酸系统是高并发应用吗？这里我们做一个估算：人口估算方法：据统计，成都人口超过2000万。假设核酸集中在6小时以内，则每小时支持的平均并发人数为3531666人。支持的并发度约为每秒1000个。基于测试人员集中度不均衡，假设高峰期是平均并发数的2-3倍。然后每秒大约有2000-3000个并发的“核酸注册”。检测点估算方法：今年5月，上海抗疫期间，共有15000+个核酸检测点。我们假设成都的核酸检测点和上海一样多。市民排队进行核酸检测时，核酸医务人员扫描居民健康码的时间间隔在10秒到15秒之间，每个核酸检测点有两排平行检测通道，因此并发“核酸登记”每秒也是2000-3000条左右。通过两种估算方式，我们发现核酸系统的请求并发度不高。虽然并发度不高，但是日常业务数据量级比较高。根据东软公告，每天可采集核酸样本1200万份。假设核酸检测一天记录1000万条数据，一周就有7000万条数据，一个月就有3亿条数据。那么就要用到分库分表了。医护人员扫描市民健康码，核酸登记请求发送至api网关，api网关将请求转发至核酸系统；缓存存储检测点、批次等基本信息，核酸系统通过缓存判断业务请求是否合法，然后组装真正的传入数据；核酸系统调用分库分表中间件将数据插入数据库。看来核酸系统的架构设计比较简单明了，核心点就是利用分库分表来阻断大流量访问。但是现在这种模式完美吗？我们以湖北易通码为例。核酸登记完成后，健康码状态会在10-20分钟后变为绿色，并标记为：核酸已检测，即核酸已检测状态会同步到健康码服务异步地。我们不禁想到消息队列MQ。MQ最大的优点是：异步和解耦。MQ模式还有一个好处：当流量激增时，消息队列还可以起到降峰的作用。在MQ方案中，核心流程是：医护人员扫描公民健康码，核酸登记请求发送到api网关，api网关转发请求到核酸系统；缓存检测点、批次等基本信息，核酸系统通过缓存判断业务请求是否合法，合法则汇集真实入库数据；核酸系统将检测记录发送到消息队列，返回前端响应成功；消费者收到消息后调用分库分表中间件将数据插入数据库；消费者收到消息后将状态同步到健康码服务。在架构设计中，仅仅引入组件是不够的，还要考虑如何准确的使用组件。比如使用消息队列kafka，如何保证消息不丢失，如何保证高可用。如果使用分库分表中间件，是否需要考虑数据异构和冷热分离？4监控平台我们常说：研发人员有两只眼睛，一只是监控平台，一只是日志平台。在注重性能和高可用的场景下，监控平台的重要性怎么强调都不为过。1、基础运维监控基础运维监控负责监控服务器的CPU、网络、磁盘、负载、网络流量、TCP连接等指标，并通过设置报警阈值。基础运维监控我们在基础设施层部分提到：当核酸系统崩溃时，成都政务云无法提供顺畅的核酸检测服务。可能的原因之一是政务云机房的问题。当政务云机房出现问题时，基础运维监控可以帮助运维人员更快地发现问题并制定解决策略。2.应用系统监控应用系统监控是研发人员接触最多的监控类型。当系统出现瓶颈时，应用系统监控会有最直观的反映。笔者一般侧重于性能监控、方法可用性监控、方法调用计数监控、JVM监控。PerformancemonitoringPerformancemonitoringPerformance监控不同时间段的性能分布，实时统计TP99、TP999、AVG、MAX等维度指标，这也是性能调优的重点。方法调用次数监控方法调用次数监控可以按机器、时间段分析接口或方法的调用次数。当大流量来袭时，你可以清楚地看到请求的波动。MethodAvailabilityMonitoringMethodAvailabilityMonitoringMethodAvailabilityMonitoring是指：调用接口或执行方法时，方法执行过程中可能返回异常或抛出异常，分析该方法是否被正常调用。当系统出现严重问题时，方法可用率是一个重要的参考指标。JVM监控JVM监控JVM监控是JAVA工程师特别关注的一种监控。我们会重点关注：堆内存、GC频率、线程数等。3、业务监控业务监控功能从业务角度出发，各个应用系统在业务层面需要进行哪些监控，提供什么样的业务层面的监控功能来支持业务相关的应用系统.具体来说，就是对业务数据和业务功能进行监控，实时采集业务流程数据，根据设定的策略对业务流程中不符合预期的部分进行预警和报警，并集中统一存储和处理。存储采集到的业务监控数据。以多种方式展示。例如，订单系统中有一个定时结算服务，每两分钟执行一次。我们可以在定时任务JOB中添加埋点，配置业务监控。如果预定任务在十分钟内没有执行，将给相关负责人发送邮件或短信。5多方协作不少同学指责东软的失职：“核酸系统仓促上线后，是否进行了完整的性能测试？”确实，性能测试非常重要。通过压力测试，我们可以知道系统的极限值。当系统无法承受访问时，就会暴露出瓶颈，如服务器CPU、数据库、内存、响应速度等，促使研发团队进行重新优化。这里我们先抑制一下责备的冲动。核酸系统是一个多方协同的系统。它不仅与政府直接相关，还涉及多个制造商。一个系统项目的背后，除了系统集成商，还有多个分包商。《核酸检测系统崩溃，东软该不该背锅？》这篇文章提到：原则上，监督管理部门要召集所有生产企业，共同抗击。但是，如果没有顶层协调的强大压力，厂商之间的沟通协调就很难实现。在大多数情况下，压力测试是由每个制造商以“单独的方式”进行的。一般都是软件厂商自己测试，很少有公司联合测试。“不同厂家坐在一起，大家都觉得自己没问题，都认为是别人的问题，道理都会一样，我们的系统在别的地方跑过，没出过问题。”即便是应对这种情况，各家也是极为微妙。“每个厂商都在系统上投入了大量的资金，在紧急情况下，如果上层不表态，不清楚是公益还是有偿捐助，厂商在选择上也是谨慎的因此。”因此，在大多数情况下，压力测试是由每个制造商以“分开的方式”进行的。一般软件厂商会自己测试，很少有厂商会联合起来压测。这篇文章的一个观点，“这不仅仅是技术层面的问题，更是一个城市应急预案管理能力的问题。”我深表赞同。6总结假设我是核酸系统的架构师。...我会采用消息队列+分库分表的方式来最大化系统的吞吐量。在使用消息队列中间件的时候，我会重点关注如何不丢失消息，如何实现消息系统的高可用。我在使用分库分表中间件的时候，会重点关注冷热分离，以及如何将数据异构存储到数据仓库中。我会在政务云部署监控系统，提供基础运维监控、应用系统监控、业务监控能力。当系统出现问题时，团队可以第一时间发现并解决问题。然而，核酸系统是一个多方协作的系统。我们不仅需要和政府沟通，还需要和很多第三方厂商合作。也许，当我提出需要增加服务器预算时，政府部门的预算不够，或者即使足够，也需要一个月的时间才能完成；或许，当我提出要部署监控系统时，公司会以人手不足为借口。因电子政务云硬件资源不足，否决了我的方案；也许，当我在联合调查时发现一个三方接口很慢，调查需要4-7天（沟通成本），我不得不埋头于琐碎的事情；直到最后，当系统崩溃时，我只能感叹：“尊重技术，尊重专业”。
