成都的朋友昨晚大家应该都在风雨中排队，腿和腰都站到酸痛，称之为罚站！
昨晚上出现很多关于核酸系统的传言，提示大家不信谣、不传谣。
作为一名开发人员，客观分析核酸采集系统崩溃的原因，有不同见解大家可以评论区交流，谢谢！
造成核酸系统崩溃的原因猜想
开发人员技术真的菜，这一点不能排除，但是也不一定就是这个原因，这一项原因不在本文讨论范围。（传言中还有说MySQL使用1万+表头字段的，属于无稽之谈，哪怕是学习过一天数据库的开发人员也不会这样玩，而且1万+字段不得把人搞抑郁？其他传言就不提了，不信谣、不传谣！）
接口交互原因。接口设计不合理，提交数据量过大，导致服务器吞吐量下降。（比如提交健康码、提交试管条码、二维码等）
服务端未做缓存处理，每次操作相关查询效率低。（比如健康码管理用户信息），这一点相信开发人员能想到吧？
数据库问题。如果是mysql数据库，单节点数据库单表肯定是不行的。光是用户数据几千万，以mysql单表单库的能力肯定支撑不住，需要分库分表。
代码逻辑问题。比如循环查询等低级错误。或者还有发送提示短信等操作是否可以异步执行等。
网络架构问题。这一点是我分析后排除开发问题后最有可能的原因，注意这里说的网络架构不是说你什么nginx代理之类的，而是内外网穿透、网闸、边界这些网络。政府项目为了保证数据安全，经常服务器是在内网或专网，没有直接和互联网打通的。
服务器原因。服务器配置不足，支撑不了并发。
服务器滥用配置。关于tomcat等服务器的配置，调优参数相关。
接下来根据我的经验分析以上可能性较大的点。（第2、7、8点）
接口设计交互原因
我为什么会有这个猜测呢？由于核酸检测过程中涉及到健康码、试管条形码等需要解析的图片。
由于在开发生涯中遇到过一些对接文档要求将二维码图片转base64字符串提交到http接口的情况。（大家仔细想想，这很可笑。继续下文）
图片转base64，少说也是几K文件大小，多则几十K甚至上百K，直接提交到服务器对带宽的压力可想而知。还有服务端收到base64还要做处理、解析出二维码的内容，是不是也是耗时、耗性能操作。
我的解决办法是在客户端（小程序端）就解析好二维码、条形码的内容，在http接口提交二维码的文本内容即可，无需提交二维码、条形码图片。
加入健康码中是一个用户ID，提交一个二维码图片base64和提交一个用户ID相比，哪个更节约资源？我想不用多说吧
这是比较可能的一种原因，因为确实有这样的不合理的接口设计。
网络架构原因
如前文中所说，官方的服务器为了保证数据安全，一般服务器都部署在内网或专网中。
个人推测：这次是政府的项目的话，我推测服务器在政府专网（Tips：其他的还有比如公安网、视频专网等等专用网络）。
那么微信小程序采集核酸人员、试管信息属于是在互联网，那么要使http请求到达政务专网，按照我的经验来看是要经过网闸、边界等相关物理设备（这些设备你可以看成是物理防火墙，中间需要以文件方式摆渡数据，会把http请求落地为文件，文件再转为http请求到内网服务器）。
这样一来我们就可以推测，是否是边界、网闸等设备承受不住压力，导致超高延迟呢？
服务器滥用配置
假设核酸系统的服务器是使用的Tomcat，其实不是Tomcat也无所谓，道理一致。
服务器的连接超时时间配置过大，并且是故意配置过大。（我感觉这个原因可能性很大）
为何我会有此猜测呢？在做核酸的时候我看大白点击提交按钮后一直在转圈圈，并且按钮被置灰，转圈圈转了多久你们都想不到，按照昨晚上大家分享的平均每3分钟一个人来看，这个时间是非常久的，甚至超过3分钟的情况很多，大白说有一段时间存在20分钟左右才会一个人的情况。
假设服务器连接超时时间是默认值，那么不可能等待这么久，还能请求成功，Tomcat默认是45秒（ConnectionTimeout参数可配置），超过45秒会自动断开连接，请求失败。而昨晚上的情况并非如此。
那么很有可能就是开发人员修改过服务器的连接超时时间，配置了很大，才会出现这种情况。
如果连接超时时间配置过大，然而服务器处理能力又不够，那么就会造成请求堆积在操作系统上排队，导致迟迟没有响应，轮到你才会响应，堆积越来越多，响应时间越等越久。严重情况（maxThreads参数配置过大）可能还会导致CPU线程切片压力过大，导致服务器卡死。
结语
今早上通过简单猜想到的可能原因，如若有错请指正，谢谢！
如果大家还有什么猜想，可以评论区留言，到时候我吧大家留言补充在文章底部。
最后，请大家不信谣、不传谣，希望早日度过疫情难关。
四川加油！成都加油！