互联网架构,如何进行容量设计?

标签: 互联网 架构 何进 | 发表时间:2017-10-23 03:31 | 作者:
出处:http://mp.weixin.qq.com

一,需求缘起

互联网公司,这样的场景是否似曾相识:

 

场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题:

1机器能抗住么?

2如果扛不住,需要加多少台机器?

 

场景二:系统设计阶段,技术老大杀过来,又问了两个问题:

1数据库需要分库么?

2如果需要分库,需要分几个库?

 

技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一。常见的容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等,今天分享的内容,就以【并发量】为例,看看如何回答好这两个问题。

 

二,容量评估的步骤与方法

【步骤一:评估总访问量】

如何知道总访问量?对于一个运营活动的访问量评估,或者一个系统上线后PV的评估,有什么好的方法?

答案是:询问业务方,询问运营同学,询问产品同学,看对运营活动或者产品上线后的预期是什么。

 

举例:58要做一个APP-push的运营活动,计划在30分钟内完成5000w用户的push推送,预计push消息点击率10%,求push落地页系统的总访问量?

回答:5000w*10% = 500w

 

【步骤二:评估平均访问量QPS

如何知道平均访问量QPS

答案是:有了总量,除以总时间即可,如果按照天评估,一天按照4w秒计算

 

举例1push落地页系统30分钟的总访问量是500w,求平均访问量QPS

回答:500w/(30*60) = 2778,大概3000QPS

 

举例2:主站首页估计日均pv 8000w,求平均访问QPS

回答:一天按照4w秒算,8000w/4w=2000,大概2000QPS

 

提问:为什么一天按照4w秒计算?

回答:一天共24小时*60分钟*60=8w秒,一般假设所有请求都发生在白天,所以一般来说一天只按照4w秒评估

 

【步骤三:评估高峰QPS

系统容量规划时,不能只考虑平均QPS,而是要抗住高峰的QPS如何知道高峰QPS呢?

答案是:根据业务特性,通过业务访问曲线评估

 

举例:日均QPS2000,业务访问趋势图如下图,求峰值QPS预估



回答:从图中可以看出,峰值QPS大概是均值QPS2.5倍,日均QPS2000,于是评估出峰值QPS5000

 

说明:有一些业务例如“秒杀业务”比较难画出业务访问趋势图,这类业务的容量评估不在此列。

 

【步骤四:评估系统、单机极限QPS

如何评估一个业务,一个服务单机能的极限QPS呢?

答案是:压力测试

 

在一个服务上线前,一般来说是需要进行压力测试的(很多创业型公司,业务迭代很快的系统可能没有这一步,那就悲剧了),以APP-push运营活动落地页为例(日均QPS2000,峰值QPS5000),这个系统的架构可能是这样的:



1)访问端是APP

2)运营活动H5落地页是一个web站点

3H5落地页由缓存cache、数据库db中的数据拼装而成

 

通过压力测试发现,web层是瓶颈,tomcat压测单机只能抗住1200QPS(一般来说,1%的流量到数据库,数据库500QPS还是能轻松抗住的,cache的话QPS能抗住,需要评估cache的带宽,假设不是瓶颈),我们就得到了web单机极限的QPS1200。一般来说,线上系统是不会跑满到极限的,打个8折,单机线上允许跑到QPS1000

 

【步骤五:根据线上冗余度回答两个问题】

好了,上述步骤1-4已经得到了峰值QPS5000,单机QPS1000,假设线上部署了2台服务,就能自信自如的回答技术老大提出的问题了:

1)机器能抗住么?->峰值5000,单机1000,线上2台,扛不住

2)如果扛不住,需要加多少台机器?->需要额外3,提前预留1台更好,给4台更稳

 

除了并发量的容量预估,数据量、带宽、CPU/MEM/DISK等评估亦可遵循类似的步骤。

 

三,总结

互联网架构设计如何进行容量评估:

【步骤一:评估总访问量】->询问业务、产品、运营

【步骤二:评估平均访问量QPS->除以时间,一天算4w

【步骤三:评估高峰QPS->根据业务曲线图来

【步骤四:评估系统、单机极限QPS->压测很重要

【步骤五:根据线上冗余度回答两个问题】->估计冗余度与线上冗余度差值

 

个人一些经验分享,大伙轻拍,有更好的建议欢迎回复,下篇文章会将好的经验share给更多的同学。

==【完】==

回【无锁】如何实现超高并发的无锁缓存?

回【机房】从IDC到云端架构迁移之路

回【设置】线程数究竟设多少合理

回【单点】单点系统架构的可用性与性能优化

回【服务】互联网架构为什么要做服务化?




相关 [互联网 架构 何进] 推荐:

互联网架构,如何进行容量设计?

- -
互联网公司,这样的场景是否似曾相识:. 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题:. (2)如果扛不住,需要加多少台机器. 场景二:系统设计阶段,技术老大杀过来,又问了两个问题:. (2)如果需要分库,需要分几个库. 技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一.

淘宝的可伸缩高性能互联网架构

- 浪客 - 博客园-首页原创精华区
一 应用无状态(淘宝session框架).          假如在session中保存了大量与客户端的状态信息,保存状态信息的server宕机时.          通常通过集群解决,不仅有负载均衡,更重要的是要有失效恢复failover.          tomcat用集群节点广播复制,jboss用配对复制等session状态复制策略,但严重影响系统的伸缩性,不能通过增加更多的机器达到良好的水平伸缩.

一个移动互联网应用地图服务架构

- Ian - 出家如初,成佛有余
    在移动互联网中,各种与位置相关的服务都严重依赖于地图服务,地图服务质量的好坏很大程度决定了所提供服务的高低. 尽管有Google Map等免费或收费的地图服务可供使用,但没有那一家地图服务提供商能够完整提供移动互联网应用所必须的各种地图服务及数据,尤其是针对那些垂直行业应用.     在中国特色的制度下,除了技术因素外,值得注意的是由于地图牌照发放问题带来的政策上的不确定性对架构实现的冲击和挑战.

中大型移动互联网公司技术架构选择

- - 五四陈科学院
以下内容由 [五四陈科学院]提供. 总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:. 可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问). 天然可扩展(业务层无状态,尽可能全部放到最后). 自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可).

[转][转]互联网系统架构的演进

- - heiyeluren的blog(黑夜路人的开源世界)
来源: http://www.csdn.net/article/2013-08-27/2816716. 摘要:多终端接入、开放平台给互联网带来了前所未有的用户数量和访问规模,信息之多、传播速度之快,是传统网站难以想象的. 本文将从发展演进的角度,解读高性能互联网系统架构. 多终端接入、开放平台给互联网带来了前所未有的用户量级和访问规模,SNS网站产生了海量的UGC(用户产生内容),而且这些内容依托关 系链扩散速度之快、传播范围之广是传统网站难以想象的,海量数据的计算存储也一直是近年互联网领域的热点.

移动互联网系统架构十大陷阱

- - 五四陈科学院-坚信科学,分享技术
以下内容由 [五四陈科学院]提供. 过去的三年,54chen一直奋斗在中国移动互联网一线,历经各种坑爹的情况. Top 1.时不我待 连通性. cmwap cmnet这样的词语以后应该都会消失在人世间. 三年前,经常性地有移不动联不通手机连不上服务器机房的情况. 相信未来会越来越好,时代在召唤. Top 2.生不逢时 HTML5.

[转]各大互联网公司架构演进之路汇总

- - 鸟窝
原文地址: 各大互联网公司架构演进之路汇总 by HollisChuang. 请转载时务必保留文章的上述原始出处. 支付宝和蚂蚁花呗的技术架构及实践. 支付宝的高可用与容灾架构演进. 聚划算架构演进和系统优化 (视频+PPT). 淘宝交易系统演进之路 (专访). 淘宝技术发展历程和架构经验分享(视频+PPT)(2.3日更新).

互联网时代,我眼中的架构变迁

- - SegmentFault 最新的文章
作者简介:黄庆兵,网易蜂巢首席技术布道师,浙大硕士毕业,从事云计算、Docker、Go等相关开发及技术布道工作;喜欢开源,乐于分享,勤于布道,折腾过开源小工具,制作过Docker课程,分享过 Gopher Meetup. 互联网在变,架构也在变,架构的变迁亦是互联网的变迁. 所以,我们有必要来聊聊互联网的架构及其变迁.

互联网网站架构升级----消息中间件的实现方案

- liu - ITeye论坛最新讨论
    最近一直比较忙,前面设计的架构完成了基本的实现,最近工作重心发生了点转变,偷闲来继续前面的话题;.     这一篇博客准备聊聊消息系统,消息中间件对目前大中型互联网来说是非常重要的,在业务数据流动中仅次于RPC服务调用,担负着越来越复杂的网站业务从主流程上解耦的重要责任;.     从目前互联网对消息中间件的需求来看应该分为两种类型,一种是和钱相关的需求,一种是和钱无关的需求;和钱相关的需求消息的可靠性是放在第一位的,和钱无关的需求是速度放在第一位的,但这两种需求又是矛盾的,很难设计出一种既可靠又高效的系统,除非将两套方案捏合成一个系统,通过配置来选择不同方案,但从实现上说还是两种实现.

分享架构实践,搞移动互联网数据分析不得不看!

- - SegmentFault 最新的文章
在日前的 nfoQ ArchSummit(全球架构师峰会)上,友盟高级技术总监叶谦分享了一些友盟数据平台的整体架构实践经验,很多伙伴要演讲速记. 刚巧,友盟君发现【chinastor】阿明同学已经梳理了一份详文,借花献佛了. 友盟早在 2010 年就专注移动开发者平台,在叶谦看来,数据是移动互联网的主旋律.