跳到主要内容
版本：3.6.x

服务

一个服务代表了一个后端应用或外部的微服务。它本质上将该应用或微服务提供的所有 API 进行了分组。以下是几个和服务有关的关键关系：

  • 路由（Route）与四层路由（Stream Route）：大多数服务与路由或四层路由（二者不能共存于一个服务之内）之间是一对多的关系。这意味着一个服务可以与多个路由或流路由关联，定义了传入的 API 请求如何被导向到服务内的相应功能。

  • 上游： 通常，服务与上游保持一对一的关系。上游充当容器，指定处理服务请求的后端服务器的地址。但是，对于高级场景（例如灰度部署、蓝绿部署或管理多个集群），服务可能会使用多个上游。在这种情况下，默认上游充当大多数请求的主要目标，而其他上游可用于特定目的，例如将流量路由到金丝雀部署或辅助集群。

信息

对于熟悉 Apache APISIX 的人来说，需要注意的是，API7 企业版中的服务对象与 Apache APISIX 中的服务对象是不同的。

服务工作原理​

下图展示了一个已发布的服务，该服务架构了一个宠物店（Petstore）服务。该服务具有两个具有分别配置的路由。你可以使用 HTTP GET 方法从该服务获取相关数据。


Services Diagram


本示例仅将流量转发到一个上游节点。你可以根据需要为服务添加更多上游节点，以维持平稳的运行和响应，同时防止单点故障。

服务状态​

一个服务可以有多个版本，每个版本有三种状态：模板、已发布和历史。这些状态代表了服务的整个 API 生命周期。每个服务都有自己的版本号体系。如果版本号相同，则说明服务的表现完全相同。

模板​

模板是初始状态，代表最新的未发布配置草案。模板中的 API 不可访问，也没有特定的版本号。

已发布​

将模板发布到网关组会创建一个具有唯一版本号的已激活版本。已发布版本中的 API 和网关组绑定，用户可以访问网关组内的 API，但是只能编辑其运行时配置（主机、路径前缀和上游节点）。更新正在运行中的 API 时，必须发布新的服务版本。模板更改不会影响已发布的版本。

历史​

发布新版本时，以前的版本会转换为历史版本。请注意，一个服务不能同时在网关组中拥有两个已激活版本，但不同的网关组可以同时运行不同的版本。

历史版本为问题追踪提供了对过去配置的可见性，但不可编辑。它们主要用于紧急回滚。

历史版本不包括运行时配置。回滚时会保留当前值。

运行时配置​

以下配置被归类为运行时配置。这是因为当同一服务版本发布到不同网关组时，它们可能会有不同的值，而且可以在网关组内直接编辑。这些配置并不构成不同的版本。

  • 上游配置
  • 服务主机
  • 路径前缀
  • 是否忽略路径前缀
  • 插件
  • 路由超时配置

请注意，服务运行时配置可以针对每个网关组进行自定义，从而允许进行特定于环境的调整。这些配置与服务版本和服务模板无关，并且在每个网关组内独立管理。

备注

例如

  • 测试环境中的 API URL 是 https://api7-test.ai/v1/pet，节点地址是 127.0.0.1:80。
  • 生产环境中的 API URL 是 https://api7.ai/petstore/pet，节点地址是 192.168.0.1:80。

服务ID vs 服务模板ID​

API7 企业版为服务使用了两个关键标识符：服务模板ID 和 服务ID，以及为路由和四层路由使用了类似的标识符。

  • 服务模板仅有 服务模板ID。服务模板中的路由/四层路由仅有 路由模板ID/四层路由模板ID。
  • 网关组上已发布的服务同时具有 服务模板ID 和 服务ID，用于不同的用途。已发布服务中的路由/四层路由同时具有 路由模板ID/四层路由模板ID 和 路由ID/四层路由ID。
  • 历史版本仅有 服务模板ID。历史版本中的路由/四层路由仅有 路由模板ID/四层路由模板ID。

相比之下，服务ID 是特定于某个网关组中已发布的服务。你可以通过 ADC、管理 API 或 Ingress Controller 直接创建已发布的服务时自定义此 ID。

请注意，服务ID 仅在其所属的网关组内唯一。不同网关组上的两个已发布服务可以具有相同的 服务ID（不推荐）。 服务ID 不能用于权限策略。

服务模板ID 是自动生成的，作为在所有网关组中持久存在的唯一且不可变的标识符，用于服务版本控制。 此 ID 适用于服务本身，包括服务模板、所有网关组中的所有已发布版本以及所有历史版本。 它在权限策略中起着至关重要的作用，允许你根据服务的身份分配资源。

备注

路由ID vs 路由模板ID，四层路由ID vs 四层路由模板ID 类似。

相关阅读​