1.应用场景

API网关是将一个业务系统内部的多个微服务进行封装，对外提供唯一访问入口，实现系统内高内聚，系统间通过网关交互达到松耦合的效果。它可以和Eureka、Ribbon、Hystrix等组件配合使用，实现身份认证与安全、审查与监控、动态路由、压力测试、负载均衡、流量控制等功能

2.网关与应用

如果让客户端直接与各个应用直接通信，会有如下问題：

• 客户端会多次请求不同的应用，增加了客户端的复杂性。
• 存在跨域请求，在一定场景下处理相对复杂。
• 认证复杂，每个服务都需要独立认证。
• 难以重构，比如需要重新划分微服务时，改动量较大。
• 某些微服务可能使用了防火墻或者浏览器不友好的协议，直接访问会存在困难。
  以上问题都可以通过服务网关来解决。网关可以看成是应用系统的一个”前置“，将内部接口进行封装，对外提供统一的调用地址，封装统一的限流、认证授权等逻辑。下文分别对虚拟机和容器两类部署环境进行简要描述。

2.1应用部署于虚拟机

网关部署于虚拟机.png

如上图，当前API网关主要用于业务系统对外提供的接入入口，对业务系统内部多个微服务提供统一的限流与认证授权等功能。为确保网关高可用，API网关采用集群的形式。Zuul本身也是微服务，和下游的服务全部注册到注册中心，当外部服务需要访问该业务系统内的微服务时，外部请求首先路由到网关集群，再由网关负责转发到各个业务系统。

2.2 应用部署于容器

网关容器云部署图.png

基于Openshift的容器云平台，为业务系统提供了便捷的运维和管理能力。在该平台中，将业务系统划分为不同的space（openshift中为project，k8s中为namespace），进行分组管理。Space的划分会带来几个方面的影响：

1. 不同space之间会进行网络隔离，需通过外部访问方式访问其他space资源；特殊情况下可以将space间网络打通后直接调用。
2. 外部用户访问容器内资源时，将通过容器云入口HAproxy，然后转发至每个space。
3. 每个space需有独立的网关服务，将网关地址注册到HAproxy，形成HAproxy管理所有space，每个space的网关管理自己内部服务的两层模型。
4. 通常，不同的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（客户端模式）实现微服务的鉴权和认证。