多网合一网站平台建设,免费品牌网站制作,如何美化网站,网站投放广告多少钱这里是Z哥的个人公众号每周五11#xff1a;45 按时送达当然了#xff0c;也会时不时加个餐#xff5e;我的第「85」篇原创敬上随着20年来互联网的蓬勃发展#xff0c;一个软件系统所要面对的访问压力上限被逐渐提高。虽然如此#xff0c;但是那些体量达到亿级或者是千万级… 这里是Z哥的个人公众号每周五1145 按时送达当然了也会时不时加个餐我的第「85」篇原创敬上随着20年来互联网的蓬勃发展一个软件系统所要面对的访问压力上限被逐渐提高。虽然如此但是那些体量达到亿级或者是千万级的产品也只是少数公司的专属。对于整个行业里百万的程序员群体来说估计也就只有10%人有机会接触到这些“大系统”。所以一提到容量预估大家可能第一时间想到的是这是大公司的事我们这种小系统不用考虑这个问题。这说法其实不太对。现在这个时代营销活动满天飞初创企业更是在绞尽脑汁想着“一炮而红”所以哪怕不是那些千万级以上的系统也需要考虑容量预估的问题。对大型系统来说容量预估是刚需关乎到系统能不能扛住或者投入的资源会不会过度浪费毕竟1%都是好多钱呐。而对小系统来说多花个百八十万多冗余一些资源也没问题。虽然如此但是Z哥觉得能不能做好「容量预估」背后体现的是一个人解决没有标准答案的问题的能力。这是很多程序员都缺乏的一个能力。所以不管你当前是在大公司还是小公司只要你希望提高你的架构能力或者未来想有机会把握住在大公司的工作机会那么这是一个必须要掌握的基本技能。日积月累的程序员思维让大家都习惯了事事都有0和1true和false。然而真正复杂的问题是那些没有标准答案的问题在这些问题中没有对和错只有合适和不合适。而且如今大家的生活越来越“在线化”。如果一个系统的负载能力我们一直不去关注它。那么当好不容易熬到的“风口”真的吹来的时候能把握住吗还是眼睁睁的错过它们。我想大多数人对容量预估还是有一些概念的。通过数据推算出对系统承载能力的要求并且实施满足要求的程序部署。比如下个月要做一轮大促。系统要达到一个什么状态才能顺利支撑大促的开展大家脑子里至少都会有这样的一个公式流量 / 单机性能  X台机器但我认为这个理解还可以再深入一些。Z哥的理解是容量预估的本质是为了获得技术投入与业务发展之间的合理值追求的是无限接近于“刚刚好”的状态。要达到“刚刚好”的状态必然意味着不能凭借拍脑袋办事而要考虑到尽可能多的维度采集更多维度的数据作为参考。因为实际的情况肯定不是像上面公式一样简单的线性关系。而是类似下面这样的对数曲线关系。那么具体该怎么做容量规划呢在这之前我们先得搞清楚几个概念。首先是指标。我们主要关注以下几个指标。UVUnique Vistor一段时间内的访客数同一访客在该时段内的多次访问只计一次。PVpage view一段时间内的页面浏览次数同一用户多次打开同一页面也继续累计。响应时间/系统延迟(Latency)系统处理一个请求/任务的延迟请求处理时间数据传输时间吞吐量(Throughput)一个单位时间内可以处理的请求数。也就是该单位时间内发起的请求总数/平均响应时间请求数可以是一次pv、也可以是一次rpc调用等等。TPSTransaction Per Second可以理解为单位时间是“秒”的「吞吐量」。其次我们要对会产生性能开销的地方要有认识。这主要分为3个部分。硬件/操作系统层面的开销。如磁盘I/O、网络I/OCPU的多线程切换等等。进程运行的开销。如代码逻辑啊、锁啊等等。多个进程之间的通信开销。rpc框架、数据库访问框架、redis/memcached访问SDK、MQ访问SDK等等。然后就可以开始做「容量规划」了。我一般是按以下5个步骤进行。第一步搞清楚业务的状况先得到业务上的指标。技术工作最怕隔着“部门墙”蒙着头做沉浸在自己的“小世界”里。所以不管通过什么途径得先对一些业务指标有客观的认识PV、UV的数据是必须的。可以找业务方聊也可以借助百度指数、微信指数等更宏观数据来进行参考和修正。第二步围绕这个业务指标对所涉及的相关技术接口制定性能指标。其实就是要得到一个业务流量与技术的性能指标之间的一个比例关系。比如访问一次A页面涉及到调用a接口2次b接口1次c接口3次这样。做这事儿有一个简单的办法。先在系统中的每个api接口做好数据采集目的是为了后续能获得两个数据响应时间和次数等等。然后借助一些压测工具比如loadrunner之类对当前的业务场景做一轮的全链路压测。模拟的用户数不用很大因为我们只是为了得到一个比例。这样在压测结束后你就可以将loadrunner中所记录的发起请求的数量对比api接口采集到的数据就能得到每个接口与业务流量之间的关系。顺带也能看到在低压力下的错误率、平均响应时间、tp95、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步法来实现。得到业务的流量指标通过调用比例获得相关接口的性能指标根据历史数据进行校准根据衰减曲线得到预估的节点数量预留一些弹性空间希望对你有所帮助。推荐阅读分布式系统关注点——360°的全方位监控分布式系统关注点——深入浅出「异步」原创不易如果你觉得这篇文章还不错就「在看」或者「分享」一下吧。鼓励我的创作 如果有希望我写一下什么主题的话欢迎在后台给我留言哦可以试试点击「阅读原文」