一个开箱即用的「容量预估」思路

职场故事 阅读(1047)

我是一个着迷于产品和运营的技术人,乐于跨界的终身学习者。欢迎关注我哟~

每周五早6点 按时送达~我的第「85」篇原创敬上

?

随着20年来互联网的蓬勃发展,一个软件系统所要面对的访问压力上限被逐渐提高。

虽然如此,但是那些体量达到亿级或者是千万级的产品也只是少数公司的专属。对于整个行业里百万+的程序员群体来说,估计也就只有10%人有机会接触到这些“大系统”。

所以,一提到容量预估,大家可能第一时间想到的是,这是大公司的事,我们这种小系统不用考虑这个问题。

这说法其实不太对。现在这个时代,营销活动满天飞,初创企业更是在绞尽脑汁想着“一炮而红”,所以哪怕不是那些千万级以上的系统也需要考虑容量预估的问题。

对大型系统来说,容量预估是刚需,关乎到系统能不能扛住,或者投入的资源会不会过度浪费,毕竟1%都是好多钱呐。

而对小系统来说,多花个百八十万,多冗余一些资源也没问题

虽然如此,但是Z哥觉得,能不能做好「容量预估」,背后体现的是一个人解决没有标准答案的问题的能力。

这是很多程序员都缺乏的一个能力

所以,不管你当前是在大公司还是小公司,只要你希望提高你的架构能力,或者未来想有机会把握住在大公司的工作机会,那么这是一个必须要掌握的基本技能。


日积月累的程序员思维让大家都习惯了事事都有0和1,true和false。然而真正复杂的问题是那些没有标准答案的问题,在这些问题中,没有对和错,只有合适和不合适。

而且,如今大家的生活越来越“在线化”。如果一个系统的负载能力,我们一直不去关注它。那么,当好不容易熬到的“风口”真的吹来的时候,能把握住吗?还是眼睁睁的错过它们。


我想,大多数人对容量预估还是有一些概念的。通过数据推算出对系统承载能力的要求,并且实施满足要求的程序部署

比如,下个月要做一轮大促。系统要达到一个什么状态才能顺利支撑大促的开展

大家脑子里至少都会有这样的一个公式:

流量 / 单机性能 = X台机器

但我认为这个理解还可以再深入一些。Z哥的理解是:容量预估的本质是为了获得技术投入与业务发展之间的合理值,追求的是无限接近于“刚刚好”的状态

要达到“刚刚好”的状态,必然意味着不能凭借拍脑袋办事,而要考虑到尽可能多的维度,采集更多维度的数据作为参考

因为实际的情况,肯定不是像上面公式一样简单的线性关系。而是类似下面这样的对数曲线关系。

一个“开箱即用”的「容量预估」思路

弹性部分可以不用100%提前启用,但要随着备着。

到这里你就完成了整个容量预估工作的5个步骤。

其实最终得到的数据还有一些其他作用。比如,设置程序的线程数量、配置web容器(nginx、tomcat、iis)等等。

因为大多数情况下,参数都会设置的过大,甚至有不少小伙伴会一拍脑袋的设置成max值。

其实这样的风险是非常大的,不但会有资源耗尽的风险,在分布式系统中还会产生级联反应,影响上游系统。


好了,我们来总结一下。

这次呢,Z哥先和你聊了一下容量预估的意义。

然后,分享了我自己做容量预估的思路,通过5步法来实现。

  1. 得到业务的流量指标
  2. 通过调用比例获得相关接口的性能指标
  3. 根据历史数据进行校准
  4. 根据衰减曲线得到预估的节点数量
  5. 预留一些弹性空间

希望对你有所帮助。


推荐阅读:

  • 程序员如何摆脱“系统又卡了”的骚扰
  • 分布式系统「高性能」大招之——深入浅出「异步」


如果你觉得这篇文章还不错,就麻烦给个「」或者「分享」一下吧。

鼓励我的创作 :)


也可以「关注」我,带你以技术思维看世界~

想更进一步和我一起玩耍,欢迎「搜索微信公号:跨界架构师」。

内容包括:架构设计丨分布式系统丨产品丨运营丨个人深度思考。

更多原创精品,欢迎加入小圈子,请戳【了解更多】