In this document, you will learn the basic concept of services in APISIX and the advantages of using services.
Explore additional resources at the end for more information on related topics.
A service object in APISIX is an abstraction of a backend application providing logically related functionalities. The relationship between a service and routes is usually one-to-many (1:N).
The following diagram illustrates an example of a service object used in architecting a data analytics (
da) backend at Foodbar Company (a fictional company), where there are two routes with distinctive configurations - one for getting data (HTTP GET) and the other one for uploading data (HTTP POST):
Note that the rate-limiting plugin
limit-count is configured once on the service object, regulating incoming client requests from the two routes. Similarly, the upstream address is also configured only once on the upstream object. While plugins and upstreams can also be configured in routes individually (and repetitively) to serve the same purpose, it is advised against adopting this approach, as things quickly become hard to manage when the system grows. Using upstreams and services help reduce the risk of data anomalies and minimize operational costs.
For simplicity, the example above only pointed the traffic to one upstream node. You can add more upstream nodes, when needed, to enable load balancing, maintaining a smooth operation and response for users and avoiding a single point of failure in the architecture.