This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.
How did THE API gateway evolve?
Our initial service is a single service, all the functional services are on a server. Filters can be used to implement security checks, such as permission checks.
In the monomer era, the architecture of microservices is relatively simple. Then as the business became more and more complex, we switched to the era of microservices
Into the era of micro services, there are the following characteristics: \
- The original single service was split into n small micro-services \
- These microservices have some common cross-sectional functional logic, such as security, routing, logging, and so on. If each microservice handles these functions, the microservice will be very complex. The microservice will have to handle not only the business logic, but also the logic of security, routing, logging, and so on, and the development burden will be heavy. Therefore, we extract these common services and put them on a service like gateway, which is why the concept of gateway comes into being in microservices.
Summary: Extract the common functions of microservices to form an independent component, an independent service, and deal with cross-cutting logic 3. On the other hand, in the monomer era, our client is mainly the browser. In the microservice era, the client may be the browser, may be the mobile phone, may be the API that we provide externally. It is also complicated to have these clients connect to microservices individually. If they are connected to the gateway service, the various external platforms only need to connect to a gateway, access through the gateway can be, do not need to know a lot of internal details.
Summary: How did the gateway come about?
1. It is to extract the things across the cross section of each micro-service to make an independent gateway service
2. As a single point of entrance, various external forms can conveniently access the internal micro-services of the enterprise.
* * * *
Basic functions of the gateway
As shown in the figure above, the main functions of the gateway are: single point entry, routing and forwarding, fusing traffic limiting, log monitoring, security authentication, and so on
-
Single point of entry: With a gateway, the client only needs to see one entry, not the intricacies of the interior
-
Routing and forwarding: when a client request comes in, there is only one entry to the gateway. Which service is requested? The gateway needs to do a route forwarding
-
Flow limiting circuit breaker: In the micro service era, there are many micro services, each micro service may be wrong or delay, if there is no good flow limiting circuit breaker mechanism, it is very likely to cause the client to be blocked, or have serious consequences, such as avalanche effect. The gateway needs to do a circuit breaker to protect the function of the background service.
-
Log monitoring: All requests that pass through the gateway can be logged and monitored. The health status of the entire service, whether someone is using the gateway to do bad things etc. We also need to keep track of gateway performance. You can do this by adding monitoring to the gateway
-
Security authentication: All requests enter microservices through the gateway, the gateway is like a door, a request comes in, we have to check at the door, it is safe. Is it authenticated?
Netflix Zuul Gateway
On the flix website, the description reads: zuul is a border service that offers dynamic routing, monitoring, elasticity, security and more.
Highlights: Dynamic publishing filter mechanism.
The gateway is the gateway of the whole service, and we cannot restart and publish the gateway service frequently. It has some cross-cutting capabilities, and it is best to be able to dynamically plug and unplug the gateway cross-cutting logic without needing to redeploy it. This is a dynamic publishable filter from Zuul, which greatly improves flexibility
- Zuul means monster in English, which means to see the door god beast
- It was incorporated into spring Cloud system in 2014
Advanced application scenario of Zuul Gateway
4.1 Red-green Deployment
The green cluster is the old system and the red cluster is the new system. When the new function online, through the network traffic concerns, first cut part of the flow to the red cluster, that is, the new system. Do the canary test. the test is fine and gradually switch to the red cluster until all traffic is switched to the red cluster. During any errors can be directly switched back to the old system
4.2 Developer testing has ### branches
Some features are critical and require developers to test them online. This is called the developer testing branch. The test branch is not a direct call to generate traffic, but rather the developer calls the test cluster with their own traffic. This capability is also supported through the Zuul gateway.
The Zuul gateway can take traffic from internal development requests to test clusters to do testing. This allows you to test the functionality of the build environment without affecting the actual flow of production. The gateway determines the traffic
4.3 Buried point test
Buried point testing can also be implemented using gateways. After application to production, it can be divided into buried and unburied. Burial point is where you have to bury some logic in your application. Such as instruments burial points or call chain burial points. Sometimes, buried points have a performance overhead. We can’t send all the code to production, there may be performance problems. Buried points need to know the performance of the system, to do some testing. I can send the buried site application to production, and testers can measure the buried site cluster. You can learn more about your application through point-of-purchase testing. When the buried point test is completed and the performance is found to be OK, we can remove the buried point. To production.
4.4 Pressure Test
The application is deployed to the Squeeze stress test cluster before it goes live. This is actually going to use the production flow. But this production traffic is mirrored or copy-replicated. Real traffic generated, or to a real application. Since the request is mirrored or copied, the traffic will not be returned to the client after it is processed and will be discarded. This request is mainly used to test the stress test before the application goes live.
4.5 Debugging Routes
Sometimes we need to use debug routing in addition to some problems in the build environment. For example, the tester adds some parameters to the header. Or special information in it. When the request comes in, the gateway allocates that traffic to the debug cluster. This allows you to do debugging online to find some problems.
4.6 The Golden Bird test
We can also use the gateway for canary testing. Before a new application is online, the baseLine cluster and Canary cluster are available. Through the gateway, a small amount of traffic is diverted to Canary, and if there is no problem with the traffic, the application is healthy. Then fully switch to the new version. If you have a problem, always switch back.
4.7 Sticky canaries
The sticky canary test is also the canary test. If it is not sticky, the traffic passes through to the gateway, which is randomly assigned to the baseLine and the canary cluster. If it’s stickiness, the gateway has the ability to stick to you, so if you go to canary one time, the gateway remembers your information, such as IP, and the next time you come, lets you go to canary cluster. He wouldn’t be jumping around. This is necessary in some cases, do not let the IP jump around, otherwise it may result in inconsistent functionality or results, sticky is consistent.
4.8 Cross-Region HIGH Availability
Neffilx’s gateway is partitioned, with branch deployments in three REGIONS of AWS, and Zuul is highly available in all three regions. If one fails, you can switch to a server in another area
4.9 Total anti-creeper
Netflix monitors all traffic on the gateway, detects abnormal traffic, crawlers or offensive traffic, and has the ability to reject the request and protect the service behind it
4.10 Health Check and Masking Bad Nodes
Netflix measures requests and monitors them. If one of the backend microservice nodes fails or becomes unresponsive, Netflix automatically removes the useless servers and blocks the bad ones. So the user experience is better.