Nginx、Kong、Apisix、Gateway网关比较

Nginx

Nginx是一款高性能的http 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。能够支撑 5 万并发链接，并且 cpu、内存等资源消耗却非常低，运行非常稳定，由C语言编写。支持负载均衡、限流熔断、热部署、安全认证等。

应用场景

1. http 服务器：独立提供 http 服务，用于做网页静态服务器
2. 虚拟主机：可以实现在一台服务器虚拟出多个网站
3. 反向代理，负载均衡：多台服务器集群可以使用 nginx 做反向代理

缺陷

1. Nginx不支持集群管理
2. Nginx不支持配置的热加载。修改配置重新加载Nginx的时间可能需要半个小时以上

正向代理服务器位于客户端和服务器之间，为了向服务器获取数据，客户端要向代理服务器发送一个请求，并指定目标服务器，代理服务器将目标服务器返回的数据转交给客户端。正向代理代理的是客户端，我们需要在客户端进行一些代理的设置。

反向代理我们只需要将请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据后，在返回给客户端，此时反向代理服务器和目标服务器对外就是一个服务器，暴露的是代理服务器地址，隐藏了真实服务器IP地址。反向代理代理的是服务器，作为客户端的我们是无法感知到服务器的真实存在的。

Kong 

Kong是一款基于OpenResty（Nginx + Lua模块）编写的高可用、易扩展的Gateway项目。Kong是基于Nginx和Apache Cassandra或PostgreSQL构建的，能提供易于使用的RESTful API来操作和配置API管理系统，所以它可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对大批量的网络请求。解决了Nginx问题，支持集群部署和热加载。

支持使用插件进行定制功能，但插件基于lua编写，不易维护，目前官网提供的基础插件有：HTTP基本认证、密钥认证、文件日志、API请求限流、请求转发以及Nginx监控。

相关组件

1. Kong Server：基于nginx的服务器，用来接收API请求。
2. Apache Cassandra/PostgreSQL：用来存储操作数据。
3. Kong dashboard：官方推荐UI管理工具，当然，也可以使用restfull方式管理admin api

Kong的网关架构

1. Kong核心基于OpenResty构建，实现了请求/响应的Lua处理化
2. Kong插件拦截请求/响应
3. Kong Restful管理API提供了API/API消费者/插件的管理
4. 数据中心用于存储Kong集群节点信息、API、消费者、插件等信息，目前提供了PostgreSQL和Cassandra支持，如果需要高可用建议使用Cassandra
5. Kong集群中的节点通过gossip协议自动发现其他节点，当通过一个Kong节点的管理API进行一些变更时也会通知其他节点。每个Kong节点的配置信息是会缓存的，如插件，那么当在某一个Kong节点修改了插件配置时，需要通知其他节点配置的变更。

缺陷

1. Kong需要依赖于PostgreSQL或Cassandra数据库，这使Kong的整个架构非常臃肿，会带来高可用的问题。如果数据库故障了，那么整个API网关都会出现故障。
2. Kong的路由使用的是遍历查找，当网关内有超过上千个路由时，它的性能就会出现比较急剧的下降。

APISIX

Apache APISIX基于 nginx（openresty）和 Lua 实现的一款国产软件，是一个动态、实时、高性能的云原生API网关，提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。可以使用ApacheAPISIX处理传统的南北向流量，也可以处理服务间的东西向流量。同时，它也支持作为K8s Ingress Controller来使用。

主要特性

1. 全动态能力：APISIX支持热加载
2. 高性能路由匹配算法：使用压缩前缀树RadixTree，当对某个请求进行匹配时，RadixTree将采用层层递进的方式进行匹配，其复杂度为O(K)（K是路由中URI的长度，与API数量多少无关）。当进行IP匹配时使用Hash的方式进行查找，时间复杂度为O(1)，性能更高。
3. 精细化路由：APISIX支持使用Nginx内置变量做为路由的匹配条件，你可以自定义匹配函数来过滤请求，匹配路由。
4. 运维友好：APISIX支持与以下工具和平台集成：Zipkin、SkyWalking、Consul、Nacos、Eureka。通过APISIXDashboard控制台，运维人员可以通过友好且直观的UI配置APISIX。
5. 支持多语言插件：目前官网支持80多种插件（grpc、serverless、skywalking、kafka、es等），也支持通过PluginRunner或者Wasm（运行字节码文件）自定义插件。

APISIX网关架构

数据面：它是真正去处理来自客户端请求的一个组件，去处理用户的真实流量，包括像身份验证、证书卸载、日志分析和可观测性等功能。数据面本身并不会存储任何数据，所以它是一个无状态结构。如果监听etcd的配置信息变更，APISIX就可以将获取最新配置的时间控制在毫秒级别之内，达到实时生效。

控制面：使用etcd存储配置，能更好地体现高可用特性，拥有低于毫秒级别的变化通知。

应用场景

负载均衡和API网关

具备高性能、安全等特性，在负载均衡的服务能力上也更优秀。从Nginx切换到APISIX不仅性能不会下降，而且可以享受到动态、统一管理等特性带来的管理效率的提升。

微服务网关

支持多种语言编写扩展插件，可以解决东西向微服务API网关面临的主要问题（异构多语言和通用问题）。内置支持的服务注册中心有Nacos、Eureka等，可以平滑替代Zuul、Gateway等微服务API网关。（东西向微服务指系统内各个微服务间的调用）

K8s Ingress

官网的 Ingress主要基于Nginx配置文件的方式，使用APISIX Ingress Controller可以支持全动态，无需重启加载。同时继承了APISIX的所有优势，还支持原生KubernetesCRD，方便用户迁移。

Gateway

API网关为微服务架构的系统提供简单、有效 且统一的API路由管理，作为系统的统一入口，提供内部服务的路由中转，给客户端提供统一的服务，可以实现一些和业务没有耦合的公用逻辑，主要功能包含认证、鉴权、路由转发、安全策略、防刷、流量控制、监控日志等。

Gateway 是Spring Cloud官方推出的第二代网关框架，定位于取代 Netflix Zuul。旨在为微服务架构提供一种简单且有效的 API 路由的管理方式，并基于Filter 的方式提供网关的基本功能，例如说安全认证、监控、限流等等。Spring Cloud Gateway 是由 WebFlux + Netty + Reactor 实现的响应式的 API 网关。

相关概念

路由：路由是网关中最基础的部分，路由信息包括一个ID、一个目的URI、一组断言工厂、一组Filter组成

断言：断言函数允许开发者去定义匹配Http request中的任何信息，比如请求头和参数等。如果断言为真，则说明请求的URL和配置的路由匹配

过滤器：分为Gateway FilIer和Global Filter。Filter可以对请求和响应进行处理。默认支持的过滤器有：AddRequestHeader请求头，AddRequestParameter请求参数、RequestRateLimiter限流、Hystrix熔断、Retry重试等20多种过滤器，也支持自定义过滤器。

# 相关配置
spring:
  cloud:
    gateway:
      #设置路由：路由id、路由到微服务的uri、断言
      routes:
        - id: order_route  #路由ID，全局唯一，建议配置服务名
          uri: lb://mall-order  #lb 整合负载均衡器ribbon,loadbalancer
          predicates:
            - Path=/order/**   # 断言，路径相匹配的进行路由
          filters: #过滤器
			‐ AddRequestHeader=X‐Request‐color, red  #添加请求头过滤

工作原理

跟 Zuul 的差不多，最大的区别就是 Gateway 的 Filter 只有 pre和 post 两种。

客户端向 Spring Cloud Gateway 发出请求，如果请求与网关程序定义的路由匹配，则该请求就会被发送到网关Web 处理程序， 先执行pre过滤器，再执行代理请求，代理请求完成后执行post 过滤器逻辑。

网关选型

云原生领域APISIX更加优于Kong和Nginx，Apisix 是对标云原生网关的，严格来说和 Spring Cloud Gateway 这种业务形网关没什么可比性。

如果是小公司，架构简单，业务单一，则使用Gateway作为业务网关完全够用，而且还便于定制化扩展。若架构复杂，业务流量大，k8s容器化部署，对标云原生的则可以使用Apisix。也可以Apisix和gateway搭配使用，流量网关使用Apisix，业务网关使用gateway，使用流量网关对公网入口流量进行转发到业务网关，再由业务网关将请求转发至各个系统。