这是一个创建于 1268 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前一直没有考虑过这个问题，每次需要服务器的时候，都竟可能想着参数越大就越好。但是，这样子肯定是有资源浪费的情况的。
有想过跟服务的用户数、QPS 等因素有关，但是还是想问问磁盘，内存，带宽，CPU 跟用户数、QPS 等等有什么可以量化的关系吗
 | 1 guisheng 2022-05-24 08:32:47 +08:00 via iPhone 压测后得出结论后预估 |
 | 2 xinhero123 2022-05-24 08:38:24 +08:00 压测+动态扩缩容 |
 | 3 xuanbg 2022-05-24 08:49:37 +08:00 用户数是无法准确预估的，正确的做法是要具备动态的扩容能力。 |
 | 4 fisherwei 2022-05-24 10:22:18 +08:00 首先预估出来你的业务场景占比，比如： 1 、典型请求 A ，20%比例，对应 4 次 SQL |
| 5 fisherwei 2022-05-24 10:25:11 +08:00 上一条按错了，没写完发出去了。。。 2 、典型请求 B ，50%占比，对应 1 次 SQL 3 、典型请求 C ，xx%，对应 y 次 SQL 然后压测这几种场景，按照占比计算出来每 qps 对应的 cpu mem 的平均消耗，比如平均每 qps 需要 0.25 Mhz CPU 和 5k mem 。 最后按照这个数据套用一下，上线观测，修正，观测，修正。 最终，你会发现，由于现在机器便宜，这么做成本高，收益低。 |
 | 7 Kinnice 2022-05-24 13:49:13 +08:00 via Android 带宽：平均请求大小除一下就有了 磁盘：这个好估计，基本是看业务了 内存 /CPU：压测 |
8
westoy 2022-05-24 13:53:08 +08:00 我倒觉得这个其实是不存在的问题
如果团队有资源， 有牛逼的运营， 可以一上来就打爆， 那肯定要大量冗余的啊， 这问题就不需要考虑了
如果没有， 那按照正常的流量增长曲线去走就行了， 前期在能跑得动的基础上适当加点冗余就可以了， 这问题也不需要考虑啊
如果团队有资源， 有牛逼的运营， 可以一上来就打爆， 那肯定要大量冗余的啊， 这问题就不需要考虑了
如果没有， 那按照正常的流量增长曲线去走就行了， 前期在能跑得动的基础上适当加点冗余就可以了， 这问题也不需要考虑啊
 | 9 Chinsung 2022-05-24 17:30:10 +08:00 没什么量化关系，现在整个应用运行都太复杂了 一般微服务就单台 2 核 4g ，然后就是压测，再垃圾的压测也是压测 |
 | 10 Saxton 2022-05-24 17:31:29 +08:00 看你们的推广团队了 |
 | 11 lizy0329 2022-05-25 10:22:28 +08:00 可以参考其他业务的起步阶段 |
Select Language