## 一、简介 Spring Cloud GateWay 是由Spring 官方社区开发的API 服务网关，在新一代的开发技术中使用到了Spring WebFlux的全新的响应式的非阻塞IO框架。相对于Spring Cloud第一代的网关组件zuul，性能有了长足的进步（宣称性能提升1.6倍）。WebFlux底层是基于高性能的非阻塞IO通信框架Netty实现的。 ## 核心功能特性 笔者在上一节已经为大家介绍过，API服务网关的主要作用有三个： * 统一流量入口，面向前端更加友好。减少分散入口配置，降低客户端与服务端的耦合度。 * 统一认证鉴权，避免多个服务分散鉴权造成的维护与开发的成本升高 * 访问日志、限流、过滤、缓存、监控等公共服务也可以在网关上集中完成。避免分散造成的开发及维护成本  ## 二、阻塞IO与异步非阻塞IO的区别 笔者用相对通俗的话为大家说明一下阻塞IO与非阻塞IO之间的区别。我们以软件开发团队的工作方式来做一个比喻。作为软件开发人员，我们肯定知道软件开发的基本流程： * 项目立项与可行性研究 * 需求分析与设计 * 代码开发 * 迭代测试 * 上线及配置管理、运维 在以Spring MVC或者struct为代表的框架都是基于sevlet的，其底层IO模型是阻塞IO模型。这种模型就好像你是公司的一个开发人员，上面的所有的5项工作全都由你一个人完成。如果公司有10个人，最多就只能**同时进行**10个需求。客户需求增多了也没有办法，只能让他们等着。如下图：一个请求占用一个线程，当线程池内的线程都被占用后新来的请求就只能等待。  spring 社区为了解决Spring MVC的阻塞模型在高并发场景下的性能瓶颈的问题，推出了Spring WebFlux，WebFlux底层实现是久经考验的netty非阻塞IO通信框架。该框架的请求处理与线程交互关系图如下：  boosGroup用于Accetpt连接建立事件并分发请求， workerGroup用于处理I/O读写事件和业务逻辑 每个Boss NioEventLoop循环执行的任务包含3步： * 1 轮询accept事件 * 2 处理accept I/O事件，与Client建立连接，生成NioSocketChannel，并将NioSocketChannel注册到某个Worker NioEventLoop的Selector上 * 3 处理任务队列中的任务，runAllTasks。任务队列中的任务包括用户调用eventloop.execute或schedule执行的任务，或者其它线程提交到该eventloop的任务。 每个Worker NioEventLoop循环执行的任务包含3步： * 1 轮询read、write事件； * 2 处I/O事件，即read、write事件，在NioSocketChannel可读、可写事件发生时进行处理 * 3 处理任务队列中的任务，runAllTasks。 如果通俗的将上图中的各个任务池、线程池的组合比做一个软件开发公司，那么: * 项目立项及可研，由公司项目经理及顾问来完成 * 需求分析与设计，由产品经理和架构师来完成 * 代码研发，由项目经理带领开发人员来完成 * 迭代测试，由测试团队来完成 * 上线及配置管理、运维，可能由专门的devops团队来完成 这样一个公司内的所有人完成分工，就能在有限的资源的情况下,去接触更多的客户，谈更多的需求，合理的分配人力资源，达到并发处理能力最大化的极限水平。相比于一个员工从头到位的负责一个项目，它的组织性更强，分工更明确，合理的利用空闲资源，专业的人最专业的事。 这种人力资源的合理利用及组织方式和非阻塞IO模型有异曲同工之处，通过合理的将请求处理线程及任务进行分类，合理的利用系统的内存、CPU资源，达到单位时间内处理能力的最大化就是异步非阻塞IO的核心用意！ **所以非阻塞IO模型的核心意义在于：提高了有限资源下的服务请求的并发处理能力，而不是缩短了单个服务请求的响应时长。**由于API 服务网关集中的承载了微服务系统内的流量进行转发，所以他的并发处理能力至关重要的原因，也是netflix Zuul被淘汰的根本原因！