# Routing introduction

Routing provides a unified external entrance for internal microservices, which is used to receive external requests and forward them to the corresponding back-end services. Routes can be divided into three major types:

  • Service orchestration: Forward the request to the interface configured through the service orchestration module. Select the service name without configuring the IP and port of the instance.
  • Service discovery: Forward the request to the microservice registered in the service registration center. Select the service name without configuring the IP and port of the instance.
  • Proxy forwarding: forward the request to a service without a registration center. You need to configure the instance IP and port of the backend service.

Routing supports the following features:

  • Support service registration center
  • Support load balancing -Support configuration caller
  • Supports built-in key-auth, JWT, basic-auth and other authentication methods
  • Support configuration plug-in
  • Support matching regular expressions
  • Support path testing to verify whether the configured route is correct -Supports configuring routes that prohibit access

# Configure routing

Add a new route and fill in the basic information

Add the plug-ins required for routing according to the situation. For example, if all requests through this route require HTTP Basic authentication and JWT verification, add the following plug-ins. In addition to the built-in plug-ins, you can also add custom plug-ins. For custom plug-ins, please refer to the plug-in mechanism chapter document.

After configuring the routing, if the matching rules of the front and back ends are complex (for example, regular expressions or wildcards are used), you can use the test function to check whether the configuration is correct.

# API path matching rules

API path matching rule description:

? matches a character

* matches 0 or more characters within the first-level directory

** Matches 0-level or multi-level directories

{fizz:[a-z]+} matches the regular expression [a-z]+, and the matching result is assigned to the path variable named fizz

The back-end API path can use {$1}-{$n} to obtain the values of wildcards and regular expressions in the front-end API path. The value of the regular expression can also be obtained through named variables;

example:

Front-end API path: /x/{fizz:[a-z]+}/z/**

Backend API path: /x/{fizz}/{$2} or /x/{$1}/{$2}

In this example, {fizz} and {$1} take the value of the regular expression {fizz:[a-z]+} in the front-end API path.

When requesting the interface path /x/y/z/a/b/c, the above route will be matched. The values of {fizz} and {$1} are y, and the value of {$2} is a/b/c.

# Enable APPID

Routing supports configuring APPID to restrict the caller. After enabling APPID, the caller needs to transmit the following request headers as required.

  • fizz-appid The caller ID maintained in the APPID management module
  • The signature verification method corresponding to the APPID set in the fizz-sign APPID management module
  • fizz-ts timestamp when requested

Example:

fizz-appid: 10001
fizz-sign: e4502ba3a71448bbbcecef22b305d2ba
fizz-ts: 1605255335977

# Custom alternate signature header

fizz-appid, fizz-sign and fizz-ts are the default verification request headers and support custom configurable backup signature headers. When the default request header has no value, the value of the backup request header is taken.

Add the following configuration in application.yml. You can configure only some of the alternate request headers and use the default request headers for others.

custom.header.appid=app-id,gw-appid # Multiples are separated by commas. If the previous request header has no value, the gateway will take the next value in order.
custom.header.sign=signature # Multiple ones separated by commas. If the previous request header has no value, the gateway will take the next value in order.
custom.header.ts=timestamp # Multiple ones separated by commas. If the previous request header has no value, the gateway will take the next value in order.

← Gateway grouping →