SpringCloud系列八：Zuul网关服务

一. 为什么需要网关呢？

第一，我们知道我们要进入一个服务本身，很明显我们没有特别好的办法，直接输入IP地址+端口号，我们知道这样的做法很糟糕的，这样的做法大有问题，首先暴露了我们实体机器的IP地址，别人一看你的IP地址就知道服务部署在哪里，让别人很方便的进行攻击操作。

 

第二，我们这么多服务，我们是不是要挨个调用它呀，我们这里假设做了个权限认证，我们每一个客户访问的都是跑在不同机器上的不同的JVM上的服务程序，我们每一个服务都需要一个服务认证，这样做烦不烦呀，明显是很烦的。

 

那么我们这时候面临着这两个极其重要的问题，这时我们就需要一个办法解决它们。首先，我们看IP地址的暴露和IP地址写死后带来的单点问题，我是不是对这么服务本身我也要动态的维护它服务的列表呀，我需要调用这服务本身，是不是也要一个负载均衡一样的玩意，

 

还有关于IP地址暴露的玩意，我是不是需要做一个代理呀，像Nginx的反向代理一样的东西，还有这玩意上部署公共的模块，比如所有入口的权限校验的东西。因此我们现在需要Zuul API网关。它就解决了上面的问题，你想调用某个服务，它会给你映射，把你服务的IP地址映射成

 

某个路径，你输入该路径，它匹配到了，它就去替你访问这个服务，它会有个请求转发的过程，像Nginx一样，服务机器的具体实例，它不会直接去访问IP，它会去Eureka注册中心拿到服务的实例ID，即服务的名字。我再次使用客户端的负载均衡ribbon访问其中服务实例中的一台。

 

API网关主要为了服务本身对外的调用该怎么调用来解决的，还有解决权限校验的问题，你可以在这里整合调用一系列过滤器的，例如整合shiro,springsecurity之类的东西。

 

Zuul的原理图如下：

二  应用场景

说了这么多，我们来总结一下网关的应用场景：

(1)黑白名单：实现通过IP地址控制禁止访问网关功能，此功能是应用层面控制实现，再往前也可以通过网络传输方面进行控制访问。

(2)日志：实现访问日志的记录，可用于分析访问、处理性能指标，同时将分析结果支持其他模块功能应用。

(3)协议适配：实现通信协议校验、适配转换的功能。

(4)身份认证：负责网关访问身份认证验证，此模块与“访问认证中心”通信，实际认证业务逻辑交移“访问认证中心”处理。

(5)计流限流：实现微服务访问流量计算，基于流量计算分析进行限流，可以定义多种限流规则。

(6)路由：路由是API网关很核心的模块功能，此模块实现根据请求，锁定目标微服务并将请求进行转发。此模块需要与“服务发布管理中心”通信。“服务发布管理中心”实现微服务发布注册管理功能，与其通信获得目标微服务信息。

 

三 zuul和feign的应用场景和区别

(1)、zuul作为整个应用的流量入口，接收所有的请求，如app、网页等，并且将不同的请求转发至不同的处理微服务模块，其作用可视为nginx。

(2)、feign则是将当前微服务的部分服务接口暴露出来，并且主要用于各个微服务之间的服务调用。

(3)、两者的应用层次以及原理均不相同。

(4)、zuul也含有hystrix和ribbon，基于http通讯的，可以直接代理服务就行。在它和服务间增加feign只会增加通讯消耗，没有特别的意义。feign在服务互相调用的时候用就行了，可以仿rpc通讯。

(5)、Feign主要作客户端流控，Feign的负载均衡是基于Eureka实现的,Zuul主要作服务端流控，并且Zuul的负载均衡结合Eureka实现易用性较好，并且Zuul我一般用在对第三方提供访问接口。

 

四 具体案例

在以前案例的基础上，我们保持注册中心和服务提供者不变，新建zuul maven工程，如下图：

Pom文件代码如下，重点是引入了spring-cloud-s