当前服务器配置能承受多大的QPS？如何评估？

LinkedIn的基础设施上运行着数百个应用，它们为4.67亿的LinkedIn会员提供服务。在发布新功能、规划流量增长规模和分析数据中心失效备援方案的过程中，我们经常会遇到以下几个问题：

目前的服务配置最大可以承担多大的QPS（每秒查询数）？

这些服务器能够处理比当前峰值高出50%的流量吗？

从基础设施来看，服务潜在的容量瓶颈是什么？

作为LinkedIn的性能团队工程师，我们的工作就是要在短时间内为上述的问题寻找准确的答案。

不过，因为服务的增长过于迅速，在对服务的容量极限进行评估时，我们面临着巨大的挑战。这些挑战来自于持续变化的流量模式、不均衡的基础设施特征，以及持续变化的瓶颈。为了能够准确地对服务容量极限进行评估，并有效地识别出容量瓶颈，我们的解决方案需要具备如下特点。

利用生产环境来突破实验室的局限

使用真实的流量作为负载

最小化对用户体验造成的影响

低运营成本和开销

自动伸缩

我们的解决方案：Redliner

我们使用生产环境的真实流量，通过Redliner实现自动化的容量评估和准确的余量分析。Redliner在目标服务上运行压力测试，逐步增加流量，直到服务无法处理更多的流量为止，以此来评估服务的吞吐量。

Redliner自动从生产环境引入流量，并确保对用户只有很小的影响。在设计Redliner时，我们遵循了两个原则：影响最小化和完全自动化。

影响最小化

在进行流量重定向时，最主要的问题是如何避免对站点和用户造成影响。Redliner使用以下的策略来缓解对生产环境性能造成的影响。首先，通过增量的方式将流量导向redline实例。其次，Redliner对服务进行实时的监控，并根据实际情况来分发流量。Redliner捕捉实时的性能指标，并基于EKG健康评估规则（见图1和图2）的计算结果来确定服务的健康状况。另外，在进行redline实例的测试过程中，Redliner也会评估流量测试对上游和下游服务所产生的影响。

图1 Redliner内部度量指标规则示例

图2  Redliner系统度量指标规则示例

完全自动化

为了克服手动测试的缺点（缺乏一致性、高昂的运营成本，等等），我们需要一个完全自动化的方式来运行测试、确定吞吐容量、检测系统性能衰退告警，并在出现问题时停止测试或回滚。我们借助LinkedIn的技术平台保证Redliner自动化的健壮性和伸缩性。Redliner能够运行调度测试，通过EKG检测性能状态，还能利用A/B测试平台XLNT来动态地调整导向目标服务的流量。在经过几轮的迭代之后，Redliner就可以确定单个服务能够处理的最大QPS。一般整个过程需要不到一个小时的时间。Redliner会生成测试报告，报告里包含了QPS和延迟趋势走向以及资源瓶颈信息。如果某个服务出现过载或者尚有余量，Redliner会向相关人员发送邮件，邮件里会为他们提供具体的建议。

Redliner生态系统

图3是Redliner的架构图，包含导流组件和容量评估组件。主要组件如下：导流层（代理/负载均衡器）、服务健康状态分析器和服务度量指标收集器。

图3  Redliner和它的依赖组件

导流层（代理/负载均衡器）

Redliner目前只支持无状态的服务。也就是说，发送给这些服务的请求可以被路由到数据中心SUT（Service Under Test）的任意服务实例上，不涉及粘性会话（sticky session）。负载均衡机制负责控制流量负载，从而能够实现动态导流。

导流层是Redliner实现动态调整流量的关键组件。Redliner确定目标服务的流量等级，并通过LiX（LinkedIn实验服务）将其转换成代理和负载均衡器的配置变更。LinkedIn使用LiX（以及A/B测试）作为默认的流量探测工具，它提供了更为可控和安全的导流。通过改变代理和负载均衡器的配置，Redliner就可以自由地控制从客户端发送给目标服务的流量。

度量指标收集器

容量评估和余量分析通过分析性能度量指标来确定SUT是否已经达到了容量极限。LinkedIn所有的服务都会向Autometrics发送度量指标，Autometrics是一个基于推送的实时度量指标收集系统。Autometrics会收集实时的系统数据和服务数据，比如QPS、请求延迟、错误率，以及CPU和内存的使用情况。

 服务健康分析器

EKG是Redliner的服务健康检测工具，它通过分析上述的性能指标来确定服务的整体健康情况。Redliner向EKG查询正常流量负载性能与当前流量负载性能之间的比较结果，也会通过查询服务的健康检测结果来决定后续的导流操作。

Redliner实战

Redliner通过在目标服务上增量运行不同的流量压力测试来确定服务的容量极限。在对目标服务的流量负载做出变动后，Redliner等待EKG返回健康检测结果。如果健康检测失败，Redliner会降低流量等级，否则，它会增加流量，给服务施加更大的压力。Redliner就是通过这样的反馈闭环来确定服务的流量等级的。在得到一个令人信服的红线（redline）数字之前，这个迭代过程会一直进行，而这个数字就是服务能够处理的最高吞吐容量。

图4展示了Redliner一个测试案例的细节。SUT设定了一个红线数字（红色虚线），Redliner触发快速坡道（ramp）算法，逐步增加流量负载，直至达到目标QPS。这个过程改进了测试效率，同时降低了测试之间的时间间隔。之后，Redliner一直保持流量的逐步增加，直到目标服务的CPU使用率和调用延迟出现显著的增长，这个时候的健康检测会返回异常。Redliner随之降低目标服务的流量负载。在经过几轮的迭代调整之后，Redliner就得到了目标服务的红线数字。

图4 Redliner测试结果概要：QPS和延迟vs时间

使用案例

Redliner在LinkedIn内部被用于多种用途，包括下面的几种。

降低数据中心的成本

一般来说，服务所需要的资源需要根据未来的增长规模来调配。不过受多种因素的影响，比如功能弃用和不准确的增长规模预测，分配给服务的资源可能不够用，所以资源分配是一件很复杂的工作。通过指定红线区间，我们可以识别出过度分配资源的服务，并将资源收回，用作其他用途。举个例子，当100%的流量被导向目标服务，健康检测没有返回错误，Redliner测试就随之结束。根据这个测试结果，工程师们可以减少生产环境的服务实例，或者利用LPS对资源进行更有效的分配。图5展示了使用Redliner对生产环境的服务器资源进行回收的例子。

图5 服务资源减持趋势示例

前瞻性容量规划

生产环境的容量问题总是很难缓解。通过运行Redliner的自动化测试，服务所有者和运维团队会收到潜在的容量告警。在Redliner识别出资源竞争问题（CPU、内存、网络、线程池）之后，做出缓解计划就会变得相对容易。另外，通过分析容量历史和可视化红线QPS趋势，工程师们可以建立评估模型，并作出适当的预测，提前为流量增长规划好资源。

吞吐量衰退检测

工程师们可以使用Redliner来检测应用程序的衰退情况，还可以通过自动化测试识别出新的资源瓶颈。Redliner支持同时运行canary环境的测试和生产环境的测试。工程师们可以在不同的服务实例上运行相同等级的流量负载：一个服务实例包含了新的配置、属性变更或者代码变更，另一个服务实例是当前的生产环境版本。负载测试结果可以作为部署的参考，可以避免部署包含了可能导致性能衰退的代码。

原文来自:聊聊架构

免责声明：以上内容为本网站转自其它媒体，相关信息仅为传递更多信息之目的，不代表本网观点，亦不代表本网站赞同其观点或证实其内容的真实性。