在日常工作中，不同的场合下，我们可能都会听说网关的概念，当然通常是指业务网关（API网关），负责API的输入和输出。有了业务网关之后，各个API服务提供者可以专注于自己的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。从功能层次我们又会联想到一个概念——代理。网关与代理的区别：代理本质是数据的透传，协议不会发生变化；网关在数据透传的背景下，还会涉及协议的转换，比如从HTTP到Dubbo。
那么作为一名架构师，我们该如何选型“业务网关”呢？我们自己先要学会做技术选型，自己预期有一个技术成本的预判，比如我推荐使用Spring Cloud Alibaba Spring Gateway，就是我自己作为一个架构师的技术预判。
Zuul
Zuul是Netflix开源的微服务网关，可以和Eureka、Ribbon、Hystrix等组件配合使用，Spring Cloud对Zuul进行了整合与增强，Zuul总共有两个大的版本：Zuul1.0和Zuul2.0，目前最新的版本为v2.2.0，Zuul1.0和Zuul2.0版本之间功能差异性非常大。
Netflix的Zuul包含如下功能：
- 身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求；
- 审查与监控：在边缘位置追踪有意义的数据和统计结果；
- 动态路由：动态地将请求路由到不同的后端集群；
- 压力测试：逐渐增加指向集群的流量，以了解性能；
- 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求；
- 静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群；
- 多区域弹性：跨越AWS Region进行请求路由，旨在实现ELB（Elastic Load Balancing）使用的多样化和以及让系统的边缘更贴近系统的使用者。
以上介绍来自Zuul官方文档，但其实开源版本的Zuul以上功能一个都没有——开源的Zuul只是几个Jar包而已，以上能力指的应该是Netflix官方自用的Zuul的能力；Netflix自用的Zuul能力是比较强大的，可使用Groovy编写过滤器，并且可动态加载/卸载、修改规则，而且使用Cassandra作为数据库，然而开源版本这些一个都没有；Spring Cloud中，Zuul绝大部分功能都是Spring Cloud团队为Zuul开发的；所以Zuul 2.x的开源进度延后一年，Spring Cloud团队开发了自己的SCG，并宣布Spring Cloud不打算支持Zuul 2.x，你还觉得意外吗？看到这里，很多人可能没有动力学习Zuul了，个人认为还是可以了解一下的，后面讲到SCG时，你会发现很多设计理念是相通的。
既然说到了Spring Cloud对Zuul的封装，那么我们来简单的分析下Spring Cloud与Zuul的关系。Spring Cloud通过Spring Cloud Netflix 1.X来封装Zuul1.0，1.X的最后一个版本是v1.4.7.RELEASE，对应的Zuul版本是1.3.1。Spring Cloud Netflix从3.X开始就没有封装Zuul网关，包括Zuul1.0和Zuul2.0，也就是说开发者想要通过Spring Cloud来复用Zuul，只能使用Zuul1.0，暂时不能复用Zuul2.0。
Zuul目前在github上的star数为10.2k，fork数为2k，也就是说还是有很多开源爱好者会基于Zuul来定制化业务网关。
除了开源的Spring Cloud定制化Zuul，开源微服务框架jhipster也参与了定制，并集成到它的生态中。Jhipster主要包含generator-jhipster和jhipster-registry，前者star数微17.7k，fork数为3.5k，后者star数为604，fork为607。
Zuul1.0整体架构设计如图所示。
Zuul2.0整体架构设计如图所示。
Spring Cloud Gateway
SCG是基于Spring Framework 5.0和Spring Boot 2.0构建的API网关，提供路由等功能。其旨在提供一种简单而有效的方法路由到API，并为它们提供跨领域的关注点，例如：安全性、监视/指标和弹性。
主要特性：
- Java8
- Spring Framework5
- Spring Boot2
- 动态路由
- Spring Handler Mapping内置的路由匹配
- HTTP请求的路由匹配（路径、方法、Header、主机等）
- 过滤器限定范围以匹配路由
- 过滤器可以修改下游HTTP请求和HTTP响应（添加、删除Header、添加/删除参数、重写路径、设置路径等）
- API或配置驱动
- 支持Spring Cloud Discovery Client配置路由
SCG的专业术语包括：
- 路由：它是基本构建模块，主要包含ID、URI、断言集合以及过滤器集合，如果能够匹配断言就会执行路由；
- 断言：主要是指Java8的函数式断言，输入类型是Spring Framework的ServerWebExchange，基于断言可以匹配基于headers或者parameters的http请求；
- 过滤器：它是通过特殊的工厂方法构造的基于Spring Framework GatewayFilter的实现，通过过滤器开发者可以在http请求下行之前修改请求响应参数，在请求响应返回之后可以修改响应的结果。
SCG整体架构设计如图所示。
自研网关
一个API网关的基本功能包括统一接入、协议适配、流量管控与容错，以及安全防护，这个四大基本功能构成了网关的核心能力。网关首要的功能是负责统一接入，然后将请求的协议转换成内部的接口协议，在调用的过程中还要限流、降级和熔断等容错的方式来保护网关的整体稳定，同时网关还要做到基本的安全防护（防刷控制），以及黑白名单（比如IP地址白名单）等基本的安全措施，主要包括：统一标准接入，具备高性能、高并发和高可靠性，具备负载均衡的能力；
除了基本的四个功能，网关运行良好的环境还包括注册中心（比如通过Nacos读取已经发布的API接口的动态配置）。为了实现高性能，将数据全部异构到缓存（比如Redis）中，同时还可以配合本机缓存来进一步的提高网关系统的性能。为了提高网关的吞吐率，可以使用NIO Servlet3异步的方式，还可以利用Servlet3的异步特性将请求线程与业务处理线程分开，为后续的线程池隔离做好基本的支撑。访问日志的存储我们可以放到Hbase或者ES中，如果要作为开放网关使用，那么需要一个支持OAuth2.0协议的授权中心，同时还可以引入Nginx Lua的方式，将一些基本的校验判断前置到应用系统之上，这样可以更加轻量级的处理网关接入的问题。
主要包括接入层，开发者可以通过Nginx和Lua脚本，解决限流、黑白名单、路由、负载均衡、长短连接以及容灾切换的问题。网关需要保证服务的稳定性，需要接入注册中心，因为本书是Spring Cloud Alibaba的布道书籍，所以强烈推荐使用Nacos作为注册中心和配置中心。统一的鉴权中心，主要是统一解决网关为各个API服务的鉴权问题，当然可以按照服务维度做隔离，自定义鉴权规则。统一用户中心主要是解决用户登录问题，确保微服务调用的安全性。
自研网关还需要有泛化功能，使用者在调用提供者的接口的时候，不再需要API提供者的客户端JAR包，因此也就没有了POJO，通过泛化的方式进行远程调用。一般情况下我们要通过RPC调用接口提供方的服务，首先在系统中嵌入接口提供者的JAR包，然后使用JAR包里面的类和方法。对于一个网关系统来说，如果要调用N个接口，就需要N个JAR包，这样的网关是很难维护的，当然Dubbo RPC是支持泛化的。
网关要具备时间校验、方法校验、版本校验和签名校验等功能，当然网关还需要具备服务降级、日志记录以及监控与告警功能。
对比以上三种网关
网关 | 限流 | 鉴权 | 监控 | 易用性 | 可维护性 | 成熟度 |
|---|---|---|---|---|---|---|
SCG | 可以通过IP，用户，集群限流，提供了相应的接口进行扩展 | 普通鉴权auth2.0 | Gateway Metrics Filter | 简单易用 | Spring系列可扩展强，易配置和可维护性好 | Spring社区成熟，但Gateway资源少。 |
Zuul2 | 可以通过配置文件配置集群限流和单服务器限流，也可以通过filter实现限流扩展 | filter中实现 | Filter中实现 | 参考资料比较少 | 可维护性差 | 开源不就资源少。 |
Zuul1 | 同上 | 同上 | 同上 | 同上 | 同上 | 同上 |
自研网关 | 需要开发 | 需要开发 | 需要开发 | 需要开发 | 可维护性极高 | 需要开发 |
总结
推荐使用Spring Cloud Alibaba Spring Cloud Gateway，可以更加高效的利用Spring Cloud ALibaba的服务治理能力去融合网关API的治理，从而提升业务服务API的系统稳定性。
公众号初衷
知识输出是笔者的初衷，借助知识输出，能够认识更多的牛人,能够和牛人沟通，也是自己技术提升的一个机会。
