总阅读量:次

《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，之后看看访问量再起飞的时候，能不能扛得住吧。

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

文章目录