A service gateway acts as an intermediary between the service client and an invoked service.

The service client talks only to a single URL managed by the service gateway. The service
gateway pulls apart the path coming in from the service client call and determines what service
the service client is trying to invoke.

Spring Cloud Gateway is an open-source, developer-friendly, and fully customizable gateway

framework that's part of the Spring Cloud ecosystem. It provides a foundation for building
robust, scalable, and secure microservices-based applications.

cross-cutting concerns that can be implemented in a service gateway include these:

Static routing—A service gateway places all service calls behind a single URL and API route.
This simplifies development as we only have to know about one service endpoint for all of our
services.

Dynamic routing—A service gateway can inspect incoming service requests and, based on the
data from the incoming request, perform intelligent routing for the service caller. For instance,
customers participating in a beta program might have all calls to a service routed to a specific
cluster of services that are running a different version of code from what everyone else is using.
Authentication and authorization—Because all service calls route through a service gateway,
the service gateway is a natural place to check whether the callers of a service have
authenticated themselves.

Metric collection and logging—A service gateway can be used to collect metrics and log
information as a service call passes through it. You can also use the service gateway to confirm
that critical pieces of information are in place for user requests, thereby ensuring that logging is
uniform. This doesn’t mean that you shouldn’t collect metrics from within your individual
services. Rather, a service gateway allows you to centralize the collection of many of your basic
metrics, like the number of times the service is invoked and the service response times

Gateway and Routing: Spring Cloud Gateway serves as an entry point for incoming HTTP
requests to your microservices architecture. It handles routing requests to the
appropriate services based on predefined rules and filters.
Filtering and Transformation: Spring Cloud Gateway includes a wide range of built-in
filters for request and response transformation, logging, authentication, rate limiting, and
more. You can also create custom filters to meet specific requirements.
Load Balancing: The gateway supports load balancing across multiple instances of a
service, ensuring high availability and scalability.
Security: It provides security features like authentication and authorization through
integration with Spring Security. You can implement authentication and authorization
logic for your services.
Integration with Discovery Services: Spring Cloud Gateway seamlessly integrates with
service discovery tools like Netflix Eureka or HashiCorp Consul, making it easy to
discover and route requests to services.
Monitoring and Metrics: It includes support for monitoring and metrics using Spring Boot
Actuator and integration with tools like Prometheus and Grafana.
WebSocket Support: Spring Cloud Gateway can handle WebSocket traffic and route it to
WebSocket-enabled services.
Customization: The framework is highly customizable and extensible. You can customize
routes, filters, and behavior to suit your application's unique requirements.
Distributed Tracing: Integration with distributed tracing solutions like Zipkin or Sleuth
enables end-to-end tracing of requests across microservices.
Developer-Friendly: Spring Cloud Gateway is built on Spring Boot, which means it benefits
from Spring Boot's developer-friendly features, auto-configuration, and easy integration
with other Spring projects.
Cloud-Native: It is designed with cloud-native principles in mind and is well-suited for
building microservices-based applications that can be deployed in containerized
environments like Kubernetes.
In summary, Spring Cloud Gateway is a versatile and powerful gateway solution for building
modern, microservices-based applications. It offers features for routing, filtering, security, and
more, making it a central piece of infrastructure in a microservices architecture. It empowers
developers to build scalable and resilient systems while maintaining flexibility and customization
options.
Spring Cloud Gateway offers several capabilities, including
Mapping the routes for all the services in your application to a single URL
The Spring Cloud Gateway isn’t limited to a single URL, however. Actually, with it, we can
define multiple route entry points, making route mapping extremely fine grained (each service
endpoint gets its own route mapping). But the first and most common use case is to build a
single entry point through which all service client calls will flow.
Building filters that can inspect and act on the requests and responses coming through the
gateway. These filters allow us to inject policy enforcement points in our code and to perform a
wide number of actions on all of our service calls in a consistent fashion. In other words, these
filters allow us to modify the incoming and outgoing HTTP requests and responses.
Building predicates, which are objects that allow us to check if the requests fulfill a set of given
conditions before executing or processing a request. The Spring Cloud Gateway includes a set
of built-in Route Predicate Factories.

Setting up Spring Boot Gateway Project:

Once the project is created, open the pom.xml and make the changes by excluding the netflix
ribbon libraries

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-ribbon</artifactId>
 </exclusion>
<exclusion>
<groupId>com.netflix.ribbon</groupId>
<artifactId>ribbon-eureka</artifactId>
</exclusion>
</exclusions>
</dependency>

Add below properties in application.properties file for application name and port and to
integrate with Eureka discovery service

spring.application.name=gateway-server
#Register the IP Address of the service rather than the server name
eureka.instance.preferIpAddress=true
#Registers the service with Eureka
eureka.client.registerWithEureka=true
# Pulls down a local copy of registry
eureka.client.fetchRegistry=true
eureka.client.serviceUrl.defaultZone = http://localhost:8070/eureka/
spring.cloud.gateway.discovery.locator.enabled=true
spring.cloud.gateway.discovery.locator.lowerCaseServiceId=true
server.port=8072

Configuring routes in Spring Cloud Gateway:

At its heart, the Spring Cloud Gateway is a reverse proxy. A reverse proxy is an intermediate
server that sits between the client trying to reach a resource and the resource itself. The client
has no idea it’s even communicating with a server. The reverse proxy takes care of capturing
the client’s request and then calls the remote resource on the client’s behalf.

In the case of a microservice architecture, Spring Cloud Gateway (our reverse proxy) takes a
microservice call from a client and forwards it to the upstream service. The service client thinks
it’s only communicating with the gateway. But it is not actually as simple as that. To
communicate with the upstream services, the gateway has to know how to map the incoming
call to the upstream route.

The Spring Cloud Gateway has several mechanisms to do this, including

● Automated mapping of routes using service discovery
● Manual mapping of routes using service discovery

Below properties Enables the gateway to create routes based on services registered with
service discovery

spring.cloud.gateway.discovery.locator.enabled=true
spring.cloud.gateway.discovery.locator.lowerCaseServiceId=true
The Gateway server is accessed via the http://localhost:8072 endpoint.

The beauty of using Spring Cloud Gateway with Eureka is that not only do we now have a single
endpoint through which we can make calls, but we can also add and remove instances of a
service without ever having to modify the gateway. For instance, we can add a new service to
Eureka, and the gateway automatically routes calls to it because it’s communicating with Eureka
about where the actual physical service endpoints are located. If we want to see the routes
managed by the Gateway server, we can list the routes via the actuator/gateway/routes
endpoint on the Gateway server. This will return a listing of all the mappings on our service.

Manual mapping of routes using service discovery:

Add the below properties in application.properties file to manually mapping a route to a service
spring.cloud.gateway.routes[0].id=courseservice
spring.cloud.gateway.routes[0].uri=lb://course-service
spring.cloud.gateway.routes[0].predicates[0]= Path=/training/**

Here course-service which is registered with eureka server is mapped to route id courseservice.
Predicate property value can be used in the url to access the course-service.
Follow the below url to test the service:
http://localhost:8072/training/courses/all

We can see all the routes by using the actuator endpoint url. We need to enable the
actuator/gateway endpoint as shown below:
application.properties
management.endpoint.gateway.enabled=true
management.endpoints.web.exposure.include=gateway,health,info

Lets verify all the routes by following the below url:

http://localhost:8072/actuator/gateway/routes

We can get the response as below:

[
{
"predicate": "Paths: [/gateway-server/**], match trailing slash: true",
"metadata": {
"management.port": "8072"
},
"route_id": "ReactiveCompositeDiscoveryClient_GATEWAY-SERVER",
"filters": [
"[[RewritePath /gateway-server/?(?<remaining>.*) = '/${remaining}'], order = 1]"
],
"uri": "lb://GATEWAY-SERVER",
 "order": 0
},
{
"predicate": "Paths: [/course-service/**], match trailing slash: true",
"metadata": {
"management.port": "8080"
},
"route_id": "ReactiveCompositeDiscoveryClient_COURSE-SERVICE",
"filters": [
"[[RewritePath /course-service/?(?<remaining>.*) = '/${remaining}'], order = 1]"
],
"uri": "lb://COURSE-SERVICE",
"order": 0
},
{
"predicate": "Paths: [/training/**], match trailing slash: true",
"route_id": "courseservice",
"filters": [],
"uri": "lb://course-service",
"order": 0
}
]

Now test the service with the manually configured route by following the below URL:

http://localhost:8071/training/courses/all