1 微服务架构的两种方式

• 点对点
  
  API-网关，应用最广泛的方式

2 Zuul 的生命周期

在SoringQloud Finchley正式版之前，Spring Cloud推荐的网关是Netfix提供的Zuul:
Zuul 1.x, 是一个基于阻塞IO的API Gateway，基于Servlet 2. 5使用阻塞架构，它不支持任何长连接(如WebSocket)
Zuul的设计模式和Nginx较像，每次I/ 0操作都是从工作线程中选择一 个执行，请求线程被阻塞到工作线程完成，但是差别是Nginx用C++实现，Zuul用Java实现，而JVM本身会有第一次加载较慢的情况，使得Zuul的性能相对较差。

2.x理念更先进,想基于Netty非阻塞和支持长连接,但SpringCloud目前还没有整合。Zuul 2.x的性能较Zuul 1.x有较大提升, 在性能方面，根据官方提供的基准测试， Spring Cloud Gateway的RPS (每秒请求数)是Zuul的1. 6倍。

Spring Cloud Gateway建立在 Spring Framework 5、 Project Reactor和Spring Boot2之上， 使用非阻塞API。Spring Cloud Gateway还支持WebSocket, 并且与Spring紧密集成拥有更好的开发体验

3 上述的缺点

servlet是一个简单的网络I0模型，当请求进入servlet container时， servlet container就会为其绑定一个线程，在并发不高的场景下这种模型是适用的。一旦高并发(此如抽风用jemeter压测)，线程数量就会上涨，而线程资源代价是昂贵的(上线文切换，内存消耗大)严重影响请求的处理时间。
在一些简单业务场景下， 不希望为每个request分配个线程， 只需要1个或几个线程就能应对极大并发的请求，这种业务场景下servlet模型没有优势。

所以Zuul 1.X是基于servlet之上的一个阻塞式处理模型，即spring实现了处理所有request请求的个servlet (DispatcherServlet) 并由该servlet阻

Cloud全家桶中有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关；但在2.x版本中，zuul的升级一直跳票, SpringCloud最后自己研发了一个网关替代Zuul,那就是SpringCloud Gateway : gateway是原zuul1.x版的替代

SpringCloud Gateway是Spring Cloud的一个全新项目,基于Spring 5.0+Spring Boot 2.0和Project Reactor等技术开发的网关，它旨在为
微服务架构提供-种简单有效的统一的API路由管理方式。
SpringCloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Zuul,在Spring Cloud 2.0以上版本中，没有对新版本的Zuul 2.0上
最新高性能版本进行集成，仍然还是使用的Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty.
Spring Cloud Gateway的目标提供统-的路由方式且基于 Filter 链的方式提供了网关基本的功能，例如:安全，监控/指标，和限流。

因为Zuul1.0已经进入了维护阶段,而且Gateway是SpringCloud团队研发的, 是亲儿子产品，值得信赖。而且很多功能Zuul都没有用起来也非常的简单便捷。

Gateway是基于异步非阻塞模型上进行开发的,性能方面不需要担心。虽然Netflix早就发布了最新的Zuul 2.x,但Spring| Cloud貌似没有整合计划。而且Netflix相关组件都宣布进入维护期;前景无望。
多方面综合考虑Gateway是很理想的网关选择。

4 网关的架构位置

• 注意负载均衡依旧是 Nginx
  

特性