继贤2021-05-20老师，咨询下，对于一些公共服务，会同时支撑好多个产品，如果按照每个产品每个场景业务指标来规划，可能公共服务的规划容量会很大，实际应用中，所有产品并不会同时出现峰值的情况，那么问题来了，对于公共服务，如何做成本最优估算？作者回复: 好问题！我来简化一下问题，考虑有一个公共服务A，支撑了业务服务B和C。B和C不一定会在某个时间点同时出现峰值，但是综合起来对于到达公共服务A的总压力来说，一定会有一个峰值点X，在这个峰值点X上B和C不一定是峰值，但它们对于A的累计压力值是最高的。于是，在X这个峰值点的业务场景就是你应该考虑的容量预估的基准场景。 当然，前提是B和C要保证能够承载各自的峰值压力。
共 2 条评论3
远航2022-08-26 来自上海总结：限流的方式有两种，定量和定速。老师的问题应该用定速来解决，就是漏桶算法，但是这个桶要很大不能丢弃任何请求。作者回复: 精彩的回答！
1
于加硕2022-06-23本章主要是业务层的容量保障方案。 怎么避免无脑扩容呢？例如从运维视角，看到CPU使用率确实很高了，就应该扩容。运维从哪些方向，指标来判断业务代码需要优化呢？作者回复: 开玩笑的说，其实这是一个习惯问题，因为代码总是有优化空间的，但是不想优化也总是有理由的，哈哈。 建立这一习惯的方法是通过流程建设，将代码优化的流程植入到容量风险的防治工作中去。例如，运维可以与各团队的架构师合作，列出一些性能优化的检查项（如连接池大小、缓存大Key/热Key、慢SQL检测等），在提交扩容申请时，先通过这些检查项证明代码已经得到优化，再去执行扩容操作。在第14讲的最后部分，我还提到了一种激励措施来避免无脑扩容，你可以参考应用。 当然，应急响应不在其列，如果要紧急止损，该扩容还是要先扩容。
肥宅快乐饮^_^2021-05-28既然第三方接口有明确的tps上限，那么应该使用流量整形的方式让所有请求以tps=5的速率匀速通过系统。对应的限流策略可以使用漏桶算法或者令牌桶算法作者回复: 理解的非常准确！
Roy Liang2021-05-20我觉得这个系统是内部服务，即使高峰期流量也有限，限流只针对第三方接口，使用简单的固定窗口就可以了作者回复: 虽然是内部系统，但是如果工资没及时发出去也挺可怕的吧，哈哈。可以再想一想，针对这里的第三方接口限流，有没有流量整形和平滑限流的要求？
Chuck2021-07-13消息队列异步处理