西安最近因为疫情+出血热一度备受关注，加之一码通事件，让其争议不断。
事件回顾：12月20日8点左右，不少人发现西安一码通无法打开，整整一天，一码通处于瘫痪状态，严重影响民众的出行，更闹出了发誓自己做过核酸才能上班的闹剧。
后来，官方解释道：因访问量过大，导致系统崩溃。
据悉，负责运维一码通的是西安电信，所以在恢复系统的策略是优先恢复电信用户，移动和联通用户迟迟无法恢复（这种时候还在搞这种小九九）。直至21日上午，系统才恢复正常。
在此，其他不作讨论，仅从技术的角度分析这起事件。
下面分析下一码通事件所犯的技术错误
1.压力测试不充分
对于一个常驻人口千万级的城市，在疫情严峻的大背景下，应该预测到一码通的并发访问压力。在架构设计时，结合实际使用场景，应充分考虑系统的QPS，做好严谨的压力测试，最终输出可信的压测报告。
2.容灾能力差
对于并发访问场景的乐观估计，导致瞬时流量骤增时，系统扛不住压力崩溃。对此，常规的限流、熔断、降级等措施，都可以有效的保护系统。反观一码通，应急方案欠缺，容灾能力有待提升。
3.架构设计的问题
首先，健康码和核酸证明，不应该做强绑定。不能因为其中一个异常，导致另一个无法访问。这是产品设计层面的缺陷；
其次，单个用户的访问异常，不能无限次的允许其访问服务，这只会使服务压力更加雪上加霜；
最后，容错性差，猜想没有做分布式集群部署或即使做了但也存在很大的问题；
4.监控不足
任何一个程序软件都不是完美的，不可能一直稳定运行，我们要承认其可能出错的事实。比如常见的CPU、内存使用率飙升，很大概率会导致系统崩溃。这时应设置最起码的阈值，当超过这个阈值时，提前预警，可防止灾难的发生。
标签：一码,思考,系统,访问,事件,西安,压力 来源： https://www.cnblogs.com/cuiliyang/p/15718776.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。