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

背景

 随着业务的增长，日流量从1W级别，增长到100W,甚至更多，此时需要对系统进行容量预估，

那么容量预估应该如何预估呢，需要考虑什么指标呢

容量预估指标

看具体业务，对应到系统侧的主要矛盾是什么

1. 数据量
2. 并发量，吞吐量
3. 带宽
4. CPU/MEM/DISK等

 

什么情况要进行容量评估

1. 容量有质变行增长
2. 临时运营活动
3. 新系统上线等

  场景一：比如最近做的春节司机奖励活动，促销

• 问题一：机器能抗住吗？
• 问题二：如果机器扛不住，需要加几台机器，需要做什么优化

  场景二：平台结算接入度假中台，新系统上线

•  问题一：需要分库分表吗？ 
•  问题二：如果需要，分库分表，几个比较合适
•  问题三：如果还是抗不住，需要做优化吗？

如何进行容量设计评估

• 评估总访问量

      比如完单量每天大概在2W单，而度假中台场景有下单，订单完成，完成后取消，取消冲平，改派罚款等场景

     那么总访问量2W*3 = 6W

• 评估平均吞吐量QPS

      每天的订单数量在吞吐大概在6W，一天24小时，由于订单比较集中，按照白天时间算，大概在4万秒（60*60*10）

      QPS= 6W/4W = 1.5

• 评估高峰吞吐量

     

   看图可以知道，最高吞吐量大概是平均吞吐量的20/3 = 7 那么高峰吞吐量QPS = 7 * 1.5 = 10.5

• 评估单机极限QPS

    通过压力测试，这部分可以JMeter工具进行压力测试，评估单机极限QPS,假如单机极限QPS :100,一般根据二八法则

   单机尽量不要达到极限原则QPS 100*0.8 = 80

• 根据线上冗余都做决策

     机器能抗住吗？峰值10.5，单机80，线上两台（灾备），可以抗住

总结：

    互联网架构设计如何进行容量评估，评估总访问量，评估平均吞吐量QPS,评估峰值QPS，评估高峰吞吐量，评估单机极限QPS，然后再根据线上冗余做决策，就可以轻松应对，容量预估，新系统上线

   大促，活动等情况，此外，这种方案，还可以延伸到Redis容量申请，MYSQL申请（是否需要分库分表）等