作「容量预估」可没有true和false

若是第二次看到个人文章，欢迎「文末」扫码订阅我我的的公众号（跨界架构师）哟~ 

每周五11：45 按时送达。固然了，也会时不时加个餐～

个人第「85」篇原创敬上

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

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

因此，一提到容量预估，你们可能第一时间想到的是，这是大公司的事，咱们这种小系统不用考虑这个问题。

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

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

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

虽然如此，可是Z哥以为，能不能作好「容量预估」，背后体现的是一我的解决没有标准答案的问题的能力。

这是不少程序员都缺少的一个能力。

因此，无论你当前是在大公司仍是小公司，只要你但愿提升你的架构能力，或者将来想有机会把握住在大公司的工做机会，那么这是一个必需要掌握的基本技能。

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

并且，现在你们的生活愈来愈“在线化”。若是一个系统的负载能力，咱们一直不去关注它。那么，当好不容易熬到的“风口”真的吹来的时候，能把握住吗？仍是眼睁睁的错过它们。

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

好比，下个月要作一轮大促。系统要达到一个什么状态才能顺利支撑大促的开展？

你们脑子里至少都会有这样的一个公式：

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

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

要达到“刚恰好”的状态，必然意味着不能凭借拍脑壳办事，而要考虑到尽量多的维度，采集更多维度的数据做为参考。

由于实际的状况，确定不是像上面公式同样简单的线性关系。而是相似下面这样的对数曲线关系。

那么具体该怎么作容量规划呢？

在这以前咱们先得搞清楚几个概念。

首先是指标。咱们主要关注如下几个指标。

• UV（Unique Vistor）：一段时间内的访客数，同一访客在该时段内的屡次访问只计一次。
• PV（page view）：一段时间内的页面浏览次数，同一用户屡次打开同一页面也继续累计。
• 响应时间/系统延迟(Latency)：系统处理一个请求/任务的延迟（请求处理时间+数据传输时间）
• 吞吐量(Throughput)：一个单位时间内能够处理的请求数。也就是该单位时间内发起的请求总数/平均响应时间，请求数能够是一次pv、也能够是一次rpc调用等等。
• TPS（Transaction Per Second）：能够理解为，单位时间是“秒”的「吞吐量」。

其次，咱们要对会产生性能开销的地方要有认识。这主要分为3个部分。

• 硬件/操做系统层面的开销。如磁盘I/O、网络I/O，CPU的多线程切换等等。
• 进程运行的开销。如代码逻辑啊、锁啊等等。
• 多个进程之间的通讯开销。rpc框架、数据库访问框架、redis/memcached访问SDK、MQ访问SDK等等。

而后就能够开始作「容量规划」了。

我通常是按如下5个步骤进行。

第一步，搞清楚业务的情况，先获得业务上的指标。

技术工做最怕隔着“部门墙”，蒙着头作，沉浸在本身的“小世界”里。

因此，无论经过什么途径，得先对一些业务指标有客观的认识，PV、UV的数据是必须的。能够找业务方聊，也能够借助百度指数、微信指数等更宏观数据来进行参考和修正。

第二步，围绕这个业务指标，对所涉及的相关技术接口制定性能指标。

其实就是要获得一个业务流量与技术的性能指标之间的一个比例关系。

好比，访问一次A页面，涉及到调用a接口2次，b接口1次，c接口3次这样。

作这事儿有一个简单的办法。

先在系统中的每一个api接口作好数据采集，目的是为了后续能得到两个数据，响应时间和次数等等。

而后借助一些压测工具，好比loadrunner之类，对当前的业务场景作一轮的全链路压测。模拟的用户数不用很大，由于咱们只是为了获得一个比例。

这样，在压测结束后，你就能够将loadrunner中所记录的发起请求的数量，对比api接口采集到的数据，就能获得每一个接口与业务流量之间的关系。顺带也能看到在低压力下的错误率、平均响应时间、tp9五、tp99等等的状况。

第三步，借助过去的经验对标准进行校准。

真实的生产环境是错综复杂的，由于一个api接口每每会被众多地方调用。

那么作校准就是为了让咱们的预估更接近真实的生产环境一些。

若是有过去成功支撑的案例数据就最好了。用当时的UV、PV数据、接口与业务量比例对比当前的业务预估的UV、PV、接口与业务量比例进行同比例的调整。

能够得出下面这样的公式：

应知足的TPS = 成功时的TPS  (当前预估业务流量 / 成功时业务流量)  (当前业务接口比例/成功时业务接口比例)。

没有成功案例的话，能够经过分析数据库中任何带有“时间”字段的数据，找到其中已知可承受的最高并发值，以及对应的时间点。（简单粗暴的方式能够groupby“时间字段”）

再反向去找对应这个时间节点的PV、UV。

而后再与此次的业务指标预估进行对比，看下差别比例。

应知足的TPS = 历史最高TPS(无论抗没扛住)   (当前预估业务流量 /  历史最高TPS时业务流量)  (当前业务接口比例 / 历史最高TPS(无论抗没扛住) 时业务接口比例)。

固然了，最坏的状况就是，过去对数据不够重视，彻底没有数据能够参考。

那就立刻作数据埋点，分析当前系统的运行时数据，获得当前某个时段的业务流量以及对应的TPS。这应该不是难事。

这样也能够推算出一个「应知足的TPS」。

应知足的TPS = 该TPS   （当前预估业务流量 / 某时段业务流量）  当前业务接口比例

最后，获得了一个这样的每一个接口的性能指标。

接下来要作的第四步，就是肯定到底要部署多少服务器，多少程序才能知足这些标准。

正如前面所说，获得这个结果不是简单的作除法，由于这不是一个线性关系。

因此，咱们须要动手进行验证。

你能够经过分别压测1台、2台、3台、……，不一样数量的服务器，获得下面这样的一个曲线。（固然，性能优化工做也是在这个期间进行）

如此一来，你就能够根据这个衰减的趋势，获得一个理论上能支撑业务所需的程序数量和服务器数量。

固然了，理论毕竟是理论，为了保险起见，仍是要预留必定的弹性空间，这就是第五步。省得算的太“扣”，没给本身留后路。

该“弹”多少合适呢？

Z哥的建议是，同比分析一下过去一段时间内的业务量状况，观察每一个波峰的同比增加大小，将同比增加的最大值做为弹性部分的比例。

弹性部分能够不用100%提早启用，但要随着备着。

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

其实最终获得的数据还有一些其余做用。好比，设置程序的线程数量、配置web容器（nginx、tomcat、iis）等等。

由于大多数状况下，参数都会设置的过大，甚至有很多小伙伴会一拍脑壳的设置成max值。

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

好了，咱们来总结一下。

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

而后，分享了我本身作容量预估的思路，经过5步法来实现。

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

但愿对你有所帮助。

推荐阅读：

• 分布式系统关注点——360°的全方位监控
• 分布式系统关注点——深刻浅出「异步」

做者：Zachary

出处：https://zacharyfan.com/archives/835.html

若是你喜欢这篇文章，能够点一下文末的「赞」。

这样能够给我一点反馈。: )

谢谢你的举手之劳。

▶关于做者：张帆（Zachary， 我的微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎 扫描下方的二维码~。

若是你是初级程序员，想提高但不知道如何下手。又或者作程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注个人公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思惟导图。

若是你是运营，面对不断变化的市场一筹莫展。又或者想了解主流的运营策略，以丰富本身的“仓库”。欢迎关注个人公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思惟导图。

按期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些深度思考。