前言

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

使用 Spring Cloud Gateway 的第一步

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

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

xml复制代码<dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-gateway</artifactId>
      <version>4.0.6</version>
</dependency>

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

概念和抽象

Apache APISIX 具有丰富的模型：

format_png

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

这是 Spring Cloud Gateway 模型：

format_png 1

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

如何配置

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

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

示例：

yaml复制代码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 项目的所有配置选项，并且它们很多。

Properties复制代码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配置如下，这是与上面相同的配置：

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 通过过滤器实现功能。如果详细的逐个功能比较超出了一篇文章的范围，我们简单概括如下。

特性	SPRING GATEWAY	APACHE APISIX
Request headers manipulation	AddRequestHeader`AddRequestHeadersIfNotPresent`RemoveRequestHeader`SetRequestHeader`MapRequestHeader`SecureHeaders`FallbackHeaders`SetRequestHostHeader`PreserveHostHeader`AddRequestParameter`RemoveRequestParameter	proxy-rewrite
Path manipulation	StripPrefix`PrefixPath`RewritePath`SetPath</p> </td> <td> <p></p> </td> </tr> <tr> <td> <p>Response headers manipulation</p> </td> <td> <p>AddResponseHeader`DedupeResponseHeader`RewriteLocationResponseHeader`RemoveResponseHeader`RewriteResponseHeader`SetResponseHeader`SetStatus</p> </td> <td> <p>response-rewrite</p> </td> </tr> <tr> <td> <p>Redirection</p> </td> <td> <p>RedirectTo</p> </td> <td> <p>redirect</p> </td> </tr> <tr> <td> <p>JSON gRPC transcoding</p> </td> <td> <p>JsonToGrpc</p> </td> <td> <p>grpc-transcode</p> </td> </tr> <tr> <td> <p>Body manipulation</p> </td> <td> <p>ModifyRequestBody`ModifyResponseBodyOnly available via code	response-rewriteOnly the response can be modified
Resiliency	CircuitBreaker`Retry</p> </td> <td> <p>api-breaker</p> </td> </tr> <tr> <td> <p>RequestRateLimiter<em>No configuration via "shortcut" notation</em></p> </td> <td> <p>limit-count`limit-conn``limit-request
-	fault-injection
Caching	LocalResponseCache	proxy-cache

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 项目中使用它，只需添加依赖项：

xml复制代码<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
    <version>3.1.0</version>
</dependency>

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

xml复制代码<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
    <version>1.11.0</version>
</dependency>

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

用于追踪：zipkin、skywalking和opentelemetry
对于指标：prometheus、node-status和datadog
用于日志记录：太多，无法详尽列出，但与 Kafka、Elasticsearch、Splunk、Google Cloud、ClickHouse 等集成。

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

可用性

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

format_png 2

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

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

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

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

启动项目：

shell复制代码docker compose up

然后，测试一下：

bash复制代码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 图表。