微服务架构中zuul的两种隔离机制实验

ZuulException REJECTED_SEMAPHORE_EXECUTION 是一个最近在性能测试中经常遇到的异常。查询资料发现是因为zuul默认每个路由直接用信号量做隔离,并且默认值是100,也就是当一个路由请求的信号量高于100那么就拒绝服务了,返回500。

信号量隔离

既然默认值太小,那么就在gateway的配置提高各个路由的信号量再实验。

两个路由的信号量分开提高到2000和1000。我们再用gatling测试一下。

1setUp(scn.inject(rampUsers(200) over (3seconds)).protocols(httpConf))

这是我们的模型,3s内启动200个用户,顺序访问5个API。所以会有1000个request。机器配置只有2核16G,并且是docker化的数据库。所以整体性能不高。

看结果仍然有57个KO,但是比之前1000个Request有900个KO的比例好很多了。

线程隔离

Edgware版本的spring cloud提供了另一种基于线程池的隔离机制。实现起来也非常简单,

use-separate-thread-pools的意思是每个路由都有自己的线程池,而不是共享一个。

thread-pool-key-prefix会指定一个线程池前缀方便调试。

hystrix的部分主要设置线程池的大小,这里设置了10000,其实并不是越大越好。线程池越大削峰填谷的效果越显著,也就是时间换空间。系统的整体负载会上升,导致响应时间越来越长,那么当响应时间超过某个限度,其实系统也算是不可用了。后面可以看到数据。

这次没有500的情况了,1000个Request都正常返回了。

比较

从几张图对比下两种隔离的效果,上图是信号量隔离,下图是线程隔离。

响应时间分布


直观上能发现使用线程隔离的分布更好看一些,600ms内的响应会更多一些。

QPS



两张图展示的是同一时刻的Request和Response的数量。

先看信号量隔离的场景,Response per second是逐步提升的,但是达到一个量级后,gateway开始拒绝服务。猜测是超过了信号量的限制或是超时?

线程隔离的这张就比较有意思了,可以看到Request per second上升的速度要比上面的快,说明系统是试图接收更多的请求然后分发给线程池。再看在某个时间点Response per second反而开始下降,因为线程不断的创建消耗了大量的系统资源,响应变慢。之后因为请求少了,负载降低,Response又开始抬升。所以线程池也并非越大越好,需要不断调试寻找一个平衡点。

在此我向大家推荐一个交流学习群:855801563 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源。

小结

线程池提供了比信号量更好的隔离机制,并且从实际测试发现高吞吐场景下可以完成更多的请求。但是信号量隔离的开销更小,对于本身就是10ms以内的系统,显然信号量更合适。

原文地址:http://blog.51cto.com/13981400/2316480

时间: 2024-10-29 04:59:42

微服务架构中zuul的两种隔离机制实验的相关文章

微服务架构中APIGateway原理

背景 我们知道在微服务架构风格中,一个大应用被拆分成为了多个小的服务系统提供出来,这些小的系统他们可以自成体系,也就是说这些小系统可以拥有自己的数据库,框架甚至语言等,这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用. 但是在UI上进行展示的时候,我们通常需要在一个界面上展示很多数据,这些数据可能来自于不同的微服务中,举个例子. 在一个电商系统中,查看一个商品详情页,这个商品详情页包含商品的标题,价格,库存,评论等,这些数据对于后端

Java生鲜电商平台-SpringCloud微服务架构中网络请求性能优化与源码解析

Java生鲜电商平台-SpringCloud微服务架构中网络请求性能优化与源码解析 说明:Java生鲜电商平台中,由于服务进行了拆分,很多的业务服务导致了请求的网络延迟与性能消耗,对应的这些问题,我们应该如何进行网络请求的优化与处理呢? 到底有没有一些好的建议与方案呢? 下面这个文章将揭晓上面的问题,让你对SpringCloud微服务网络请求性能有一个全新的认识. 目录简介 01.网络请求异常分类 02.开发中注意问题 03.原始的处理方式 04.如何减少代码耦合性 05.异常统一处理步骤 06

微服务架构中整合网关、权限服务

前言:之前的文章有讲过微服务的权限系列和网关实现,都是孤立存在,本文将整合后端服务与网关.权限系统.安全权限部分的实现还讲解了基于前置验证的方式实现,但是由于与业务联系比较紧密,没有具体的示例.业务权限与业务联系非常密切,本次的整合项目将会把这部分的操作权限校验实现基于具体的业务服务. 1. 前文回顾与整合设计 在认证鉴权与API权限控制在微服务架构中的设计与实现系列文章中,讲解了在微服务架构中Auth系统的授权认证和鉴权.在微服务网关中,讲解了基于netflix-zuul组件实现的微服务网关.

微服务架构中的安全认证与鉴权

转载:http://www.bootdo.com/blog/open/post/125 从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验.为了适应架构的变化.需求的变化,身份认证与鉴权方案也在不断的变革.面对数十个甚至上百个微服务之间的调用,如何保证高效安全的身份认证?面对外部的服务访问,该如何提供细粒度的鉴权方案?本文将会为大家阐述微服务架构下的安全认证与鉴权方案. 单体应用 VS 微服务 随着微服务架构的兴起,传统的单体应用场景下的身份认证和鉴权面临的挑战越来越大

微服务架构中主流的配置中心对比分析?

为什么需要配置中心 配置实时生效: 传统的静态配置方式要想修改某个配置只能修改之后重新发布应用,要实现动态性,可以选择使用数据库,通过定时轮询访问数据库来感知配置的变化.轮询频率低感知配置变化的延时就长,轮询频率高,感知配置变化的延时就短,但比较损耗性能,需要在实时性和性能之间做折中.配置中心专门针对这个业务场景,兼顾实时性和一致性来管理动态配置. 配置管理流程: 配置的权限管控.灰度发布.版本管理.格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分. 开源配置中心基本介

微服务----微服务架构中的提取基础组件

一.前言 在第一家公司中,接触到了公司的项目代码,在代码中使用了微服务的功能,使用到了公司封装的xx架构服务,简称为B架构,在B架构中具有基础业务功能服务,比如组织架构服务,日志服务,权限服务. 然后我们在项目中使用B架构中的服务,能够很容器也能很快捷地进行项目的开发,从而避免其他的非核心业务的编写. 二.基础功能组件 这些组件肯定是每一个应用到可以需要使用到的,这些组件是可以提取出来的,比如日志服务.监控服.统计服务.权限服务.认证服务等等.通过微服务的注册发现.配置.网关等,从而搭建出基础功

微服务架构下的数据一致性:概念及相关模式

主页:http://www.howardliu.cn/ 博客:微服务架构下的数据一致性:概念及相关模式 从2014年开始,微服务逐渐进入大家的实现,被认为是下一代实现信息化的有效手段.设计到系统,其中绕不开的就是数据一致性,从本地事务,到后来的分布式事务,都能够有效的保证数据一致性.但是在微服务架构中,这两种方式都不是最好的选择. 1. 使用本地事务和分布式事务保证一致性 在传统的单击应用中,最简单.最直接.最普遍的会使用一个关系型数据库,通过关系型数据库的事务保证数据的一致性.这种事务有四个基

几种常见的微服务架构方案,2018年是否还一如既往的火

微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果.虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程. 本文盘点了四种常用的微服务架构方案,分别是ZeroC IceGrid.Spring Cloud.基于消息队列与Docker Swarm. ZeroC IceGrid微服务架构 ZeroC IceGrid作为一种微

几种常见的微服务架构方案简述——ZeroC IceGrid、Spring Cloud、基于消息队列

微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果.虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程.本文选自<架构解密:从分布式到微服务>一书,了解本书详情请点击阅读原文. 本文盘点了四种常用的微服务架构方案,分别是ZeroC IceGrid.Spring Cloud.基于消息队列与Docker Swarm 1