如何使用 PTS 快速发起微服务压测

简介：本文讲阐述什么是微服务架构、微服务架构对系统稳定性带来的影响，以及用性能测试验证稳定性的必要性、用户进行微服务压测的痛点和 PTS 的独特优势、云上使用 PTS 快速发起微服务压测的步骤，以及压测完成后排查分析相关问题的 Tips。

作者：亦炎

什么是微服务

通常而言，微服务架构是一种架构模式或者说是一种架构风格。

本文阐述了：

什么是微服务架构
微服务架构对系统稳定性带来的影响，以及用性能测试验证稳定性的必要性
用户进行微服务压测的痛点和 PTS 的独特优势
云上使用 PTS 快速发起微服务压测的步骤，以及压测完成后排查分析相关问题的 Tips

它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

微服务以其高内聚、低耦合等特性，提供了更好等容错性，也更适应业务等快速迭代，为开发人员带来很多便利。但是随着业务的发展，微服务拆分越来越复杂，模块越来越多，意味着服务间的调用链路比以前延长很多，在调用链路上发生故障的几率也就随之增大，这给我们的系统稳定性带来不小的挑战。比如：

在单服务流量激增情况下，需要快速响应扩容；
当一个服务无法承受大请求压力的时候，是否会影响所依赖的其他服务；
整个系统被拆成了很多的微服务，当某个服务出现故障时，是否有容错手段能够让业务继续跑下去，而不影响整体应用。

利用性能压测验证微服务稳定性

保障微服务稳定性的常见方式

1.超时机制如果调用一个接口，但迟迟没有返回响应的时候，我们往往需要设置一个超时时间，以防自己被远程调用拖死。超时时间的设置也是有讲究的，设置的太长起的作用就小，自己被拖垮的风险就大，设置的太短又有可能误判一些正常请求，大幅提升错误率。在实际使用中，我们可以取该应用一段时间内的 TP999 的值，或者取 TP95 的值 * 2。

2.限流限流就是限制服务请求流量，服务提供者可以根据自身情况(容量)给请求设置一个阈值，当超过这个阈值后就丢弃请求，这样就保证了自身服务的正常运行。阈值的设置可以针对两个方面考虑，一是 QPS 即每秒请求数，二是并发线程数。从实践来看，我们往往会选择后者，因为 QPS 高往往是由于处理能力高，并不能反映出系统“不堪重负”。

3.降级熔断由于微服务调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。我们需要在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断。

4.扩容链路中的某一应用可能出现 cpu 使用率较高或者连接池资源不够用(rpc、jdbc、redis 连接池等)，但本身对于拿到连接的请求处理又很快，这一类需要横向扩展资源。

利用性能压测验证微服务稳定性

那么如何验证上述保障稳定性的措施是否满足我们的需要？

1. 通过微服务性能测试，我们可以得到系统在“高压”下 RT 的 TP95 和 TP999 等指标分布，根据这些指标设计合理的超时时间；

2. 在 RT 没有明显飙升的情况下能承受多高并发的请求，摸清调用链路请求堆积的节点，设计合理的限流、降级熔断策略，在尽可能不影响用户体验的情况下，更好的提升微服务稳定性。

3. 验证服务扩容的有效性。

因此，无论是为了评估单服务上线或变更对系统性能对影响，还是需要对服务精准扩容并验证扩容的有效性，在全面正式压测前，对重点微服务应用做性能测试，摸清局部对性能极限，都是必不可少的。

微服务压测痛点

目前常见的微服务压测工具，比如基于自定义插件的 JMeter 和 Gatling，都存在以下难以避免的痛点：

1. 出于安全性的考虑，单个微服务应用不会暴露公网入口，这时就需要压测工具有打通 VPC 内网的能力，用户自建成本较高。

2. 无法模拟跨应用多接口的调用。

3. 每个服务的注册中心地址、接口名和参数配置起来十分繁琐。

4. 缺乏直观的调用链分析和监控。

使用 PTS 压测微服务的优势

PTS 作为具备强大的分布式压测能力的 SaaS 平台，用户不需要去管底层环境的搭建，便可直接使用百万级的并发模拟能力和数据分析汇总能力，在微服务压测领域具有独特优势。

安全实惠，支持 VPC 内网压测PTS 支持 VPC 内网压测，可以在压测时快速打通施压机与用户VPC网络，保证内网压测的网络畅通。在压测结束后，也会即时关闭网路通道，保证网络安全。
随心所欲，支持多应用多接口场景编排一个微服务应用从开发到上线需要做哪些性能测试？首先我们需要对单服务的接口进行性能测试，可能会发现一些应用逻辑的问题，这时候有针对性的进行性能优化。当我们把单服务接口性能优化完以后，我们就需要结合用户场景进行多应用多接口的场景性能测试，这时候可能会发现一些服务与服务之间的接口调用的问题，同样也会进行对应的性能优化；最后我们还需要关注服务的伸缩能力验证，从而确定我们每一个服务所支持的扩容模型。
使用简单，支持直接压测 EDAS/MSE 应用PTS 天然打通 EDAS/MSE 应用，可直接对其发起压测，省去配置各项服务参数的烦恼，快捷方便。
直观清晰，支持调用链分析和监控在启动压测之前，用户可以接入 PTS 的问题诊断功能，实现微服务应用之间的调用链分析和监控。针对 Java 类型的服务，用户侧无需进行业务侧代码改造即可完成问题诊断的探针接入。对于压测中出现的各种异常信息，即使调用关系十分复杂，用户也能清晰地分析问题所在。

PTS 微服务压测的原理

我们通常会使用 RPC 框架来实现微服务间的远程调用，RPC 框架包含三个最重要的组件，如下图所示，分别是客户端、服务端和注册中心。

在一次 RPC 调用流程中，这三个组件是这样交互的：

服务端在启动后，会将它提供的服务列表发布到注册中心，客户端向注册中心订阅服务地址；
客户端会通过本地代理模块 Proxy 调用服务端，Proxy 模块收到负责将方法、参数等数据转化成网络字节流；
客户端从服务列表中选取其中一个的服务地址，并将数据通过网络发送给服务端；
服务端接收到数据后进行解码，得到请求信息；
服务端根据解码后的请求信息调用对应的服务，然后将调用结果返回给客户端。

在实际压测中，PTS 扮演着客户端的角色，并且在本地维护了一个服务列表，每 5 秒主动请求一次注册中心，更新该服务列表，在保证实时性的同时，尽可能降低注册中心的负载。原理如图所示。

云上使用 PTS 快速发起微服务压测

创建场景。PTS 目前支持 Dubbo、Spring Cloud 和 gRPC 三种微服务框架，这里以 Dubbo 为例，压测事先接入的 EDAS 应用。首先，我们在 PTS 控制台的【压测中心】->【创建场景】中创建 Dubbo 压测场景；

2. 选择应用。我们选择压测应用来源为【EDAS】,地域为【杭州】，选择默认微服务空间；

3. 编辑场景。在场景配置-基础配置页中选择需要压测的应用、接口和方法，设置合理的连接和响应超时时间；PTS 支持同时压测多应用和多接口，还可以借助控制器与定时器实现场景编排。

4. 最后，在施压配置页中，用户只需要选择微服务应用所在的 VPC 内网、安全组、交换机，即可开启 VPC 内网压测。让您的服务无需暴露公网入口，也可以探测出性能指标。此外，PTS 还推出了 VPC 压测专属资源包[1]，价格只需公网压测 1/10。

常见微服务性能测试问题分析

存在部分响应超时：a) 服务器繁忙,如某个服务节点 CPU 利用率高
b) 网络 IO 超过 VM/EIP 带宽
c) 后端微服务、数据库的超时时间设置过长
TPS 未随着并发数增长而上升：a) 系统性能到达瓶颈，持续并发加压过程中响应时延增加（可观察响应区间统计）
b) 验证进一步加压是否会出现非正常响应
运行一段时间后全部响应超时或者检查点校验不通过：a) 大压力导致系统中某个微服务崩溃
b) 后端数据库无响应
TP90 响应时延较短，TP99 时延高：a) 系统性能接近瓶颈
b) 验证进一步加压是否会出现非正常响应