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