网关服务和Zuul
为什么需要网关服务
如果没网关，当前启动了十几个对外的微服务，那么客户端去调用只能是和各个服务一个一个打交道，这显然是不现实的。从运维角度说，当请求通过Nginx等设施的路由和负载均衡分配后，被转发到各个不同的服务实例上，而为了让这些设施能够正确路由与分发请求，运维需要手工维护这些路由规则与服务实例列表，大大增加了运维人员的工作量与出错率；从开发人员角度说，对外服务一般都有一些安全性的校验和权限校验机制，如果每个微服务写一套，那么一旦出现BUG，是需要修改每个微服务的，增加了开发和测试的工作量。
为了解决上面这些问题，API网关的概念应运而生，它的存在就像是整个微服务架构系统的门面，所有的外部客户端访问都需要经过它来进行调度和过滤.。
那么它是如何解决上面这两个普遍的问题呢？
首先，对于路由规则与服务实例的维护问题。Zuul通过Eureka进行整合，将自身注册到Eureka上面，从Eureka中获得了所有其他微服务的实例，这样设计可以将服务治理体系中维护的实例信息利用起来，使得维护服务实例的工作交给了服务治理框架自动完成不需要人工介入。而对于路由规则的维护，Zuul将会通过服务名作为ContextPath的方式来创建路由映射，大部分情况下这样的默认设置已经可以实现我们大部分的路由需求。
其次，对于类似签名校验、登陆校验在微服务架构中的冗余问题。Spring Cloud Zuul提供了一套过滤机制，可以很好的支持这样的任务。
服务网关的要素：
1.稳定性，高可用
2.性能，并发性
3.安全性
4.扩展性
常用的网关方案
1.Nginx+Lua
2.Kong
3.Tyk
4.Spring Cloud Zuul(如果用了Spring 又 用了Spring Cloud 那么用Zuul是很合适的)
Zuul的特点 路由+过滤器=Zuul 核心就是一系列过滤器
Zull的四种过滤器API 前置(Pre)，路由(Route)，后置(post)，错误(Error)
Zull主件架构
一次请求进来，红色的为过滤器，Server为服务。首先进入的是"pre"filter这个是一个类型 下面还有过滤器可以在这一步对参数做一些操作过滤;然后是"route"filter(s)这个过滤器把请求发送到了服务端，服务端把结果返回;然后到"post"filter，如果报错了那么会进入"error filters";
完整架构图
