业务背景

随着挪动开发行业的步入存量时代，App 整体架构的负载能力、以及各个环节的优化逐渐成为各个开发者们关注的重点。

压力测试就是实现以上性能的次要计划。个别能够基于压力测试：

• 测试后端业务的负荷瓶颈；
• 评估整体架构性能；
• 业务稳固峰值；
• 排查出各节点的单薄关系；
• 优化系统资源；
• 防止短板效应；

为经营提供精确的用户承载量作为作证，防止流动 / 新利用的上线带来的突发流量造成的用户体验不佳。

明天，咱们将为大家介绍全链路压测计划的是实现原理和施行门路。

全链路压测与原理

通常咱们能够简略的把负载性能 = 单机性能 * 机器总量这一公式套用到预估的计划中，然而在理论的场景下，经常会波及到大量的业务节点，如 DNS，网关，数据库等环节，都有可能是导致整体业务性能的瓶颈，因此理论服务能力可能与预期存在较大误差。

个别用户会通过 loadrunner 等计划实现生产环境下的服务器性能压力测试，然而在 mPaaS 利用中，简单的部署无奈通过 MGS 网关，昂扬的费用等难点应运而生，为了解决这些痛点。

mPaaS 团队这边根据多位客户的述求，提供出 MGS 全链路压测计划。

区别于以往的测试计划，全链路压测计划中最大的不同是视角上的不同，站在客户端角度上作为切入点，将整个服务端链路作为一个黑盒，以实在的 request 和 response 作为评估的根据，模仿实在的业务申请，实在的数据流量，实在的用户习惯，来达到得出尽可能实在的评估后果。

链路梳理

在一个规范的数据链路中，个别为以下模型

而在全链路压测中，咱们把整体的服务端实现视为一个黑盒，因此咱们所需关注的焦点聚焦在前半段，重点能够概括为：

1. 客户端申请构建；

2. 客户端申请发送并通过 MGS 网关；

3. 客户端解析 MGS 网关返回的 response 并做出正确处理；

4. 实现高并发的客户端申请集群。

以上再次梳理，能够演绎出以下难点

难点 1 客户端申请构建

mPaaS 挪动网关 RPC 通信是在 HTTP 协定根底之上的实现的一种标准化接口方式，在复用 HTTP 申请规范的前提下，定义了一套数据交换格局，采纳 Header，Body 作为理论辨别，能够近似了解为，通过 Header 中的 Operation-Type 做为实在 api 指向，将 body 局部根据规定封装后进行转发。

在该步骤中，咱们以 JMeter 作为实现计划，Jmeter 灵便的脚本个性能够良好的实现客户端的实在申请模仿。

难点 2 数据加解密

mPaaS 挪动网关 RPC 申请特有的数据加密形式构建申请中比较复杂的局部。客户侧已有的测试计划不能笼罩这部分能力，因而往往抉择敞开网关服务端验签和加密性能施行压测。

这种形式的隐患在于无奈预计加解密给网关服务器带来的计算压力。

依据教训，不同的加解密算法配置，对网关的吞吐量有 20% ~ 40% 影响。在此阶段，由金融线 SRE 团队基于用户生产环境定制开发的 JMeter 插件 MGSJMeterExt，该插件逆向实现了申请体的加密和解密过程，使得压测脚本的编排能够包含加密局部。

难点 3 申请签名构建

mPaaS 挪动网关 RPC 申请特有的签名校验机制也比拟非凡。同数据加解密一样，目前客户侧无计划可笼罩这部分能力，往往抉择敞开接口验签进行测试。同样借助 MGSJMeterExt，能够实现在 JMeter 中实现对报文的正确签名，并通过服务端校验。

难点 4 压测集群环境部署

对于压测来说，须要的重点侧重于实在，实在的流量入口，实在的并发数量，能力得出实在的后果，而自行实现压测环境，昂扬的集群部署费用，也成了不必要的开销.

因此咱们举荐用户采纳阿里云 PTS 作为压测平台，基于其余计划，具备部署繁难，反对 Jmeter 脚本，流量实在等劣势，也可为用户提供更为详实的压测报告。

概览

以上模型简略能够演绎为以下构造

全链路计划及施行

Part1 后期筹备及调研

在后期阶段，指标是为了为理论的压测提供相干的筹备和数据撑持，确立压测指标和整体方向。

1.1 指标及数据筹备

1. 客户须要明确本身的压测指标和压测目标，基于压测指标，参照以往的经营数据，给出波及到的具体业务类目和可能的用户行为习惯，在整体的业务中各习惯所带来的相干比重关系。

1.2 客户端筹备

1. 客户端这边须要根据相应的业务指标，整顿出在客户端实现中可能波及到的接口和数据流程，如是否蕴含前置步骤，如登陆等，是否蕴含强制的步骤，如首页的刷新等，通过抓包等收集该步骤中实在的 request 和 response，以及确定合乎预期的值条件。

2. 该步骤波及业务构造的不同，亦可由服务端接口端实现该筹备。

1.3 服务端筹备

1. 服务端这边根据 1.2 中统计的相干接口，做好相干的数据挡板，防止导致测试数据净化实在数据库。

2. 因为在 mPaaS 全链路压测中，服务端被视为黑盒，因此须要实现对于服务端各业务的性能指标的监控，为前期的服务端调优作为根据。

1.4 MGSJMeterExt 插件筹备

因为 MGSJMeterExt 须要根据理论网关环境进行定制开发，须要用户提供以下数据：

1. 工作空间相干环境数据

2. 加密算法和公钥

Q&A 答疑

Q：如何实现压测脚本？

A：会由咱们的专家团队和现场同学实现简略场景下的压测脚本培训，在理论的场景下，可能波及到业务的多个环节，如登陆 token 的获取，一些明确的前置步骤，这一类因为波及到简单的业务场景，须要客户在阿里专家团队的帮助下自行实现。

Q：为什么是全链路的?

A：尽管咱们的压测脚本是基于客户端逻辑实现的，然而咱们实际上是模仿了实在的数据申请，也会确认服务端的返回是否达到预期，波及到整个残缺的数据链路及节点。

Q：链路的指标如何实现埋点?

A：压测计划的对象是基于黑盒的，通过零碎的 pts 指标，申请参数与返回的回报率，校验合乎预期后果的成功率，来确认基于用户角度下的整个架构所能负载的性能，对于一些后端的指标，因为不同的客户采纳的服务端的架构存在不少的差别，对于后端这类指标，个别对应的服务商都能提供相干的监控计划，也无需 mPaaS 这边进行解决。

Q：为什么应用 PTS?

A：mPaaS 团队实际上提供的是 MGS 的通信解决方案，帮助客户实现 PTS 脚本的编写，并不强制应用 PTS，只须要能提供相干的 Jmeter 集群部署环境即可，且 PTS 相干资源须要用户自行洽购，但目前 mPaaS 团队基于多个案列评估，相对而言，应用 PTS，有更高的性价比，且能提供更为合乎预期的压测环境，残缺的压测报告，故举荐用户应用 PTS 进行压测。

Q：有没有什么具体的规范，如 2c4g 状况下，或者 4c8g 下，应该达到怎么的性能指标?

A：压力测试自身即是为了明确在相干的系统资源下，能够达到的性能指标，因为服务端的架构不同，理论业务波及的流程节点不同，不同环境下的性能存在着微小的差别，这些即是应用压力测试的目标，须要通过压测能力明确实在的指标和评估各个节点的理论资源耗时。

Part2 Jmeter 开发与脚本革新

咱们演绎出了 MGS 通信计划的非凡侧重点，因此咱们须要在 Jmeter 实现这几点的革新

2.1 Header 革新

在 Header 中，咱们须要留神以下几点：

1.MGS 网关协定是依赖于一些 Header 字段的，因此须要确保网关参数齐全。

2. 局部参数为固定值，可间接写死，相干的配置能够参考控制台下载的配置文件。

3. 如业务有其余的 Header 依赖如 cookide 等业务上须要应用，也可间接增加，MGS 网关不会对 Header 信息进行过滤。

2.2 Url 革新

在 URL 中，咱们须要留神以下几点：

1.URL 的理论指向应为 MGS 网关，而非理论的业务服务器，相干的配置能够参考控制台下载的配置文件。

2. 目前所有到 MGS 网关的申请均为 post，如有 get 申请，也是由 MGS 进行转发时变为 get 的，在与 MGS 的通信中也为 post。

3.Body 局部如无非凡需要倡议如图所示即可。

2.3 Request 革新

在 Request 中，咱们须要留神以下几点：

1. 这里的加密 / 验签，依赖于 MGSJMeterExt 文件，须要援用该文件。

2. 个别状况下仅需批改 //config 局部即可。

3. 下述局部个别为对立计划，次要为了实现加密和验签，无需批改。

2.4 Response 革新

在 Response 中，咱们须要留神以下几点：

1. 在这里思考到施压机性能，不会影响到服务端的评估能力，因而若无数据二次应用需要，或后果判断需要，这里可不写

2. 如有相干需要，可在这里实现 Response 回参的二次解决

Part3 理论压测

大抵的步骤可演绎为：

3.1 PTS 及脚本性能调优

阿里云性能测试服务（PTS）提供了方便快捷的云端压测能力，在本次压测服务中，借助 PTS 实现互联网压力流量的输出。

有意思的点在于，加解密计算不仅给网关带来计算压力，也会给施压机带来了肯定的计算压力。因而，第一个版本的插件和压测脚本在施行前，咱们首先进行了针对试压机进行了的“压力测试”。

第一轮根底测试

PTS 试压机配置：

1.PTS 单 IP 单元配置

2. 并发数 500（单机最高并发）

3. 固定压力值流量模型

4. 两分钟压测时常

从回收的压测报告看，TPS 后果并不高，但返回 RT 值并不高：

接下来察看施压机的性能体现，能够看到施压机的 CPU 使用率水位始终比拟高，因而有理由狐疑加密计算压力给施压机的压力开释带来比拟大的影响。

通过对反复内容加密后果的缓存，大幅升高了计算压力；同时，为了防止缓存设计引起内存问题，对缓存下限进行了限度。

第二轮测试

与第一轮的测试配置完全相同，仅更换了优化后的加密插件。从回收的测试报告看，场景 TPS 有 75% 的晋升：

从施压机 CPU 性能看有一个显著的优化。

第三轮测试

有了第一轮的摸底和第二轮的优化状况，第三轮测试在配置上应用两台施压机满负荷进行压测，察看压测后果：

从后果看，压测脚本和编排过程合乎预期，能够在客户生产环境进行正式的 PTS 云端压测。

3.2 生产环境压测摸底

在正式压力测试开始，进行了若干轮小规模的压力测试，察看后端系统的工作状态是否合乎预期。摸底期间发现如下问题：

问题一：Nginx 流量转发不均

从 MGS 容器的日志体现上看，局部容器始终获取不到任何申请，通过排查发现该问题由三个起因导致：

1）DMZ 区 Nginx 转发配置少配了一个 MGS 容器 IP；

2）DMZ 区到每一个 MGS 容器 IP 的网络策略均须要开明拜访权限；

3）Nginx 转发规定设置为 iphash，在单 IP 起源的测试状况，流量仅能转发到一个容器上。

配置了正确的 IP 列表、开明了网络权限以及批改转发规定后，该问题失去解决。

问题二：特定 MGS 容器根底 CPU 负载过高

后期测试发现，有一台 MGS 容器（mpaasgw-7）在静默状态下的 CPU 负载在 25%，不合乎预期。

登录容器发现存在一个 JPS 过程，耗费了大量的 CPU。狐疑是后期调测阶段调用后未失常开释。杀掉 JPS 过程后问题解决，为了防止其余问题，一并重启了该容器

注：JPS, Java Virtual Machine Process Status Tool)，是 java 提供的一个显示以后所有 java 过程 pid 的命令，参见：https://docs.oracle.com/javas…）。

问题三：CoreWatch 监控平台无法访问

CoreWatch 控制台无法访问，浏览器中报 502 谬误。重启 CoreWatch 容器后，页面能够加载，但始终处于加载中状态。

http://corewatch.*.com/xflush/env.js 始终处于 pending 状态。排查发现 ALB 实例监听配置存在谬误，修改后问题失去解决。

3.3 生产环境压力测试 & 总结

在解决了 3.2 中的所有问题后，零碎具备了压力测试的条件，正式压测会针对“加密场景”和“非加密”场景别离做压力测试。

因为生产数据不做外泄，以下仅对遇到的问题进行一些例举。

“加密”状况下测试

1. 压测时发现在并发数 500 左右即呈现 TPS 不做增长，代表着可能达到了瓶颈。

2. 察看 MGS 网关容器的负载状况，整体 CPU 负载达到极限。

3. 同一时间段的 MCUBE 容器 CPU 负载状况衰弱，其余性能指标（IO、网络等）也处于衰弱状态。

4. 从上述情况看，加密场景下，次要性能瓶颈在 MGS 网关上，依据教训及流程剖析，次要性能压力由报文加解密过程中的密集计算所带来。要解决这一瓶颈，须要对 MGS 容器进行扩容。

“不加密”状况下的测试

1.TPS 的增长在并发达到 1000 左右时进行增长。个别状况下，这种状况阐明涉及了零碎容量的瓶颈。

2. 察看 MGS 网关容器的负载状况，与加密状况下的状况不同，此时整体 CPU 负载均不高。

3. 与此同时，依据网络组的反馈：压测期间互联网到 DMZ 区的 TCP Session 数量是 DMZ 区到内网区的 3~4 倍，交易内网段的防火墙 CPU 压力较高。

4. 联合上述三种体现，狐疑涉及网络层面瓶颈。依据现场状况发现，DMZ 区 Nginx 转发到内网时没有采取长连贯放弃策略。批改 Nginx 配置，增加 keepalive 1000 配置，从新进行第二轮测试。

对于参数 Keepalive 阐明：默认状况下，Nginx 拜访后端都是用的短连贯（HTTP1.0），每一个新的申请，Nginx 都会新开一个端口和后端建设连贯，后端执行结束后被动敞开该链接。Keepalive 参数会告知 Nginx 和后端服务器之间缓存的长连贯数量，当新的申请进来时，可间接复用 TCP 连贯，缩小建设 TCP 连贯所带来的性能影响。参见：http://nginx.org/en/docs/http…。

总结

在上述问题优化后，非加密场景下至多有 70% 的性能晋升，加密场景下 10% 的性能晋升，并在 MGS 扩容实现后可实现大幅的性能晋升，调优的后果远超预期。

本文作者：阿里云 mPaaS TAM 团队（王泽康，北默，东雷，荣阳）

END