Upstreams
An upstream acts like a container that groups together one or more backend server addresses. It is a crucial element within services, specifying where API requests are routed and how they are distributed. Most of the time, a single upstream can be linked to multiple routes within a service.
How Upstream Works
Imagine a busy airport. Passengers (API requests) arrive and need to be directed to their departure gates (backend services). Upstreams in API7 Gateway act like these departure gates. They are not physical locations, but logical groupings that define where incoming requests should be sent. An upstream can represent a single backend service, or a pool of identical services for load balancing, or point to the service registry with dynamically changing backends.
In essence, upstreams provide a layer of abstraction between your routes and the actual backend services they target. This abstraction simplifies configuration management and enables features like load balancing and fault tolerance.
Use Case(s)
Single Backend Service
An upstream can represent a single backend service, ideal for scenarios where you have a well-defined and static backend.
For example, an upstream of "user-service" can be created, pointing to a single backend service responsible for user data management (login, registration, profile updates). This straightforward approach simplifies configuration for user-related API endpoints.
Load Balancing Pool
Upstreams can be configured as pools of identical backend services. API7 Gateway can then distribute incoming requests across these servers for improved performance and scalability.
For example, an upstream of "product-service" can be configured. This upstream, however, will point to a pool of backend service instances replicating your product service. This enables load balancing, distributing incoming product information requests (retrieving product details, searching for products) across multiple service instances. This ensures optimal performance as your user base grows and product information requests surge.
Dynamic Service Discovery
Upstreams can leverage service registries. This allows them to dynamically discover and connect to backend services that register themselves with the registry(Nacos, Kubernetes, etc). This is ideal for microservices with constantly changing backends or those that self-scale
Canary Deployment
API7 Gateway streamlines backend service upgrades with canary deployments. Create a separate upstream for the new service version and route a small portion of traffic to it. This allows testing alongside the existing service (original upstream). Gradually increase traffic to the new version while monitoring performance. If stable, switch all traffic. Rollback is simple by adjusting traffic distribution. This approach minimizes risk and simplifies upgrades for developers and users thanks to API7 Gateway handling traffic shifting based on canary rules.
Canary deployments are developer-friendly. Developers can keep using the existing API calls during the canary phase. API7 Gateway handles traffic shifting based on canary rules, you do not need to add more routes or change the current route configuration. This simplifies upgrades for both developers and users.
Upstream Health Checks
API7 Gateway provides active and passive health checks. These checks constantly monitor your backend services (upstream nodes) to ensure they are online and healthy. If a node falters, API7 Gateway automatically stops routing traffic to it until it recovers. This ensures your API remains responsive and reliable. To enable health check, you need first to add /health endpoint for your backend service.
Additional Resource(s)
- Key Concepts
- Getting Started
- Best Practice