首先，需求来源于互联网公司。这个场景是不是很熟悉？场景一：PM要做一个大操作，技术老大过来问两个问题：（1）机器能不能承受？（2）如果我搞不定，我需要增加多少台机器？场景二：系统设计阶段，技术负责人过来，又问了两个问题：（1）数据库是否需要拆分？（2）如果需要拆分，需要做什么？有多少图书馆？从技术上讲，这些都是系统容量估算的问题，而容量设计是架构师必备的技能之一。常见的容量评估包括数据量、并发、带宽、CPU/MEM/DISK等，今天分享的内容，我们以【并发】为例，看看如何回答这两个问题。二、能力评估的步骤和方法【第一步：评估总访问量】如何知道总访问量？一个操作的访问量，或者说系统上线后的PV，最好的评估方式是什么？答案是：问业务方，问运营同学，问产品同学，看运营活动或产品上线后的预期是什么。例如：58要做一个APP推送操作，计划30分钟内完成5000w用户的推送推送。预计推送消息点击率为10%。推送登陆页面系统的总访问量是多少？答：5000w*10%=500w【第二步：评估平均访问QPS】如何知道平均访问QPS？答案是：总金额除以总时间即可。如果按天来评价，则按一天4w秒计算。例1：推送落地页系统30分钟总访问量为500w，求平均访问QPS答案：500w/(30*60)=2778，约3000QPS例2：主站首页预估每日平均pv8000w，求平均访问QPS回答：一天按4w秒计算，8000w/4w=2000，约2000QPS问：为什么一天按4w秒计算？答：一天总共24小时*60分钟*60秒=8w秒，一般假设所有的请求都发生在白天，所以一般来说，只按照一天4w秒来评估【第三步：评估峰值QPS】规划系统容量时，不能只考虑平均QPS，还要考虑峰值QPS。怎么知道峰值QPS？答案是：根据业务特点，基于业务访问曲线评估示例：日均QPS为2000，业务访问趋势图如下图所示。QPS峰值如何估算？答：从图中可以看出，峰值QPS约为平均QPS的2.5倍，日均QPS为2000，所以峰值QPS预估为5000。说明：对于“秒杀服务”等部分服务，很难绘制出服务访问趋势图，此类服务的容量评估不在此列表中。【第四步：评估系统，单机限制QPS】如何评估一个业务，一个服务单机功能的限制QPS？答案是：服务上线前一般需要进行压测（很多创业公司，业务迭代快的系统可能没有这一步，那就悲剧了），以APP推送运营活动的落地页作为例子（日均QPS2000，峰值QPS5000），这个系统的架构可能是这样的：1）接入端是一个APP2）运营活动的H5落地页是一个网站3）H5落地页是由缓存缓存和数据库db中的数据。通过压测发现web层是瓶颈，tomcat压测单机只能承受1200QPS（一般来说1%的流量去数据库，数据库可以轻松承受500QPS.如果缓存能承受QPS，需要评估缓存的带宽，假设不是瓶颈。）我们得到web单机限制的QPS是1200。一般来说，线上系统是不会跑到极限的。单机在线系统最高可运行QPS1000，优惠20%。【第五步：根据在线冗余回答两个问题】好了，上面的1-4步骤已经得到了峰值QPS为5000，单机QPS为1000，假设在线部署2台服务器，你可以自信的回答技术老大提出的问题：（1）机器能承受得住吗？->峰值5000，单机1000，联机2台。加3台机器最好提前预留1台，4台机器更稳定。除了并发容量估算，数据量、带宽、CPU/MEM/DISK等的评估也可以按照类似的步骤进行。3、总结互联网架构设计如何进行容量评估：【第一步：评估总访问量】->查询业务、产品、运营【步骤二：评估平均访问QPS】->除以时间，40000秒一个day【步骤】三：评估峰值QPS】->根据业务曲线【步骤4：评估系统，单机限制QPS】->压测很重要【步骤5：根据线上冗余回答两题】->估计冗余度和在线冗余差
