Services
A service acts as a representation of a backend application or an external microservice. It essentially groups all the APIs that this application or microservice provides. Here's a breakdown of key relationships:
Routes & Stream Routes: Most services have one-to-many relationships with routes or stream routes. This means a single service can be associated with multiple routes or stream routes, defining how incoming API requests are directed to the appropriate functionality within the service. Note that each service can only contain (HTTP) routes or stream routes, but not a mix of both.
Upstreams: Typically, a service maintains a one-to-one relationship with an upstream. An upstream acts as a container, specifying the address(es) of the backend servers that handle requests for the service. To facilitate canary deployment, a service might temporarily have two upstreams: one upstream pointing to the existing backend version, and another upstream pointing to the new version being introduced.
For those familiar with Apache APISIX, it is important to note that the Service object in API7 Enterprise differs from the Service object in Apache APISIX.
How Services Work
The following diagram illustrates a published service that architects a Petstore service. The service has two routes with distinctive configurations. You can use the HTTP GET method to get related data.
This example directs traffic to only one upstream node. You can add more upstream nodes as required to maintain smooth operation and response while preventing single points of failure.
Service States
The service state represents the service's entire API lifecycle. A service has the template, published, or history states.
Template
The template state is the initial state, representing the latest unpublished draft configuration. APIs in the template state are not accessible and do not have a specific version number.
Published
An active version with a unique version number is created when you publish a template to a gateway group. Published versions contain accessible APIs that are tied to the gateway group. You can only edit service runtime configurations (host, path prefix, and upstream nodes).
To update live APIs, a new version must be published. A service can have multiple versions but the version number is unique, which guarantees identical API configurations across gateway groups. Template changes do not affect published versions.
History
When a new version is published, the previous versions are historical versions. A service cannot simultaneously have two active versions in one gateway group but can run different versions concurrently in different gateway groups.
Historical versions provide visibility into past configurations to track issues. Like in the template state, you cannot edit service configurations in the history state. Historical versions are mainly used for emergency rollbacks.
History versions do not include service runtime configurations. Existing values are retained during rollbacks.
Service Runtime Configurations
The following configurations are classified as service runtime configurations:
- Upstreams
- Service discovery
- Service host
- Path prefix
These service runtime configurations may vary when the same service version is published to different gateway groups, and you can edit them directly within the gateway group.
For example:
- The API URL in the
testenvironment is https://api7-test.ai/v1/pet, while the node address is 127.0.0.1:80. - The API URL in the
productionenvironment is https://api7.ai/petstore/pet, while the node address is 192.168.0.1:80.
Additional Resource(s)
- Key Concepts - Routes, Upstreams, Stream Routes, Service Discovery
- Getting Started
- Best Practices