我正在寻找好的经验法则来了解何时不虚拟化机器。
例如，我知道使用接近 100% 的完全受 CPU 限制的进程虚拟化可能不是一个好主意，但是运行在大多数时间利用 CPU 的“大量”（比如 40或 50%）？
另一个例子：如果我虚拟化 1000 台机器，即使它们只是轻度或中度使用，在只有 4 个内核的主机上运行它们也可能是不好的。
与主机资源相比，有人可以根据机器工作负载或来宾机器的绝对数量总结有关虚拟化的提示吗？
我通常使用 VirtualBox 或 VMWare 在 Windows 主机上进行虚拟化，但我假设这是一个非常通用的问题。
virtualization virtual-machines central-processing-unit cpu-architecture
我正在寻找一种以尊重站点策略的方式灵活管理出站 HTTP/HTTPS 流量的方法，并且可以部署在我们数据中心网络的“边缘”。
例如，我们使用了几个具有限制率的 Web API，例如“每秒不超过 4 个请求”或“每天最多 50K 个请求”等。我们公司有很多人使用这样的各种服务，所以我不能集中管理软件中的所有请求。人们以不同的时间表和不同的强度运行这些东西。我们对此很好（它满足内部需求），但我们意识到 - 总的来说 - 我们可能会遇到产生如此多并发流量的情况，我们会被网站阻止。（虽然是无意的）
我所期待/希望的是，我们可以利用网络硬件世界中已经存在的带宽管理/流量整形解决方案，然后我们可以在数据中心网络的边缘部署这样的东西。
理想情况下，我可以编写 L4 或 L7 路由规则，以确保我们的数据中心生成不超过 - 例如 - 4 req/sec 出站。理想情况下，其余的请求将由硬件排队一段合理的时间，而队列容量过剩则被简单地拒绝。我意识到没有免费的午餐，节流不会解决基本的内在需求（请求）与供应（站点策略）问题。但是，节流将允许我们在某个窗口（例如一天）内“平滑”请求，以便我们可以以适当限制的方式利用外部服务，同时最大限度地利用。
有谁知道这样的网络级带宽管理解决方案？如果是这样，它是否还支持不仅基于 HTTP 请求中的 URL 之类的规则，而且还支持一些额外的 HTTP 标头？