本文来自一名学员的分享nginx
平常工做中，不免会遇到临危受命的状况，虽然没有这么夸张，可是也可能会接到一个陌生的任务，也许只是对这个概念有所耳闻。也许这个时候会感到一丝的焦虑，生怕无法完成领导交给的测试任务。其实也没有必要那么紧张，面对一个陌生的被测对象，咱们只须要去了解清楚它的应用场景、内部原理、实现逻辑，结合开发的设计需求，同样也能完成好测试任务，积累经验。此次就分享一些从0到1学习如何测试API网关的经验。web
1、什么是API网关
简述：
API网关出现的缘由是微服务架构的出现，不一样的微服务通常会有不一样的网络地址，而外部的客户端可能须要调用多个服务的接口才能完成一个业务需求，这个时候系统结构会显得很是错综复杂，会出现许多问题：正则表达式
- 客户端复杂性增长，如今通常同一套后端服务会支撑多个客户端
- 存在跨域请求，在必定场景下处理相对复杂
- 认证复杂，每一个服务都须要单独验证
- 耦合度高，难以重构
- 某些微服务会存在防火墙等一些保护措施，没法直接访问
微服务网关是微服务架构中的一个关键角色，用来保护，加强和控制对于微服务的访问，微服务网关是一个处于应用程序或服务以前的系统，用来管理受权，访问控制和流量限制等，这样微服务就会被微服务网关保护起来对全部的调用者透明。所以，隐藏在微服务网关后面的业务系统就能够更加专一于业务自己。redis
组成：
- 路由转发：接受外界请求，转发到后端微服务
- 过滤器：完成一系列横切功能，例如权限校验，限流以及监控等
优势：
- 安全性高，只有网关系统对外进行暴露，微服务能够隐藏在内网，经过防火墙策略保护
- 易于监控，能够在网关收集监控数据并将其推送到外部监控系统进行分析
- 易于认证，能够在网关处统一进行认证，无需在后端微服务中进行认证
- 减小耦合，避免多个客户端与后端微服务之间的交互次数
- 易于鉴权，在网关处统一鉴权
职能：
- 请求接入，做为全部API接口服务请求的接入点
- 业务聚合，做为全部后端业务服务的聚合点
- 中介策略，实现安全，验证，路由，过滤，流控等策略
- 统一管理，对全部API服务和策略进行统一管理
2、微服务网关常见技术
- nginx是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务
- zuul，Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器
- spring-cloud-gateway是spring出品的基于spring的网关项目，集成断路器，路径重写等，性能比Zuul好
2.1 gateway是什么
Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway做为Spring Cloud生态系中的网关，目标是替代Zuul，其不只提供统一的路由方式，而且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。spring
几个概念
- Route（路由）：这是网关的基本构建块。它由一个ID，一个目标URI，一组断言和过滤器定义。若是断言为真，则路由匹配成功。
- Predicate（断言）：输入类型是一个ServerWebExchange。咱们可使用它来匹配来自HTTP请求的任何内容，例如headers或参数。
- Filter（过滤器）：Gateway中的Filter分为两种类型的filter，分别是gateway filter和global filter，过滤器会对请求和响应做处理。
2.2 gateway怎么用
说到底predicate就是为了实现一组匹配规则，方便让请求过来找到对应的Route进行处理，而spring cloud gateway内置了几种predicate的使用。数据库
一、经过时间匹配json
Predicate 支持设置一个时间，在请求进行转发的时候，能够经过判断在这个时间以前或者以后进行转发。好比咱们如今设置只有在 2018 年 1 月 20 日才会转发到个人网站，在这以前不进行转发，我就能够这样配置：后端
spring:
cloud:
gateway:
routes:
- id: time_route
uri: http://youknowit.com
predicates:
- After=2018-01-20T06:06:06+08:00[Asia/Shanghai]
二、经过cookie匹配跨域
Cookie Route Predicate 能够接收两个参数，一个是 Cookie name , 一个是正则表达式，路由规则会经过获取对应的 Cookie name 值和正则表达式去匹配，若是匹配上就会执行路由，若是没有匹配上则不执行。数组
spring:
cloud:
gateway:
routes:
- id: cookie_route
uri: http://youknowit.com
predicates:
- Cookie=youknowit, value
三、经过请求路径匹配
Path Route Predicate 接收一个匹配路径的参数来判断是否走路由。
spring:
cloud:
gateway:
routes:
- id: host_route
uri: http://x.x.x.x:8022/
predicates:
- Path=/foo/{segment}
若是请求路径符合要求，则此路由将匹配，例如：/foo/1或者/foo/bar。
固然内置的匹配规则还有不少，经过请求参数，请求方式，请求IP地址等去匹配，也能够组合使用。
注意：
一个请求知足多个路由的谓词条件时，请求只会被首个成功匹配的路由转发
本次提测版本，开发使用spring-cloud-gateway来将平台业务侧引入网关， 将网关做为调用PaaS的惟一入口，便于维护，同时利用网关的能力实现限流，熔断，鉴权，灰度验证等功能。第一期只接入统一前装，充分验证后后续接入其余应用。所以，本次测试的重点在路由转发功能。
3、常见测试点
spring:
cloud:
gateway:
httpclient:
connect-timeout: 5000
response-timeout: 5s
ssl:
close-notify-flush-timeout-millis: 3000
close-notify-read-timeout-millis: 0
handshake-timeout-millis: 10000
useInsecureTrustManager: true
routes:
# gis
- id: gis_route
predicates:
- Path=/gis/**
uri: http://x.x.x.x:8022/
知道了网关的基础知识和基本原理以后，对于咱们如何测试它，做为一名测试人员心中已经有了大概的思路，接下来就是根据咱们实际的需求去列出测试点，并进一步转换为用例去执行。从上面开发给出的配置能知道，这次开发提测主要是实现了基于路径匹配的路由转发功能，其他功能暂未引入，这样想来就简单了许多。
3.1 功能测试
常见请求正常转发
- get请求正常转发：带参数与不带参数
- post请求正常转发：数据格式校验，例如json，form等
- delete请求正常转发：带参数与路径带参
- put请求正常转发：数据格式校验，例如json，form等
- patch请求正常转发：数据格式校验，例如json，form等
- 接口超时测试：具体的边界值测试需根据自身业务需求场景来设计case
- 文件上传功能：大小限制，乱码问题，格式问题
- 路由规则：根据项目需求的不一样规则来制定，例如全量匹配，正则，前后顺序等
- 负载策略：轮询，权重等
- 超时设置
3.2 插件测试
API网关插件各个公司根据不一样的需求有不一样的插件，这次提测也没有涉及，因此收集整理了一些常见的通用插件，例如降级，限流，熔断，跨域，abtest插件等，提供一些测试思路。
限流
基本概念： 客户端请求太多，超出了服务端的承受能力，致使服务端不可用或没法响应，耗尽服务端资源甚至是服务崩溃。解决方案：服务端对客户端进行限流，保护服务端资源。对各种请求设置最高的QPS阈值，当请求高于阈值时直接阻断。
限流插件测试思路：能够在API网关平台为对应测试接口配置限流策略。根据不一样时间，使用压测工具进行阶段性的压力测试，并统计阻断接口数，具体的数值能够根据自身业务场景进行测试。
降级
基本概念： 服务降级是指当服务器压力剧增的状况下，根据实际业务状况，将一些不重要的接口换种简单的方式处理，从而将服务器资源释放给当前的核心业务使其能够高效运做。
降级插件测试思路：降级策略主要看开发如何选择，有的就是让请求没法访问到后端服务，借口暂停使用，当接口配置降级插件。插件开关打开，返回API网关所配置的响应信息状态码等，接口是没法真正的请求到后端服务。
熔断
基本概念： 微服务架构中，各个微服务之间相互依赖很是广泛，所以在整个链路中 ，有一个环节出现问题，都会形成整个上下游服务调用出现问题，服务出现宕机。也就是说，熔断就是调用方发起服务调用时，若是被调用方返回的错误率超过必定的阈值，那么后续的请求不会真正发起请求，而是调用方直接返回错误。两个关键点，判断什么时候熔断和什么时候从熔断状态恢复。
熔断插件测试思路： 不一样的网关有不一样的熔断策略，例如针对5xx的返回，根据不一样的入参控制返回，可返回2xx，4xx，5xx，当规定的时间5xx数达到阈值，服务是否开启熔断。熔断恢复测试也是同样，好比10s，容许部分请求经过，你能够继续控制请求，若这部分请求都成功，恢复熔断。具体的case设计仍是要根据自身业务为准。
跨域
基本概念： 跨域是指，只要协议，域名，端口有任何一个不相同，都被看成是不一样的域。所谓同源策略就是指，协议，域名和端口都要相同，其中有一个不一样都会产生跨域。
跨域测试思路： CORS是一种基于HTTP头的机制，该机制经过容许服务器标识除了本身之外的其余origin，这样浏览器能够访问加载这些资源。浏览器必须首先使用OPTIONS方法发起一个预检请求，从而获知服务端是否容许该垮源请求。服务器容许以后，才发起实际的HTTP请求。在预检请求的返回中，服务端也能够通知客户端，是否须要携带身份凭证。测试时，咱们就能够经过是否须要携带参数，身份凭证等；各类参数组合，不一样请求等方面去设计case。
3.3 容错测试
- 数据库宕机或者重启：新发布的路由或者插件设置等数据操做可能失败，可是不影响已生效的路由和插件
- 后端服务其中一台或多台宕机，重启，添加新节点等：负载策略可以自动提出不可用的服务节点和自动增长新的服务节点
- redis服务宕机一台或多台：不影响已生效路由和插件
- eureka挂一台或多台：不影响已生效负载策略
注意： 数据库down,由于有本地缓存，验证本地缓存是否生效，因此数据库重启或者down掉，不能影响已经生效的路由和插件；后端服务down掉一台，验证eureka是否有将死掉的节点删除，若eureka并无将死掉的节点删除，则会报错。添加新的节点，须要看请求是否有轮询；redis主要用于限流，在redis down掉限流策略失效，可是其余插件功能及路由应该不受影响；eureka是注册中心，注册中心在启动的时候会将全部资源加载本地，因此eureka挂一台或者多台，不影响已经加载到本地的。 总上所述，总结来讲就是API网关的全部依赖均可以down，可是gateway不能够不用。
3.4 压力测试
- 正常压测：压API网关的API便可
- 负载测试：压测时，增长和减小后端服务节点；某个服务资源打满或者超时严重，不影响其余项目正常访问
- 切换路由配置
- 项目资源测试：超过配置资源返回错误
- ...
注意： 项目资源的做用是进行线程隔离，每一个项目资源分配应该是固定的，不能抢占其余项目资源而致使其余服务不可用，进行负载测试时，增长压力，增长和减小后端服务节点，请求应该不报错。
4、总结
上述内容，是对一些网关通用功能的测试思路总结。因为本次开发提测网关版本并无涉及过多的功能，例如还有集群的热加载，插件在集群项目与API间的运用，API的发布，下线，插件的随时切换，监控等需求，亲身实践还不够，只能提供一些思路，还须要具体结合项目的业务进行更为准确的case设计。