性能：如何在生产环境中进行真实的容量测试

问题

在性能优化的过程中，经常会遇到这类问题：一个服务可以承受的最大QPS是多少？要满足100K QPS的服务需求，我需要多少服务器？

要怎么解决这些问题呢？一个大招是在生产环境中进行真实的容量测试

QPS：每秒MySQL可以执行多少个SQL

为什么需要在生产环境中进行容量测试

我们知道，一个在线互联网公司的存活和发展，靠的是它提供的互联网在线服务，自然也就依赖于这些服务的性能和稳定性。要保证每个服务都能够稳定地运行，我们必须为之提供足够的服务容量，比如适当数量的服务器。

那如何保证服务容量足够呢？首先就必须做好服务容量的预测

要预测服务容量，我们就需要做容量的性能测试。一般是先确定每台单独的服务器可以支撑多少服务流量；然后用这个单台服务器的数据，来决定这个服务整体需要多少台服务器。这种测试就是容量测试

举个例子，如果测试结果表明，一台服务器最多可以支撑 100 个 QPS，那么要满足100K QPS 的服务需求，总共就需要部署一千台服务器。

问题：“服务”到底是指什么？

一般来说，公司提供的服务大致上分为两种：前端服务和后端服务。前端服务是怎么样呢？包括各种服务的登录页面和移动App，这些服务会直接影响用户和体验。后端服务，一般是为前端服务和其他后端服务提供数据和结果。后端服务可以有多种，比如键值数据库服务、微服务。

问题：测试为什么要在生成环境中进行？

这是因为实际的生产环境里面，有多个特殊因素会导致和非生产环境中不同的结果。比如：

• 客户需求会随着时间而变化，比如高峰时段和非高峰时段的流量就很不一样
• 用户请求的多样性，例如不同国家的查询类型不同
• 负载流量的规模，基础架构设施的变化，例如服务的软件版本更新，微服务互相调用的变化等等。

所以，对一个重要而复杂的互联网在线服务，由于难以在非生产环境中进行准确的容量测试，我们经常需要转向真正的生产环境，使用实时而真实的客户流量负载来测试。

如何在真实环境中进行容量测试

一般来说，我们需要把生产环境的流量进行重定向，让这些重定向的流量，实时的驱动运行SUT的单个或者几个服务器。根据重定向流量大小，会产生不同级别的流量负载。通过仔细的操作重定向的多少，并且把握测试的时间，我们可以获得非常准确的运行SUT服务器的容量值

但是，生产环境中的容量测量也有诸多挑战，你需要特别小心。

• 第一个挑战是需要设计一个控制重定向流量的机制。这个机制要能够根据其他一些参数，来调整重定向的流量多少。
• 第二个挑战（也是最大的挑战）是这种重定向生产流量可能会影响真正的客户。
  • 因为我们会把客户请求重定向到某个服务器，并且会不断的给服务器加压，直到这个服务器接近超载，那么这个服务器上所有的客户的延迟都会受到影响，也就是可能会变大，用户性能也就可能收到损害
  • 为了尽量减少对客户的影响，我们的容量测试需要设计合适的机制，来讲这种可能的损害降到最低点。系统中必须有一个模块，来不断的检测客户的性能，一旦达到临界点，就停止继续加压的操作，甚至适当减压。这就是所谓的非侵入性
• 第三个挑战是对测试时间的控制。既然重定向生产流量可能影响客户性能，当然是测试的时间越短越好。可是测试时间太短，有可能会影响数据的稳定性。

设计原则

所以，合理方案的设计原则如下：

• 要使用实时流量以确保准确性。
• 尽量不影响生产流量，这就需要实时的监测和反馈模块。
• 可以定制重定向等行为规则；对不同的服务和不同的场景的测试，各种性能指标和阈值都会不同。
• 能自动终止测试，并把测试环境复位，尽量减少人工干预。
• 支持基于日历和事件的自动触发和调度。

RedLiner

为了应对这些挑战，准确地确定服务容量的极限，并精确定位容量瓶颈，LinkedIn 采用了一个叫做RedLiner的解决方案

• 宏观来讲，Redliner是固定一个生产环境中的SUT，这个SUT包括服务器和上面运行的被测服务，然后不断地把其他服务器上的流量，重定向到这个SUT服务器上面。随着流量的不断增大，这个SUT服务器的资源使用也就越来越多，所服务的客户请求的性能，比如端到端延迟，就会越来越差
• 直到客户请求的性能差到一个定好的阈值，比如端到端延迟是200ms，流量重定向才会停止。这个时候，基本就可以确定SUT服务器不能再处理任何额外的负载。此时获得的容量结果就是SUT服务器的最大容量

架构

其架构如下：

• 核心控制器 LiveRedliner
• 重定向流量的 TrafficRedirector
• 收集性能数据的 PerfCollector
• 分析性能数据的 PerfAnalyzer

核心控制组件 LiveRedliner

核心控制组件是整个系统的神经中枢，负责总体调度容量测试的过程。比如何时发起测试、何时终止测试、何时需要增大更大的流量等。

用户可以自己定义一些特殊的规则，来更好地控制整个测试。用户可以自定义性能指标的阈值。这些性能指标，可以是用户的端到端延迟，包括各种统计指标，比如 P99。也可以把几个不同的性能指标组合起来，实现复杂的逻辑，比如“端到端延迟不超过 200 毫秒，并且错误率不超过 0.1% 等”。

重定向流量组件 TrafficRedirector

重定向流量组件负责对生产流量进行重定向。具体的实现机制，根据被测试的服务类型分为两种：前端服务和后端服务。

• 用于前端服务时，Redliner 是通过客户请求的属性（例如用户 ID、语言或帐户创建日期），来决定是否对一个客户请求来进行重定向的。这个转换也很简单，可以是取模机制。
  举个例子来说，如果 Redliner 需要重定向 1％的流量，它可以把用户的一个属性比如userid 转换成整数，然后执行用 100 来取模的操作，并且和一个固定整数值作比较。

• 用于后端服务时，重定向流量可以通过另外一个叫做“资源动态发现和负载均衡”的模块来实现。一般会采用一个服务器列表（URI 集群），以相对应的权重值来决定一个请求发送到哪个服务器。
  假设这样一个机制有 10 个可用的 URI 集群，并且最初所有这些集群都接收等量的流量（即每个 URI 的权重为 10％）。如果 Redliner 决定将 20％的流量重定向到特定的URI（即 SUT），那么它可以为 SUT 的 URI 分配 20％的权重。

性能数据收集组件 PerfCollector

容量测试必须采集各种类型的性能指标，比如CPU、内存和QPS等。这些性能指标的作用，就是确定SUT何时达到其容量最大值，以及容量值是多少。

PerfCollector组件负责收集各种性能指标，包括系统级和服务级的指标。这个组件运行在所有受监视的节点。组件传递的数据量通常很大，因为一般要检测较多的性能指标。所以最好采用扩展性较好的实时消息传递系统比如Kafka，来把这些性能数据及时传到其他组件。

性能分析组件 PerfAnalyzer

收集性能指标是第一步，下一步就是分析性能，并采取相应的措施。具体来说，可以根据性能指标的值来确定SUT是否饱和。

根据性能数据和用户定义的规则，如果发现当前的SUT，仍有空间来承担更多的负载，我们可以将更大比例的实时流量重定向到该SUT。否则，如果SUT显示饱和迹象，那么重定向的流量百分比就应该降低。PerfAnalyzer 组件能分析收集的数据，并确定是否有特定指标是否违反用户定义的规则。

具体操作流程

• 首先根据以前的测试历史数据，决定一个初始重定向数量，也就决定了SUT的初始负载。理论上讲，每个测试都可以从０开始；但是如果起点流量太低，整个测试需要花很长时间，所以最好能利用历史数据，从一个比较高的起点开始。
• 在使用历史数据的基础上，我们还需要决定总体测试时间
  • 决定了时间后，每次调整重定向流量的百分比也就确定了。这个调整的数值大小也就是所谓的“步距”，如同人迈步走路，每一步都有大小。对每个百分比，我们一般固定测试 3 分钟，让数据稳定下来，然后调用PerfAnalyzer 分析并决定下一步。
  • 举个例子，假如我们决定总体测试 60 分钟，并且是从 0% 开始。因为每一个百分点需要测试 3 分钟，那么我们就会决定调整的“步距”大小是 5%，因为最大就是 100%。如果
    PerfAnalyzer 决定需要继续增加或者减少重定向百分比，那么就按照前面决定的步距，进行相应的调整。