Zuul 一

Zuul 网关，联想一下就和海关之类的差不多，可以帮我们拦截一些非法请求，或者未授权的请求等等。

Zuul网关还有一个作用就是让用户的请求不直接和微服务挂钩，而是通过Zuu网关去分发请求。

首先通过我们之前的学习，可以搭建一个初步的架构

在该架构中，我们的服务集群包含内部服务ServiceA和ServiceB, 它们都会向EurekaServer集群进行注册与订阅服务，而OpenService是一个对外的RESTfulAPI服务，它通过FS、 Nginx 等网络设备或工具软件实现对各个微服务的路由与负载均衡， 并公开给外部的客户端调用。

这样架构的问题:

首先， 我们从运维人员的角度来看看， 他们平时都需要做一些什么工作来支持这样的架构。当客户端应用单击某个功能的时候往往会发出一些对微服务获取资源的请求到后端，这些请求通过FS、 Nginx等设施的路由和负载均衡分配后， 被转发到各个不同的服务实例上。 而为了让这些设施能够正确路由与分发请求， 运维人员需要手工维护这些路由规则与服务实例列表， 当有实例增减或是IP地址变动等情况发生的时候， 也需要手工地去同步修改这些信息以保持实例信息与中间件配置内容的一致性。 在系统规模不大的时候， 维护这些信息的工作还不会太过复杂， 但是如果当系统规模不断增大， 那么这些看似简单的维护任务会变得越来越难， 并且出现配置错误的概率也会逐渐增加。 很显然， 这样的做法并不可取， 所以我们需要一套机制来有效降低维护路由规则与服务实例列表的难度。

上面这段话我感觉是有问题的:就算没有Zuul网关，我们在配置OpenService的时候，必然也会和Eureka一起使用。同时Nginx本身是带有心跳检测的，会检测他下面所拥有的tomcat是否可用，如果不可用，则会剔除服务。这样就保证OpenService的可用，OpenService是注册在Eureka上面的，通过Eureka的服务治理就可以保证下面微服务的高可用。这样基本不用去更改我们的服务状态。  这里有补充或者感觉说的有问题的欢迎指出。

其次，我们再从开发入员的角度来看看，在这样的架构下，会产生一些怎样的问题呢？大多数清况下， 为了保证对外服务的安全性， 我们在服务端实现的微服务接口， 往往都会有一定的权限校验机制， 比如对用户登录状态的校验等； 同时为了防止客户端在发起请求时被篡改等安全方面的考虑， 还会有一些签名校验的机制存在。 这时候， 由千使用了微服务架构的理念， 我们将原本处千一个应用中的多个模块拆成了多个应用， 但是这些应用提供的接口都需要这些校验逻辑， 我们不得不在这些应用中都实现这样一套校验逻辑。 随着微服务规模的扩大， 这些校验逻辑的冗余变得越来越多， 突然有一天我们发现这套校验逻辑有个BUG需要修复，或者需要对其做一些扩展和优化，此时我们就不得不去每个应用里修改这些逻辑， 而这样的修改不仅会引起开发入员的抱怨， 更会加重测试人员的负担。 所以， 我们也需要一套机制能够很好地解决微服务架构中， 对于微服务接口访问时各前置校验的冗余问题。

Zuul网关的好处:

 API网关是一个更为智能的应用服务器， 它的定义类似于面向对象设计模式中的Facade模式， 它的存在就像是整个微服务架构系统的门面一样，所有的外部客户端访问都需要经过它来进行调度和过滤。它除了要实现请求路由、 负载均衡、 校验过滤等功能之外， 还需要更多能力， 比如与服务治理框架的结合、 请求转发时的熔断机制、 服务的聚合等一系列高级功能。

zuul网关介绍到这个就结束了。

努力吧，皮卡丘