为什么需要服务网关
在分布式系统系统中，有商品、订单、用户、广告、支付等等一大批的服务，前端怎么调用呢？和每个服务一个个打交道？这显然是不可能的，这就需要有一个角色充当所有请求的入口，这个角色就是服务网关（API gateway）。
服务网关应该具备的要素
稳定性、高可用：网关是所有请求的入口，如果这里出现问题就会导致所有的服务不能对外提供服务了，可见其重要性
性能、并发性：既然是所有请求的入口，那就意味着并发量大，这对其性能就有很高的要求
安全性：要确保服务的安全，防止外部的恶意访问，像金融行业一般会对数据进行加密传输
拓展性：因为各种请求都经过网关服务，所以网关上大有文章可做，是处理所有非业务功能的绝佳场所，比如流控、协议转发、日志、防刷等等。
在这里需要明确一点，服务网关并不是微服务出现后才有的！！！
常见的网关方案
Nginx + Lua： 性能和高可用是Nginx傲视群雄的资本
Kong：基于Nginx + Lua之上进行封装，更简单易用，但是需要付费才能使用
Tyk：开源的、轻量级、快速伸缩的服务网关，基于go语言开发
spring cloud zuul：也是基于Netflix提供的开源工具上进行封装，天生服务于微服务，如果是基于Java开发的，结合spring cloud提供的微服务治理体系的话，zuul提供了认证、鉴权、限流、监控、弹性、安全、动态路由、负载均衡、协作单点压测、静态响应等等功能。但是性能方面肯定是比不上Nginx的。
个人觉得如果你是使用了spring cloud去开发微服务，那么使用zuul去做服务网关真的是非常合适的，而且特别适合快速上手，虽然其并发性能比不上Nginx，但是我们开发的可以灵活配置啊，Nginx+zuul 让他们发挥各自的优点。
zuul的特点
路由+过滤器 = zuul，个人觉得zuul的核心就是由一系列的过滤器组成。
zuul的四种过滤器API
前置（Pre）：首先到达的是这里，注意这里是指Pre这种类型的过滤器，实际上不止一个过滤器，对请求路由前置加工，比如参数校验、限流、鉴权
路由（route）：这里的是将请求转发到具体的Origin Server（具体的微服务）上，可以在这里重写http请求。
后置（Post）：这里是已经拿到请求的结果了，如果想对结果再加工一下，可以在这里，比如统计、日志
错误（Error）：Pre或者Route、Post出现异常就会来到Error，这里可以种统一异常处理
此外还有Custom（自定义过滤器），实际上它也归属于上面四类，看你自定义它是何种类型就是何种类型，上面的四种都支持自定义。
