关于后端:Spring-Cloud-Gateway与Apache-APISIX的对比

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

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

Spring Cloud Gateway 的办法齐全不同。它只是对惯例 Spring 我的项目的惯例依赖：

<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 具备丰盛的模型：

特地是，您能够创立 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 通过过滤器实现性能。如果具体的一一性能比拟超出了一篇文章的范畴，咱们简略概括如下。

个性	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`
Response headers manipulation	`AddResponseHeader``DedupeResponseHeader`RewriteLocationResponseHeader`RemoveResponseHeader`RewriteResponseHeader`SetResponseHeader`SetStatus	`response-rewrite`
Redirection	`RedirectTo`	`redirect`
JSON gRPC transcoding	`JsonToGrpc`	`grpc-transcode`
Body manipulation	`ModifyRequestBody``ModifyResponseBody`Only available via code	`response-rewrite`Only the response can be modified
Resiliency	`CircuitBreaker``Retry`	`api-breaker`
`RequestRateLimiter`No configuration via “shortcut” notation	`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 我的项目中应用它，只需增加依赖项：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
    <version>3.1.0</version>
</dependency>

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

<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 等集成。

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

可用性是相当主观的，但我没有留神到我的示例演示中有显着差别。这是个别设计，伪装模拟微服务架构。

不过，我略微扭转了实现，以利用网关。我没有调用定价 / 库存组件的目录，而是调用网关来转发呼叫。此外，我想避免内部调用者拜访定价和库存：只容许目录。

此要求的多种实现形式都是可能的。在事实场景中，我可能会应用基于 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 图表。

本文由 mdnice 多平台公布

关于后端:Spring-Cloud-Gateway与Apache-APISIX的对比

前言

应用 Spring Cloud Gateway 的第一步

概念和形象

如何配置

个性比拟

可察看性

可用性

论断