浅谈SpringCloud里面的Zuul(路由器&过滤器)

前奏曲:    

     在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

其实Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门，其充当的作用更多是网关，更加简单的理解就是相当与Web里面的过滤器，它的核心也是各种过滤器的混杂。

为什么需要API Gateway呢?

1、简化客户端调用复杂度

在微服务架构模式下后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。

2、数据裁剪以及聚合

通常而言不同的客户端对于显示时对于数据的需求是不一致的，比如手机端或者Web端又或者在低延迟的网络环境或者高延迟的网络环境。

因此为了优化客户端的使用体验，API Gateway可以对通用性的响应数据进行裁剪以适应不同客户端的使用需求。同时还可以将多个API调用逻辑进行聚合，从而减少客户端的请求数，优化客户端用户体验

3、遗留系统的微服务化改造

对于系统系统而言进行微服务改造通常是由于原有的系统存在或多或少的问题，比如技术债务，代码质量，可维护性，可扩展性等等。API Gateway的模式同样适用于这一类遗留系统的改造，通过微服务化的改造逐步实现对原有系统中的问题的修复，从而提升对于原有业务响应力的提升。通过引入抽象层，逐步使用新的实现替换旧的实现。

在Spring Cloud体系中， Spring Cloud Zuul就是提供负载均衡、反向代理、权限认证的一个API gateway。

这样做的好处是什么呢？在我理解就是将N:N，1:N，N:1的问题转换成1:1的问题

他的功能还是很多的，比如，认证，洞察，压力测试，金丝雀测试，动态路由，等等反正多的要命，废话不多说，很多原理上面的东西我也不是很懂，先把踩过的坑和如何使用粘贴出来, 学以致用嘛

1、首先必不可少的肯定还是添加相应的Jar包，这两个Jar必不可少

2、这一步很关键，和之前不同的就是多添加了一个@EnableZuulProxy这个注释的意思是我是一个Zuul网关路由，understand

3、其次就是配置文件，这边的网关有两个，一个是city，另外一个是data，path的意思是拦截city的所有的请求，serviceId也是你的服务中心里面的对应的服务提供者的名称，data同理。这边注意一点你的path，我后面会说

上面就相当于你的Zuul。

4、下面就是调用方(之前我们的获取都是直接从服务里面获取，现在我们可不这么干了，我们获取数据从上面的代理里面获取，相当于你的网关)    

同理，这边的@FeignClient里面的名称就是你的服务网关对应的名称，记住一定要保持一致

下面就很重要的地方了，还记得上面的path吗？哈哈，这里的就用到了，我们调用方法的声明前面一定要和你上面的path里面的路径一致，千万不要错了，不然报错我可不负责！！！然后除了前缀一定要一样，后面的就不用我说了吧，你懂的，有了他，就行了，该怎么调用就怎么调用

注意:

    如果想看看Zuul是否实现了负载均衡，可以给服务提供者开两个节点，然后打印一段话，看看是否实现了负载均衡