1.应用场景
API网关是将一个业务系统内部的多个微服务进行封装，对外提供唯一访问入口，实现系统内高内聚，系统间通过网关交互达到松耦合的效果。它可以和Eureka、Ribbon、Hystrix等组件配合使用，实现身份认证与安全、审查与监控、动态路由、压力测试、负载均衡、流量控制等功能
2.网关与应用
如果让客户端直接与各个应用直接通信，会有如下问題：
- 客户端会多次请求不同的应用，增加了客户端的复杂性。
- 存在跨域请求，在一定场景下处理相对复杂。
- 认证复杂，每个服务都需要独立认证。
- 难以重构，比如需要重新划分微服务时，改动量较大。
- 某些微服务可能使用了防火墻或者浏览器不友好的协议，直接访问会存在困难。
以上问题都可以通过服务网关来解决。网关可以看成是应用系统的一个”前置“，将内部接口进行封装，对外提供统一的调用地址，封装统一的限流、认证授权等逻辑。下文分别对虚拟机和容器两类部署环境进行简要描述。
2.1应用部署于虚拟机
网关部署于虚拟机.png
如上图，当前API网关主要用于业务系统对外提供的接入入口，对业务系统内部多个微服务提供统一的限流与认证授权等功能。为确保网关高可用，API网关采用集群的形式。Zuul本身也是微服务，和下游的服务全部注册到注册中心，当外部服务需要访问该业务系统内的微服务时，外部请求首先路由到网关集群，再由网关负责转发到各个业务系统。
2.2 应用部署于容器
网关容器云部署图.png
基于Openshift的容器云平台，为业务系统提供了便捷的运维和管理能力。在该平台中，将业务系统划分为不同的space（openshift中为project，k8s中为namespace），进行分组管理。Space的划分会带来几个方面的影响：
- 不同space之间会进行网络隔离，需通过外部访问方式访问其他space资源；特殊情况下可以将space间网络打通后直接调用。
- 外部用户访问容器内资源时，将通过容器云入口HAproxy，然后转发至每个space。
- 每个space需有独立的网关服务，将网关地址注册到HAproxy，形成HAproxy管理所有space，每个space的网关管理自己内部服务的两层模型。
- 通常，不同的space间的访问将会被认为是不可信的，每个space的网关需要负责对调用方的身份识别，以保证安全。
3. 基本原理
在整个SpringCloud微服务框架里，Zuul扮演着”智能网关“的角色。一方面，Zuul是接入网关，起到反向代理的作用，是外部消费者请求内部服务的唯一入口。另一方面，Zuul也具备过滤功能，通过在运行时注入过滤规则可实现用户鉴权、动态路由、灰度发布、A/B测试、负载均衡、限流等功能。
Zuul的大部分功能都是通过过滤功能来完成的，Zuul可以提供四种标准类型的过滤，如下图所示：
- Pre:：过滤规则在路由之前起作用。可以利用”Pre“过滤器实现用户鉴权，记录请求日志等；
- Routing：过滤规则在路由时发生作用。可以利用”Routing“过滤器实现动态路由、灰度发布、A/B测试、负载限流等。
- Post：过滤规则在路由之后发生作用。可以利用”Post“过滤器手机统计信息和指标，将微服务的想要写入HTTP相应并返回给服务消费者。
- Error：过滤规则路由过程中发生错误时发生作用。可以利用Error过滤器记录错误日志，并对错误进行二次处理等。
对网关做了大量定制开发，一方面通过引入google RateLimiter，重写过滤器实现了限流功能；另一方面，基于Oauth2（客户端模式）实现微服务的鉴权和认证。
