一、网关是什么
1、广义网关
网关(Gateway)又称网间连接器、协议转换器。网关在网络层以上实现网络互连，是复杂的网络互连设备，仅用于两个高层协议不同的网络互连。网关既可以用于广域网互连，也可以用于局域网互连。 网关是一种充当转换重任的计算机系统或设备。使用在不同的通信协议、数据格式或语言，甚至体系结构完全不同的两种系统之间，网关是一个翻译器。与网桥只是简单地传达信息不同，网关对收到的信息要重新打包，以适应目的系统的需求。 -- 摘自百度百科。
我们可以理解网关就是为了实现不同网络之间的网络互联。那我们在平时的工作中肯定也会听到很多“网关”这个词汇，其实我们通常所说的网关就是API 网关。
2、API 网关
在微服务架构里，服务的粒度被进一步细分，各个业务服务可以被独立的设计、开发、测试、部署和管理。这时，各个独立部署单元可以用不同的开发测试团队维护，可以使用不同的编程语言和技术平台进行设计，这就要求必须使用一种语言和平台无关的服务协议作为各个单元间的通讯方式，让外界看起来是一个统一的接口。同时也可在网关中提供额外的功能。
API 网关的作用范围可大可小。比如有的公司就公用一个公共的公司级网关，有的在中心、部门内部都会搭建自己的网关。
2.1 API网关定义
网关的角色是作为一个 API 架构，用来保护、增强和控制对于 API 服务的访问。API 网关是一个处于应用程序或服务（提供 REST API 接口服务）之前的系统，用来管理授权、访问控制和流量限制等，这样REST API 接口服务就被 API 网关保护起来，对所有的调用者透明。因此，隐藏在 API 网关后面的业务系统就可以专注于创建和管理服务，而不用去处理这些策略性的基础设施。
2.2 API网关职能
关于API网关的能做什么事情，下图中的四个方面已经描述的很清楚了，我个人理解上有点偏差就是是否可以做业务聚合这一点。个人认为网关上不要做重的业务聚合，因为网关上承接的是公司或者部门所有的对外请求做过多的业务聚合势必造成请求的阻塞和网关的资源占用率高，并且容易由于一个问题导致其他的请求收到影响。当然这里描述的API网关，兼顾有API的职能做业务聚合也无可厚非。至于做怎么定位，如何选择还是在系统设计中做好权衡。
2.3 API网关分类和
API网关可以分为两个分类分别是“流量网关”和“业务网关”，不同分类关注的事务也不一样。流量网关主要关注应运的稳定行和安全性，业务网关主要关注的是如何使应运提供更好的服务。公司基本上是多层网关架构，公司的网关负责流量，部门的网关负责业务。当然也不是这么绝对具体的业务场景在具体设计。比如我们部门的网关就兼顾流量和业务网关的职责。
2.4 API网关设计重点
网关的设计准则无非就是三高：高性能、高可用、高扩展。
高性能
在技术设计上，网关不应也不能成为性能的瓶颈。对于高性能当然对于不同的编程语言采用合适的模型来实现最合适不过。不如C、C++、Go、Java等语言一定要采用异步非阻塞IO来确保后端的服务延迟不会导致应用程序的性能问题。C、C++语言在可以参考Linux下的epoll异步IO模型。Java的话可以参考Netty、Spring Reactor的NIO模型。后面咱们要学习的SCG就是基于WebFlux响应式实现。
高可用
因为网关承接的是部门所有的流量，所以网关必须是有个高可用的组件，它的稳定性直接关系到所有系统的稳定。网关如果没有设计就可能变成一个单点故障，因此一个好的网关的设计应该考虑以下三点。
集群化：网关要集群化部署，并且可伸缩。这个在云环境下可以很好的做到，咱们服务上云之后可以快速的扩容和缩容，并且可以基于请求的流量做到AI DevOps。
服务化：网关需要在不停服务的情况下修改配置，类似 Nginx reload那样修改配置，可以做到不停服。另一种就是服务化，有自己的Admin API来修改配置。
持续化：这就要求我们的服务在重启的时候平滑发布，不会因为服务重启导致一些请求直接断掉，应该在老的服务上摘流完毕之后在下掉老服务，在新服务完全启动完毕之后在接入新请求。这个部分在各自的公司应该都有组件来保证。
高扩展
因为网关或多多少都会承接一部分业务逻辑，比如我们目前的网关里权限校验和session解析就会根据不同的业务做一些差异话的开发，这就要求我们的网关要做到好扩展，可以在组件上进行方便快捷的二次开发。
2.5 API网关选型
目前业界常用的API 网关主要有几类：Nginx、Zuul、SpringCloudGateway、Kong（OpenResty）
Nginx
Nginx是一个高性能的Http和反向代理服务器。Nginx可以作为后端服务的反向代理，也可以运做静态资源服务器，接口使用Lua可以灵活的进行功能制定。这里就不过多介绍，相关学习大家可以看另一系列文章《Nginx教程》传送门
Zuul
Zuul是 NetFlix 公司开源的一个API网关，有两个大的版本其中1.0的版本是被SpringCloud纳入全家桶的，但是由于1.0的版本基于Servlet框架，采用的阻塞多线程模式，效率比较低。2.0版本有了重大更新，他运行在异步无阻塞架构上，每个CPU核一个线程，用来处理所有的请求和响应，请求和相应的生命周期通过事件和回调的方式来处理，这种方式减少了线程量降低阻塞，因此开销比较小。
Kong（OpenResty）
为什么将OpenResty和Kong放在一起，是因为Kong是基于OpenResty开发的，Kong是一款基于OpenResty（Nginx + Lua模块）编写的高可用、易扩展的，由Mashape公司开源的API Gateway项目。Kong是基于NGINX和Apache Cassandra或PostgreSQL构建的，能提供易于使用的RESTful API来操作和配置API管理系统，所以它可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对大批量的网络请求。
SCG
酱酱，SCG也就是 SpringCloudGateway 的首字母缩写，是Spring Cloud的一个全新的API网关项目，目的是为了替换掉Zuul1，它基于Spring5.0 + SpringBoot2.0 + WebFlux（基于⾼性能的Reactor模式响应式通信框架Netty，异步⾮阻塞模型）等技术开发，性能⾼于Zuul，官⽅测试，Spring Cloud GateWay是Zuul的1.6倍，旨在为微服务架构提供⼀种简单有效的统⼀的API路由管理⽅式。SCG也就是咱们本期系列着重要学习的网关。
在面试几种主流API网关的差异性对比，大家在做技术选型的时候可以借鉴、参考。
3、SCG 网关
3.1、SCG简介
SCG的官网地址：https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.1.RELEASE/reference/html/
下面是来自官网的介绍
This project provides an API Gateway built on top of the Spring Ecosystem, including: Spring 5, Spring Boot 2 and Project Reactor. Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.Spring Cloud Gateway是Spring Cloud 的二级子项目，可以与Spring Cloud Discovery Client（如Eureka）、Ribbon、Hystrix等组件配合使用，实现路由转发、负载均衡、熔断、鉴权、路径重写、⽇志监控等，并且Gateway还内置了限流过滤器，实现了限流的功能。
SpringCloud Gateway 作为 Spring Cloud 生态系统中的网关，目标当然是是替代 Zuul，在Spring Cloud 2.0以上版本中，没有对新版本的Zuul 2.0以上最新高性能版本进行集成，仍然还是使用的Zuul 2.0之前的非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
SpringCloud官方，对SpringCloud Gateway 特征介绍如下，由此可见，SpringCloudGateway和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的区别，还是在底层的通信框架上。
（1）基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0
（2）集成 Hystrix 断路器
（3）集成 Spring Cloud DiscoveryClient
（4）Predicates 和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters
（5）具备一些网关的高级功能：动态路由、限流、路径重写3.2、名词解释
Filter （过滤器）
和Zuul的过滤器在概念上类似，可以使用它拦截和修改请求，并且对上游的响应，进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
Route （路由）
网关配置的基本组成模块，和Zuul的路由配置模块类似。一个Route模块 由一个 ID，一个目标 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目标URI会被访问。
Predicate （断言）
这是一个 Java 8 的 Predicate，可以使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。
3.3、工作方式
下图是 Spring Cloud Gateway工作方式的高级概述。如图所示，客户端向 Spring Cloud Gateway 发出请求。再由网关处理程序 Gateway Handler Mapping 映射确定与请求相匹配的路由，将其发送到网关 Web 处理程序 Gateway Web Handler 。该处理程序通过指定的过滤器链将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器由虚线分隔的原因是，过滤器可以在发送代理请求之前和之后运行逻辑。所有 pre 过滤器逻辑均被执行。然后发出代理请求。发出代理请求后，将运行 post 过滤器逻辑。
今天的SpringCloudGateway开篇就到这里。从广义网关引入API网关，以及为什么要有API网关。通过详详细介绍API网关的职能、分类和功能知道了API网关所要具备的能力。后面也介绍了API网关的设计思路和选型，最后引入本次系列的目标对象SpringCloudGateway，下一篇咱们展开实战，从最基本的使用开始说起，敬请期待！
参考资料：
https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.1.RELEASE/reference/html/
https://blog.csdn.net/rain_web/article/details/102469745
还有其他的资料太多了没有贴，感谢大家的分享。