西安一码通事件的技术思考

西安最近因为疫情+出血热一度备受关注，加之一码通事件，让其争议不断。

事件回顾：12月20日8点左右，不少人发现西安一码通无法打开，整整一天，一码通处于瘫痪状态，严重影响民众的出行，更闹出了发誓自己做过核酸才能上班的闹剧。

后来，官方解释道：因访问量过大，导致系统崩溃。

据悉，负责运维一码通的是西安电信，所以在恢复系统的策略是优先恢复电信用户，移动和联通用户迟迟无法恢复（这种时候还在搞这种小九九）。直至21日上午，系统才恢复正常。

在此，其他不作讨论，仅从技术的角度分析这起事件。

下面分析下一码通事件所犯的技术错误

 

1.压力测试不充分

对于一个常驻人口千万级的城市，在疫情严峻的大背景下，应该预测到一码通的并发访问压力。在架构设计时，结合实际使用场景，应充分考虑系统的QPS，做好严谨的压力测试，最终输出可信的压测报告。

 

2.容灾能力差

对于并发访问场景的乐观估计，导致瞬时流量骤增时，系统扛不住压力崩溃。对此，常规的限流、熔断、降级等措施，都可以有效的保护系统。反观一码通，应急方案欠缺，容灾能力有待提升。

 

3.架构设计的问题

首先，健康码和核酸证明，不应该做强绑定。不能因为其中一个异常，导致另一个无法访问。这是产品设计层面的缺陷；

其次，单个用户的访问异常，不能无限次的允许其访问服务，这只会使服务压力更加雪上加霜；

最后，容错性差，猜想没有做分布式集群部署或即使做了但也存在很大的问题；

 

4.监控不足

任何一个程序软件都不是完美的，不可能一直稳定运行，我们要承认其可能出错的事实。比如常见的CPU、内存使用率飙升，很大概率会导致系统崩溃。这时应设置最起码的阈值，当超过这个阈值时，提前预警，可防止灾难的发生。

标签：一码,思考,系统,访问,事件,西安,压力
来源： https://www.cnblogs.com/cuiliyang/p/15718776.html