【51CTO.com原创稿件】西安一码通不到一个月就崩溃两次，虽然说在实际项目和线上运行时系统崩溃是很有可能遇到的问题，但是如此大规模的，而且还是短时间内两次大规模崩溃，着实少见。那么如果回到未来，该怎么设计一码通来降低崩溃的情况呢?下面从技术和业务两方面来谈谈一码通的设计。
一、崩溃的原因分析
因为这两次崩溃的模块只是扫码和亮码，因此我们来分析一下这两个模块的业务。扫码和亮码功能类似，都是典型的查询大于更新的业务，大部分流量都来自于查询。下面我们来看看一码通在不同版本的发展。
第一版的一码通只展示个人身份证号、姓名和码的颜色。这三个字段有可能是存储于一个表中，使用一条 SQL 就能查出来。但是作为一个上万人使用的系统，不可能所有数据存在于一张表中，因此身份证号和姓名极有可能存储在一张表里，码的颜色在另一张表中，因此这里很有可能最少存在一条 join 连接。
到了第二版和第三版一码通做了很大的改变，首先是新增了疫苗接种信息，其次又新增了核酸检测信息，展示核酸检测的时间和结果。这就增加了两个查询，如果一码通在不考虑使用缓存，只是用关系数据库的情况下，那么就有可能增加最少两个 SQL 查询。
以上就是一码通扫码和亮码两个模块大致的业务情况。这个业务所需要面对的是最高百万级别的并发量(西安人口一千多万)，这种级别的并发量在互联网公司就是日常的并发量。那么它怎么就崩了呢?在官方的消息中有这么两段话(只截取里面关键部分)：
1. 西安一码通用户访问量激增，每秒访问量达到以往峰值的10倍以上，造成网络拥塞;
2. 判断问题出现在网络接口侧。
由此可以判断是网络出现了问题。一般来说用户的请求，先访问域名，然后通过 DNS 服务器解析拿到 IP ，通过 IP 访问到服务器，最后服务器将响应结果返回给客户端。本次的故障就出现在通过 IP 访问服务器阶段。因为网络拥塞，因此可以直接增加带宽，但当系统恢复时，西安的小伙伴都发现一码通回滚到了第一版，而且在一码通的首页新增加了核酸查询页面的链接，因此出现崩溃很有可能不只是带宽的问题。这应该是外部请求的数量超过了系统最大处理能力造成的问题。
一般来说，产生这种问题的原因无非就是系统架构的问题，解决这个问题有两种方法，扩容和限流：
1. 在请求达到承载的顶峰时，让后续所有请求等待，进行限流。限流方案很多，最简单的方式是使用 Nginx，如果效果不理想的话可以自定义算法在接入层限流。限流不能完全解决问题，只会阻挡部分请求。
2. 通过增加服务器数量、增加数据库数量来提升系统的承载能力，这个是扩容。因为一码通在出现问题后进行了回滚，并没有进行扩容。因此大概率他们在系统架构设计上并没有考虑扩容问题，因此扩容这个方案对于系统架构来说可能很难。
二、崩溃的解决方案
如果要解决上一小节的问题，可以从三个方面来解决。
1. 采用读写分离
将一码通业务按照访问频率进行拆分：常用模块和非常用模块。常用模块流量较大，将“读”单独处理出来，在数据库前端加入缓存中间件，优先读取缓存中的信息，这样即使数据库挂了，业务系统也能从缓存中读取数据。非常用模块流量较小，比如核酸信息和疫苗接种信息的更新，直接对数据库进行操作。
2. 分库分表和服务拆分
利用用户 ID 取模后的值确定需要拆分成多少个库或表，每个库或表对应一个或多个服务子系统，接口将流量分配到不同的服务子系统上，这样就减轻了单库或单表以及服务系统的压力，并且也能在流量暴增的时候快速地进行扩容。
3. 容灾备份
使用异地多机房部署服务，提前做好的容灾备份方案，避免出现前述的问题。
总结
西安一码通明显是在系统没有严格测试的情况下，就发布到了生产环境，并发一高就崩溃。本文所述的这些问题只是根据目前可见的情况进行的分析，所提出的解决方案也是比较常见的解决方案。但是根据这些解决方案几乎可以处理掉西安一码通崩溃的问题。
作者介绍
朱钢，51CTO社区编辑，2019年CSDN博客专家20强，2020年腾讯云+社区优秀作者，10年一线开发经验，曾参与猎头服务网站架构设计，企业智能客服以及大型电子政务系统开发，主导某大型央企内部防泄密和电子文档安全监控系统的建设，目前在BIM头部企业从事招投标软件开发。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
