为什么要使用微服务网关
不同的微服务一般会经过不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求。
如果让客户端直接与各个微服务通信，会有以下的问题：
- 客户端会多次请求不同的微服务，增加了客户端的复杂性。
- 存在跨域请求，在一定场景下处理相对复杂。
- 认证复杂，每个服务都需要独立认证。
- 难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务整个成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。
- 某些微服务可能使用了防火墙/浏览器不友好协议，直接访问会有一定的困难。
以上问题可借助微服务网管解决。微服务网关是介于客户端和服务器之间的中间层，所有外部请求都会先经过微服务网关。
如图，微服务网关封装了应用程序的内部结构，客户端只需跟网关交互，而无需直接调用特定微服务的接口。这样，开发就可以简化。不仅如此，使用微服务网关还有以下优点：
- 易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。
- 易于认证。可在微服务网关上进行认证，然后再将请求转发到后端的微服务，而无需再每个微服务中进行认证。
- 减少了客户端与各个微服务之间的交互次数。
Zuul简介
Zuul是Netflix开源的微服务网关，核心是一系列的过滤器，这些过滤器可以完成以下功能。
身份认证与安全：识别每个资源的验证需求，并拒绝那些与要求不符的请求。
审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
动态路由：动态地请求路由到不同的后端集群。
压力测试：逐渐增加执行集群的流量，以了解性能。
负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。
静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群。
多区域弹性：跨越AWS Region进行请求路由，旨在实现ELB（Elastic Load Balancing）使用多样化，以及让系统的边缘更贴近系统的使用者。
编写Zuul微服务网关
1.pom.xml添加maven依赖
<dependency>
<groupId>org.springframewor.cloud</groupId>
<artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
2.在启动类上添加注解@EnableZuulProxy，声明一个Zuul代理。该代理使用Ribbon来定位注册在Eureka Server中的微服务；同时，该代理还整合了Hystrix，从而实现了容错，所有经过Zuul的请求都会再Hystrix命令中执行。
3.编写配置文件application.yml
这样，一个简单的微服务网关就编写完成了。从配置可知，此时仅是添加了Zuul的依赖，并将注册到Eureka Server上。
路由配置详解
上边已经编写了一个简单的Zuul网关，并让该网关代理了所有注册Eureka Server的微服务。但在现实中可能让Zuul代理部分微服务，又或者需要对URL进行更加精确的控制。
Zuul的路由配置非常灵活、简单
1.自定义指定微服务的访问路径。
配置zuul.routes。指定微服务serviceId = 指定路径即可。例如：
zuul: routes: microservice-provider-user:/user/**
这样设置，microservice-provider-user微服务就会被映射到/user/**路径。
2.忽略指定微服务。
忽略服务非常简单，可以使用zuul.ignore-services配置要忽略的服务，多个用逗号分隔
zuul:
ignored-services:microservice-provider-user,microservice-consumer-movie
这样就可让Zuul忽略microservice-provider-user和microservice-consumer-movie微服务，只代理其他微服务。
3.忽略所有微服务，只路由指定微服务