这是一个创建于 946 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前一直没有考虑过这个问题，每次需要服务器的时候，都竟可能想着参数越大就越好。但是，这样子肯定是有资源浪费的情况的。
有想过跟服务的用户数、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