【Spring Cloud】网关

1. 背景

通过Spring Cloud 和微服务的学习，我们了解到使用Spring Cloud实现微服务的架构基本成型，大致是这样的：
在这里插入图片描述
我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过 Ribbon 或Feign实现服务的消费以及均衡负载。为了使得服务集群更为健壮，使用 Hystrix 的熔断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。

在该架构中，服务集群包含：内部服务Service A 和 Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？

先来说说这样的架构需要做的一些事儿以及存在的不足：
• 破坏了服务无状态特点。
为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。
从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。
• 无法直接复用既有接口。
当我们需要对一个即有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。

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

为了解决上面这些问题，我们需要将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器的服务网关。

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix 中的 Zuul 就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。

2. Zuul简介

Zuul是Netflix开源的微服务网关，它可以和Eureka、Ribbon、Hystrix等组件配合使用。
Zuul 的核心是一系列的过滤器，这些过滤器可以完成以下功能：

身份认证与安全：识别每个自愿的验证要求，并拒绝那些与要求不符合请求。
审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
动态路由：动态地将请求路由到不同的后端集群。
压力测试：主键增加指向集群的流量，以了解性能。
负载分配：为每一种负载类型分配对应容量，并启用超出限定值的请求。
静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群。
多区域言行：跨越 AWS Region进行请求路由，旨在实现ELB（Elastic Load Balancing）使用的多样化，以及让系统的边缘更贴近系统的使用者。

微服务架构中，会存在多个服务，每个服务拥有不同的地址，用户在请求一个业务时，可能会执行多次请求，这时候，就需要我们的网关来进行转发了。网关是位于请求发起后，访问服务前的中间层，所有的访问，都需要先经过网关，比如在用户访问api时，请求链接为/login，则将其转发到login服务，请求链接为/shop，则将其转发到shop服务。

zuul 是netflix开源的一个API Gateway 服务器, 本质上是一个web servlet应用，Zuul 的主要功能是路由转发和过滤器。

Zuul 在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。将整个项目比喻为一个大房子，那么Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的门童，由它来引导请求进入他们要求的房间。