#如何合理分配 CPU 和内存资源

针对平台提出的 小型、中型、大型 和 自定义 生产环境规格，以及 实例 和 端口 的资源分配方式，以下建议可供部署参考。

#小型生产环境

对于较小的业务规模，比如集群中节点不超过 5 个，仅用于运行标准应用，单个 负载均衡器即可满足需求。建议以 高可用 模式运行，至少部署 2 个副本，以保证环境的稳定性。

可以通过 端口 隔离来实现负载均衡器的隔离，允许多个项目共享同一个负载均衡器。

该规格在实验室环境下测得的峰值 QPS 约为每秒 300 次请求。

#中型生产环境

当业务量达到一定规模，比如集群中节点不超过 30 个，需要处理高并发业务并运行标准应用时，单个 负载均衡器仍然足够。建议采用 高可用 模式，至少部署 3 个副本，以维持环境的稳定性。

可以使用 端口 隔离或 实例 分配方式，让多个项目共享负载均衡器。当然，也可以为核心项目新建专用负载均衡器。

该规格在实验室环境下测得的峰值 QPS 约为每秒 10,000 次请求。

#大型生产环境

对于更大规模的业务，比如集群中节点超过 30 个，需要处理高并发业务以及长连接数据时，建议使用 多个 负载均衡器，每个均采用 高可用 类型，至少部署 3 个副本，以确保环境的稳定性。

可以通过 端口 隔离或 实例 分配方式实现负载均衡器的隔离，供多个项目共享。也可以为核心项目新建专用负载均衡器。

该规格在实验室环境下测得的峰值 QPS 约为每秒 20,000 次请求。

#特殊场景部署建议

场景	部署建议
功能测试	建议部署 单实例 负载均衡器。
测试环境	如果测试环境符合上述 小型 或 中型 定义，使用 单点 负载均衡器即可。负载均衡器 实例 可被 多个项目 共享。
核心应用	建议为核心应用专门使用特定的负载均衡器。
大规模数据传输	由于负载均衡器本身的内存消耗较小，即使是 大型 规格，预留 2Gi 内存也足够。但如果业务需要传输大规模数据，导致内存消耗较大，则应相应增加负载均衡器的内存分配。 建议在 自定义 规格场景下逐步扩展负载均衡器内存，密切监控内存使用情况，最终确定合理使用率下可接受的内存大小。

#负载均衡器使用模式选择

使用模式	优势	劣势
（推荐）将负载均衡器作为实例资源分配给单个项目	管理相对简单。 每个项目拥有独立负载均衡器，确保规则隔离和资源分离，互不干扰。	在主机网络模式下，集群必须拥有较多可用节点供负载均衡器使用，导致资源消耗较高。
将负载均衡器作为实例资源分配给多个项目	管理相对简单。	由于所有分配的项目对负载均衡器实例拥有完全权限，当某个项目配置负载均衡器的端口和规则时，可能出现以下情况： 该项目配置的规则可能影响其他项目。 负载均衡器配置误操作可能更改其他项目设置。 某个业务的流量请求可能影响负载均衡器实例的整体可用性。
按端口动态分配负载均衡器资源，不同项目使用不同端口	项目间规则隔离，确保互不干扰。	管理复杂度增加。平台管理员需主动规划和分配项目端口，并配置外部服务映射。 基于端口的分配成熟度较低，目前使用的客户较少，功能仍需进一步完善。 资源冲突。所有使用同一负载均衡器的服务可能面临单个服务影响整个负载均衡器的情况。