网关选型对比

一、为什么使用网关

  不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会有以下的问题：
  1）客户端会多次请求不同的微服务，增加了客户端的复杂性
  2）存在跨域请求，在一定场景下处理相对复杂
  3）认证复杂，每个服务都需要独立认证
  4）难以重构，随着项目的迭代，可能需要重新划分微服务
  5）某些微服务可能使用了防火墙 / 浏览器不友好的协议，直接访问会有一定的困难
  典型的网关架构如下：

二、常见网关对比

1、Nginx
1）处理流程

2）进程间通信

2、Zuul
  Zuul 是 Netflix 开源的微服务网关组件，它可以和 Eureka、Ribbon、Hystrix 等组件配合使用,Zuul 的核心是一系列的过滤器，这些过滤器可以完成以下功能：
  1）身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。
  2）审查与监控：与边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
  3）动态路由：动态地将请求路由到不同的后端集群。
  4）压力测试：逐渐增加指向集群的流量，以了解性能。
  5）负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。
  6）静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群。
  7）多区域弹性：跨越 AWS Region 进行请求路由，旨在实现 ELB（Elastic Load Balancing，弹性负载均衡）使用的多样化，以及让系统的边缘更贴近系统的使用者。
Zuul1 ：基于 Servlet 框架构建，采用的是阻塞和多线程方式

Zuul2：运行在异步和无阻塞框架上，每个 CPU 核一个线程，处理所有的请求和响应，请求和响应的生命周期是通过事件和回调来处理的，这种方式减少了线程数量，因此开销较小。又由于数据被存储在同一个 CPU 里，可以复用 CPU 级别的缓存

3、SpringCloud Gateway
  zull从开源到闭源再到开源，对外表现出很不稳定，springcloud 推出了自己的网关springcloud gateway来应对这种不靠谱，其使用webflux，底层使用netty做异步和回调处理，即使单节点也支持大量的并发连接，基于Filter的机制可自定义业务处理逻辑，详情见使用文档
https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#gateway-starter
4、Kong
  Kong是一款基于Nginx_Lua模块写的高可用，易扩展由Mashape公司开源的API Gateway项目。由于Kong是基于Nginx的，所以可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对大批量的网络请求，主要有三个组件：
  1）Kong Server ：基于nginx的服务器，用来接收API请求
  2）Apache Cassandra/PostgreSQL ：用来存储操作数据
  3）Kong dashboard：官方推荐UI管理工具，当然，也可以使用 restfull 方式 管理admin api
  Kong采用插件机制进行功能定制，插件集（可以是0或n个）在API请求响应循环的生命周期中被执行。插件使用Lua编写，目前已有几个基础功能：HTTP基本认证、密钥认证、CORS（ Cross-origin Resource Sharing，跨域资源共享）、TCP、UDP、文件日志、API请求限流、请求转发以及nginx监控
  1）Kong 官网：https://getkong.org/ 插件介绍，帮助文档等。
  2）Kong 源码：https://github.com/Mashape/kong
  3）Kong UI管理工具：https://github.com/PGBI/kong-dashboard 浏览器UI管理工具
  4）Kong 桌面管理工具：https://github.com/ajaysreedhar/kongdash 有linux版本，windows版本，mac版本。

相关推荐：
1、注册中心选型对比
2、配置中心选型对比
3、网关选型对比
4、远程调用选型对比
5、分布式数据一致性
6、消息队列选型对比
7、监控工具选型对比
8、全链路追踪选型对比