Zuul是spring cloud中的微服务网关。网关：是一个网络整体零碎中的前置门户入口。申请首先通过网关，进行门路的路由，定位到具体的服务节点上。
Zuul是一个微服务网关，首先是一个微服务。也是会在Eureka注册核心中进行服务的注册和发现。也是一个网关，申请应该通过Zuul来进行路由。
Zuul网关不是必要的。是举荐应用的。
应用Zuul，个别在微服务数量较多（多于10个）的时候举荐应用，对服务的治理有严格要求的时候举荐应用，当微服务权限要求严格的时候举荐应用。
一、Zuul网关的作用
网关有以下几个作用：
- 对立入口：未全副为服务提供一个惟一的入口，网关起到内部和外部隔离的作用，保障了后盾服务的安全性。
- 鉴权校验：辨认每个申请的权限，回绝不符合要求的申请。
- 动静路由：动静的将申请路由到不同的后端集群中。
- 缩小客户端与服务端的耦合：服务能够独立倒退，通过网关层来做映射。
二、Zuul网关的利用
- 1、网关拜访形式
通过zuul拜访服务的，URL地址默认格局为：http://zuulHostIp:port/要拜访的服务名称/服务中的URL
服务名称：properties配置文件中的spring.application.name。
服务的URL：就是对应的服务对外提供的URL门路监听。
- 2、网关依赖注入
<!-- spring cloud Eureka Client 启动器 --><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId></dependency><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artifactId></dependency><!-- zuul网关的重试机制，不是应用ribbon内置的重试机制 是借助spring-retry组件实现的重试 开启zuul网关重试机制须要减少下述依赖 --><dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId></dependency>- 3、网关启动器
/** * @EnableZuulProxy - 开启Zuul网关。 * 以后利用是一个Zuul微服务网关。会在Eureka注册核心中注册以后服务。并发现其余的服务。 * Zuul须要的必要依赖是spring-cloud-starter-zuul。 */@SpringBootApplication@EnableZuulProxypublic class ZuulApplication { public static void main(String[] args) { SpringApplication.run(ZuulApplication.class, args); }}- 4、网关全局变量配置
4.1 URL门路匹配
# URL pattern# 应用门路形式匹配路由规定。# 参数key构造：zuul.routes.customName.path=xxx# 用于配置门路匹配规定。# 其中customName自定义。通常应用要调用的服务名称，不便前期治理# 可应用的通配符有： * ** ?# ? 单个字符# * 任意多个字符，不蕴含多级门路# ** 任意多个字符，蕴含多级门路zuul.routes.eureka-application-service.path=/api/**# 参数key构造：zuul.routes.customName.url=xxx# url用于配置合乎path的申请门路路由到的服务地址。zuul.routes.eureka-application-service.url=http://127.0.0.1:8080/4.2 服务名称匹配
# service id pattern 通过服务名称路由# key构造 ：zuul.routes.customName.path=xxx# 门路匹配规定zuul.routes.eureka-application-service.path=/api/**# key构造 ：zuul.routes.customName.serviceId=xxx# serviceId用于配置合乎path的申请门路路由到的服务名称。zuul.routes.eureka-application-service.serviceId=eureka-application-service服务名称匹配也能够应用简化的配置：
# simple service id pattern 简化配置计划# 如果只配置path，不配置serviceId。则customName相当于服务名称。# 合乎path的申请门路间接路由到customName对应的服务上。zuul.routes.eureka-application-service.path=/api/**4.3 路由排除配置
# ignored service id pattern# 配置不被zuul治理的服务列表。多个服务名称应用逗号','分隔。# 配置的服务将不被zuul代理。zuul.ignored-services=eureka-application-service# 此形式相当于给所有新发现的服务默认排除zuul网关拜访形式，只有配置了路由网关的服务才能够通过zuul网关拜访# 通配形式配置排除列表。zuul.ignored-services=*# 应用服务名称匹配规定配置路由列表，相当于只对已配置的服务提供网关代理。zuul.routes.eureka-application-service.path=/api/**# 通配形式配置排除网关代理门路。所有合乎ignored-patterns的申请门路都不被zuul网关代理。zuul.ignored-patterns=/**/test/**zuul.routes.eureka-application-service.path=/api/**4.4 路由前缀配置
# prefix URL pattern 前缀路由匹配# 配置申请门路前缀，所有基于此前缀的申请都由zuul网关提供代理。zuul.prefix=/api# 应用服务名称匹配形式配置申请门路规定。# 这里的配置将为：http://ip:port/api/appservice/**的申请提供zuul网关代理，能够将要拜访服务进行前缀分类。# 并将申请路由到服务eureka-application-service中。zuul.routes.eureka-application-service.path=/appservice/**- 5 Zuul网关配置总结
网关配置形式有多种，默认、URL、服务名称、排除|疏忽、前缀。
网关配置没有优劣好坏，应该在不同的状况下抉择适合的配置计划。
zuul网关其底层应用ribbon来实现申请的路由，并内置Hystrix，可选择性提供网关fallback逻辑。应用zuul的时候，并不举荐应用Feign作为application client端的开发实现。毕竟Feign技术是对ribbon的再封装，应用Feign自身会进步通信耗费，升高通信效率，只在服务互相调用的时候应用Feign来简化代码开发就够了。而且商业开发中，应用Ribbon+RestTemplate来开发的比例更高。
三、Zuul网关过滤器
Zuul中提供了过滤器定义，能够用来过滤代理申请，提供额定性能逻辑。如：权限验证，日志记录等。
Zuul提供的过滤器是一个父类。父类是ZuulFilter。通过父类中定义的形象办法filterType，来决定以后的Filter品种是什么。有前置过滤、路由后过滤、后置过滤、异样过滤。
- 前置过滤：是申请进入Zuul之后，立即执行的过滤逻辑。
- 路由后过滤：是申请进入Zuul之后，并Zuul实现了申请路由后执行的过滤逻辑，路由后过滤，是在近程服务调用之前过滤的逻辑。
- 后置过滤：近程服务调用完结后执行的过滤逻辑。
- 异样过滤：是任意一个过滤器产生异样或近程服务调用无后果反馈的时候执行的过滤逻辑。无后果反馈，就是近程服务调用超时。
3.1 过滤器实现形式
继承父类ZuulFilter。在父类中提供了4个形象办法，别离是：filterType, filterOrder, shouldFilter, run。其性能别离是：
filterType：办法返回字符串数据，代表以后过滤器的类型。可选值有-pre, route, post, error。
- pre - 前置过滤器，在申请被路由前执行，通常用于解决身份认证，日志记录等；
- route - 在路由执行后，服务调用前被调用；
- error - 任意一个filter产生异样的时候执行或近程服务调用没有反馈的时候执行（超时），通常用于解决异样；
- post - 在route或error执行后被调用，个别用于收集服务信息，统计服务性能指标等，也能够对response后果做非凡解决。
filterOrder：返回int数据，用于为同filterType的多个过滤器定制执行程序，返回值越小，执行程序越优先。
shouldFilter：返回boolean数据，代表以后filter是否失效。
run：具体的过滤执行逻辑。如pre类型的过滤器，能够通过对申请的验证来决定是否将申请路由到服务上；如post类型的过滤器，能够对服务响应后果做加工解决（如为每个响应减少footer数据）。Java知音公众号内回复“后端面试”， 送你一份Java面试题宝典
3.2 过滤器的生命周期
3.3 代码示例
/** * Zuul过滤器，必须继承ZuulFilter父类。 * 以后类型的对象必须交由Spring容器治理。应用@Component注解形容。 * 继承父类后，必须实现父类中定义的4个形象办法。 * shouldFilter、 run、 filterType、 filterOrder */@Componentpublic class LoggerFilter extends ZuulFilter { private static final Logger logger = LoggerFactory.getLogger(LoggerFilter.class); /** * 返回boolean类型。代表以后filter是否失效。 * 默认值为false。 * 返回true代表开启filter。 */ @Override public boolean shouldFilter() { return true; } /** * run办法就是过滤器的具体逻辑。 * return 能够返回任意的对象，以后实现疏忽。（spring-cloud-zuul官网解释） * 间接返回null即可。 */ @Override public Object run() throws ZuulException { // 通过zuul，获取申请上下文 RequestContext rc = RequestContext.getCurrentContext(); HttpServletRequest request = rc.getRequest(); logger.info("LogFilter1.....method={},url={}", request.getMethod(),request.getRequestURL().toString()); // 能够记录日志、鉴权，给保护人员记录提供定位帮助、统计性能 return null; } /** * 过滤器的类型。可选值有： * pre - 前置过滤 * route - 路由后过滤 * error - 异样过滤 * post - 近程服务调用后过滤 */ @Override public String filterType() { return "pre"; } /** * 同品种的过滤器的执行程序。 * 依照返回值的天然升序执行。 */ @Override public int filterOrder() { return 0; }}四、Zuul网关的容错（与Hystrix的无缝联合）
在spring cloud中，Zuul启动器中蕴含了Hystrix相干依赖，在Zuul网关工程中，默认是提供了Hystrix Dashboard服务监控数据的(hystrix.stream)，然而不会提供监控面板的界面展现。能够说，在spring cloud中，zuul和Hystrix是无缝联合的。
4.1 Zuul中的服务降级解决
在Edgware版本之前，Zuul提供了接口ZuulFallbackProvider用于实现fallback解决。从Edgware版本开始，Zuul提供了ZuulFallbackProvider的子接口FallbackProvider来提供fallback解决。
Zuul的fallback容错解决逻辑，只针对timeout异样解决，当申请被Zuul路由后，只有服务有返回（包含异样），都不会触发Zuul的fallback容错逻辑。
因为对于Zuul网关来说，做申请路由散发的时候，后果由近程服务运算的。那么近程服务反馈了异样信息，Zuul网关不会解决异样，因为无奈确定这个谬误是否是利用实在想要反馈给客户端的。Java知音公众号内回复“后端面试”， 送你一份Java面试题宝典
4.2 代码示例
/** * 如果须要在Zuul网关服务中减少容错解决fallback，须要实现接口ZuulFallbackProvider * spring-cloud框架，在Edgware版本(包含)之后，申明接口ZuulFallbackProvider过期生效， * 提供了新的ZuulFallbackProvider的子接口 - FallbackProvider * 在老版本中提供的ZuulFallbackProvider中，定义了两个办法。 * - String getRoute() * 以后的fallback容错解决逻辑解决的是哪一个服务。能够应用通配符‘*’代表为全副的服务提供容错解决。 * 如果只为某一个服务提供容错，返回对应服务的spring.application.name值。 * - ClientHttpResponse fallbackResponse() * 当服务产生谬误的时候，如何容错。 * 新版本中提供的FallbackProvider提供了新的办法。 * - ClientHttpResponse fallbackResponse(Throwable cause) * 如果应用新版本中定义的接口来做容错解决，容错解决逻辑，只运行子接口中定义的新办法。也就是有参办法。 * 是为近程服务产生异样的时候，通过异样的类型来运行不同的容错逻辑。 */@Componentpublic class TestFallBbackProvider implements FallbackProvider { /** * return - 返回fallback解决哪一个服务。返回的是服务的名称 * 举荐 - 为指定的服务定义个性化的fallback逻辑。 * 举荐 - 提供一个解决所有服务的fallback逻辑。 * 益处 - 服务某个服务产生超时，那么指定的fallback逻辑执行。如果有新服务上线，未提供fallback逻辑，有一个通用的。 */ @Override public String getRoute() { return "eureka-application-service"; } /** * fallback逻辑。在晚期版本中应用。 * Edgware版本之后，ZuulFallbackProvider接口过期，提供了新的子接口FallbackProvider * 子接口中提供了办法ClientHttpResponse fallbackResponse(Throwable cause)。 * 优先调用子接口新定义的fallback解决逻辑。 */ @Override public ClientHttpResponse fallbackResponse() { System.out.println("ClientHttpResponse fallbackResponse()"); List<Map<String, Object>> result = new ArrayList<>(); Map<String, Object> data = new HashMap<>(); data.put("message", "服务正忙，请稍后重试"); result.add(data); ObjectMapper mapper = new ObjectMapper(); String msg = ""; try { msg = mapper.writeValueAsString(result); } catch (JsonProcessingException e) { msg = ""; } return this.executeFallback(HttpStatus.OK, msg, "application", "json", "utf-8"); } /** * fallback逻辑。优先调用。能够依据异样类型动静决定解决形式。 */ @Override public ClientHttpResponse fallbackResponse(Throwable cause) { System.out.println("ClientHttpResponse fallbackResponse(Throwable cause)"); if(cause instanceof NullPointerException){ List<Map<String, Object>> result = new ArrayList<>(); Map<String, Object> data = new HashMap<>(); data.put("message", "网关超时，请稍后重试"); result.add(data); ObjectMapper mapper = new ObjectMapper(); String msg = ""; try { msg = mapper.writeValueAsString(result); } catch (JsonProcessingException e) { msg = ""; } return this.executeFallback(HttpStatus.GATEWAY_TIMEOUT, msg, "application", "json", "utf-8"); }else{ return this.fallbackResponse(); } } /** * 具体处理过程。 * @param status 容错解决后的返回状态，如200失常GET申请后果，201失常POST申请后果，404资源找不到谬误等。 * 应用spring提供的枚举类型对象实现。HttpStatus * @param contentMsg 自定义的响应内容。就是反馈给客户端的数据。 * @param mediaType 响应类型，是响应的主类型， 如：application、text、media。 * @param subMediaType 响应类型，是响应的子类型， 如：json、stream、html、plain、jpeg、png等。 * @param charsetName 响应后果的字符集。这里只传递字符集名称，如：utf-8、gbk、big5等。 * @return ClientHttpResponse 就是响应的具体内容。 * 相当于一个HttpServletResponse。 */ private final ClientHttpResponse executeFallback(final HttpStatus status, String contentMsg, String mediaType, String subMediaType, String charsetName) { return new ClientHttpResponse() { /** * 设置响应的头信息 */ @Override public HttpHeaders getHeaders() { HttpHeaders header = new HttpHeaders(); MediaType mt = new MediaType(mediaType, subMediaType, Charset.forName(charsetName)); header.setContentType(mt); return header; } /** * 设置响应体 * zuul会将本办法返回的输出流数据读取，并通过HttpServletResponse的输入流输入到客户端。 */ @Override public InputStream getBody() throws IOException { String content = contentMsg; return new ByteArrayInputStream(content.getBytes()); } /** * ClientHttpResponse的fallback的状态码 返回String */ @Override public String getStatusText() throws IOException { return this.getStatusCode().getReasonPhrase(); } /** * ClientHttpResponse的fallback的状态码 返回HttpStatus */ @Override public HttpStatus getStatusCode() throws IOException { return status; } /** * ClientHttpResponse的fallback的状态码 返回int */ @Override public int getRawStatusCode() throws IOException { return this.getStatusCode().value(); } /** * 回收资源办法 * 用于回收以后fallback逻辑开启的资源对象的。 * 不要敞开getBody办法返回的那个输出流对象。 */ @Override public void close() { } }; }}五、Zuul网关的限流爱护
Zuul网关组件也提供了限流爱护。当申请并发达到阀值，主动触发限流爱护，返回谬误后果。只有提供error错误处理机制即可。
Zuul的限流爱护须要额定依赖spring-cloud-zuul-ratelimit组件。
<dependency> <groupId>com.marcosbarbero.cloud</groupId> <artifactId>spring-cloud-zuul-ratelimit</artifactId> <version>1.3.4.RELEASE</version></dependency>5.1 全局限流配置
应用全局限流配置，zuul会对代理的所有服务提供限流爱护。
# 开启限流爱护zuul.ratelimit.enabled=true# 60s内申请超过3次，服务端就抛出异样，60s后能够恢复正常申请zuul.ratelimit.default-policy.limit=3zuul.ratelimit.default-policy.refresh-interval=60# 针对IP进行限流，不影响其余IPzuul.ratelimit.default-policy.type=origin5.2 部分限流配置
应用部分限流配置，zuul仅针对配置的服务提供限流爱护。
# 开启限流爱护zuul.ratelimit.enabled=true# hystrix-application-client服务60s内申请超过3次，服务抛出异样。zuul.ratelimit.policies.hystrix-application-client.limit=3zuul.ratelimit.policies.hystrix-application-client.refresh-interval=60# 针对IP限流。zuul.ratelimit.policies.hystrix-application-client.type=origin5.3 限流参数简介
六、Zuul网关性能调优：网关的两层超时调优
应用Zuul的spring cloud微服务结构图：
从上图中能够看出。整体申请逻辑还是比较复杂的，在没有zuul网关的状况下，app client申请app service的时候，也有申请超时的可能。那么当减少了zuul网关的时候，申请超时的可能就更显著了。
当申请通过zuul网关路由到服务，并期待服务返回响应，这个过程中zuul也有超时管制。zuul的底层应用的是Hystrix+ribbon来实现申请路由。构造如下：
zuul中的Hystrix外部应用线程池隔离机制提供申请路由实现，其默认的超时时长为1000毫秒。ribbon底层默认超时时长为5000毫秒。如果Hystrix超时，间接返回超时异样。如果ribbon超时，同时Hystrix未超时，ribbon会主动进行服务集群轮询重试，直到Hystrix超时为止。如果Hystrix超时时长小于ribbon超时时长，ribbon不会进行服务集群轮询重试。
那么在zuul中可配置的超时时长就有两个地位：Hystrix和ribbon。具体配置如下：
# 开启zuul网关重试zuul.retryable=true# hystrix超时工夫设置# 线程池隔离，默认超时工夫1000mshystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=8000# ribbon超时工夫设置：倡议设置比Hystrix小# 申请连贯的超时工夫: 默认5000msribbon.ConnectTimeout=5000# 申请解决的超时工夫: 默认5000msribbon.ReadTimeout=5000# 重试次数：MaxAutoRetries示意拜访服务集群下原节点（同门路拜访）；MaxAutoRetriesNextServer示意拜访服务集群下其余节点（换台服务器）ribbon.MaxAutoRetries=1ribbon.MaxAutoRetriesNextServer=1# 开启重试ribbon.OkToRetryOnAllOperations=trueSpring-cloud中的zuul网关重试机制是应用spring-retry实现的。工程必须依赖下述资源：
<dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId></dependency>写在最初
欢送大家关注我的公众号【惊涛骇浪如码】，海量Java相干文章，学习材料都会在外面更新，整顿的材料也会放在外面。
感觉写的还不错的就点个赞，加个关注呗！点关注，不迷路，继续更新！！！