技术背景

前面我们通过Ribbon或Feign实现了微服务之间的调用和负载均衡，那我们的各种微服务又要如何提供给外部应用调用呢。

当然，因为是REST API接口，外部客户端直接调用各个微服务是没有问题的，但出于种种原因，这并不是一个好的选择。

让客户端直接与各个微服务通讯，会有以下几个问题：

• 客户端会多次请求不同的微服务，增加了客户端的复杂性。
• 存在跨域请求，在一定场景下处理会变得相对比较复杂。
• 实现认证复杂，每个微服务都需要独立认证。
• 难以重构，项目迭代可能导致微服务重新划分。如果客户端直接与微服务通讯，那么重构将会很难实施。
• 如果某些微服务使用了防火墙/浏览器不友好的协议，直接访问会有一定困难。

面对类似上面的问题，我们要如何解决呢？答案就是：服务网关！

使用服务网关具有以下几个优点：

• 易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。
• 易于认证。可在服务网关上进行认证，然后再转发请求到微服务，无须在每个微服务中进行认证。
• 客户端只跟服务网关打交道，减少了客户端与各个微服务之间的交互次数。
• 多渠道支持，可以根据不同客户端（WEB端、移动端、桌面端...）提供不同的API服务网关。

Spring Cloud Zuul

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。

Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。

在Spring Cloud体系中， Spring Cloud Zuul 封装了Zuul组件，作为一个API网关，负责提供负载均衡、反向代理和权限认证。

Zuul工作机制

过滤器机制

Zuul的核心是一系列的filters, 其作用类似Servlet框架的Filter，Zuul把客户端请求路由到业务处理逻辑的过程中，这些filter在路由的特定时期参与了一些过滤处理，比如实现鉴权、流量转发、请求统计等功能。Zuul的整个运行机制，可以用下图来描述。

过滤器的生命周期

Filter的生命周期有4个，分别是“PRE”、“ROUTING”、“POST”、“ERROR”，整个生命周期可以用下图来表示。

基于Zuul的这些过滤器，可以实现各种丰富的功能，而这些过滤器类型则对应于请求的典型生命周期。

PRE： 这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。

ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。

POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。

ERROR：在其他阶段发生错误时执行该过滤器。

除了默认的过滤器类型，Zuul还允许我们创建自定义的过滤器类型。例如，我们可以定制一种STATIC类型的过滤器，直接在Zuul中生成响应，而不将请求转发到后端的微服务。

Zuul中默认实现的Filter

Zuul默认实现了很多Filter，这些Filter如下面表格所示。