2019-11-12天呐，这么好的内容怎么没几个人交流呢。
前一段时间微信支付故障，前端没有关闭微信支付通道，后端其他逻辑因为失败在疯狂重试（不是有节奏的延长重试时间），服务端也没有做限流，差点导致悲剧。
过载保护确实很重要。
对于老师说的:基于QPS还是基于资源使用率，我们常规压测是基于QPS。容量规划上可以容忍一半的机器故障。展开作者回复: 目前我看到的的确也是基于qps比较常见一些
1 3
2019-11-01用量的确很好
更好的解决方案，是直接基于该服务所依赖的关键资源，如 CPU 和内存等，来衡量服务的可用容量。我们为该服务预留了多少资源，这些资源已经用了多少，预计还能够用多久。 2
2019-11-01许老师，这几讲读下来，有一个疑问请教下：
每个人所处的项目规模有很大的不同，有的没做服务化还在跑负载均衡、有的可能到了七牛云的体量、有的可能是微博那种体量，另外就是人力可能也不允许，那么有什么衡量指标或依据可以判断一个服务端相关的SRE工作是否做到位？以此指导每个阶段应该做哪些最主要的事情？谢谢作者回复: 用户量不大的时候，方案简陋些没关系的，毕竟出问题影响面也小，所以怎么平衡每个公司有自己的一杆秤
1- 2020-01-26老师好，请问能推荐一两个基于服务器资源做限流熔断的框架或应用吗？
- 2019-12-20老师，请问重试是将请求失败的请求用代码直接再次发起请求吗？这会增加代码量，怎么判断一个接口需不需要重试的机制呢？
作者回复: 一般用比较统一的重试机制
2019-11-01负载均衡处的过载保护是怎么做的？作者回复: 比如，负载均衡是业务服务的前端，上面介绍的客户端侧能够做的过载保护机制都是可以考虑的。