30 如何做好微服务容量规划？

30 如何做好微服务容量规划？

专栏上一期我给你讲解了单体应用拆分为微服务后带来的开发、测试和运维复杂度的提升，可以通过DevOps实现CI/CD流程的自动化来解决。除此之外，单体应用拆分为微服务还带来另外一个问题，也就是拆分出来后的多个微服务容量如何规划的问题。在单体应用时，只需要针对这个单体应用的访问量和实际接口性能来决定要不要给单体应用扩容，而拆分为众多的微服务之后，需要考虑每个服务的容量规划，它的复杂度主要来自下面几个方面。

• 服务数量众多，纯靠人肉运维难以管理，比如微博Feed业务仅仅RPC服务就有将近40个。
• 服务的接口表现差异巨大，有的接口属于访问量比较大，但接口响应时间比较短的轻接口；有的接口属于访问量比较小，但接口响应时间比较长的重接口。比如微博Feed业务中计数接口的平均耗时只有2～3ms，而微博Feed业务中Feed接口的平均耗时要超过200ms。
• 服务部署的集群规模大小不同，需要扩容的机器数量差异很大。比如微博的AB测试服务集群只有大约20台机器，扩容只需要几台机器就满足了；而Feed服务则有上千台机器，往往扩容需要上百台机器。
• 服务之间还存在依赖关系，在服务扩容的时候，还需要考虑依赖服务的容量是否足够。比如微博Feed业务扩容还依赖用户关系服务和Card服务，扩容时还