容量治理-扩容、限流和降级

优秀的容量治理 不但能解决当前问题，还能防患于未然

扩容

• 扩容避免盲目，可以作为应急手段，避免滥用和无脑用
• 考虑对底层资源的影响 （中间件、数据库、缓存这类、连接数、长连接数之类的）
• 建立谨慎扩容风气
• 优化程序为主（异步、读写分离、增加缓存、代码和SQL调优等等）

限流

常见限流策略

• 流量整形： 指不管流量到达的速率多么不稳定，在接收流量后，都将其匀速输出的过程，即“乱进齐出”。
• 容忍突发流量： 指的是限流策略允许流量在短时间内突增，且在突增结束后不会影响后续流量的正常限流。
• 平滑限流： 指的是在限流周期内流量分布均匀，比如限制 10 秒内请求次数不超过 1000，平滑限流应做到分摊到每秒不超过 100 次请求。反之，不平滑限流有可能在第 1 秒就请求了 1000 次，后面 9 秒无法再发出任何请求。

限流策略	流量整形	容忍突发流量	平滑限流	实现复杂度
固定窗口	不支持	不支持	不支持	低
滑动窗口	不支持	不支持	不支持	中
漏桶算法	支持	不支持	支持	高
令牌桶算法	支持	支持	支持	高

限流应当采用分治的思想

按位置划分的话，可以分为：

1. 网关层限流｜入口限流 静态资源走CDN，仅放过合法的请求，针对IP或者域名粗放式进行限流。
2. 接入层限流 ｜ 粒度比网关细，主要手段有负载均衡和限流措施，分摊服务压力。
3. 应用层限流 ｜ 有自己或者单机的限流， 常用的微服务相关的容量治理主要是在这个环节，针对自己，集群，第三方调用的治理。
4. 数据库层限流 ｜ 主要采取集群、读写分离等方法分摊压力。

和搞安全类似的想法，“一切输入都是有害的”，不信任上层，要有自己的一套治理方法。

降级

降级主要分 自动降级和人工降级。

通过停用或者简化一些不重要的功能或者服务，来保证核心业务的正常运转。

像微服务的熔断就属于自动降级一种。

降级策略：

1. 牺牲用户体验 如不个性化推荐
2. 放弃部分功能 如热词推荐
3. 降低安全性 如不记录审查日志之类的
4. 降低准确性 如不计算权重
5. 降低一致性 如允许一定超卖
6. 降低数据量 如展示数据量少 只最近的多少条

以上学习笔记来自