微服务（六）网关zuul

1、网关zuul

微服务基本模块已经有了，也可以做微服务了。但完成一个复杂的业务，可能需要多个微服务合作来完成，比如下单，需要用户服务，支付服务，地图服务，订单服务。一般是我们对外服务的窗口，进行服务内外隔离。一般微服务都在内网，不做安全验证，

就好像：很多明星，可以独立开演唱会（独立提供服务）。也可以去春晚（微服务群提供服务）。但一台春晚就不能让 观众一个一个调用了。观众要调用，需要检票啥的，检票就类似于网关，进来之后，界面随便看，不会说你 看个小品，还需要再检票。

微服务没有网关，会有下面的问题：

1. 客户端请求多个微服务，增加了客户端复杂性，每个微服务都要做用户认证，限流等，避免和多个微服务打交道的复杂性。

2. 有跨域问题，不在同一个域。

3. 认证复杂，每个服务都要独立认证，服务要求的权限不一致。

4. 难以重构。因为微服务被客户端调用着，重构难以实施。

网关是介于客户端（外部调用方比如app，h5）和微服务的中间层。

Zuul是Netflix开源的微服务网关，核心是一系列过滤器。这些过滤器可以完成以下功能。

1. 是所有微服务入口，进行分发。
2. 身份认证与安全。识别合法的请求，拦截不合法的请求。
3. 监控。在入口处监控，更全面。
4. 动态路由。动态将请求分发到不同的后端集群。
5. 压力测试。可以逐渐增加对后端服务的流量，进行测试。
6. 负载均衡。也是用ribbon。
7. 限流（望京超市）。比如我每秒只要1000次，10001次就不让访问了。
8. 服务熔断

网关和服务的关系：演员和剧场检票人员的关系。
zuul默认集成了：ribbon和hystrix。

建一个新的项目，选择zuul与eureka client。
添加properties

eureka.client.service-url.defaultZone=http://euk1.com:7001/eureka/
spring.application.name=zuulserver
server.port=80

在启动类加上注解

@EnableZuulProxy

测试访问
网关会将服务名转换成具体服务的ip和端口，实际进行访问。

我们zuul启动的80端口，而userconsumer启动的是90端口。先看下访问90端口。

再看下访问80端口，并访问consumer。

下面是请求打过来的整体流程图

根据规则将请求中转到需要的服务。
以代理模式或者隧道模式处理用户的所有请求，访问后面的服务都需要过一遍网关，根据url定位具体的资源这就是路由，

降级可以前置，在网关阶段，后台的服务则不可以调起了。
这些都是基于隧道模式的网关。这种网关叫做业务网关。Zuul基于filter的，性能肯定不太行，（吞吐量不行）。但是可以将serlet状态为无状态（JWT），只做路由转发；优化线程，异步。
Nginx也可以做这些事情，kong也是基于nginx。
一般可以写请求接入进来，而读请求则用另外一种模式，加个缓存。

除了隧道模式，还有一种是路由模式DR。用户与网关建立请求后，直接将请求给后台（穿过去了），然后响应也直接给用户了。网关作为透明代理，不介入任何事。但是上面说的所有的功能都干不了。

这种·DR模型，性能来讲，最好。

2、负载均衡

直接启动2台provider，2台consumer。
负载均衡，provider失败时：

刷新一下，可以看到consumer层由负载均衡，但是provide层报错显示了哈哈。

Provider成功时：


查看路由端点，需要加入actuator的依赖。