全链路压测调研

微服务

API Gateway 网关是一个服务器，是系统的唯一入口，为了每个客户端提供一个定制的 API。  API 网关的核心是，所有的客户端和消费端都通 过统一的网关接入微服务， 在网关层处理所有的非业务功能。如它还可以具有其它职责， 如身份证、监控、负载均衡、缓存、请求分片于管理、 静态相应处理。通常，网关提供 RESTFUL/HTTP   的方式访问服务，而服务端通过服务注册中进行服务注册和管理。

微服务的特点：

单一职责：  微服务中每一个服务都对应唯一的业务能力，  做到单一职责

面向服务：面向服务是说每个服务都要对外暴露服务接口 API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现， 只要提供 Rest 的接口即可。

自治：  自治是说服务间互相独立，  互不干扰

团队独立：  每个服务是一个独立的开发团队，人数不能过多。

技术独立：  因为是面向服务，提供 Rest 接口，  使用什么技术没有别人干涉

前后端分离：采用前后端分离开发，  提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口

数据库分离：每个服务都使用自己的数据源

部署独立：服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换， 降低耦合，  易维护 Docker 部署服务

微服务性能测试与传统性能测试区别

传统性能测试更多的是以事务为核心，更多的是由单个或者多个事务构成业务场景进行压测。

微服务则需要进行全链路压测，  全链路压测指完全引入相关联的系统，尽量真实模拟线上硬件环境，  更多的是以请求为核心，完全模拟真实请 求流量，通过引流等方式进行场景的模拟进行压测，  更多的适用于业务链路较长的交易。

全链路一直是性能测试中的难点，其包含系统越多测试难度就越大，系统架构中每增加一层的监控内容就会给分析带来几何倍的难度。因此， 微服务架构下的性能测试重要性就不言而喻了。

微服务性能测试难点

1.如果在测试环境进行全链路压测，  最大的难点在于无法评估用户从客户端登录到完成交易的整个链路中，系统能最大承载能力是多少。如果 无法承载生成中的流量造成系统宕机，就会有灾难性的后果。所以在测试环境进行全链路要结合历史生成的流量，并合理做出业务增长预估， 如果能满足此流量可以判定微生产环境满足性能要求。当然，  这只是权宜之计，  如果在生产环境做全链路压测不会出现此情况。

2.全链路压测涉及的微服务模块多，  开发组多，各组开发人员又各负责自己的模块，因为版本升级快，  业务层架构变化也快，  很难能了解清楚 最新的架构，如果漏掉一个系统的调用关系，分析就会变得非常困难。

3.软件的版本控制问题，  因为版本升级快，造成测试环境与生成环境代码版本不一致，数据库表结构和索引不一致的情况。这种情况会造成测 试结果不准确，  重复测试。多系统更难控制此情况。

微服务性能测试如何开展

开展全链路压测，  除了传统性能测试的需求调研、环境准备、脚本开发、数据预埋、场景执行、应用监控分析、瓶颈定位、瓶颈修复、回归测 试、结果整理、输出报告等环节外还要加入分析需压测业务场景涉及系统和协调各个压测系统资源两个环节。

1、     梳理核心链路

在压测前我们一定要首先分析清楚需要压测的业务场景，只有分析清楚了业务场景才能梳理出来涉及的相关系统，  分析清楚后也可以更快的找 到性能瓶颈进行系统优化。这个工作一般是由架构师来梳理并确认涉及的相关系统，梳理清楚后就可以反馈给压测负责人进行人员和资源的协 调了。

2、     压测资源协调

在全链路压测过程中，  最难的工作其实不是系统优化、压测环境搭建等技术工作，  最难的是压测资源的协调工作。这里的资源不单单指压测硬 件、软件、环境等资源，  还包括了人力资源等。

3、     构建数据

数据的真实和可用是保证压测结果的关键，尽量使数据多元化，  参数重复性低，可以采用生产数据脱敏的方式。数据的真实性可以保证更真实 的模拟生产数据流量。数据的真实不光指发起的数据，  测试数据库的铺底数据量也要生产一致。