总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 zhihu.com/question/509914161/answer/2299099095 「卢兴民」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

健康码连续挂了两次真的有点业余了，不过确实也没有low到服务器生成图片进行下发这么蠢。

看一波西安健康码的接口数据。

真正的二维码数据是 /person/app/refreshQRCode这个接口

看下这个接口返回，设计上也没有太大的问题。

主要问题集中在所有的js/css/img这些静态资源全都从从一个出口进行提供，没上CDN粗略估算了一下，js/css/img数据总共约500kB按照从某个群里得到的数据，暂且认为是准的，健康码的请求量峰值达到了3.3w qps

那按照这个量估计 33000 x 500 x 8 bps ≈ 125Gbps 这个出口量级很难用单机房承载，峰值一来，出口网卡打满，直接gg。

到写这个回答时，西安健康码还是没有将静态资源上CDN，之后看看访问量再起飞的时候，能不能扛得住吧。

最后再补充一点，这应用只是其中一个原因。不排除后端和数据库缓存也有更大的问题。

文章目录