# Background introduction
Let’s look at a picture first. The page calls more than 20 back-end interfaces in total. There is obvious lag on the page. Moreover, for every six requests, the next group will be executed only after the previous group returns. Seeing that the request is in the pending status, it is easy to think that it is a problem with the back-end interface. Experienced students may see at a glance that this is caused by the browser's concurrency limit rather than a problem with the back-end interface.
Mainstream browsers generally have limits on the number of concurrent connections to the same server.
Why does the browser need to limit the number of concurrent requests?
Consider operating system port resources The total number of PC ports is 65536, so one TCP (http is also tcp) link occupies one port. The operating system usually opens half of the total ports to external requests to prevent the number of ports from being exhausted quickly.
Too much concurrency leads to frequent switching and performance problems. One thread handles one http request, so if the number of concurrent requests is huge, frequent thread switching will occur. And thread context switching is sometimes not a lightweight resource. This results in more losses than gains, so a connection pool will be generated in the request controller to reuse previous connections. Therefore, we can think that the maximum number of connection pools under the same domain name is 4 to 8. If all the connection pools are used, subsequent request tasks will be blocked and subsequent tasks will be executed when there are free links.
Avoid a large number of concurrent requests from the same client exceeding the server’s concurrency threshold. On the server side, concurrency thresholds are usually set for the same client source to avoid malicious attacks. If the browser does not set concurrency limits for the same domain name, it may cause the server to exceed the concurrency threshold and be banned.
Client conscience mechanism In order to prevent two applications from seizing resources, the stronger party will obtain resources without limit and the weaker party will be permanently blocked.
# Service orchestration applicable scenarios
Service orchestration is mainly based on existing business microservices and uses online configuration to quickly generate an aggregate interface.
For example:
The order details page needs to display order information, product information and user information. An interface can be generated through configuration to successively call the order details interface, product information interface and user information interface of the underlying microservice, and then extract the required fields from the return results of these three interfaces and return them to the front-end page.
Applicable scenarios for service orchestration of FizzGate integration platform:
# Front-end scenario
When a page calls multiple interfaces, it can arrange the returned aggregate results to improve the loading speed of page data.
Mobile devices have limited computing power. Data calculation or business processing logic can be completed on the server side to speed up page response.
# Backend scenario
Replace the aggregation interface of the application layer and reduce the glue code of the application layer.
Quickly generate interfaces for transparent transmission data types
Data conversion and mapping
# Fast aggregation interface
The above problem can be solved through the aggregation function of the service orchestration of the FizzGate integration platform. Simply put, the multiple interfaces to be called by the front-end page are changed to be called by the FizzGate integration platform, and then the results of each interface are aggregated and returned to the front-end. In this way, the front end only needs to call a simple aggregation interface.
# Data preparation
# FizzGate integrated platform installation
Please refer to: https://www.fizzgate.com/fizz/guide/installation (opens new window)
# echo interface
The back-end interface is simulated through a delayed echo interface, simulating the front-end page to call 10 interfaces
http://127.0.0.1:8080/echo?latency=1000&echo=interface 1
http://127.0.0.1:8080/echo?latency=1000&echo=Interface 2
...
http://127.0.0.1:8080/echo?latency=1000&echo=interface 10
Echo interface source code: [fizz-examples-rest-api](https://gitee.com/fizzgate/fizz-examples/blob/master/fizz-examples-rest-api/src/main/java/we/controller/ EchoController.java)
# Aggregation interface
Aggregation interface path: /fast-aggr/aggregate
Request method: POST
Input parameter format: (The format can be adjusted as needed)
{
"params1": {
"latency": 1000,
"echo": "interface 1"
},
"params2": {
"latency": 1000,
"echo": "Interface 2"
},
// ... omitted
"params10": {
"latency": 1000,
"echo": "Interface 10"
}
}
- Return results: (The format can be adjusted as needed)
{
"result1": "Interface 1",
"result2": "Interface 2",
// ... omitted
"result3": "Interface 10"
}
# Add new interface
Menu location: Service Edit->Interface List, click Add
# Configuration input
In the configuration input tab, you can define the input parameters and request headers of the interface. If you do not configure the input parameters or request headers, the gateway will receive all input parameters or request headers from the caller as is, but will not do anything with the received parameters. check. In this example, we use the agreed input parameter format and do not define the input parameters, leaving them all blank.
# Configuration steps
Because we need to call 10 interfaces concurrently, we only need to add 1 step, and then add 10 requests in the step. The service selects our pre-prepared fizz-examples-rest-api service. For input parameters, we use * asterisk to transparently transmit the parameters passed from the front end. Here we use reference values to reference the input parameters. For the usage of related reference values, please refer to the document: [Data conversion usage document] (https:// www.fizzgate.com/fizz/guide/aggregate/configuration.html#%E6%95%B0%E6%8D%AE%E8%BD%AC%E6%8D%A2). If the configuration response part is left blank, the gateway will receive the return result of the interface as is. In this way we configure 10 interfaces respectively.
# Configure output
Configure the response message to be returned to the front end. The results in the steps are directly quoted here.
# Test
After configuring the interface, click Test
# Access formal interface
After the interface is configured, you need to publish and configure routes before it can be opened to the public network. Menu: Arrangement Review-->My Application, click Add to submit and publish the application form. It can be published after passing the review.
Configure routing after publishing, menu: Gateway Management --> Routing Management
Formal interface access URL: http://[gateway IP]:8600/proxy/fast-aggr/aggregate
The front-end page changes from calling multiple interfaces to calling an aggregated interface, which greatly reduces the delay caused by network IO and improves page access speed.
# Introduction to FizzGate Integration Platform
FizzGate is a microservice aggregation gateway developed based on Java. It can achieve hot service orchestration and aggregation, automatic authorization selection, online service script coding, online testing, high-performance routing, API audit management, callback management, etc., and has powerful customization The plug-in system can be expanded by itself and provides a friendly graphical configuration interface, which can quickly help enterprises manage API services, reduce middle-layer glue codes, reduce coding investment, and improve the stability and security of API services.
Official website: https://www.fizzgate.com (opens new window)
GitHub: https://github.com/fizzgate/fizz-gateway-node (opens new window)
Code cloud: https://gitee.com/fizzgate/fizz-gateway (opens new window)
Getting Started Tutorial: https://www.fizzgate.com/fizz/guide/GettingStarted/ (opens new window)
Author: Blackhawk