04 | 容量治理的三板斧：扩容、限流与降级
扩容的实践要点
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
容量治理是保障系统稳定性和性能的重要手段。本文介绍了扩容、限流和降级这三种常见的容量治理手段。在扩容方面，强调了性能优化的重要性，提倡通过异步处理、读写分离、增加缓存、SQL调优等方式来腾出容量，避免无脑扩容和滥用扩容。同时，指出扩容需要联动系统整体资源共同规划，不能只关注服务资源，并且强调了对底层资源的影响也需要同时考虑。在限流方面，详细介绍了不同的限流策略和限流位置，并强调了限流应该是分层次的，根据业务特点选择合适的限流策略，确保限流策略的健壮性和可靠性。而降级则是从系统功能角度出发，人为或自动地将某些不重要的功能停掉或者简化，以降低服务负载，这部分释放的资源可以去支撑更核心的功能。文章还提到了降级的技术实现、分级策略和频繁演练的重要性。总的来说，本文通过实际案例讲解了扩容和限流的实践要点，提醒读者在容量治理中要谨慎对待扩容和限流，避免不经思考直接扩容，而是要努力通过性能优化和分层次的限流体系来解决容量问题。容量治理是一个全方位、体系化的思考认识，需要多角度覆盖容量保障的方方面面。
《容量保障核心技术与实战》，新⼈⾸单¥29
全部留言(6)
- 最新
- 精选
继贤老师，咨询下，对于一些公共服务，会同时支撑好多个产品，如果按照每个产品每个场景业务指标来规划，可能公共服务的规划容量会很大，实际应用中，所有产品并不会同时出现峰值的情况，那么问题来了，对于公共服务，如何做成本最优估算？作者回复: 好问题！我来简化一下问题，考虑有一个公共服务A，支撑了业务服务B和C。B和C不一定会在某个时间点同时出现峰值，但是综合起来对于到达公共服务A的总压力来说，一定会有一个峰值点X，在这个峰值点X上B和C不一定是峰值，但它们对于A的累计压力值是最高的。于是，在X这个峰值点的业务场景就是你应该考虑的容量预估的基准场景。 当然，前提是B和C要保证能够承载各自的峰值压力。
2021-05-2023
远航总结：限流的方式有两种，定量和定速。老师的问题应该用定速来解决，就是漏桶算法，但是这个桶要很大不能丢弃任何请求。作者回复: 精彩的回答！
2022-08-26归属地：上海1
于加硕本章主要是业务层的容量保障方案。 怎么避免无脑扩容呢？例如从运维视角，看到CPU使用率确实很高了，就应该扩容。运维从哪些方向，指标来判断业务代码需要优化呢？作者回复: 开玩笑的说，其实这是一个习惯问题，因为代码总是有优化空间的，但是不想优化也总是有理由的，哈哈。 建立这一习惯的方法是通过流程建设，将代码优化的流程植入到容量风险的防治工作中去。例如，运维可以与各团队的架构师合作，列出一些性能优化的检查项（如连接池大小、缓存大Key/热Key、慢SQL检测等），在提交扩容申请时，先通过这些检查项证明代码已经得到优化，再去执行扩容操作。在第14讲的最后部分，我还提到了一种激励措施来避免无脑扩容，你可以参考应用。 当然，应急响应不在其列，如果要紧急止损，该扩容还是要先扩容。
2022-06-23
肥宅快乐饮^_^既然第三方接口有明确的tps上限，那么应该使用流量整形的方式让所有请求以tps=5的速率匀速通过系统。对应的限流策略可以使用漏桶算法或者令牌桶算法作者回复: 理解的非常准确！
2021-05-28
Roy Liang我觉得这个系统是内部服务，即使高峰期流量也有限，限流只针对第三方接口，使用简单的固定窗口就可以了作者回复: 虽然是内部系统，但是如果工资没及时发出去也挺可怕的吧，哈哈。可以再想一想，针对这里的第三方接口限流，有没有流量整形和平滑限流的要求？
2021-05-20
Chuck消息队列异步处理2021-07-131
