微服务网关压力（微服务网关权限控制）

本篇文章给大家谈谈微服务网关压力，以及微服务网关权限控制对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务网关压力的知识，其中也会对微服务网关权限控制进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、微服务核心组件 Zuul 网关原理剖析
• 2、微服务 六：服务网关
• 3、Spring Cloud微服务体系的组成
• 4、为什么在微服务架构下，服务网关和数据库不能部署在虚拟机上
• 5、微服务网关层

微服务核心组件 Zuul 网关原理剖析

Zuul 网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能。在分布式的微服务系统中，系统被拆为了多套系统，通过zuul网关来对用户的请求进行路由，转发到具体的后台服务系统中。

本 Chat 主要内容如下：

网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能，下面我们从单体应用到多体应用的演化过程来讲解网关的演化历程。

一般业务系统发展历程都是基本相似的，从单体应用到多应用，从本地调用到远程调用。对应单体应用架构模式（如下图1），由于只需一个应用，所有业务模块的功能都打包为了一个 War 包进行部署，这样可以减少机器资源和部署的繁琐。

图1 单体应用

在单体应用中，网关模块是和应用部署到同一个jvm进程里面的，当外部移动设备或者web站点访问单体应用的功能时候，请求是先被应用的网关模块拦截的，网关模块对请求进行鉴权、限流等动作后在把具体的请求转发到当前应用对应的模块进行处理。

随着业务的发展，网站的流量会越来越大，在单体应用中简单的通过加机器的方式可以带来的承受流量冲击的能力也越来越低，这时候就会考虑根据业务将单体应用拆成若干个功能独立的应用，单体应用拆为多个应用后，由于不同的应用开发对应的功能，所以多应用开发之间可以独立开发而不用去理解对方的业务，另外不同的应用模块只承受对应业务流量的压力，不会对其他应用模块造成影响，这时候多体的分布式系统就出现了，如下图2。

图2 多体应用

如上图在多体应用中业务模块A和B单独起了个应用，每个应用里面有自己的网关模块，如果业务模块多了，那么每个应用都有自己的网关模块，这样复用性不好，所以可以考虑把网关模块提起出来，单独作为一个应用来做服务路由，如下图3：

如上图当移动设备发起请求时候是具体发送到网关应用的，经过鉴权后请求会被转发到具体的后端服务应用上，对应前端移动设备来说他们不在乎也不知道后端服务器应用是一个还是多个，他们只能感知到网关应用的存在。

Zuul是Netflix开源的一个网关组件，在Netflix内部系统中Zuul被用来作为内部系统的门面，如下图是Zuul在Netflix内部使用的一个架构图：

如上图最上层的移动设备或者网站首先通过aws负载均衡器把请求路由到zuul网关上，zuul网关则负责把请求路由到具体的后端service上。

Zuul开源地址 https://github.com/Netflix/zuul

Zuul网关的核心是一系列的过滤器，这些过滤器可以对请求或者响应结果做一系列过滤，Zuul 提供了一个框架可以支持动态加载，编译，运行这些过滤器，这些过滤器是使用责任链方式顺序对请求或者响应结果进行处理的，这些过滤器直接不会直接进行通信，但是通过责任链传递的RequestContext参数可以共享一些东西。

虽然Zuul 支持任何可以在jvm上跑的语言，但是目前zuul的过滤器只能使用Groovy脚本来编写。编写好的过滤器脚本一般放在zuul服务器的固定目录，zuul服务器会开启一个线程定时去轮询被修改或者新增的过滤器，然后动态进行编译，加载到内存，然后等后续有请求进来，新增或者修改后的过滤器就会生效了。

在zuul中过滤器分为四种：

如下图为zuul1.0的工作原理：

如上图，当zuul接受到请求后，首先会由前置过滤器进行处理，然后在由路由过滤器具体把请求转发到后端应用，然后在执行后置过滤器把执行结果写会到请求方，当上面任何一个类型过滤器执行出错时候执行该过滤器。

本节作者使用zuul的版本：

...

....

总结：zuul1.0时候当zuul接受到一个请求后会同步执行前置过滤器、路由过滤器、后置过滤器，等执行完毕后在同步把结果返回为调用方，调用方在整个过程中是阻塞的。其实SpringBoot集成的zuul就是自己实现了个前置过滤器做选择路由，然后自己实现了个路由过滤器根据前置过滤器选择的路由具体做路由转发。

Netty作为高性能异步网络通讯框架，在dubbo，rocketmq,sofa等知名开源框架中都有使用，如下图zuul2.0使用netty server作为网关监听服务器监听客户端发来的请求，然后把请求转发到前置过滤器（inbound filters）进行处理，处理完毕后在把请求使用netty client代理到具体的后端服务器进行处理，处理完毕后在把结果交给后者过滤器（outbound filters）进行处理，然后把处理结果通过nettyServer写回客户端。

...
总: 在zuul1.0时候客户端发起的请求后需要同步等待zuul网关返回，zuul网关这边对每个请求会分派一个线程来进行处理，这会导致并发请求数量有限。而zuul2.0使用netty作为异步通讯，可以大大加大并发请求量。

微服务 六：服务网关

服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关(Service Gateway)，见图（15），网关是连接企业内部和外部系统的一道门，有如下关键作用：

服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。

限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。

监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。

日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。

图（15）gateway服务图

除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。

网关通常工作在7层，有一定的计算逻辑，一般以集群方式部署，前置LB进行负载均衡。

开源的网关组件有Netflix的Zuul，其工作原理如下图。

图（16）zuul工作原理图

在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图(17)来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内LB服务发现和负载均衡机制。在图（17）的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务Middle Tier Service）和前端服务（也称边缘服务Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如PC，Pad或者Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似Proxy代理或者Façade门面模式，而服务注册表和服务自注册自发现类似IoC依赖注入模式，微服务可以理解为基于网关代理和注册表IoC构建的分布式系统。

图（17）简化的微服务架构图

Spring Cloud微服务体系的组成

Netflix Eureka是Spring Cloud服务注册发现的基础组件
Eureka提供RESTful风格(HTTP协议)的服务注册与发现
Eureka采用C/S架构,Spring Cloud内置客户端

启用应用,访问 http://localhost:8761
Eureka客户端开发要点
maven依赖spring-cloud-starter-netflix-eureka-client application.yml
配置eureka.client.service-url.defaultZone
入口类增加@EnableEurekaClient

先启动注册中心,在启动客户端,访问 localhost:8761查看eureka注册中心,看到客户端注册

Eureka名词概念
Register - 服务注册, 向Eureka进行注册登记
Renew - 服务续约,30秒/次心跳包健康检查.90秒未收到剔除服务
Fetch Registries - 获取服务注册列表,获取其他微服务地址
Cancel - 服务下线, 某个微服务通知注册中心暂停服务
Eviction - 服务剔除,90秒未续约,从服务注册表进行剔除
Eureka自我保护机制
Eureka在运行期去统计心跳失败率在15分钟之内是否低于 85%
如果低于 85%，会将这些实例保护起来，让这些实例不会被剔除
关闭自我保护:eureka.服务实例.
enable-self-preservation: false
PS: 如非网络特别不稳定,建议关闭

Eureka高可用配置步骤
服务提供者defaultZone指向其他的Eureka
客户端添加所有Eureka 服务实例 URL

Actuator自动为微服务创建一系列的用于监控的端点
Actuator在SpringBoot自带，SpringCloud进行扩展
pom.xml依赖spring-boot-starter-actuator

RestTemplate + @LoadBalanced 显式调用
OpenFeign 隐藏微服务间通信细节

Ribbon是RestTemplate与OpenFeign的通信基础

Feign是一个开源声明式WebService客户端，用于简化服务通信
Feign采用“接口+注解”方式开发，屏蔽了网络通信的细节
OpenFeign是SpringCloud对Feign的增强，支持Spring MVC注解

1.新建Spring boot Web项目，application name 为 product-service
在pom.xml中引入依赖

spring-cloud-starter-alibaba-nacos-discovery作用为向Nacos server注册服务。
spring-cloud-starter-openfeign作用为实现服务调用。
2.修改application.yml配置文件

3.在启动类上添加@EnableDiscoveryClient、@EnableFeignClients注解

4.编写OrderClient Interface
注：/api/v1/order/test 会在下面order-service声明。
OrderClient.java

5.编写Controller和service
ProductController.java

ProductService.java

1.OpenFeign开启通信日志
基于SpringBoot的logback输出,默认debug级别
设置项：feign.client.config.微服务id.loggerLevel
微服务id：default代表全局默认配置
2.通信日志输出格式
NONE: 不输出任何通信日志
BASIC: 只包含URL、请求方法、状态码、执行时间
HEADERS：在BASIC基础上，额外包含请求与响应头
FULL：包含请求与响应内容最完整的信息
3.OpenFeign日志配置项
LoggerLevel开启通信日志
ConnectionTimeout与ReadTimeout
利用httpclient或okhttp发送请求

1.OpenFeign通信组件
OpenFeign基于JDK原生URLConnection提供Http通信
OpenFeign支持Apache HttpClient与Square OkHttp
SpringCloud按条件自动加载应用通信组件
2.应用条件
Maven引入feign-okhttp或者feign-httpclient依赖
设置feign.[httpclient|okhttp].enabled=true

POST方式传递对象使用@RequestBody注解描述参数
GET方式将对象转换为Map后利用@RequestParam注解描述

雪崩效应:服务雪崩效应产生与服务堆积在同一个线程池中，因为所有的请求都是同一个线程池进行处理，这时候如果在高并发情况下，所有的请求全部访问同一个接口,这时候可能会导致其他服务没有线程进行接受请求，这就是服务雪崩效应效应。
服务熔断:熔断机制目的为了保护服务，在高并发的情况下，如果请求达到一定极限(可以自己设置阔值)如果流量超出了设置阈值，让后直接拒绝访问，保护当前服务。使用服务降级方式返回一个友好提示，服务熔断和服务降级一起使用。

1.Hystrix熔断器
Hystrix（豪猪）是Netflix开源的熔断器组件，用于为微服务提供熔断机制预防雪崩，保护整体微服务架构的健康
2.Hystrix功能
预防微服务由于故障，请求长时间等待导致Web容器线程崩溃
提供故障备选方案，通过回退（fallback)机制提供”服务降级”
提供监控仪表盘,实时监控运行状态
3.Hystrix 熔断器工作原理

服务的健康状况 = 请求失败数 / 请求总数.
熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的.
当熔断器开关关闭时, 请求被允许通过熔断器. 如果当前健康状况高于设定阈值, 开关继续保持关闭. 如果当前健康状况低于
设定阈值, 开关则切换为打开状态.
当熔断器开关打开时, 请求被禁止通过.
当熔断器开关处于打开状态, 经过一段时间后, 熔断器会自动进入半开状态, 这时熔断器只允许一个请求通过. 当该请求调用
成功时, 熔断器恢复到关闭状态. 若该请求失败, 熔断器继续保持打开状态, 接下来的请求被禁止通过.
熔断器的开关能保证服务调用者在调用异常服务时, 快速返回结果, 避免大量的同步等待. 并且熔断器能在一段时间后继续侦测请求执行结果, 提供恢复服务调用的可能.
4.什么情况下会触发服务降级
FAILURE: 执行失败，抛出异常
TIMEOUT:执行超时（默认1秒）
SHORT_CIRCUITED:熔断器状态为Open
THREAD_POOL_REJECTED:线程池拒绝
SEMAPHORE_REJECTED:信号量拒绝
5.使用Hystrix步骤
1.引入pom文件依赖

6.OpenFeign与Hystrix整合
OpenFeign中使用Hystrix
OpenFeign内置Hystrix，feign.hystrix.enable开启即可
feign: hystrix: enabled: true
在@FeignClient增加fallback属性说明Fallback类
@FeignClient(name="message-service",fallback = MessageServiceFallback.class) public interface MessageService { @GetMapping("/sendsms") public CallbackResult sendSMS(@RequestParam("mobile") String mobile , @RequestParam("message") String message); }
Fallback类要实现相同接口，重写服务降级业务逻辑
@Component public class MessageServiceFallback implements MessageService { @Override public CallbackResult sendSMS(String mobile, String message) { return new CallbackResult("INVALID_SERVICE","消息服务暂时无法使用，短信发送失败"); } }
7.Hystrix超时设置
8.部署Hystrix Dashboard监控
Hystrix Client依赖hystrix-metrics-event-stream
Hystrix Client注册HystrixMetricsStreamServlet
监控微服务依赖spring-cloud-starter-netflix-hystrix-dashboard
监控微服务利用@EnableHystrixDashboard开启仪表盘
9.Hystrix熔断设置
产生熔断的条件:
当一个Rolling Window(滑动窗口）的时间内（默认：10秒），最近20次调用请求，请求错误率超过50%，则触发熔断5秒，期间快速失败。
TIPS: 如10秒内未累计到20次，则不会触发熔断
Hystrix熔断设置项:

统一访问出入口,微服务对前台透明
安全、过滤、流控等API管理功能
易于监控、方便管理

Netflix Zuul
Spring Cloud Gateway

Zuul 是Netflix开源的一个API网关, 核心实现是Servlet
Spring Cloud内置Zuul 1.x
Zuul 1.x 核心实现是Servlet，采用同步方式通信
Zuul 2.x 基于Netty Server，提供异步通信

认证和安全
性能监测
动态路由
负载卸载
静态资源处理
压力测试

Spring Cloud Gateway，是Spring“亲儿子”
Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式
Gateway基于Spring 5.0与Spring WebFlux开发，采用Reactor响应式设计

1.使用三部曲
依赖spring-cloud-starter-netflix-zuul
入口增加 @EnableZuulProxy
application.yml 增加微服务映射
2.微服务映射

Spring Cloud Zuul内置Hystrix
服务降级实现接口：FallbackProvider

1.微服务网关流量控制
微服务网关是应用入口，必须对入口流量进行控制
RateLimit是Spring Cloud Zuul的限流组件
https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit
RateLimit采用“令牌桶”算法实现限流
2.什么是令牌桶
1.Zuul的执行过程

2.Http请求生命周期

1.需要实现ZuulFilter接口
shouldFilter() - 是否启用该过滤器
filterOrder() - 设置过滤器执行次序
filterType() - 过滤器类型:pre|routing|post
run() - 过滤逻辑
2.Zuul内置过滤器

3.Zuul+JWT跨域身份验证

1.Spring Cloud Config
2.携程 Apollo
3.阿里巴巴Nacos

1.依赖"spring-cloud-starter-config"
2.删除application.yml,新建bootstrap.yml
3.配置"配置中心"服务地址与环境信息

1、微服务依赖"spring-boot-starter-actuator";
2、动态刷新类上增加@RefreshScope注解
3、通过/actuator/refresh刷新配置

1、通过加入重试机制、提高应用启动的可靠性;
2、重试触发条件1:配置中心无法与仓库正常通信
3、重试触发条件2:微服务无法配置中心正常通信

为什么在微服务架构下，服务网关和数据库不能部署在虚拟机上

最近开发了一基于springcloud的微服务架构的门户项目，因为客户对系统性能有要求，所以楼主对系统的一些api接口进行了大量压力测试。在压测过程中，发现接口的性能瓶颈之一是服务网关和数据库部署在虚机上，所以本文将分享内容分为两部分

性能压测思路是从软硬件负载 f5，nginx，到容器化平台k8s、docker、zuul网关，再到数据存储es、mysql、mongodb、redis，进行全面测试。

性能压测汇总

部分接口压测结果

其中值得关注的是，用一台zuul网关节点和一个业务节点压测空接口，发现一个有意思现象：

空接口压测不走zuul，一个业务节点tps能达到 32000， 走zuul网关，一个业务节点空接口tps只有11000，性能损耗64%。

当时就感觉zuul网关在我心中高大的形象碎了一地，但是没办法，性能不达标必须要优化。所以楼主查了很多资料，也问过一些docker和k8s的容器化平台大牛，总结出两点经验：

所以楼主向公司申请物理机，继续性能压测，当然这不是重点，重点是接下来要讲的：为什么服务网关和数据库不能部署到虚拟机上 。

虚拟机的特点

io开销

我们知道，不管虚机上部署了多少个应用，一旦涉及到数据的存储，如果采用虚机部署数据库，会带来不必要的网络io开销。因为虚拟机在调度大量物理的cpu和内存、特别是磁盘IO时，必须经过虚拟机和物理机两层网络io读写开销操作，是非常耗系统性能的。

一般情况下，使用虚拟机部署应用，其性能衰减约20%左右，这不是优化代码能解决的。

共享物理机资源

因为虚拟机在cpu资源、网络等方面共享物理机资源，虚拟机之间会存在竞争物理机资源，造成程序不稳定情况。

docker容器部署

更要命的是，如果数据库和zuul网关部署到容器（实质也是虚拟机）里，那么网络io读写变成docker（虚拟机）到虚机，再到物理机三层访问，无形之中又增加了io读写性能开销。尤其是对于请求吞吐量要求很高的服务网关zuul，是不能容忍的。

所以虚机对于IO密集型以及对延迟要求很高的业务场景不合适。

另外，早期的时候，作为一名架构师需要尽早的规划好服务网关和数据库的物理部署方式以及软硬件性能要求。

微服务网关层

API网关是所有客户端的统一入口。路由服务可以被用于很多目的，例如日志、限流、认证，从而做到应用无感知。API网关对于任意一种处理请求有两种方式处理。一部分请求只要简单路由到相应的服务；还有一些请求需要拆分到多个服务。API Gateway是实现微服务重要的组件之一，常用的网关Zuul, Nginx, Spring Cloud, Linkerd，Envoy，UnderTow。

为了评估API网关各自的性能，我们使用Apache的ab作为压测工具。（另外还可以用Gatling做性能测试）

测试结果和心得如下： 关于微服务网关压力和微服务网关权限控制的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关压力的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务网关权限控制、微服务网关压力的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。