Microservices cannot do without gateways, just as Java programmers cannot do without IDEA and Eclipse. why?
There are several reasons why gateways are so important to microservices:
1. Solve the problem of where to put the API
You must know that the system using the microservice architecture itself is composed of many independent service units. If the client wants to call the system, it must be implemented through various open APIs provided by the system.
The question is, where should these APIs be placed? Can it be placed directly on the service unit that constitutes the system?
For example, in an e-commerce system, APIs related to orders are placed on the service units that make up the order service; APIs of the risk control service are placed on the service units that make up the risk control service.
Well, let's assume there is a scenario where a user wants to view product details on this e-commerce system. Then, this operation of viewing product details, it is possible to:
- Call the API of the product service to get the product description
- Call the API of the evaluation service to obtain relevant evaluations
- Calling the API of Merchant Services to obtain business information
- Call the API of the gift certificate service to obtain the relevant gift certificate
- ……
It can be seen that with just such a product viewing operation, APIs of many services may be called.
If these APIs are all distributed to each service unit for the client to call, for an operation as simple as viewing a product, the client may need to remotely access the server several times or even a dozen times.
Microservices also pay attention to the granularity of APIs. That is to say, it is possible to call product information from a product service, not just calling the product service once, but it is likely to call different APIs of the product service multiple times. , in order to obtain enough data.
As a result, the client needs to access the server more times, maybe a dozen times is not enough, but dozens of times.
This behavior of accessing the server multiple times will greatly delay the interface response time of the client, which is very unrealistic.
Therefore, putting the API on each business-related service unit seems to be a big problem.
So why can the introduction of a gateway solve this problem?
Because the introduction of the gateway is equivalent to adding a layer of isolation between the client and the microservice. Usually, the gateway itself is in the same computer room as each service unit, so that the client only needs to access the gateway once when doing business operations. Then for the rest, the gateway will access different services in the same computer room, and then the obtained data will be encapsulated in the gateway and returned to the client.
2. Solve the problem of edge function integration
In a system composed of microservices, in addition to the necessary business functions, there are also some non-business functions that must be introduced for the robustness and security of the system and the management of the microservices themselves. For these non-business but very important functions, we collectively call them edge functions.
Taking the e-commerce system as an example, let's look at some important edge functions.
Suppose that because we did a very large promotion, the traffic was too large and the system could not carry it. At this time, in order to ensure the stability of the system itself, we need to digest some unsupported traffic through various means. There are three general methods:
-
Current limiting: Through algorithms such as token buckets, some additional traffic is blocked from the system and is not allowed to access.
-
Downgrade: Since the system may have been overloaded, at this time, we give up processing requests for some services and pages or simply process them, such as returning an error directly.
-
Meltdown: Sometimes, the system is overloaded or there is a bug on the line, and downgrading can't solve the problem. For example, the cache is invalid, causing a large number of requests to frequently access the database, and this frequent access to the database may cause a large number of IO operations, which in turn affects the operating system where the database is located. At the same time, this operating system has other important Services have also been directly affected. We call this chain reaction an avalanche. In order to prevent avalanches, we will resolutely stop the services that cause the database to be frequently accessed due to cache invalidation, which is called a circuit breaker.
It can be seen that the most suitable place for system guarantee strategies such as current limiting, downgrading, and circuit breaker should be to have a centralized request entry point, just like in ancient times, people needed to go through the city gate to enter the city.
When there is a problem with the system, you can directly do the corresponding operation at this entry point.
-
To limit the flow, the subsequent requests are directly restricted at this entry point.
-
To downgrade, directly determine the service or page that the request wants to access at this entry point, and return an error directly.
-
Fusing, directly at this entry point, disconnects all requests to access a specific service, and then blocks subsequent access to a specific service.
In the e-commerce system, there are many interfaces for special scenarios, which need to be strictly restricted.
For example, the payment interface requires authentication and permission control to access it. For another example, for system access, sometimes foreigners cannot access domestic websites, which requires restricting the client's access IP, so the system also needs authentication and authorization functions.
Then this kind of authentication and authorization is also most suitable for a centralized entry point of the request, and unified implementation.
Remember the unified storage of gateway APIs we mentioned above? We only need to set the corresponding permissions for these APIs. When requesting access to the special scene interface, it must be accessed through the API. Therefore, restricting the access of the interface is essentially a restriction on a specific API, so it is more appropriate to put it on the gateway.
In reality, we sometimes need to mirror the online traffic and forward it to the grayscale environment. Using these mirrored traffic can not only be used for small-scale testing, but also better evaluate the maximum throughput that the system can carry. Therefore, the system needs to have a unified entrance for shunting.
It can be seen that whether it is the security policy, authentication and authorization required by the system, or traffic diversion and other functions, they should be placed at a unified request entry to achieve the best implementation. The gateway just assumes the role of such a unified request entry.
Therefore, for microservices, various edge functions are often integrated into the API gateway in the form of plug-ins.
3. Decoupled client and backend microservices
For a set of projects, in the early days of using the microservice model, the back-end changes are often very frequent.
There are many reasons for frequent changes, such as the inappropriate division of business fields, or the rapid expansion of a business module, which may lead to drastic changes in back-end microservices.
In this case, without a gateway, there is likely to be a situation where the client needs to be forced to change as the backend changes.
For example, in the e-commerce system, we are likely to make the risk control service very small in the initial stage. With the development of the business, the risk control service is getting larger and larger. At this time, the risk control service may be decomposed into more and more detailed services such as decision engine and analysis center.
In e-commerce, risk control is often a necessary pre-operation for ordering, payment and other operations. If there is no gateway to separate the client and the microservice, and the client directly interacts with the risk control service, then the risk control service is split, and the API will inevitably be unstable. Changes in the API will naturally lead to changes in the client code that calls the API.
With the gateway, the situation is much better. When the risk control service itself changes frequently, we only need to change the code of the gateway. The upgrade of the server code is far easier than the upgrade of the client code.
Hello, I'm Shimonai.
The technical director of a listed company, managing a technical team of more than 100 people.
I went from a non-computer graduate to a programmer, working hard and growing all the way.
I will write my own growth story into articles, boring technical articles into stories.
Welcome to pay attention to my official account. After following, you can receive high concurrency and algorithm learning materials.