Spring Cloud Zuul线程、信号量隔离性能测试
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Spring Cloud Zuul线程、信号量隔离性能测试相关的知识,希望对你有一定的参考价值。
参考技术A验证Zuul使用哪一种隔离策略更优,Zuul网关作为流量入口,理应具备良好的响应以及较高的吞吐量,所以为了验证线程、信号量隔离哪一种更适合Zuul网关,本次我们就针对这两种策略做针对实验。根据实验数据在结合自身应用做各自的选择!
左图为应用性能指标,我们关注下Apdex这个指标(满意度),0.258的满意度,说明很低啊,说明我们的请求响应时间绝大多数都是大于500ms的,我们在看看右图,成功与失败的占比约为9:1,说明在结果方面还不错,只是时间长了一点
针对数据分析这张图,我们大致解释下
我们结合这张随着时间点的响应时间图不难看出,我们的信号量整体的响应都比较平稳,信号量模式为共用请求线程,最终会依赖容器的线程池管理,随着请求的增多,多余的请求会被放到容器队列等待执行,所以看起来比较平稳
因为我们配置的Hystrix默认线程池为coreSize:2、maximumSize:5、maxQueueSize:1、queueSizeRejectionThreshold:1,最大的队列长度为1,拒绝执行的限制条件为1,有兴趣的同学可以把maxQueueSize及queueSizeRejectionThreshold参数都调整尽可能大一点,那么相对的实验数据失败率就会明显降低,但是在峰值环境下响应时间会更长!
我们在对比下0.042的满意度,约等于93%的失败率,可以说是馋不忍睹,相当于Zuul网关不可用
针对线程隔离的数据分析,失败率达到93%,响应时间、吞吐量都率高于信号量,这个也不难看出,大量的数据都失败了,那么相应的响应时间、吞吐量就要高一点
我们大概分析下这个分布图,刚开始请求会被放到Hystrix的线程池内部执行,此时线程够用,所以响应时间也相对要快一些,但是随着请求数越来越多,相应的Hystrix内部的线程也越来越多在处于排队,整个响应时间呈现断崖式波动,最终也会导致越来越多的请求无法执行,呈现出失败率成倍增长,导致最终Zuul网关不可用!
Spring Cloud:API网关服务——Spring Cloud Zuul
通过前面的介绍,我们可以使用Spring Boot进行微服务开发,使用Spring Cloud Eureka实现注册中心以及微服务的注册和发现,使用Spring Cloud Ribbon实现服务间的负载均衡,使用Spring Cloud Hystrix实现线程隔离以及断路器功能。但是实际应用中这样的架构无疑增加了开发成本以及运维难度,而且后期重构难度也很大。为了解决以上各种问题,需要使用API 网关的方式。API 网关是一个服务器,它是进入一个系统的唯一节点,封装了内部系统的架构,并且提供了API给各个客户端,另外它还具备授权,监控,负载均衡,缓存,请求分片和管理,静态响应处理等功能。
使用Zuul 构建API网关服务:
在前几节创建的工程(下载地址:https://github.com/francis785/springclouddemo.git)基础上创建 springcloud-demo-zuul 模块,添加pom依赖:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <parent> <artifactId>springcloud-demo-parent</artifactId> <groupId>com.fix</groupId> <version>1.0-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>springcloud-demo-zuul</artifactId> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-zuul</artifactId> </dependency> </dependencies> </project>
编写启动主类 ZuulMain ,添加 @EnableZuulProxy 标签:
@SpringBootApplication @EnableEurekaClient @EnableZuulProxy public class ZuulMain public static void main(String[] args) SpringApplication.run(ZuulMain.class, args);
配置 application.yaml 文件:
server: port: 8050 eureka: instance: prefer-ip-address: true #是否显示主机的Ip client: service-url: defaultZone: http://localhost:8761/eureka/ #指定eureka服务端地址 spring: application: name: springcloud-demo-zuul #指定应用名称 zuul: routes: order-serverId: #zuul的唯一标识 path: /order/** #需要映射的路径 service-id: springcloud-demo-order
分别启动服务注册中心、 springcloud-demo-order 以及网关服务 springcloud-demo-zuul ,注册中心已经注册的服务如下图:
首先通过 springcloud-demo-order 的端口7900直接访问接口http://localhost:7900/order/1,接口响应如下:
然后通过zuul的端口8050来访问 springcloud-demo-order 实例的接口:http://localhost:8050/springcloud-demo-order/order/1,接口响应如下:
说明zuul配置的路由功能已经生效,可以看到zuul的配置和使用非常简单。
除了这种配置方式,也可以不使用Eureka而单独使用zuul,但这种方式在实际应用中不推荐使用。
以上是关于Spring Cloud Zuul线程、信号量隔离性能测试的主要内容,如果未能解决你的问题,请参考以下文章
Spring Cloud:API网关服务——Spring Cloud Zuul
结合Spring Cloud Zuul 与 Kubernetes的灰度发布测试方法
结合Spring Cloud Zuul 与 Kubernetes的灰度发布测试方法