网关组与网关实例
在本文档中，你将了解网关组（Gateway Groups）和网关实例（Gateway Instances）的概念和用途，这是 API7 企业版中一项高级且独有的功能。
概览
网关实例是处理流量的单个代理，而网关组是组合了一个或多个 API 网关实例的逻辑单元。这可确保整个组内的 API 处理保持一致，并简化管理。网关组内的多个网关实例独立运行，以实现水平扩展和负载均衡。尽管使用了集中式配置，网关实例之间并不共享状态。
对于只有一个集群或生产环境的简单场景，默认的网关组就足够了。高级的网关组则用于复杂的场景，例如针对不同的子公司、业务线、集群以及 UAT 和 Staging 等环境使用独立的 API 策略。尽管 API7 企业版缺乏多集群和多环境的概念，但你可以通过对网关组进行命名和标记（labeling）来实现相同的目标。
一个网关组包含一个或多个网关实例，但每个网关实例仅属于一个网关组。网关实例可以部署在相同或不同的虚拟机、裸金属服务器或 Kubernetes 节点上。这种组合可以满足跨多条业务线、集群、工作区和环境的用户的多样化需求。
例如在下图中，一家公司的两个团队正在使用 API 网关：支付团队（Payment Team）和报价团队（Quote Team）。支付团队拥有生产（Production）和 UAT 环境，而报价团队只有一个生产环境。在这种情况下，可以创建三个网关组：Payment Prod、Payment UAT 和 Quote Prod，并可以为它们打上 Env:Prod 和 Env:UAT 标签。
核心特性
- API 网关组管理：将 API 网关集合作为共享相同配置的逻辑单元进行管理。这简化了管理并确保在各个网关实例中强制执行一致的策略。
- 与业务对齐的网关分区：通过将企业的业务线和解决方案分配给专门的 API 网关组来实现隔离。这种架构方法使得 API 基础设施与组织的职能领域更好地对齐。
- 物理隔离：网关组在不同的物理环境（包括数据中心、云平台和虚拟机）中隔离多个 API 网关实例。这有效地防止了网关组之间的干扰，并提高了系统的稳定性和安全性。
- 弹性伸缩：网关组根据流量波动动态添加或删除 API 网关实例以满足业务需求。这提高了资源利用率并降低了运营成本。
- 可扩展且灵活的基础设施：API 网关组的逻辑架构与各个网关实例的物理部署解耦。这种方法为 API 基础设施提供了更高的灵活性和可扩展性。
- 细粒度权限控制：网关组可为不同的网关实例和 API 实现不同的权限配置，以遵守合规性要求。
- Ingress Controller：支持 Kubernetes Ingress Controller 使用 API7 企 业版作为高性能的反向代理。以声明式方法配置由 API7 企业版提供的资源。
使用场景
隔离开发、测试、UAT 和生产环境
API 部署和发布会经历不同的阶段和环境，具体取决于各公司的 API 管理流程。假设你的公司有四个环境：Dev（开发）、Test（测试）、UAT 和 Prod（生产）。如果不使用网关组，你需要部署 4 个独立的 API7 企业版实例，每个实例都有其独立的控制面和数据面。开发人员、QA 和运维工程师需要通过具有不同域名的 API7 企业版控制面来访问、开发、测试和发布同一个 API。
这种方法具有明显的缺点。当你有 5 条业务线，每条都有 4 个环境时，你需要部署总共 20 套 API7 企业版，这会导致资源浪费和管理成本增加。
通过利用 API7 企业版的网关组功能，你可以轻松克服这一挑战。你可以创建 20 个不同的网关组，采用结合业务线和环境名称的命名约定，并添加标签以进行过滤和选择。此外，可以应用基于角色的访问控制（RBAC）以实现细粒度的权限控制。这样，开发人员就只能修改开发环境中的配置。
管理跨不同区域的多个集群
对于拥有全球客户群的公司来说，在跨多个区域和集群管理 API 服务的同时确保数据合规性，是一项具有挑战性的任务。 假设你的公司在北美（NA）、欧洲（EU）和亚太（APAC）地区运营，每个地区有 4 个生产集群。如果不使用网关组，你将需要维护 12 套 API 网关控制面和数据面。 然而，使用这种方法很容易出现配置差异。
一致的 API 网关配置并不能保证日志记录器、密钥和可观测性工具的加密、隐私和合规性——这需要额外的工作。
API7 企业版的网关组提供了一种使用单一控制面集中管理和配置跨多个区域的 API 网关集群的解决方案。你可以使用环境变量、服务发现和注册中心来简化和统一管理与维护，从而降低总体维护成本。
此外，API7 企业版支持多层网络，可实现跨区域的无缝数据处理和合规性。如果一位名叫 John 的美国用户从欧洲登录，欧洲（EU）集群可以根据其用户 ID 确定并将他的 API 请求重定向到北美（NA）集群。这种能力确保了合规性和高效的 API 请求处理。
满足不同项目的服务级别目标
各个项目中的服务具有不同的服务级别目标（SLO）。例如，支付服务的 SLO 可能是 99.999%，而历史订单服务的 SLO 可能是 99%。可以为每种服务使用特定的策略，以使其与各自的 SLO 保持一致。
基础设施和运维团队可以在多个区域部署支付服务。然后向该网关组分配更多的网关实例和更高质量的机器资源，并为其设置严格的警报策略和详细的可观测性指标。相反，SLO 要求较低的历史订单服务可以采用轻量级部署策略，降低警报和监控级别以减少资源分配。
网关实例状态
网关实例状态表示网关实例（数据面）与控制面之间的连接情况。该状态由每个网关实例定期报告。只有健康的网关实例才能处理 API 流量。
- 健康：网关实例运行正常。
- 仅心跳：此状态表示配置下发失败，即使网关实例正通过心跳探测保持与控制面的连接。
- 连接丢失：控制面超过 30 秒但不到 2 小时未检测到该网关实例。
- 离线：控制面超过 2 小时未检测到网关实例。在这种情况下，如果网关实例仍然无法连接到控制面，网关实例将在 7 天后被移除。
附加资源
- 入门指南