网关Zuul的简单介绍
以下内容介绍来自☞详解Spring Cloud Zuul 服务网关和使用Zuul构建API Gateway
本篇不做太深入的介绍。功能/性能测试工程师只需了解网关服务即可，开发的话就需要深入了解。
一、微服务网关背景及简介
不同的微服务一般有不同的网络地址，而外部的客户端可能需要调用多个服务的接口才能完成一个业务需求。比如一个电影购票的收集APP,可能回调用电影分类微服务，用户微服务，支付微服务等。如果客户端直接和微服务进行通信，会存在以下问题：
- 客户端会多次请求不同微服务，增加客户端的复杂性
- 存在跨域请求，在一定场景下处理相对复杂
- 认证复杂，每一个服务都需要独立认证
- 难以重构，随着项目的迭代，可能需要重新划分微服务，如果客户端直接和微服务通信，那么重构会难以实施
- 某些微服务可能使用了其他协议，直接访问有一定困难
上述问题，都可以借助微服务网管解决。微服务网管是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过微服务网关，架构演变成：
二、Zuul 简介
Zuul是Netflix开源的微服务网关，Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。它可以和Eureka,Ribbon,Hystrix等组件配合使用。Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：
- 身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求
- 审查与监控：
- 动态路由：动态将请求路由到不同后端集群
- 压力测试：逐渐增加指向集群的流量，以了解性能
- 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求
- 静态响应处理：边缘位置进行响应，避免转发到内部集群
- 多区域弹性：跨域AWS Region进行请求路由，旨在实现ELB(ElasticLoad Balancing)使用多样化
三、什么是网关？为何需要使用网关？
通过上图，对外提供的服务，在无网关的情况下，API接口直接暴露给服务调用方，当调用方增多，不同业务调用方各不相同，势必需要添加定制化访问权限、校验等逻辑。当添加API网关后，再第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端，正如无需直接访问compute-service的add方法，而是通过api-a/add链接将请求传递给service实例。Zuul就是提供负载均衡-反向代理-权限认证的这么一个API gateway。
类似于Nginx在应用服务最前端添加一堵保护墙，zuul的负载均衡是针对将请求分发给集群中某台服务或者某个服务实例。而ribbon也是主打服务负载功能，它所针对的是服务消费者将调用请求分发到某具体服务提供实例。两者均做负载均衡，实际是在系统不同的层级上进行。
好啦，简单介绍到这里over~