java Spring cloud zuul API网关服务

01

前言

通过前几章的介绍，我们对springcloud netflix的核心组件已经了解了一大半，基本涵盖了微服务架构中最为基础的几个核心设施。利用这些组件，已经可以构建一个微服务系统架构了。

在本篇内容中，我们把眼光聚集在对外服务这块内容。

02

spring cloud zuul

首先对于路由规则与服务实例的维护问题。Spring cloud zuul通过与springcloud eureka进行整合，将自身注册为eureka服务治理下的应用。同时从eureka中获取所有其他微服务的实例信息。

这样的设计非常巧妙的将服务治理体系中维护的实例信息利用起来。使得将维护实例的工作交给了服务治理框架自动完成。节约人工成本。

而对于路由规则的维护，zuul默认会以服务名作为contextPath的方式来创建路由映射。大部分情况下，这样的默认设置已经可以实现我们大部分的路由需求。除非一些特殊情况，比如兼容一些老的url。

03

签名校验

对于签名校验，登录校验在微服务架构中的冗余问题。理论上来说，这些校验逻辑在本质上与服务自身的业务并没有多大的关系。所以她们完全可以独立成一个单独的服务存在。

只是她们在剥离和独立出来之后，并不是给各个微服务调用，而是在api网关服务上进行统一调用拉对微服务接口做前置过滤.以实现对微服务的拦截和校验。

Zuul提供了一套过滤器机制，它可以很好的支持这样的任务。开发者可以通过zuul来创建各种校验过滤器，然后指定哪些规则的请求需要执行校验逻辑。

只有通过校验的才会被路由到具体的微服务接口，不然就返回错误提示。通过这样的改造，各个业务层的微服务应用在不要需要业务性质的校验逻辑了。

04

请求生命周期

对于zuul的过滤类型filterType，zuul默认定义了四种不同的过滤器类型。她们覆盖了一个外部http请求到达api网关，直到返回请求结果的的全部生命周期。

核心过滤器，它们会在api网关服务启动的时候被自动加载和启动。

Pre过滤器，它的执行顺序为-3，罪案执行的过滤器，该过滤器总是被执行。

Post过滤器，它的执行顺序为0，是post阶段第一个执行的过滤器。

Route过滤器，它的执行顺序为10，是route阶段第一个执行的过滤器。