架构，如何进行容量设计？
互联网公司，这样的场景是否似曾相识？
场景一
pm要做双十一促销活动，技术老大杀过来，问了两个问题：
机器能抗住么？
如果扛不住，需要加多少台机器？
场景二
新系统上线，技术老大杀过来，又问：
数据库需要分库么？
如果需要分库，需要分几个库？
技术上来说，这些都是系统容量预估的问题，容量设计是架构师必备的技能。
常见的容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等，今天分享的内容，就以并发量为例，看看如何通过五个步骤，得到问题的答案。
步骤一：评估总访问量
如何知道总访问量？
对于一个运营活动的访问量评估，或者一个系统上线后PV的评估，有什么好的方法？
答：
询问运营同学，活动的预期访问是什么；
询问产品同学，产品上线后的预期访问是什么。
栗子：
假设，58同城要做一个APP-push的运营活动，计划在30分钟内完成5000w用户的push推送，预计push消息点击率10%，如何评估push落地页系统的总访问量？
答：5000w*10% = 500w
步骤二：评估平均访问量QPS
如何知道平均访问量QPS？
答：总量除以总时间即可，如果按照天评估，一天按照4w秒计算。
画外音：一天86400秒，一般认为请求发生在白天，即4w秒。
栗子：
push落地页系统30分钟的总访问量是500w，求平均访问QPS？
答：500w/(30*60) = 2778，大概3000QPS。
栗子：
假设，58同城主站首页估计日均pv 8000w，求平均访问QPS？
答：一天按照4w秒算，8000w/4w=2000，大概2000QPS。
步骤三：评估高峰QPS
系统容量规划时，不能只考虑平均QPS，而是要抗住高峰的QPS，如何知道高峰QPS呢？
答：根据业务特性，通过业务访问曲线评估。
栗子：
假设，某业务日均QPS为2000，业务访问趋势图如下图，求峰值QPS预估？
答：从图中可以看出，峰值QPS大概是均值QPS的2.5倍，日均QPS为2000，于是评估出峰值QPS为5000。
画外音：有一些业务例如“秒杀业务”比较难画出业务访问趋势图，这类业务的容量评估不在此列。
步骤四：评估系统、单机极限QPS
如何评估一个业务，一个服务单机能的极限QPS呢？
答：压力测试。
在一个服务上线前，一般来说是需要进行压力测试，以APP-push运营活动落地页为例（日均QPS2000，峰值QPS5000），这个系统的架构可能是这样的：
访问端是APP
运营活动H5落地页是一个web站点
H5落地页由缓存cache、数据库db中的数据拼装而成
通过压力测试发现，web层是瓶颈，tomcat压测单机只能抗住1200的QPS。
画外音：一般来说，1%的流量到数据库，数据库500QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，假设不是瓶颈。
我们就得到了web单机极限的QPS是1200，一般线上系统是不会跑满，打个8折，单机线上允许跑到QPS1000。
步骤五：根据线上冗余度解题
好了，上述步骤1-4已经得到了峰值QPS是5000，单机QPS是1000，假设线上部署了2台服务，就能自信自如的回答技术老大提出的问题了。
技术老大问：机器能抗住么？
答：峰值5000，单机1000，线上2台，扛不住。
如果扛不住，需要加多少台机器？
答：需要额外3台，给4台更稳。
除了并发量的容量预估，数据量、带宽、CPU/MEM/DISK等评估亦可遵循类似的步骤。
总结
互联网架构设计如何进行容量评估：
一，评估总访问量：询问产品、运营；
二，评估平均访问量：总量除以总时间，一天算4w秒；
三，评估高峰QPS：根据业务曲线图来；
四，评估系统、单机极限QPS：压测很重要；
五：根据线上冗余度解题：估计冗余度与线上冗余度差值；
希望大家有收获。
架构师之路-分享可落地的技术文章
推荐阅读：