如何知道服务的QPS？

M-bao

已于 2024-09-10 22:20:16 修改

阅读量2.8k

点赞数 22

文章标签： java 开发语言

于 2024-09-10 22:20:05 首次发布

本文链接：https://blog.csdn.net/qq_74042166/article/details/142110668

版权

第一步是明确服务所对外提供的所有接口及其功能。通常，我们可以将每个接口及其用途列成一个表格。该表格不仅有助于理解系统的功能布局，还为后续的 QPS 预估打下基础。

接口的 QPS 可以通过两种方式来估算：

用户直接访问的接口：可以根据用户访问量和业务场景进行估算。例如，如果一个页面每天有 100 万次访问，那么它背后的 API 需要能够支持至少每秒数百次请求。
对外提供的服务接口：这种情况需要与外部调用方协商，了解调用频率及峰值流量需求。

通过这些方式，我们可以估算出每个接口在高峰期的 QPS，并知道服务需要达到的总 QPS 要求。

通常，4核8G 是很多微服务部署的基础配置，尤其在容器化环境中，物理机器上可以运行多个容器，而每个容器代表一个服务实例。这时候需要关注机器配置是否能支撑系统的预期 QPS。

CPU 是影响系统性能的关键指标之一，特别是在高并发项目中，大量请求会增加线程的数量，从而导致 CPU 的占用率飙升。以下是一些优化思路：

观察 CPU 使用率：当 CPU 占用接近瓶颈时，扩展单台机器的 CPU 核数是可以选择的方式之一。然而，更推荐的做法是通过横向扩容（增加更多机器或容器实例）来分担负载。这样不仅能够平衡负载，还能提高系统的容错性。如果某台机器出现故障，其他机器可以继续运行，从而保证服务的可用性。

内存的使用率也是需要关注的指标。在典型的 Web 服务中，如果没有大数据处理或批量操作，内存占用通常不会太高。内存异常升高的情况常常是由于程序存在内存泄漏或缓存数据过多，以下是几种需要关注的情况：

正常场景下内存使用率较低：如果服务主要是处理请求、查询数据库或调用其他微服务，内存的使用应该相对较低。
异常情况的排查：如果发现内存使用率持续增高，尤其是在没有执行大数据量处理的情况下，可能需要对内存进行详细的排查。问题可能出现在代码的内存管理、对象的生命周期控制不当等方面。

要准确知道服务能够承载多少 QPS，压测是最有效的方法。压测可以帮助我们发现瓶颈，评估系统在高并发下的表现，并为后续的扩容和性能优化提供依据。压测主要有以下两种方式：

单接口压测：通过对某个特定接口进行压测，可以得知该接口的最大 QPS。这种压测方式适合用于测试单个接口的性能瓶颈。例如，如果某个接口通过数据库查询获取数据，可以通过单独压测，得出该接口的性能上限。
场景化压测：这是模拟实际场景下多个接口同时承载流量的测试方式。在真实环境中，用户可能同时访问多个接口，因此场景化压测可以帮助我们了解服务在复杂流量场景下的表现。通过场景化压测，我们可以得出服务在多接口并发时的平均 QPS。

一旦通过压测找出单个服务实例的 QPS 瓶颈，就可以通过扩容来进一步提升服务的总 QPS。扩容是微服务架构中的常见做法，通过增加机器或服务实例，我们可以水平扩展系统的承载能力，解决单台机器的性能瓶颈问题。

以下是一个具体的例子，帮助理解以上内容：

假设我们有一台4核8G的机器，部署了一个常见的电商服务——商品微服务。这个微服务提供了两个接口：

查询商品详情接口：该接口基于商品ID，多线程调用 RPC 和数据库来获取商品的详细信息。由于涉及数据库查询，IO 操作较多，因此对 QPS 的要求较高。
查询商品名称接口：该接口也是基于商品ID，但是直接通过缓存来获取商品名称。由于使用缓存，查询速度较快，理论上 QPS 可以比第一种接口高很多。

此时如果面试官问到，就可以说经过压测，发现：