跳到主要内容
版本：3.2.9.5

网关组

概述​

网关组由一组（一个或者多个）共享相同配置的网关实例组成，这些网关实例在处理 API 请求时的行为是一致的。

对于简单的使用场景，比如只有一个 API 网关集群，只有生产环境而没有 UAT、Staging 等其他环境时，不需要使用网关组的功能，使用内置的默认网关组功能即可满足需求。

网关组适用于复杂的场景，比如对不同的子公司、业务线、集群、环境等配置不同的 API 策略，并对它们进行单独管理和维护时。需要注意的是，API7 企业版中并没有多集群、多环境等概念，但是用户可以通过对网关组的命名和添加标签来实现对环境和集群的区分和管理。

一个网关组内可以包含一个或多个网关实例，但每个网关实例只能属于某一个网关组。不同的网关实例可以部署在同一台或不同的虚拟机、裸金属或者 Kubernetes 节点上。通过灵活的排列组合，可以满足用户对于多业务线、多集群、多工作分区、多环境等复杂场景的需求。

如下图所示，假设一个公司有两个团队在使用 API 网关，分别是 Payment Team 和 Quote Team。其中 Payment Team 有两个环境：生产（Prod）环境和 UAT 环境；Quote Team 只有一个生产（Prod）环境。在这种情况下，可以创建三个网关组：Payment Prod, Payment UAT, Quote Prod，并为它们添加 Env:Prod 和 Env:UAT 的标签来进行区分管理。

Gateway Groups

主要特性​

  • API 网关组管理：将一个或多个 API 网关作为一个逻辑单元进行管理，网关组内的网关共享相同的配置。这确保了整个网关组内的所有网关实例都执行一致的策略和规则，并且简化了管理。

  • 业务导向的网关分区：使用网关组来划分企业的业务线和解决方案，实现了 API 基础架构与组织功能域之间的更好对接。这种架构方法有利于提高 API 基础设施与业务需求之间的契合度。

  • 物理隔离：网关组允许在不同的物理环境（包括数据中心、云平台和虚拟机）中部署多个 API 网关实例。这种物理隔离有效地避免了网关组之间的干扰，增强了系统的稳定性和安全性。

  • 弹性扩展：网关组允许根据流量波动动态地调整 API 网关实例的数量，以满足业务需求。这有助于提高资源利用率，降低整体的运营成本。

  • 可扩展和灵活的基础架构：将 API 网关组的逻辑架构与网关实例的物理结构解耦，这种方法为 API 基础设施提供了更大的灵活性和可扩展性。

  • 细粒度权限控制：网关组支持对不同网关实例和 API 设置差异化的权限配置，能实现更精细的权限管控，并满足合规要求。

使用场景​

1. 更方便地区分和管理 Dev、Test、UAT、 Prod 等不同的环境​

API 的发布和上线，可能会经历不同的阶段和环境，这和不同公司的 API 管理流程有关。假设你的公司有开发（Dev）、测试（Test）、验收（UAT）、生产（Prod）这四个环境，在没有网关组的情况下，需要部署 4 套 API7 企业版，它们的控制平面和数据平面是完全独立的。开发工程师、QA 工程师和运维工程师需要分别登录不同域名下的 API7 企业版控制台，对同一个 API 进行开发、测试和上线。这种方式的缺点很明显：如果有 5 条业务线，每条业务线有 4 个环境，就需要部署 20 套 API7 企业版，会浪费大量机器和管理资源。

使用 API7 企业版的网关组可以轻松地解决这一问题。你可以创建 20 个不同的网关组，命名规则为“业务线名字 + 环境名字”，并对它们添加标签进行过滤和筛选。同时，你还可以通过 RBAC 功能给用户设置网关组的权限，确保开发工程师只能修改开发环境的配置，实现更精细的权限管控。

2. 统一管理不同区域的多个集群​

对于有全球客户的公司而言，管理位于多个区域、 不同集群的 API 服务，并保证数据的合规，并非易事。假设你的公司有北美（NA）、欧洲（EU）和亚太地区（APAC）三个区域，每个区域中有 4 个生产环境的集群，这就意味着需要维护 12 套 API 网关的控制平面和数据平面。这些 API 网关的大部分配置是一致的，但涉及日志存储、密钥管理、可观测性等与加密、隐私和合规相关的配置可能并不统一。

通过 API7 企业版的网关组功能，用户可以在统一的控制平面上管理和配置所有区域中的网关集群。同时，用户可以使用环境变量、服务发现、注册中心等方式，尽量统一网关组的个性化配置，从而降低维护成本。

此外，API7 企业版支持多层网络，例如，当美国用户 John 在欧洲登录时，部署在欧洲区域的 API 网关集群能够根据用户 ID 识别 John 的请求应该由北美集群处理，并将重定向至北美区域的 API 网关。这种多层网络的方式有助于确保数据的合规性。

3. 为不同的业务线设置和实现差异化的服务级别目标​

不同业务线的服务往往会有不同的服务级别目标。例如，支付服务的服务级别目标可能达到 99.999%，而历史订单服务的服务级别目标可能为 99%。基础架构和运维团队可以针对不同服务的服务级别目标需求，采取差异化的部署和管理策略。

对于关键性服务（如支付服务），你可以在多个区域中部署多份，为其网关组分配更多更优质的实例资源。同时，还可以为它设置更敏感的告警策略和更详细的可观测性指标，以确保服务的高可用性。

而对于服务级别目标相对较低的服务（如历史订单服务），可以采取更轻量级的部署策略，并设置更为宽松的告警和监控措施，从而降低资源投入。

相关阅读​