Spring Cloud Gateway与Apache APISIX的对比

前言

市场上可用的 API 网关的数量很多，网上经常会讨论哪个更好。在这篇文章中，将会分享 Spring Cloud Gateway 与 Apache APISIX 的比较。

使用 Spring Cloud Gateway 的第一步

我所知道的所有 API 网关都提供 Docker 镜像。例如，Apache APISIX 提供三种风格：Debian、CentOS 以及最近的 Red Hat。此时，您可以开始在容器化架构中部署镜像。

Spring Cloud Gateway 的方法完全不同。它只是对常规 Spring 项目的常规依赖：

      org.springframework.cloud
      spring-cloud-starter-gateway
      4.0.6

您可以利用所有标准方法来创建项目，包括流行的 start.spring.io，就像任何常规 Spring 项目一样。这种面向开发人员的方法普遍存在于与 Spring Cloud Gateway 相关的所有项目中。

概念和抽象

Apache APISIX 具有丰富的模型：

特别是，您可以创建Upstream抽象并在不同的路由之间共享它。同样，Plugin Config允许您创建可重用的插件组合。

这是 Spring Cloud Gateway 模型：

APISIX 模型更丰富，具有抽象和重用的可能性。

如何配置

Apache APISIX 有两种部署模式（实际上是三种，但我们不详细介绍）：传统部署模式和独立部署模式。

在传统模式下，APISIX 将其配置存储在etcd中。APISIX 提供了丰富的 API 来访问和更新配置，即Admin API。在独立模式下，配置只是普通的 YAML。这是 GitOps 从业者的方法：您将配置存储在 Git 存储库中，通过您最喜欢的工具（例如，Argo CD 或 Tekton）观看它，后者会在发生更改时将更改传播到 APISIX 节点。APISIX 大约每秒重新加载其配置。

示例：

upstreams:
  - id: 1
    nodes:
      "catalog:8080": 1
  - id: 2
    nodes:
      "pricing:8080": 1

routes:
  - uri: /v1/products*
    upstream_id: 1
    plugins:
      proxy-rewrite:
        regex_uri: ["/v1(.*)", "$1"]
  - uri: /prices*
    upstream_id: 2
    plugins:
      referer-restriction:
        whitelist:
          - catalog.me

global_rules:
  plugins:
    prometheus:
      prefer_name: true

Spring Cloud Gateway 支持常规 Spring 项目的所有配置选项，并且它们很多。

spring.cloud.gateway.routes[0].id=products
spring.cloud.gateway.routes[0].uri=http://catalog:8080
spring.cloud.gateway.routes[0].predicates[0]=Path=/v1/products*
spring.cloud.gateway.routes[1].id=pricing
spring.cloud.gateway.routes[1].uri=http://pricing:8080
spring.cloud.gateway.routes[1].predicates[0]=Path=/prices*
spring.cloud.gateway.routes[1].predicates[1]=Header=Referer, http://catalog.me

YAML配置如下，这是与上面相同的配置：

spring.cloud.gateway.routes:
  - id: products
    uri: http://catalog:8080
    predicates:
      - Path=/v1/products*
    filters:
      - StripPrefix=1
  - id: pricing
    uri: http://pricing:8080
    predicates:
      - Path=/prices*
      - Header=Referer, http://catalog.me

当配置发生更改时，Spring 应用程序默认不会重新加载其配置。

对于 Apache APISIX，您还可以通过端点动态创建更新和删除路由/actuator。但是，API 没有提供PATCH方法：如果有更新，您需要更新整个路线。

特性比较

Apache APISIX 通过插件实现功能，而 Spring Cloud Gateway 通过 过滤器 实现功能。如果详细的逐个功能比较超出了一篇文章的范围，我们简单概括如下。

Apache APISIX 和 Spring Cloud Gateway 提供或多或少相同的功能集。对于常见的功能，Spring的方式更加细化，每个操作都有一个专门的过滤器。相比之下，APISIX 提供了一个带有许多配置选项的插件，但用于速率限制。

一些插件是 Spring 特定的，例如*.* , SaveSession- APISIX 没有这样的集成。相反，APISIX 提供了许多用于使用不同第三方服务进行身份验证的插件，例如*.* 、KeyCloak、OpenId Connect 等。Spring Cloud Gateway 通过 Spring Security 依赖项来实现。

如果某个功能无法开箱即用，则可以使用适用于 APISIX 的 Lua 以及适用于 Spring 的 JVM 语言开发自定义插件。

可观察性

Spring Cloud Gateway 和 Apache APISIX 之间的可观察性实现存在很大差异。

第一个依赖于Actuator，它提供了大量与可观察性相关的功能。要在任何 Spring Boot 项目中使用它，只需添加依赖项：

    org.springframework.boot
    spring-boot-starter-actuator
    3.1.0

要为 Prometheus 消耗提供指标，请添加以下 Micrometer 依赖项：

    io.micrometer
    micrometer-registry-prometheus
    1.11.0

另一方面，Apache APISIX 使用相同的插件系统来实现可观察性功能：

这两种产品都涵盖了可观察性的三大支柱，并提供了与第三方后端的许多集成。

可用性

可用性是相当主观的，但我没有注意到我的示例演示中有显着差异。这是一般设计，假装模仿微服务架构。

不过，我稍微改变了实现，以利用网关。我没有调用定价/库存组件的目录，而是调用网关来转发呼叫。此外，我想防止外部调用者访问定价和库存：只允许目录。

此要求的多种实现方式都是可能的。在现实场景中，我可能会使用基于 TLS 的身份验证。对于这个演示，我选择传递一个可配置的标头。

Prometheus 废弃了网关的指标。Apache APISIX 提供专用端口和线程，因此常规路由和观察是解耦的。您还可以自定义端点的路径。Spring Cloud Gateway 使用相同的端口，但使用特定的路径 ，/actuator您可以自定义该路径。您还可以通过属性更改整个执行器的端口management.server.port。

该项目提供两个分支：apisix和spring。要使用它，请查看两个分支之一。

启动项目：

docker compose up

然后，测试一下：

curl localhost:8080/products

两个分支应该产生相同的结果。

我添加了 Grafana 仪表板。请注意，Spring 不会输出任何可用的内容。

结论

Spring Cloud Gateway 和 Apache APISIX 是两个 API 网关，提供或多或少相同的功能集。然而，他们的使用方法却截然不同。

Spring Cloud Gateway 源于 Spring 框架和 Spring Boot 平台，本质上专注于已经熟悉 Spring 的开发人员。如果你熟悉Spring的开发模式，很容易就可以上手。出于性能原因，Spring Cloud Gateway 使用 Spring WebFlux 实现非阻塞 I/O，而 Spring WebFlux 依赖于 Project Reactor。如果您需要使用代码编写重要的逻辑并且您不熟悉Mono和，那么这将是一次充满挑战的旅程。

Apache APISIX 更适合常规 Ops 配置文件，以他们熟悉的包装提供产品：Kubernetes 的 Docker 映像和 Helm 图表。