“一码通”宕机事件
“一码通”在某些时段用户使用高峰时，或链接访问量太大时，出现宕机故障。
要求：采取限流措施，提供应急处置措施，要求系统再优化，细节再完善，确保不出现拥塞宕机现象。
工业和信息化部总工程师韩夏强调，要切实加强网络和信息安全，优化应急预案，强化安全防护，排查安全隐患，防止出现网络安全事故，出现问题要及时响应，快速修复；要充分发挥区域协查和三公(工)融合作用，持续做好大数据和信息化支撑，西安“一码通”要加强技术改进和网络扩容，确保平台安全稳定运行。
“一码通”宕机事件是对性能测试的考验，网友的留言：
导致的原因：
- 需要承受几乎瞬间就达到千万甚至上亿的访问量的系统
- 测试人员经验不足，没有对UP值有一个合理的估计，连接冗余不足。
- 任何系统的设计都会有一个最大量的容忍度设计，假如：这个城市有1000万人，根据现实情况，最大设计容量也许200万就够了（即200万人同时刷“一码通”的情况）。但全市封城，每天每人都需要做核酸，每人每天不知道要集中刷多少次“一码通”，所以最大设计容量应该是有多少人就设计多大容量，否则必瘫。
- 系统架构设计问题
- 软件开发时，需要确定是否支持服务器阵列以及应用并发数是否有限制
- 高并发高负载没有技术经验或者经验不足
- 时间有限或者物理环境没搭建好，很难支撑这么突发的高并发
- 服务器容量不够，配置不高，数据过载就系统卡顿
- 估计瓶颈出现在数据库，时空伴随者和用户查询14天历史路径怎么算？
- 应急管理方面准备不充足，风险应对不及时
- 需要大数据处理经验和开发运营经验的公司承担的开发
解决的思路：
- 系统架构设计为微服务，把计算和查询分成不同服务来计算，再把查询的接口第一层加上cdn缓存和服务分流，第二层nginx分流，redis集群缓存，数据库分库分表，再搞上容错主备
- 做主从，多台服务器负载均衡，优化查询和数据结构加云数据库，上OSS和CDN上大数据，HBase ElasticSearch加持微服务，容器化，CDN，混合云，搞起来！
- 面对大并发、除了对自身程序和数据组件进行优化的同时，仍然需要对负载均衡--网络--服务器--数据库--redis进行扩容，也是解决问题的根本所在。程序减少和减弱对数据库的依赖，尽可能走缓存。
- 分布式缓存，才是最直接解决问题的关键。
- 不是简单的扩容问题，需要做动态负载均衡
- 扩容用于负载均衡，不能称之为优化，只是一个解决手段
- 支持动态扩容的，只要你的系统设计时采用的分布式架构，从500次并发支持转换到3000次，提前配置好，只需要1分钟就能完成切换，高峰期过了再切回来
- 限流降级缓存外加集群和分布式，应该可以撑住500万的QPS
- 系统设计时会要求使用上限的，例如设计是每秒500次的访问，冗余是1000次！所有的后续支持都围绕这个来，但是当每秒出现3000次，哪怕一瞬间，都会造成系统堵塞，访问溢出，轻则访问卡顿，重则蓝屏死机系统奔溃。但是对于没有疫情的地方，如果按照3000次每秒设计，成本又会成倍增加，这个需要慢慢完善的过程。
- 6台服务器，300M/bps入口带宽，我保证你可靠性99.99%，开发周期1个月，压测并发200，每秒处理万次请求，平均响应时间在300ms，成功率99.9%。
- 可以垂直升级和水平升级一起做
后期的深思：
- 论性能测试的重要性
- 论性能场景设计的合理性
- 不经过实践检验，是不能发现问题和解决问题的！发现问题，及时解决问题，这就是我们今后做好一切工作的出发点和落脚点！