服务网关概述
为什么需要服务网关
在传统的单体应用中，我们通常将业务功能写在一个应用内，统一部署、统一测试。随着业务的发展，每更新一个业务模块都需要将单体应用重新进行编译部署。业务模块的更新，会影响到其他关联的业务模块，甚至于造成整个应用系统的不可用，给单体应用的系统维护造成很大的困难。
此时我们需要对旧的单体应用进行服务化改造，将单体应用中的业务功能模块拆分成独立的服务单元，每个服务单元独立管理自身的发布、维护，解决了单体应用的弊端。
在迁移到微服务架构初期，服务单元数量少，服务间调用简单。当客户端通过前端页面执行某项操作时，通过F5或Nginx等设施的路由和负载均衡分配后，被转发到不同的服务实例上。为了让这些设施能够正确处理服务路由与分发请求，需要手工维护路由规则和服务实例列表，当有服务实例增减或IP地址变更时，需要手工修改服务实例列表以保持服务实例信息与服务实例列表配置一致性。当系统应用规模越来越大时，手工维护路由规则和服务实例列表的难度增加。我们需要一套机制来有效降低维护路由规则与服务实例列表的难度。
大多数情况下，为了保证对外服务的安全性，我们在服务端实现的服务接口，往往都会提供一些权限调用机制；为了防止客户端在发起请求时被篡改等安全方面的考虑，还会有一些签名校验的机制存在。由于使用了微服务架构的理念，我们将原本单体应用中的服务模块拆分为多个独立的服务单元，每个独立的服务单元对都需要提供对应的校验逻辑。随着服务单元数量的增多，在独立的服务单元内部都需要提供这样的校验机制，当我们需要对各个服务单元中的校验机制进行扩展和优化时，不得不去每个服务单元进行校验机制的修改，增加了校验机制的维护复杂度。我们也需要一套机制来解决微服务架构中，对于微服务接口访问时各前置校验的冗余问题。
综上所述，服务网关的出现主要解决了如下问题：
- 服务路由转发
- 通过过滤器的方式解决权限校验、服务限流等功能
何为服务网关
为了解决上述问题，服务网关的概念应运而生，微服务网关的存在就像是整个微服务系统的门面一样，所有的外部客户端访问都需要通过服务网关来进行调度和过滤。除了要实现请求路由、负载均衡、校验过滤等功能外，还需要提供熔断机制、服务聚合等功能。
Zuul
概述
为了实现上述功能，Netflix提供了开源服务网关Zuul,Zuul提供了一系列不同类型的过滤器(Filter),通过这些过滤器，能够快速的实现服务路由转发、服务限流、负载均衡、服务鉴权等功能，避免外部请求冲垮微服务系统。
过滤器
功能
身份验证：通过身份验证来区分不同的权限。
鉴权：对请求的有效性进行验证，如恶意请求、提供验证码等。
限流：在高并发的场景下，限制请求通过的流量，避免过大的流量压垮服务器。
动态路由：根据需要将请求动态路由到不同的后端服务实例。
压力测试：通过增删后端服务实例，确定整体微服务系统可承担的流量。
静态响应处理:对于处于高负荷的系统，提供静态数据作为服务的相应结果。
多区域弹性：将服务请求路由到最近的服务站点，提高服务的整体性能。
过滤器类型
pre：前置过滤器,请求被网关路由之前被调用。可以用此种过滤器实现服务限流、鉴权、参数校验。
routing:路由过滤器，将服务调用请求从网关路由到微服务。用于构建发送给服务注册中心的请求，并使用Http Client或Netflix Ribbon进行服务调用。
post:路由到微服务后执行，为请求调用响应添加标准的Http Header、收集统计信息和指标、将相应从微服务发送到客户端等。
error:其他阶段发生错误时执行该过滤器。
Zuul采取了动态读取、编译和运行这些过滤器。过滤器之间不能直接相互通信，而是通过RequestContext对象来共享数据，每个请求都会创建一个RequestContext对象，Zuul过滤器具有以下关键特性：
- Type:Zuul过滤器类型，决定了过滤器在请求的哪个阶段起作用。
- Execution Order:执行顺序，规定了过滤器的执行顺序，Order值越小，执行顺序越靠前。
- Criteria:标准，过滤器执行所需要的条件
- Action:行动，如果符合执行条件，则执行具体操作。
生命周期
外部http请求到达api网关后，进入pre过滤器对http请求进行处理。该过滤器的主要目的是在进行服务调用请求路由前做一些前置加工，比如权限校验、服务限流、参数校验等。在完成了pre类型的过滤器处理之后，请求进入第二个过滤器routing阶段，即服务路由请求转发阶段，服务调用请求会被routing类型的过滤器进行处理。这里的具体处理内容就是将外部请求转发到具体服务实例上去的过程，当服务实例请求结果都返回之后，routing阶段完成，服务调用请求进入第三个阶段post过滤器。在post过滤器内处理的过程中，不仅可以获取到服务调用请求信息，还可以获取到服务实例的返回信息，在post类型的过滤器中，可以对服务请求调用结果进行加工和转换的工作。还有一个特殊的error过滤器阶段，在上述三个过滤器阶段执行的过程中发生异常的情况下被触发，最终还是流向post类型的过滤器，需要通过post类型过滤器将最终结果返回给客户端。