上游
上游（Upstream）就像一个容器，将一个或多个后端服务器地址组合在一起。它是服务（Service）中的一个关键元素，指定了 API 请求应该被路由到哪里以及如何进行分发。大多数情况下，单个上游可以与服务内的多个路由（Routes）相关联。
上游的工作原理
想象一个繁忙的机场。乘客（API 请求）到达后需要被引导到他们的登机口（后端服务）。API7 网关中的上游就像这些登机口。它们不是物理位置，而是定义了传入请求应该被发送到哪里的逻辑分组。一个上游可以代表单个后端服务、一组用于负载均衡的相同服务实例池，或者指向具有动态变化后端的服务注册中心。
从本质上讲，上游在你的路由及其目标后端服务之间提供了一层抽象。这种抽象简化了配置管理，并启用了负载均衡和容错等功能。
使用场景
单个后端服务
上游可以代表单个后端服务，这非常适合你拥有定义明确且静态后端的场景。
例如，可以创建一个指向负责用户数据管理（登录、注册、个人资料更新）的单一后端服务的“user-service”上游。这种直接的方法简化了与用户相关的 API 端点的配置。
负载均衡池
上游可以配置为相同后端服务的实例池。然后，API7 网关可以在这些服务器之间分发传入的请求，以提高性能和可扩展性。
例如，可以配置一个“product-service”的上游。然而，这个上游将指向复制了你的产品服务的后端服务实例池。这实现了负载均衡，将在多个服务实例之间分发传入的产品信息请求（检索产品详细信息、搜索产品）。这确保了随着用户群的增长和产品信息请求的激增，系统能够保持最佳性能。
动态服务发现
上游可以利用服务注册中心。这使它们能够动态地发现并连接到在注册中心（如 Nacos、Kubernetes 等）注册的后端服务。这对于后端经常变化或能够自动扩缩容的微服务来说非常理想。
灰度发布
API7 网关通过灰度发布简化了后端服务的升级。为新服务版本创建一个单独的上游，并将一小部分流量路由到该上游。这允许在现有服务（原始上游）的同时进行测试。在监控 性能的同时，逐步增加到新版本的流量。如果稳定，则切换所有流量。由于 API7 网关可以处理基于灰度规则的流量转移，因此通过调整流量分配，回滚也非常简单。这种方法最大限度地降低了风险，并为开发者和用户简化了升级过程。
灰度发布对开发者非常友好。在灰度发布阶段，开发者可以继续使用现有的 API 调用。API7 网关处理基于灰度规则的流量转移；你无需添加更多路由或更改当前的路由配置。这为开发者和用户都简化了升级流程。
上游健康检查
API7 网关提供主动和被动健康检查。这些检查不断监控你的后端服务（上游节点），以确保它们在线且健康。如果一个节点出现故障，API7 网关将自动停止向其路由流量，直到它恢复。这确保了你的 API 始终保持响应和可靠。要启用健康检查，你需要首先为你的后端服务添加一个 /health 端点。