What is API Gateway (API Geteway)
In the microservice architecture, the granularity of services is further subdivided, and each business service can be independently designed, developed, tested, deployed and managed. At this time, each independent deployment unit can be maintained by different development and testing teams, and can be designed using different programming languages and technology platforms. This requires the use of a language- and platform-independent service protocol as the communication method between each unit.
The role of the gateway is as an API architecture to protect, enhance and control access to API services. API gateway is a system in front of applications or services (providing REST API interface services) to manage authorization, access control, traffic restrictions, etc. In this way, REST API interface services are protected by the API gateway and are transparent to all callers. . Therefore, business systems hidden behind API gateways can focus on creating and managing services without having to deal with these strategic infrastructures.
GetWay is based on Spring and SpringBoot's gateway. It provides a simple and effective unified API routing management mode for microservice architecture. It provides unified routing, security, monitoring, current limiting, etc. It is a substitute for zuul and implements asynchronous I /O.
In high-concurrency systems, it is often necessary to limit current flow in the system. On the one hand, it is to prevent a large number of requests from overloading the server and rendering the service unavailable. On the other hand, it is to prevent network attacks. Common current limiting methods, such as Hystrix , apply thread pool isolation. If the load of the thread pool is exceeded, circuit breaker logic will be used. In general application servers, such as tomcat containers, concurrency is controlled by limiting the number of threads; traffic is also controlled by the average speed of the time window. Common current limiting methods include current limiting through IP , current limiting through URI , and current limiting through user access frequency.
Generally, current limiting is done at the gateway layer, such as Nginx , Openresty , kong , zuul , Spring Cloud Gateway , etc.; current limiting can also be done at the application layer through Aop . When we develop Java projects, if it is a microservice, we can generally configure the current limit in the microservice gateway ( SpringCloud Gateway ).
Spring Cloud Gateway can be regarded as an upgraded version and replacement of Zuul 1.x. It uses Netty to implement asynchronous IO earlier than Zuul 2, thereby achieving a simple, more efficient than Zuul 1. Compatible API gateway. Spring Cloud Gateway clearly distinguishes between Router and Filter, and a big feature is that it has a lot of built-in out-of-the-box functions, which can be used through SpringBoot configuration or manual coding chain calls.
For example, there are 10 types of Routers built-in, so that we can configure it directly and do routing according to Header, Path, Host, or Query as we like.
For example, general Filters and global Filters are distinguished, and 20 types of Filters and 9 types of Global Filters are built-in, all of which can be used directly. Of course, customizing Filter is also very convenient.
Commonly used algorithms:
1. Counter algorithm: The counter algorithm uses a counter to implement current limiting. It is a bit simple and crude. Generally, we will limit the number of requests that can pass in one second. For example, the current limiting qps is 100. The implementation idea of the algorithm is to start timing from the first request. , in the next 1s , every time a request comes, the count will be increased by 1. If the accumulated number reaches 100 , then all subsequent requests will be rejected. After 1s is over, restore the count to 0 and start counting again.
2. Leaky bucket algorithm: There is a container inside the leaky bucket algorithm, which is similar to a funnel used in daily life. When a request comes in, it is equivalent to water pouring into the funnel, and then flowing out slowly and uniformly from the small opening at the lower end. No matter how large the flow rate is above, the speed of outflow below always remains the same. No matter how unstable the service caller is, the leaky bucket algorithm is used to limit the flow and process a request every 10 milliseconds. Because the processing speed is fixed, the speed at which requests come in is unknown. Many requests may suddenly come in, and the requests that are not processed in time are first placed in the bucket. Since it is a bucket, there must be a capacity limit. If the bucket is full, then New incoming requests are discarded. The leaky bucket algorithm has a flaw and cannot cope with short-term burst traffic, such as the start of Double Eleven rush sales and flash sales.
3. Token bucket algorithm: The token bucket algorithm is an improvement on the leaky bucket algorithm. The bucket algorithm can limit the rate of request calls, while the token bucket algorithm can limit the average rate of calls while also allowing a certain degree of suddenness. Send a call. In the token bucket algorithm, there is a bucket that stores a fixed number of tokens. There is a mechanism in the algorithm to put tokens into the bucket at a certain rate. Each request call needs to obtain a token first. Only when you get the token can you have the opportunity to continue execution. Otherwise, you can choose to wait for an available token or reject it directly. The action of putting tokens is carried out continuously. If the number of tokens in the bucket reaches the upper limit, the tokens will be discarded. Therefore, there is a situation where there are always a large number of available tokens in the bucket. At this time, incoming requests can be directly Get the token and execute it, for example, set qps to 100. Then one second after the initialization of the current limiter is completed, there will already be 100 tokens in the bucket. At this time, the service has not been fully started. When the startup is completed and the external service is provided, This current limiter can withstand 100 requests in an instant. Therefore, the request will wait only when there is no token in the bucket, and finally it is equivalent to executing at a certain rate.
Let’s briefly talk about the getway token bucket current limit:
Spring Cloud Gateway officially provides the RequestRateLimiterGatewayFilterFactory class, which implements the token bucket method using Redis and lua scripts. The specific implementation logic is in the RequestRateLimiterGatewayFilterFactory class,
Use redis as a token bucket to implement current limiting: Implementation steps: introduce dependencies, create a current limiting identifier, and configure the current limiting rate.
Current limiting is usually based on a certain parameter value as a reference basis. For example, each IP can only be accessed 2 times per second. In this case, IP is used as a reference basis. We create an object that limits current based on IP . The object needs To implement the interface, KeyResolver，if we need to limit the flow based on IP , we need to IpKeyResolverhand over the instance to the Spring container for management. Just put it directly under the startup class. Add RequestRateLimiter configuration in the core configuration file . In the above configuration file, the current limiting filter of RequestRateLimiter is configured . This filter needs to be configured with three parameters:
burstCapacity , the total capacity of the token bucket.
replenishRate , the average rate at which the token bucket is filled per second.
key-resolver , the name of the Bean object used for the current-limited key resolver . It uses SpEL expression to get the Bean object from the Spring container based on #{@beanName} .
How to use Gateway To
put it bluntly, Predicate is to implement a set of matching rules so that requests can find the corresponding Route for processing. Next, we will take over the use of several built-in Predicates in Spring Cloud GateWay.
1. Time matching
Predicate supports setting a time. When a request is forwarded, it can be forwarded before or after this time by judging. For example, we now set it to be forwarded to my website only on January 1, 2019, and not forwarded before then. I can configure it like this:
spring:
cloud:
gateway:
routes:
- id: time_route
uri: http://ityouknow.com
predicates:
- After=2018-01-20T06:06:06+08:00[Asia/Shanghai]
Spring compares time through ZonedDateTime. ZonedDateTime is a class used to represent date and time information with time zone in the date and time function in Java 8. ZonedDateTime supports setting time through time zone. China's time zone is: Asia/Shanghai .
After Route Predicate means that requests after this time are forwarded to the target address. The above example means that all requests with a request time after 6:06:6 on January 20, 2018 are forwarded to the address http://ityyouknow.com. +08:00 means that the time is eight hours different from UTC time, and the time area is Asia/Shanghai.
After adding the routing rules, the access address http://localhost:8080 will be automatically forwarded to http://ityyouknow.com.
Before Route Predicate is just the opposite. All requests made before a certain time are forwarded. We change After in the above routing rules to Before, as follows:
spring:
cloud:
gateway:
routes:
- id: after_route
uri: http://ityouknow.com
predicates:
- Before=2018-01-20T06:06:06+08:00[Asia/Shanghai]
This means that routing can be performed before this time, and routing will be stopped after this time. After modification, restart the project and access the address http://localhost:8080 again. The page will report 404 Address not found.
In addition to before or after time, Gateway also supports limiting routing requests to a certain time period, which can be achieved using Between Route Predicate.
spring:
cloud:
gateway:
routes:
- id: after_route
uri: http://ityouknow.com
predicates:
- Between=2018-01-20T06:06:06+08:00[Asia/Shanghai], 2019-01-20T06:06:06+08:00[Asia/Shanghai]
This setting means that the route can be matched within this time period, and will not be matched beyond this time period. The function of routing via time matching is cool and can be used in some flash sale scenarios.
2. Matching
Cookie Route Predicate through Cookie can receive two parameters, one is Cookie name, and the other is regular expression. The routing rules will match by getting the corresponding Cookie name value and the regular expression. If they match, routing will be executed. If there is no match, it will not be executed.
spring:
cloud:
gateway:
routes:
- id: cookie_route
uri: http://ityouknow.com
predicates:
- Cookie=ityouknow, kee.e
Use curl to test, command line input:
curl http://localhost:8080 --cookie "ityouknow=kee.e"
The page code will be returned. If --cookie "ityouknow=kee.e" is removed, a 404 error will be reported in the background.
Header Route Predicate, like Cookie Route Predicate, also receives two parameters, an attribute name in the header and a regular expression. If the attribute value matches the regular expression, it will be executed.
spring:
cloud:
gateway:
routes:
- id: header_route
uri: http://ityouknow.com
predicates:
- Header=X-Request-Id, \d+
Use curl to test, command line input:
curl http://localhost:8080 -H "X-Request-Id:666666"
Then the page code is returned to prove that the match is successful. Change the parameter -H "X-Request-Id:666666" to -H "X-Request-Id:neo" and return 404 when executed again, proving that there is no match.
3. Match Host
Route Predicate to receive a set of parameters and a list of matching domain names. This template is an ant-delimited template, using . as the separator. It passes the host address in the parameter as a matching rule.
spring:
cloud:
gateway:
routes:
- id: host_route
uri: http://ityouknow.com
predicates:
- Host=**.ityouknow.com
Use curl to test, command line input:
curl http://localhost:8080 -H "Host: www.ityouknow.com"
curl http://localhost:8080 -H "Host: md.ityouknow.com"
After testing, the above two hosts can match the host_route route. If the host parameter is removed, a 404 error will be reported.
4. Matching by request method
Routing can be performed through different request methods such as POST, GET, PUT, DELETE, etc.
spring:
cloud:
gateway:
routes:
- id: method_route
uri: http://ityouknow.com
predicates:
- Method=GET
Use curl to test, command line input:
# curl 默认是以 GET 的方式去请求
curl http://localhost:8080
The test returns the page code to prove that the route is matched, and we then request the test via POST.
# curl 默认是以 GET 的方式去请求
curl -X POST http://localhost:8080
Returns 404 Not Found, proving that there is no matching route.
5. By requesting path matching,
the Path Route Predicate receives a matching path parameter to determine whether to take the route.
spring:
cloud:
gateway:
routes:
- id: host_route
uri: http://ityouknow.com
predicates:
- Path=/foo/{segment}
This route will match if the request path meets the requirements, for example: /foo/1 or /foo/bar.
Use curl to test, command line input:
curl http://localhost:8080/foo/1
curl http://localhost:8080/foo/xx
curl http://localhost:8080/boo/xx
After testing, the first and second commands can obtain the page return value normally, and the last command reports 404, which proves that the route is matched through the specified route.
6.
Query Route Predicate matches the request parameters. It supports passing in two parameters, one is the attribute name and the other is the attribute value. The attribute value can be a regular expression.
spring:
cloud:
gateway:
routes:
- id: query_route
uri: http://ityouknow.com
predicates:
- Query=smile
With this configuration, the route can be matched as long as the request contains the parameters of the smile attribute.
Use curl to test, command line input:
curl localhost:8080?smile=x&id=2
After testing, it was found that as long as the request summary contains the smile parameter, the route will be matched, but without the smile parameter, it will not match.
You can also configure the value of Query in the form of key-value pairs, so that when the request comes in, the attribute value and the regular pattern will be matched, and the route will be taken after matching.
spring:
cloud:
gateway:
routes:
- id: query_route
uri: http://ityouknow.com
predicates:
- Query=keep, pu.
In this way, only when the request contains the keep attribute and the parameter value is a three-digit string starting with pu, matching and routing will be performed.
Use curl to test, command line input:
curl localhost:8080?keep=pub
The test can return the page code, change the attribute value of keep to pubx, and a 404 will be reported when accessing again, which proves that the routing needs to match the regular expression before routing.
7. Matching by requesting ip address.
Predicate also supports routing by setting a certain ip interval number. RemoteAddr Route Predicate accepts a list of cidr symbol (IPv4 or IPv6) strings (minimum size is 1), such as 192.168. 0.1/16 (where 192.168.0.1 is the IP address and 16 is the subnet mask).
spring:
cloud:
gateway:
routes:
- id: remoteaddr_route
uri: http://ityouknow.com
predicates:
- RemoteAddr=192.168.1.1/24
You can set this address to the local IP address for testing.
If the requested remote address is 192.168.1.10, this route will match.
8. Combined use
In order to demonstrate the use of each Predicate above, we performed configuration tests individually. In fact, various Predicates can be combined and used together.
For example:
spring:
cloud:
gateway:
routes:
- id: host_foo_path_headers_to_httpbin
uri: http://ityouknow.com
predicates:
- Host=**.foo.org
- Path=/headers
- Method=GET
- Header=X-Request-Id, \d+
- Query=foo, ba.
- Query=baz
- Cookie=chocolate, ch.p
- After=2018-01-20T06:06:06+08:00[Asia/Shanghai]
When various Predicates exist in the same route at the same time, the request must meet all conditions at the same time to be matched by this route.
When a request meets the predicate conditions of multiple routes, the request will only be forwarded by the first successfully matched route.