30 | 如何做好微服务容量规划？
胡忠想
该思维导图由 AI 生成，仅供参考
专栏上一期我给你讲解了单体应用拆分为微服务后带来的开发、测试和运维复杂度的提升，可以通过 DevOps 实现 CI/CD 流程的自动化来解决。除此之外，单体应用拆分为微服务还带来另外一个问题，也就是拆分出来后的多个微服务容量如何规划的问题。在单体应用时，只需要针对这个单体应用的访问量和实际接口性能来决定要不要给单体应用扩容，而拆分为众多的微服务之后，需要考虑每个服务的容量规划，它的复杂度主要来自下面几个方面。
服务数量众多，纯靠人肉运维难以管理，比如微博 Feed 业务仅仅 RPC 服务就有将近 40 个。
服务的接口表现差异巨大，有的接口属于访问量比较大，但接口响应时间比较短的轻接口；有的接口属于访问量比较小，但接口响应时间比较长的重接口。比如微博 Feed 业务中计数接口的平均耗时只有 2～3ms，而微博 Feed 业务中 Feed 接口的平均耗时要超过 200ms。
服务部署的集群规模大小不同，需要扩容的机器数量差异很大。比如微博的 AB 测试服务集群只有大约 20 台机器，扩容只需要几台机器就满足了；而 Feed 服务则有上千台机器，往往扩容需要上百台机器。
服务之间还存在依赖关系，在服务扩容的时候，还需要考虑依赖服务的容量是否足够。比如微博 Feed 业务扩容还依赖用户关系服务和 Card 服务，扩容时还需要考虑依赖的用户关系服务和 Card 服务容量是否有问题。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了微服务容量规划的重要性以及容量规划系统的作用。作者提出了选择合适的压测指标和获取单机的最大容量的方法，并介绍了实时获取集群的运行负荷的方法。在调度决策方面，文章详细阐述了如何利用水位线进行扩缩容的决策，并提出了具体的扩缩容策略。此外，作者还分享了在计算集群的水位线时可能遇到的问题，并提出了解决方案。总的来说，本文通过详细介绍容量评估的关键点和方法，为读者提供了在微服务容量规划中的实用指导，有助于提高运维效率和系统稳定性。文章内容丰富，涵盖了容量规划的方方面面，对于需要深入了解微服务容量规划的读者来说，是一篇具有实际指导意义的文章。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学微服务》，新⼈⾸单¥59
《从 0 开始学微服务》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(17)
- 最新
- 精选
波波安老师，这里都是考虑服务层面的扩缩容。对于数据库层面存在瓶颈的情况，有什么经验分享吗。作者回复: 数据库方面因为实现自动扩缩容的难度太大，我们目前是留有足够的冗余度，核心数据库都是4倍冗余
2018-11-1814
每天晒白牙请问阿忠伯，分区加权计算，响应时间越长，加权越大的原因是什么呢？作者回复: 这里权重指的是对机器资源的占用
2018-10-3012
Switch为什么响应时间越长，权重越高？ 引用：区间加权来计算，也就是把请求按照响应时间分成多个区间，每个区间分别赋予不同的权重，响应时间越长权重越高作者回复: 这里权重代表的是对系统资源的占用
2018-10-311
李二木问一个与本节无关的问题，微服务通过http请求调用，数据交换你们做了压缩吗？如果使用过那么用的那种方式呢？作者回复: 一般会用gzip压缩
2018-10-311- 扁扁圆圆关于权重那块，慢请求越多，计算出来的单机容量更高？不是应该更低吗？
作者回复: 这里容量应该是所占容量的意思
2018-11-02 
Ricky Fung想问一下在生产环境做压测，由压测产生的数据要如何处理才不会污染真实的数据？2018-12-2515- 波波安不评估数据库的承受能力吗，不停的扩展服务，把数据库压挂了怎么办？2018-11-1812
Do安全线和致命线是怎么设定的呢? 和集群容量是什么样的关系?2019-01-291
俯瞰风景.微服务容量规划的目的是为了合理高效地利用硬件资源。 做出合理的容量规划的前提是对容量进行评估，通过监控数据指标，绘制集群水位线，然后通过水位线做出扩容和缩容的调度决策。2021-10-08
Tree如果响应时间越大，占用的权重越大，那么最终在计算集群容量的时候该怎么计算呢2021-05-12
收起评论
