介绍完分布式配置中心，结合前面的文章。我们已经有了一个微服务的框架了，可以对外提供api接口服务了。但现在试想一下，在微服务框架中，每个对外服务都是独立部署的，对外的api或者服务地址都不是不尽相同的。对于内部而言，很简单，通过注册中心自动感知即可。但我们大部分情况下，服务都是提供给外部系统进行调用的，不可能同享一个注册中心。同时一般上内部的微服务都是在内网的，和外界是不连通的。而且，就算我们每个微服务对外开放，对于调用者而言，调用不同的服务的地址或者参数也是不尽相同的，这样就会造成消费者客户端的复杂性，同时想想，可能微服务可能是不同的技术栈实现的，有的是http、rpc或者websocket等等，也会进一步加大客户端的调用难度。所以，一般上都有会有个api网关，根据请求的url不同，路由到不同的服务上去，同时入口统一了，还能进行统一的身份鉴权、日志记录、分流等操作。接下来，我们就来了解今天要讲解的路由服务：zuul。
一点知识 为什么要使用微服务网关
简单来说，微服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。
在未加入网关时，一般上会在服务外网架设一个负载均衡，如nginx等。此时，微服务的组成为：
此时，对于Open Service而言可能需要提供权限控制等和业务无关的能力，这样本身就破坏了微服务服务单一的原则。所以，一般上在Open Service之上，还有一层服务提供诸如通用的权限校验、参数校验等功能，此服务就是网关了。之后，对于内部微服务而言，只需要关系各自微服务提供的业务功能即可，无需去关心其他非业务相关的功能。
API网关是什么API网关可以提供一个单独且统一的API入口用于访问内部一个或多个API。简单来说嘛就是一个统一入口，比如现在的支付宝或者微信的相关api服务一样，都有一个统一的api地址，统一的请求参数，统一的鉴权。
客户端和服务端直连的弊端客户端会对此请求不同的微服务，增加客户端复杂性
存在跨域请求时，需要进行额外处理
认证服务，每个服务需要独立认证
UI端和微服务耦合
网关的优缺点优点：
减少api请求次数
限流
缓存
统一认证
降低微服务的复杂度
支持混合通信协议(前端只和api通信，其他的由网关调用)
……
缺点：
网关需高可用，可能产生单点故障
管理复杂
网关的选择现在市场上有很多的网关可供选择：
Spring Cloud Zuul：本身基于Netflix开源的微服务网关,可以和Eureka,Ribbon,Hystrix等组件配合使用。
Kong : 基于OpenResty的 API 网关服务和网关服务管理层。
Spring Cloud Gateway：是由spring官方基于Spring5.0,Spring Boot2.0,Project Reactor等技术开发的网关，提供了一个构建在Spring Ecosystem之上的API网关，旨在提供一种简单而有效的途径来发送API，并向他们提供交叉关注点，例如：安全性，监控/指标和弹性。目的是为了替换Spring Cloud Netfilx Zuul的。
在Spring cloud体系中，一般上选择zuul或者Gateway。当然，也可以综合自己的业务复杂性，自研一套或者改在一套符合自身业务发展的api网关的，最简单做法是做个聚合api服务，通过SpringBoot构建对外的api接口，实现统一鉴权、参数校验、权限控制等功能，说白了就是一个rest服务。
Zuul介绍和使用 何为ZuulZuul是Netflix开源的微服务网关，可以和Eureka、Ribbon、Hystrix等组件配合使用，Spring Cloud对Zuul进行了整合与增强，Zuul的主要功能是路由转发和过滤器。
Zuul基于JVM的路由器和服务器端负载均衡器。同时，Zuul的规则引擎允许规则和过滤器基本上用任何JVM语言编写，内置支持Java和Groovy。这个功能，就可以实现动态路由的功能了。当需要添加某个新的对外服务时，一般上不停机更新是通过数据缓存配置或者使用Groovy进行动态路由的添加的。
Zuul的核心一系列的过滤器：
身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。
审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
动态路由：动态地将请求路由到不同的后端集群。
压力测试：逐渐增加指向集群的流量，以了解性能。
负载分配：为每一种负载类型分配对应容量，并启用超出限定值的请求。
静态响应处理：在边缘位置直接建立部分相应，从而避免其转发到内部集群。
加入Zuul网关后：
创建工程：spring-cloud-zuul。
这里直接加入了注册中心进行服务化模式。