Skip to main content

Set up Request Routing

Overview​

Request routing refers to the ability to redirect requests coming into a given service to an alternative destination, such as a sandbox fork of the service, based on metadata contained within that particular request. This allows each sandbox to selectively replace only some services in the overall set of microservices with forks, so you can test unmerged changes without having to launch a copy of every service in the chain.

The necessary sandbox metadata for routing is automatically added to all requests that reach your services through a endpoint. If you additionally set up context propagation within each service, request routing can take effect not only for that initial request, but also for any subsequent service-to-service requests in the chain.

Routing Requests​

The requests can then be examined for sandbox metadata and either sent to a fork of the service or passed through to the baseline service.

One supported routing mechanism is to configure Signadot Operator to use the Signadot DevMesh sidecar container into the baseline Deployment. This is a built-in system of proxies that can be added to any workload through an annotation and used for request routing. The sidecar will then act as a L7 HTTP or gRPC proxy that examines requests for sandbox metadata and decides whether to route them to a fork or pass them through to the main container.

If you already have a supported service mesh like Istio, that mesh already does its own interception of connections and offers configuration options to achieve request routing. In this case, you can configure the Signadot Operator to use the service mesh for routing functionality.

Both of these mechanisms are described in more detail in the following sections.

Routing Mechanisms​

Signadot supports setting up request routing in the following ways: