Section 1:
In the following video lessons, he will learn how to use spring cloud gateway to aroud incoming requests
to destination Ceressus.
When my services start up, they register themselves with Eureka Discovery Service, Eureka becomes
aware of each of your micro series and their address.
And when we need to scale up, we can start 10 more micro services and each of them will register with
Eureka Discovery Service automatically and Eureka will know their addresses as well.
When we start more instances of users make a service, for example, each instance of users, my customers
will have a unique address and requests from a client application now will need to be balanced between
available instances of users microspheres.
So now, when we have multiple instances of users who is running and each service has its unique address
on the network, we need a way to rout incoming requests from a client application to one of these instances.
And to do that we can use sprinklered, API Gateway, Sprinklered, API Gateway has a built in load
balancer that will distribute requests coming from a client application equally between Arien instances
of our users Menck service.
And this makes our API more robust when the load on our system increases.
When we start up three instances of users microspheres service, it will now be the three instances,
service requests that are coming from a client application rather than one single instance and the load
on one single instance decreases.
So Sprinklered API Gateway will be a central point of entry to a system that has multiple instances
of micro services running behind an API gateway.
It will be hungriness DP requests from a client application and a within those requests, two instances
of a micro service running behind API Gateway and the list of fundraises or Franey Microcystin.
Mrs. Sprinklered and Gateway will feature from Eureka Discovery Series now because Sprinklered and Gateway
is a central point of entry to our system, there are many nice to have things that you can configure
it to do.
You can configure a set of filters that will filter all HDB requests that come in and come out of Gateway
that are built in filters that you can use out of the box and you have the ability to create your own
custom filters.
And in those custom filters you can write custom code to perform any business logic that you need.
For example, you can make it look certain details about the incoming request and you can make it look
certain details about the response that has been returned back.
You can read it.
Should you be hander's from HTP request and you can validate the GW token to make sure that it is valid
and you can make a filter after the request by adding additional information to it.
For example, after validating the public JWT token, you can generate a new internal JWT token and
included into a request to a destination microspheres.
You can configure custom routing to roll, this should be request to specific destination, make a service
and assign a specific set of filters to be performed for a specific gateway route.
And in the following the lessons, you will learn how to start up your own sprinklered, Iban Gateway,
and you will make it round requests to destination services.
Here's a diagram that I have taken from sprinklered, a packet with recommendation page, and this diagram
is a high level overview of how sprinklered iPad keyway works.
The floor starts from the top where we have Gateway client.
And this is a client application that sends such a request to a destination like a service that is running
behind an API and Gateway when sprinklered API Gateway receives this request.
The first component in the flow is a gateway handler might be the gateway handler.
Mapping determines that a request matches are configured throughout.
It is sent to Gateway Web Gateway, where premolar will take the request through a set of filters configured
for this route and in the full and the lessons you will learn how you can configure API gateway rounds.
So if a request matches around the gateway with Handler will around the request through a filter chain
that is specific to the request and you can configure multiple filters to be executed for a specific
gateway around.
And in the following video, since you will also learn how to create a new filter and how to configure
your filter to be executed for a specific request.
Notice that on the diagram, the list of filters is divided with the dotted line on the left side of
the dotted line.
There is an arrow showing a direction towards the proxy service and on the right side of the dotted
line there is an arrow going back from peroxided service towards the Gateway Web handler.
And the reason for that is because filters can run logic both before and after the proxy request is
made.
So there can be pre filters and there can be post filters.
You can have filters that execute their logic before the proxy request is made and you can have filter
that execute their logic after proxy request is made.
So additionally to learning how to start up your spring-loaded by Gateway and how to make it through
all the requests to specific MICRA services, you will also learn how to create a custom filter that
will be executed for a specific request.
Only in that custom filter will validate if the inability access token that was included in the authorization
header is valid or not.
If the token is not valid, the request will not pass through.
But if the JWT token is valid, then the request will pass through and the destination Macassar can
perform additional authorization to make sure that this user is actually allowed to perform the requested
separation or access the requested information.
All right.
So let's learn how to do it.
Section 2
In the following video lessons, he will learn how to use sprinklered gateway to aroud incoming requests
to destination Ceressus.
When my services start up, they register themselves with Eureka Discovery Service, Eureka becomes
aware of each of your micro series and their address.
And when we need to scale up, we can start 10 more micro services and each of them will register with
Eureka Discovery Service automatically and Eureka will know their addresses as well.
When we start more instances of users make a service, for example, each instance of users, my customers
will have a unique address and requests from a client application now will need to be balanced between
available instances of users microspheres.
So now, when we have multiple instances of users who is running and each service has its unique address
on the network, we need a way to rout incoming requests from a client application to one of these instances.
And to do that we can use sprinklered, API Gateway, Sprinklered, API Gateway has a built in load
balancer that will distribute requests coming from a client application equally between Arien instances
of our users Menck service.
And this makes our API more robust when the load on our system increases.
When we start up three instances of users microspheres service, it will now be the three instances,
service requests that are coming from a client application rather than one single instance and the load
on one single instance decreases.
So Sprinklered API Gateway will be a central point of entry to a system that has multiple instances
of micro services running behind an API gateway.
It will be hungriness DP requests from a client application and a within those requests, two instances
of a micro service running behind API Gateway and the list of fundraises or Franey Microcystin.
Mrs. Sprinklered and Gateway will feature from Eureka Discovery Series now because Sprinklered and Gateway
is a central point of entry to our system, there are many nice to have things that you can configure
it to do.
You can configure a set of filters that will filter all HDB requests that come in and come out of Gateway
that are built in filters that you can use out of the box and you have the ability to create your own
custom filters.
And in those custom filters you can write custom code to perform any business logic that you need.
For example, you can make it look certain details about the incoming request and you can make it look
certain details about the response that has been returned back.
You can read it.
Should you be hander's from HTP request and you can validate the GW token to make sure that it is valid
and you can make a filter after the request by adding additional information to it.
For example, after validating the public JWT token, you can generate a new internal JWT token and
included into a request to a destination microspheres.
You can configure custom routing to roll, this should be request to specific destination, make a service
and assign a specific set of filters to be performed for a specific gateway route.
And in the following the lessons, you will learn how to start up your own sprinklered, Iban Gateway,
and you will make it round requests to destination services.
Here's a diagram that I have taken from sprinklered, a packet with recommendation page, and this diagram
is a high level overview of how sprinklered iPad keyway works.
The floor starts from the top where we have Gateway client.
And this is a client application that sends such a request to a destination like a service that is running
behind an API and Gateway when sprinklered API Gateway receives this request.
The first component in the flow is a gateway handler might be the gateway handler.
Mapping determines that a request matches are configured throughout.
It is sent to Gateway Web Gateway, where premolar will take the request through a set of filters configured
for this route and in the full and the lessons you will learn how you can configure API gateway rounds.
So if a request matches around the gateway with Handler will around the request through a filter chain
that is specific to the request and you can configure multiple filters to be executed for a specific
gateway around.
And in the following video, since you will also learn how to create a new filter and how to configure
your filter to be executed for a specific request.
Notice that on the diagram, the list of filters is divided with the dotted line on the left side of
the dotted line.
There is an arrow showing a direction towards the proxy service and on the right side of the dotted
line there is an arrow going back from peroxided service towards the Gateway Web handler.
And the reason for that is because filters can run logic both before and after the proxy request is
made.
So there can be pre filters and there can be post filters.
You can have filters that execute their logic before the proxy request is made and you can have filter
that execute their logic after proxy request is made.
So additionally to learning how to start up your spring-loaded by Gateway and how to make it through
all the requests to specific MICRA services, you will also learn how to create a custom filter that
will be executed for a specific request.
Only in that custom filter will validate if the inability access token that was included in the authorization
header is valid or not.
If the token is not valid, the request will not pass through.
But if the JWT token is valid, then the request will pass through and the destination Macassar can
perform additional authorization to make sure that this user is actually allowed to perform the requested
separation or access the requested information.
All right.
Note: Spring cloud API Gateway is design to work with reactive applications and it requires Webflux dependency
Built-in Route Predicate Factories in Spring Cloud API Gateway
Below is a list of built-in predicates that you can use when creating routes in Spring Cloud API Gateways. These are built-in predicates and you do not need to write any additional Java code for them to work.
Note: The description of the following built-in predicates is taken from the Spring Cloud API Gateway documentation page.
1. The After Route Predicate Factory
The After route predicate factory takes one parameter, a datetime (which is a java ZonedDateTime). This predicate matches requests that happen after the specified datetime. The following example configures an after route predicate:
- spring.cloud.gateway.routes[0].id = after_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = After=2017-01-20T17:42:47.789-07:00[America/Denver]
This route matches any request made after Jan 20, 2017 17:42 Mountain Time (Denver).
2. The Before Route Predicate Factory
The Before route predicate factory takes one parameter, a datetime (which is a java ZonedDateTime). This predicate matches requests that happen before the specified datetime. The following example configures a before route predicate:
- spring.cloud.gateway.routes[0].id = before_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = Before=2017-01-20T17:42:47.789-07:00[America/Denver]
This route matches any request made before Jan 20, 2017 17:42 Mountain Time (Denver).
3. The Between Route Predicate Factory
The Between route predicate factory takes two parameters, datetime1 and datetime2 which are java ZonedDateTimeobjects. This predicate matches requests that happen after datetime1 and before datetime2. The datetime2 parameter must be after datetime1. The following example configures a between route predicate:
- spring.cloud.gateway.routes[0].id = between_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = Between=2017-01-20T17:42:47.789-07:00[America/Denver], 2017-01-21T17:42:47.789-07:00[America/Denver]
This route matches any request made after Jan 20, 2017 17:42 Mountain Time (Denver) and before Jan 21, 2017 17:42 Mountain Time (Denver). This could be useful for maintenance windows.
4. The Cookie Route Predicate Factory
The Cookie route predicate factory takes two parameters, the cookie name and a regexp (which is a Java regular expression). This predicate matches cookies that have the given name and whose values match the regular expression. The following example configures a cookie route predicate factory:
- spring.cloud.gateway.routes[0].id = cookie_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = Cookie=chocolate, ch.p
This route matches requests that have a cookie named chocolate whose value matches the ch.p regular expression.
5. The Header Route Predicate Factory
The Header route predicate factory takes two parameters, the header name and a regexp (which is a Java regular expression). This predicate matches with a header that has the given name whose value matches the regular expression. The following example configures a header route predicate:
- spring.cloud.gateway.routes[0].id = header_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = Header=X-Request-Id, \d+
This route matches if the request has a header named X-Request-Id whose value matches the \d+ regular expression (that is, it has a value of one or more digits).
6. The Host Route Predicate Factory
The Host route predicate factory takes one parameter: a list of host name patterns. The pattern is an Ant-style pattern with . as the separator. This predicates matches the Host header that matches the pattern. The following example configures a host route predicate:
- spring.cloud.gateway.routes[0].id = host_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = Host=**.somehost.org,**.anotherhost.org
URI template variables (such as {sub}.myhost.org) are supported as well.
This route matches if the request has a Host header with a value of www.somehost.org or beta.somehost.org or www.anotherhost.org.
This predicate extracts the URI template variables (such as sub, defined in the preceding example) as a map of names and values and places it in the ServerWebExchange.getAttributes() with a key defined in ServerWebExchangeUtils.URI_TEMPLATE_VARIABLES_ATTRIBUTE. Those values are then available for use by GatewayFilterfactories
7. The Method Route Predicate Factory
The Method Route Predicate Factory takes a methods argument which is one or more parameters: the HTTP methods to match. The following example configures a method route predicate:
- spring.cloud.gateway.routes[0].id = method_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = Method=GET,POST
This route matches if the request method was a GET or a POST.
8. The Path Route Predicate Factory
The Path Route Predicate Factory takes two parameters: a list of Spring PathMatcher patterns and an optional flag called matchOptionalTrailingSeparator. The following example configures a path route predicate:
- spring.cloud.gateway.routes[0].id = path_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = Path=/red/{segment},/blue/{segment}
This route matches if the request path was, for example: /red/1 or /red/blue or /blue/green.
This predicate extracts the URI template variables (such as segment, defined in the preceding example) as a map of names and values and places it in the ServerWebExchange.getAttributes() with a key defined in ServerWebExchangeUtils.URI_TEMPLATE_VARIABLES_ATTRIBUTE. Those values are then available for use by GatewayFilterfactories
9. The Query Route Predicate Factory
The Query route predicate factory takes two parameters: a required param and an optional regexp (which is a Java regular expression). The following example configures a query route predicate:
- spring.cloud.gateway.routes[0].id = query_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = Query=green
The preceding route matches if the request contained a green query parameter.
10. The RemoteAddr Route Predicate Factory
The RemoteAddr route predicate factory takes a list (min size 1) of sources, which are CIDR-notation (IPv4 or IPv6) strings, such as 192.168.0.1/16 (where 192.168.0.1 is an IP address and 16 is a subnet mask). The following example configures a RemoteAddr route predicate:
- spring.cloud.gateway.routes[0].id = remoteaddress_route
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = RemoteAddr=192.168.1.1/24
This route matches if the remote address of the request was, for example, 192.168.1.10.
11. The Weight Route Predicate Factory
The Weight route predicate factory takes two arguments: group and weight (an int). The weights are calculated per group. The following example configures a weight route predicate:
- spring.cloud.gateway.routes[0].id = weight_high
- spring.cloud.gateway.routes[0].uri = https://example.org
- spring.cloud.gateway.routes[0].predicates[0] = Weight=group1, 8
- spring.cloud.gateway.routes[1].id = weight_low
- spring.cloud.gateway.routes[1].uri = https://example.org
- spring.cloud.gateway.routes[1].predicates[0] = Weight=group1, 2
This route would forward ~80% of traffic to weighthigh.org and ~20% of traffic to weighlow.org
A list of API Gateway filters is very long to be included in a single lecture. Below are direct links to gateway filters published in Spring Cloud API Gateway documentation.
You can bookmark these pages in your browser for quick access.
Comments
Post a Comment