已阅读
高并发？大流量？CDN加速供应商是不二选择
前几天年三十前后的时候，百度的抢红包广告大肆铺开，导致很多用户参与进来。结果，百度App没挂，苹果商店App Store倒是挂了。毕竟对于其他国家，可能难以想象需要面对中国如此大的用户群的“测试”。
不过解决高并发大流量大致算个伪需求，绝大多数应用开发出来不会遇上如此场景，绝大多数开发者也不会面对如此的挑战。
那两个爆火的“抑郁症测试”H5、“香菇蓝瘦”H5游戏的意想不到的爆发给我在技术角度上提了很高的要求。
参考一下之前两次面对大流量场景的心情，真是痛并快乐着：
下面是当时写的文字和方案
有幸在一个月内两次面对这样的极端场景:
“香菇蓝瘦”H5小游戏峰值日访问5百万，并发上千。应用本身基本是纯静态，动态部分是初始化向微信请求openid，分享出去时还有个服务器的请求存储分享记录。
我的服务器是双核4G，很普通的机器，能用这样的机器勉强撑住其实很屌了。处理如此场景不只是纯技术问题，还有一些聪明的解决之道。说下我的一些解决方案。
-
静态资源CDN。大多数程序员都知道，似乎也没什么好说。
-
配置调优。我用的是Tengnie作反向代理，ngnix在高并发下性能不错。
-
因为CDN的域名不能与源站相同，所以html的请求得处理得远精小越好，甚至body里的代码可以一并放在js加载，而js可以放在CDN上。香菇游戏的html就只有3K，gzip压缩后只有1.8k。
-
ngnix再做个html缓存，进一步降低web容器的压力。
-
分享出去的链接放个其他域名的html作为着陆页，这个着陆页内部跳转到应用地址。而这个html再放到CDN上，进一步减少压力。
当时写的这些tips问题不大，不过我想如今还可以适当多补充几点，对于当时技术上还算弱鸡的我，竟然有了别人穷其一生都没有的挑战，之后的几年自然有更多的认识。
所以如果今时今日我还有这样的面对挑战的机会，我会把这些同样给完善好：
-
能缓存的都缓存，redis、物理层、应用层，能加的都加上（不过缓存击穿和缓存刷新是另外个课题）
-
全CDN，包括html（过去html是直接请求应用服务器，现在可以用全站CDN解决了，参考《从阿里云CDN弃坑去又拍云CDN，告诉你不是越大越好》）
-
负载均衡（静态文件都CDN了，那这个就是针对动态接口了）
-
监控随时提高配置（同样针对动态接口）
-
做好构建部署，以防爆火后的修改。（之前就吃过这亏，火了之后还想再优化，但是原始方式上传很慢）
暂时想到那么多...看看以后特别展开再写个详细的文章。
事实上，以目前中国互联网的环境以及技术人员的能力，开发实现98%的产品需求都不成问题。而技术人员的区分度除了熟练度、效率那些相差几倍之外，更多的是来自于开发出来的产品能否应付最恶劣的使用场景，这里的差距可能可以形成几十几百倍的“壁垒”。
