MySQL|西安一码通系统崩溃技术分析 docker

这两天西安一码通系统崩溃的事情传的沸沸扬扬的。有很多粉丝留言给我，让我发表一下对这件事的看法。也有粉丝开玩笑问我说这个系统是不是我做的，我在这里正式回复一下，这个系统不是我做的。如果是我做的，以我的经验和能力，不用等到今天才崩溃，应该早就崩溃了。开个玩笑。

下面我从技术角度来分析一下，有可能导致西安一码通系统崩溃的几种原因。说的不一定对，我抛砖引玉，请大家批评指正。
西安一码通这样的大型系统，通常具有三个特点：
1. 海量数据，数据量比较大，尤其是用户的行程数据量非常大；
2. 高并发，同一时间很多人同时使用；
3. 需要具有高可用性，因为是防疫工作依赖的系统，所以需要保证系统稳定。
这种系统出现问题，最有可能是这几个方面的问题：
1. 网络堵塞，这种情况发生的可能性比较小。因为一码通业务需要传输的数据量不大，都是一些文本内容，相比图片、视频类网站来说，数据量是非常小的。
【MySQL|西安一码通系统崩溃技术分析】2. 硬件故障，这种情况发生的可能性也比较小。首先硬件不那么容易坏，另外，系统搭建的时候都会建立硬件冗余备份机制。硬件故障的话，也会平滑切换到备用硬件上。
3. 关键服务不可用，这种可能性最大。通常这种系统都会有很多个子系统和关联系统组成，做系统设计的时候都会非常细致地分析和设计，这些子系统也应该都是经过高强度压力测试的，每个子系统内部应该都是稳健性（鲁棒性）很好的。所以，自从20年上线以来一直比较稳定。
但是，这种大的软件系统最怕的就是紧急需求变更。因为开发、设计人员更迭，要求的时间又紧，很容易激发技术人员的冒险精神。尤其是没做过大型高并发系统的开发人员，他们想象不到那种源源不绝的网络请求涌进来的场景，这种场景很像DDOS攻击，也叫分布式拒绝服务攻击。如果系统分析做的不够透彻，测试方案不够完备，就会导致新增加的功能不稳定。有时候一个请求的响应速度只要慢几毫秒，就会形成堵塞，服务器就会开始拒绝服务。
网上有人说，西安一码通的二维码是服务器端生成，需要将图片从服务器下载到app端，造成网络流量加大形成瓶颈。我觉得这个不大可能，有点开发常识的人都知道二维码就是一串字符，只要把字符下发到app上， app可以自行生成二维码了。我认为一码通的开发人员是绝对不会在服务器上生成二维码的。
大家有什么看法，可以在评论区留言讨论。