成都程序员分析，核酸系统一崩再崩，到底谁的锅？

作为9月2日成都核酸检测的亲历者，也跟所有的成都市民一样，经历了核酸系统崩溃之后的排队崩溃和心理崩溃。

昨天，在至少排了一个小时的队之后，前面还没有动静。我跑到志愿者扫码登记的地方观察了很久，也看了网上各种各样的分析，声音很多。

作为一个程序猿，也来说说我的看法。

在发出这个内容之前，我看到东软已经发出了声明，概括起来主要是这样：第一次崩溃是成都政府的系统不行，第二次则是因为网络不行。总而言之，都不是东软自己软件的问题。

对于这个声明，你问我怎么看？我最后再告诉你。

我先从技术角度对这个问题做一个整体分析。首先是网上的几个传说，但传说也仅仅只是传说，这个锅应该都不归它们。

首先：是说网络信号有问题，这个说法很明显在打脸。运营商的资源非常丰富。从事实上看，当时排队的人那么多，大家也都在刷视频、聊天，都非常流畅，完全无卡顿。呼吁大家让出信号通道，设置为飞行模式，完全是想多了，运营商表示不答应。

其次：有人认为是天府健康通的问题。

这个问题也有人澄清，成都的核酸检测可以通过刷身份证，或者扫天府健康通的健康码进行。

如果说真的是健康码有了故障，那市民们完全可以刷身份证来做核酸。但从市民们的反馈来看，这两种方法都无法成功。

那很明显，问题自然出现在了核酸系统这一端。我们也可以看到，这两套系统也是两个不同厂家提供的支持，另外根据热心人士提供信息，天府健康通规划的容量是完全足够的。

第三：有人认为是数据库的问题。

这个确实有可能，但不是数据库本身的问题，而是数据设计的问题。即便用了MySQL，也不能就说是数据库本身的问题，比如说，有一个灶台和一口小锅，一次不能炒很多，但可以多几口锅，分开炒，所以也不能把这个锅甩给MySQL数据库，同时这个数据库的设计一定是核酸系统厂家（迷之厂商）设计的才对。

分析完了几个传言，那么核酸系统是哪里出现了问题？

成都市民不外出小区，检测点全部进入小区，所以一下子要多出好几倍的业务量，的确对核酸系统提出了非常高的要求。针对这类高并发的业务系统，如何提高系统稳定性，可靠性，确实是一个技术活，这也不是简单某一点上的问题，而是一个系统工程，在多个环节上都需要进行控制，否则很难达到目标。

我接着从程序员的角度，来列举几个可能存在问题的环节。

第一：接入网关。

这个能力非常重要，也是互联网架构中不可缺少的环节，主要的能力是鉴权和限流。鉴权的目的是防止被非法访问，不合规不合法的访问请求被阻止掉；其次是限流，我们的系统设计一定有一个上限，超过上限怎么办？与其让系统崩溃还不如把请求控制在设计的流量范围内，系统还可以运行。

例如：我们设计的交通是四车道，当车流量达到四车道的负荷时，就进行限制，控制车辆进入，这样可以保障四车道的车流继续进行运转，如果不限流，其结果就是将四车道变成停车场，全部都堵死，谁也跑不了。这就是有些系统设计时考虑了这个环节时的情况是可能较慢，但不至于崩盘，不至于都不能用。

成都核酸系统，就很可能存在这种问题，在2号之前在区县使用的时候没有问题，2号进行大面积使用时，系统经常卡死，一直转圈，操作人员被迫终止程序重新登录。

高速公路变成停车场

第二：应用服务器扩展能力。

扩展分为垂直扩展和水平扩展。所谓的垂直扩展，大家容易理解，就是将处理能力低的服务器升级到高配置，例如：增加CPU，增加内存等，但是这种往往比较受限，服务器垂直扩展能力是有限的，不能无限制的扩展。

其次是水平扩展，就是说增加数量，就是一台服务不够，再增加一台，10台不够，就增加到20台，这个就和架构设计有关系了，能做到水平扩展才行，不然想通过资源来扩展都没有办法使上力。

成都核酸系统根据2号的情况来看，无论是扫描身份证读取身份基本信息，还是读取天府健康通健康码获取用户信息都比较慢，比较怀疑这里处理的服务器能力也不足，如果架构上非常灵活支持水平扩展，通过申请政务云资源，应该很快可以提升。

第三：业务缓存。

大家都知道数据存放在数据库中，每次的读写都需要产生大量的磁盘IO，这是性能的瓶颈，可以将高频使用的数据存放在内存中，大大提升读写的效率，同时也不用每次都访问数据库，既减轻了数据库的压力，也大大提升效率。

但是内存的数据不是长久存放，最终还必须要写到磁盘中，所以在架构设计的时候要充分考虑数据一致性和安全问题，防止数据丢失以及不一致。

根据2号的表现来看，成都的核酸系统在获取完待检测人员信息之后，加入到检测人员列表时，也需要较长时间，并且还容易在这个环节卡死，所以大概率是在写入数据时出现异常，有可能是直接采用写入数据库的方式，产生了数据库拥塞，所以是否使用了缓存技术无法判断。

第四：数据库的性能优化。

这是最后一个环节，包括：分库、分表、读写分离，也是最容易出现问题的地方。

一是采用分库，就是给数据库瘦身，不要把所有的数据都放在一个库中，类似不能把高新区的人都安排在一个小区一样，安排在一个小区，所有人都要通过小区大门进出，容易导致阻塞，就是说的请求拥堵。

二是采用分表，就是让单个的表中的数据不能太多，也是避免读写时产生拥堵，类似一个小区中的不同楼栋一样，如果所有的人都住在一栋楼，这些人员的进出就会很拥堵，进门要堵，电梯要堵，所以可以分成不同的楼栋，大家分开进行，减低拥堵可能性。分表的方式很多，可以按照日期来分表，每天一套表，也可以按照区域来分表，不同区域的数据存在不同的表中，结果就是单表的数据量会变小，读写拥堵可能性大大减低，这也是提升数据库性能的很好的手段。

三是采用读写分离，就是分成不同的库，有些库主要负责写入数据，有些数据库是负责查询数据，一个主库负责写，然后复制几个库来支持查询，这样可以将数据库的负荷进行分担，也可以大大提升性能。

成都的核酸系统也有可能是在写入数据时出现异常，很大可能是没有采用分库、分表的技术，导致在数据写入时产生大量的并发，写入不了。

其实，核酸系统的业务并不复杂。

主要流程就是：登录人员登录到对应的检测点之后，然后就是选择单检、混检1（10混）、混检2（20混）。假如选择混检1，然后扫描试管上条码，生成一组，再扫描检测人员，满10人后，选择封管，就能完成一组操作。

但就算业务逻辑不复杂，还能出现如此差的表现，那我分析主要问题还是出现在架构设计上，没有考虑高并发场景。

很大可能性是：

没有考虑限流机制（应该根据压测的容量进行设置阈值）；

没有考虑缓存机制，导致都需要直接读写数据库，给数据库造成极大压力；

没有考虑数据库的分库分表，导致数据库异常繁忙，并发量大时，没有办法正常写入。

所以我认为与网络没有太大关系，和天府健康通也没有关系，和政务云资源也没有关系（按照需求进行分配，政务云的资源是动态分配，满足业务需求不会太大挑战）。

真心建议核酸系统开发公司认真分析，找出问题根源，进行认真优化，不要让我们再经历这样的情况！