Zuul

前言 在微服务架构中，由于系统和服务的细分，导致系统结构变得非常复杂， 为了跨平台，为了统一集中管理api，同时为了不暴露后置服务。甚至有时候需要对请求进行一些安全、负载均衡、限流、熔断、灰度等中间操作，基于此类种种的客观需求一个类似综合前置的系统就产生了，这就是API网关（API Gateway）。API网关作为分散在各个业务系统微服务的API聚合点和统一接入点，外部请求通过访问这个接入点，即可访问内部所有的REST API服务。目前常用的微服务网关有zuul、gateway，今天来简单介绍一下另一种选择——Kong 。说到Kong可能对大家有点陌生，我们来先了解下另一种不陌生的中间件——OpenResty。 OpenResty OpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。因此，我们可以做出各种符合我们需要的网关策略的Lua脚本，以其为基础构建高性能的网关系统。 Kong Kong基于OpenResty，是一个云原生、快速、可扩展、分布式的Api 网关。继承了OpenResty的高性能、易扩展性等特点。Kong通过简单的增加机器节点，可以很容易的水平扩展。同时功能插件化

关于Zuul前2篇 1. 分布式04-Spring Cloud Zuul Api网关 一 2. 分布式04-Spring Cloud Zuul 二 Zuul拦截器 回退机制只有针对于服务出现故障，Zuul做的一些后续操作。 代码 package com.cloud.config ; import org.springframework.cloud.netflix.zuul.filters.route.FallbackProvider ; import org.springframework.http.HttpHeaders ; import org.springframework.http.HttpStatus ; import org.springframework.http.MediaType ; import org.springframework.http.client.ClientHttpResponse ; import org.springframework.stereotype. Component ; import java.io.ByteArrayInputStream ; import java.io.IOException ; import java.io.InputStream ; import java.nio.charset.Charset ;

Spring Cloud 整合Zuul见上一篇 https://my.oschina.net/u/4039389/blog/3221637 1.拦截器类型 /** * “pre” 预过滤器 - 在路由分发一个请求之前调用。 * “route” 路由过滤器 - 用于路由请求时调用。 * “post” 后过滤器 - 在路由分发一个请求后调用。 * “error” 错误过滤器 - 在处理请求时发生错误时调用 */ 2.编写拦截器 @Component public class PreFilter extends ZuulFilter { @Override public String filterType () { return "pre" ; } @Override public int filterOrder () { return 0 ; } @Override public boolean shouldFilter () { return true; } @Override public Object run () throws ZuulException { RequestContext ctx = RequestContext. getCurrentContext () ; HttpServletRequest request = ctx.getRequest() ;

1.什么是 Zuul zuul 是netflix开源的一个API Gateway 服务器, 本质上是一个web servlet应用。 熟悉Nginx的朋友可以把zuul理解为一个Nginx，个人认为2者主要在使用区别上，Zuul主要是处理与服务之间调用的，而Nginx主要处理与服务器之间的调用和一些静态文件的访问支持。 2.搭建Zuul应用 引入maven库 compile 'org.springframework.cloud:spring-cloud-starter-zuul:1.4.4.RELEASE' compile( 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client' ) 配置application.properties server.port = 12003 eureka.instance.hostname = localhost eureka.client.service-url.defaultZone = http://${ eureka.instance.hostname }:12000/eureka/#注册到eureka eureka.client.healthcheck.enabled = true spring.application.name = eureka-Zuul

什么是 Zuul 　　 　　Zuul 是从设备和网站到应用程序后端的所有请求的前门。作为边缘服务应用程序，Zuul 旨在实现动态路由，监视，弹性和安全性。Zuul 包含了对请求的 路由 和 过滤 两个最主要的功能。 　　Zuul 是 Netflix 开源的微服务网关，它可以和 Eureka、Ribbon、Hystrix 等组件配合使用。Zuul 的核心是一系列的过滤器，这些过滤器可以完成以下功能： 身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求 审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产试图 动态路由：动态地将请求路由到不同的后端集群 压力测试：逐渐增加只想集群的流量，以了解性能 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求 静态响应处理：在边缘位置直接建立部份响应，从而避免其转发到内部集群\ 多区域弹性：跨越AWS Region进行请求路由，旨在实现ELB（Elastic Load Balancing）使用的多样化，以及让系统的边缘更贴近系统的使用者 　　 什么是服务网关 　　 　　API Gateway（APIGW / API 网关），顾名思义，是出现在系统边界上的一个面向 API 的、串行集中式的强管控服务，这里的边界是企业 IT 系统的边界，可以理解为 企业级应用防火墙 ，主要起到 隔离外部访问与内部系统的作用

我的Spring Cloud（一）：微服务概述 我的Spring Cloud（二）：Eureka Server注册中心 我的Spring Cloud（三）：Eureka Client 服务提供者 我的Spring Cloud（四）：RestTemplate的使用 我的Spring Cloud（五）：Zuul 服务网关 我的Spring Cloud（六）：Ribbon 负载均衡 我的Spring Cloud（七）：Feign 声明式接口调用 我的Spring Cloud（八）：Hystrix 容错机制与数据监控 我的Spring Cloud（九）：Config 配置中心 我的Spring Cloud（十）：Zipkin 服务跟踪 来源： oschina 链接： https://my.oschina.net/qq785482254/blog/3217701

在启动应用时会发现在控制台打印的日志中出现了两个路径为 {[/error]} 的访问地址，当系统中发送异常错误时，Spring Boot 会根据请求方式分别跳转到以 JSON 格式或以界面显示的 /error 地址中显示错误信息。 2018-12-18 09:36:24.627 INFO 19040 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped "{[/error]}" ... 2018-12-18 09:36:24.632 INFO 19040 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped "{[/error],produces=[text/html]}" ... 默认异常处理 使用 AJAX 方式请求时返回的 JSON 格式错误信息。 { "timestamp": "2018-12-18T01:50:51.196+0000" , "status": 404 , "error": "Not Found" , "message": "No handler found for GET /err404" , "path": "/err404" } 使用浏览器请求时返回的错误信息界面。 自定义异常处理 引入依赖 <

研究了好久的springCloud微服务架构，在这里整理总结一下，做个梳理和备忘。 这里只记录一些个人认为比较重要，但是网上基本没有什么明确答案的问题。像什么注册中心什么的就不总结了，网上一大堆。 先从网关开始说吧，网关也有很多东西，这里先说一下网关和nginx的整合。 1、nginx在这里的作用： 在这个方案中，通过nginx可以做前后端分离，静态化，对网关做高可用和负载均衡。提供统一的404，500页面。 2、网关zuul zuul本身也是一个反向代理，也可以对其管理的微服务做负载均衡。同样，zuul也可以做一些统一的处理，可以做熔断，统一的错误处理，统一的拦截器，还可以做微服务的聚合处理。这些细节就先不说了。 好了，两者的职责确立完毕，开始看看如何去做整合。 一、思路 假设：nginx服务器地址为192.168.2.104 zuul的地址为192.168.160.66，端口号为5555 oauth2认证服务器微服务地址为192.168.2.104，端口号为9999，服务名为sso zuul为oauth2认证服务器设置统一入口为api-auth 我们希望把192.168.2.104:9999/sso/code/image的地址代理到192.168.2.104/api-auth/code/image上并且经过zuul 做法为：nginx将zuul设置的代理地址(api-auth

3 月，跳不动了？>>> 一、什么是springcloud，有什么作用 　　Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。 Spring Cloud是一个全家桶式的技术栈，包含了很多组件。实例 www.b123.com 。先从其最核心的几个组件入手，来剖析一下其底层的工作原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul这几个组件。 Eureka Eureka是微服务架构中的注册中心，专门负责服务的注册与发现。库存服务、仓储服务、积分服务中都有一个Eureka Client组件，Eureka Client这个组件专门负责将这个服务的信息注册到Eureka Server中（就是告诉Eureka Server，自己在哪台机器上，监听着哪个端口）。而Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。 订单服务里也有一个Eureka Client组件，这个Eureka Client组件会找Eureka Server问一下：库存服务在哪台机器啊？监听着哪个端口啊？仓储服务呢？积分服务呢

不同的微服务一般有不同的网络地址，而外部的客户端可能需要调用多个服务的接口才能完成一个业务需求。比如一个电影购票的收集APP,可能回调用电影分类微服务，用户微服务，支付微服务等。如果客户端直接和微服务进行通信，会存在一下问题： # 客户端会多次请求不同微服务，增加客户端的复杂性 # 存在跨域请求，在一定场景下处理相对复杂 # 认证复杂，每一个服务都需要独立认证 # 难以重构，随着项目的迭代，可能需要重新划分微服务，如果客户端直接和微服务通信，那么重构会难以实施 # 某些微服务可能使用了其他协议，直接访问有一定困难 上述问题，都可以借助微服务网关解决。微服务网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过微服务网关。 Zuul是Netflix开源的微服务网关，他可以和Eureka,Ribbon,Hystrix等组件配合使 用。Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能： # 身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求 #审查与监控： ## 动态路由：动态将请求路由到不同后端集群 # 压力测试：逐渐增加指向集群的流量，以了解性能 # 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求 # 静态响应处理：边缘位置进行响应，避免转发到内部集群 # 多区域弹性：跨域AWS Region进行请求路由，旨在实现ELB