又崩溃了,假如我是核酸系统架构师……

成都核酸检测系统“崩溃”事件,将东软推至风口浪尖,同时也在技术圈内引发了广泛的讨论。

开发一个不崩溃的核酸系统到底难不难?

这篇文章,勇哥想象自己是核酸系统架构师,谈谈自己对核酸系统的理解。

一、明确系统边界

作为架构师,首先需要明确系统边界。

核酸检测核心流程:

成都核酸系统崩溃时,流程阻塞在步骤一和二。

本文里我们提到的核酸系统,也就是指医护人员使用的系统。而核酸检测系统会将检测结果同步到健康码系统 , 健康码系统面向的是大众居民 , 是高频场景。

对于成都市居民来讲,与他们关系最为密切的就是两套系统。

二、崩溃疑云

核酸系统软件是属于政府购买 (TO G),市民使用 (TO C) 。

核酸系统是一个多方协作的系统,它不仅直接和政府有关系,还涉及到多个厂商,一个系统工程背后,除了系统集成商之外,包括多个分包商。比如西安的一码通,曾集结了电信、东软、美林和安恒等公司。

正因为这套系统涉及面之广,当成都核酸系统崩溃时,我们需要冷静下来,缕清条理。

我们先从基础设施层的维度来分析,很多互联网公司会将自己的服务部署在阿里云或者腾讯云,部署方便,也可以动态扩容。

那么核酸系统部署在哪里呢?假如核酸系统是以 SAAS 形态部署(东软自建机房,或者东软采用阿里云/腾讯云服务),那么成都核酸崩溃事件,东软必然脱不了干系 。但东软随后硬气的发了公告:

系统上线后,发现有响应延迟、卡顿等现象,东软集团第一时间组织专家组和坚守现场的公司技术人员,与成都市相关部门一起,排查事故原因,强化安全防护,保证系统运行。据技术专家研判,目前出现的系统响应延迟、卡顿等现象与核酸检测系统软件无关。9月3日零点左右打开网络访问策略,在进行网络调整之后,系统运行平稳顺畅,效率得到极大提升,当日共完成1200万样本采集量。

假如核酸系统没有问题,会不会是网络问题呢?

成都核酸系统奔溃时,医护人员以为是信号问题,纷纷举起手中的手机,捕捉信号,而排队的市民却可以刷抖音,头条。

9月3日下午4点32分,四川省通信管理局发文称,“全市通信网络运行平稳,各核酸检测点移动网络覆盖良好,没有出现网络拥塞和故障。”

我们基本可以做出判断:成都核酸系统部署在政务云,也就是政府部门提供基础设施 ,应用开发商将软件部署在政务云机房里 。

核算系统崩溃的可能原因:

网络问题(负载均衡,带宽,防火墙), 或者机房服务器出现故障。

核酸检测软件确实承载能力有限,软件崩溃了。

三、应用层设计

核酸系统是属于高并发应用吗?这里我们做个估算:

据统计成都市人口2千万多人,假设集中在6小时内做核酸,平均每小时支持的并发人数是3531666。每秒支持的并发约为1000。基于检测人员的集中度不均衡的因素,假设高峰期是平均并发的2-3倍。则每秒并发“核酸登记”2000-3000左右。

今年5月份,上海抗疫期间一共有 15000 + 核酸检测点 ,我们假设成都有和上海一样多的核酸检测点。市民在排队核酸检测时,核酸医护人员扫居民健康码的时间间隔在10秒到15秒之间,每个核酸检测点并行两排检测通道,那么每秒并发“核酸登记”也是在 2000-3000 左右。

通过两种估算方法,我们发现:核酸系统的请求并发度并不高。

虽然并发度不高,但每天的业务数据条数量级较高打开网络访问策略,按照东软的公告,每天可以完成1200万核酸样本采集。

假设核酸检测记录一天1000万条数据,一周就有7000万条,1个月就能达到3亿条数据。那么势必要使用分库分表。

看起来,核酸系统的架构设计还是比较简单清晰的,核心点在于用分库分表硬挡高流量访问。

但现在这种模式就完美了吗 ?

我们举湖北鄂通码举例,核酸登记后,健康码在 10~20 分钟状态会修改成绿色并标识成:核酸已检测,也就是核酸已检测的状态会异步同步到健康码服务。

我们不由得想到了消息队列 MQ ,MQ 最大的优势在于:异步和解耦,MQ 模式还有一个优点:当流量激增时,消息队列还可以起到消峰的作用。

MQ 方案里,核心流程如下:

在架构设计中,并不是引入了组件就完事了,更需要考虑如何精准的使用组件。

比如,使用消息队列 kafka ,如何保证不丢消息,如何保证高可用。使用了分库分表中间件,是不是需要考虑数据异构,以及冷热分离等。

四、监控平台

我们经常讲:研发人员有两只眼睛,一只是监控平台,另一只是日志平台。

在对性能和高可用讲究的场景里,监控平台的重要性再怎么强调也不过分。

1、基础运维监控

基础运维监控负责监控服务器的 CPU、网络、磁盘、负载、网络流量、TCP 连接等指标,并且通过设定报警阈值实时通知指定负责人。

基础运维监控

我们在基础设施层这一节里提到:

核酸系统崩溃时,成都政务云不能提供畅通的核酸检测服务 , 可能原因之一是政务云机房问题。

当政务云机房出现问题时,基础运维监控可以帮助运维人员更快的发现问题,并制定解决策略。

2、应用系统监控

应用系统监控是研发人员接触最多的一种监控类型,系统出现瓶颈的时候,应用系统监控会有最直观的体现。

笔者一般会关注性能监控,方法可用性监控,方法调用次数监控,JVM 监控这四大类。

性能监控

性能监控不同时间段性能分布,实时统计 TP99、TP999 、AVG 、MAX 等维度指标,这也是性能调优的重点关注对象。

方法调用次数监控可以按照机器,时间段分析接口或者方法的调用次数,当大流量来袭时,可以清晰的看到请求的波动。

方法可用率监控

方法可用性监控是指:当接口被调用或者方法被执行,可能返回异常或者方法执行抛异常,分析该方法是否调用正常,当系统出现严重问题时,方法可用率是一个重要的参考指标。

JVM 监控

本文到此结束,希望对大家有所帮助!

关于作者:

生活百科常识网