今天节后第一天上班，突然看到朋友的发文，“国家在支援几位程序员吧”...。
是的，西安一码通又崩了！。。。。
从程序员的角度来说，这天实现技术型清零（但这显然不是我们想要的）。
--- 程序员的疑问 ---
为什么西安一码通短时间会出现两次崩溃？
产品设计推测：
西安一码通其它业务我们暂且不分析，那并不是重点，因为没有完全崩溃，崩溃的仅有扫码显示功能。
其实这是一个非常典型的大量查询、少数更新的业务，闭着眼睛分析一下，可以说， 90% 以上的流量都是查询。
我们先来看看第一版的产品形态，扫码之后展示个人部分姓名和身份证信息，同时下面展示绿、黄、红码。
这是西安一码通最开始的样子，业务流程仅仅只需要一个请求，甚至一个查询的 SQL 就可以搞定。到了后来，这个界面做了2次比较大的改版。
第一次改版新增了疫苗接种信息，加了一个边框；第二次改版新增了核酸检测信息，在最下方展示核酸检测时间、结果。
整个页面增加了2个查询业务，如果系统背后使用的是关系数据库，可能会多增加至少2个查询SQL。
基本上就是这样的一个需求，据统计西安有1300万人口，按照最大10%的市民同时扫码，也就是百万的并发量（说实话，这些并发量真的不高），但还是崩了。
问题推测：性能过载、架构设计、容灾备份。
出现疫情之后，用户在长时间无法刷出健康码的情况下，多次退出刷新重试，新的流量到达服务器，导致服务器压力变大、承受负载增加。也许西安“一码通”系统可能没做好限流措施。
紧接着是服务器问题。无论是企业和个人在租用服务器的时候都会受到峰值承受限制，一旦超过服务器的承受能力，就会导致服务器瘫痪，应用程序暂停，网站无法访问。造成服务器瘫痪的原因是在同一段时间内访问人数多，造成高流量的突进，超出了服务器的承受范围。
这一点在12月20日第一次崩溃当天晚上的官方回复中，我们看到有这样一句话：
12月20日早7:40分左右，西安“一码通”用户访问量激增，每秒访问量达到以往峰值的10倍以上，造成网络拥塞，致使包括“一码通”在内的部分应用系统无法正常使用。“
一码通”后台监控第一时间报警，各24小时驻场通信、网络、政务云、安全和运维团队立即开展排查，平台应用系统和数据库运行正常，判断问题出现在网络接口侧。
类似的推想还有性能过载问题及场景问题。这是典型的性能过载场景，或许内因是数据库瓶颈点以及网络链接数瓶颈点，但外因都是过载导致。
分析：或许西安“一码通”是个门户，核酸等“卡片”的数据是从各子系统引过来的服务器宕机。
上班高峰期，市民共同访问，导致服务器瞬时访问流量飙升，数据库性能跟不上，最终整个西安“一码通”服务挂了，可能之前设计的时候没有考虑过这种场景。
设计漏洞方面，也许没有考虑高流量高负载的情况，导致测试不充分；产品设计未考虑千万级的并发访问，交付前未进行同等级的压力测试。
此外，或许还涉及架构问题。
西安“一码通”功能影响“核酸检测”服务，说明模块间从界面到数据调用互相影响，可能不是微前端、微服务架构。
曾经有当地前端开发人员指出，西安“一码通”页面与核酸检测页面是有关联的，正常情况下这两大业务已经很大。“一码通”里面不仅承载了本身的数据，而且有核酸检测数据。按道理来说，两个模块是不应该互相影响的，关联性应该不是很高，其实可以分成两个不同的模块，分离开来降低它们之间的粘性。这样做的好处是，两块互不影响。假如数据仍有关联，可以把关联度降到最低，即使一个服务出现问题，另一个还能独立运行。
这两次的崩溃（特别是短时间），可能意味着不仅仅是“一码通”与核酸检测这两个模块之间的问题，或许后端与前端的架构有问题，可能不是微前端、微服务架构，没有做到很好的分离。
最后，不管怎么分析，这肯定是“天灾＋人祸”。
系统在没有经过严格测试之下，就直接投入到生产，在强度稍微大一点的环境中就崩溃了。
比西安大的城市很多，比西安现在疫情还要严重的情况，其它城市也遇到过，怎么没有出现类似的问题？
西安做为一个科技重镇，出现这样的问题真的不应该，特别是我看了这个小程序背后使用的域名地址之后。
有一种无力吐槽的感觉，虽然说这不影响程序的使用，但是从细节真的可以看出一个技术团队的严谨态度，特别是做公共服务的基础应用，一定要经得起极限测试才能交付。
希望这次能够吸取教训，避免再次出现类似的问题！