Application of Service Gateway in Microservices
We turn our attention to the periphery of the Spring Cloud application and discuss how each module under the microservice architecture provides external services.
1. Difficulties in external services
The application system system under the microservice architecture is huge. The basic components that require independent parts include registration center, configuration center and service bus, Turbine exception aggregation and monitoring disk, call chain tracker and link aggregation, and Kafka And middleware such as MQ, plus the scattered microservice modules after splitting, a small system can easily produce about 20 deployment packages.
We have used localhostthe method of adding ports to access directly. What should we do if these services are also provided to external users?
The product manager said that front-end programmers can work overtime to configure URLs and port numbers for various requests on each page. People are not a problem, as long as the project is completed. However, there are a lot of URLs that are exchanged on the page. Users think that they have entered a phishing website. Some students will say that we have a URL that can be routed through F5 or Nginx. It is true, but this The operation and maintenance team must manually maintain the routing rule table, which is very troublesome when we add or delete nodes or change the IP due to the replacement of the computer room; therefore, we need to introduce a mechanism to reduce the maintenance cost of the routing table.
Another problem is security. When we provide external services, we often add some access controls. For example, the order interface does not allow non-logged-in users to access, and some services also use some JWT signatures to prevent client tampering data. It would be too cumbersome for each service provider to implement the same access verification logic, which would only increase the anger of the R&D staff. Moreover, if one day we need to change the authorization scheme, such as OAuth2.0, is it difficult? Do you need to change every service provider?
How can we provide services to the outside world, manage route planning and access control well?
In this context, the API Gateway came into being, which acts like a reception room to receive all incoming requests.
2. Communication room for microservices
System Design Theory: In the computer field, any problem can be solved by introducing an intermediate layer.
Next, we will introduce a special middle layer for microservices—the briefing room. When we go to another company to do business, the first pass is the pass of the communication room. The uncle mainly does two things. thing:
- Access control to see if you have the right to access, reject unauthorized visitors;
- Guide and guide the way to ask clearly what you want to do, point out the way, and find the person who should deal with these things.
After introducing the gateway layer, our microservice architecture becomes like this:
The gateway layer is the only external service. External requests do not directly access the service layer. The gateway layer undertakes all HTTP requests. In actual applications, we will also use Gateway and Nginx together. Next, we will introduce the two aspects of access control and routing rules.
3. Access control
Access control mainly includes two tasks. The specific implementation is not provided by the gateway layer, but the gateway as a carrier carries these two tasks:
- Intercept requests: Some interfaces need to be accessed by logged-in users. For access to such interfaces, the gateway layer can check whether the access request carries identity information such as "token", such as the "Authorization" or "token" attribute in the HTTP Header. If there is no token, it means that you have not logged in, and you can directly return 403 Forbidden;
- Authentication: For services that carry tokens, we need to verify the authenticity of the tokens, otherwise users can communicate through forged tokens, and reject service requests that fail token verification, or requests that have expired tokens Serve.
4. Routing rules
Routing rules include two aspects, URL mapping and service addressing;
**URL mapping:** In most cases, the HTTP URL accessed by the client is often not the real path we configured in the Controller. For example, the client can initiate a request for "/password/update" to change the password, but the background does not For this service, at this time, the gateway layer needs to make a routing rule to map the visiting URL into a real service path, such as mapping the path of the password modification request just now to the "/user/settings/security/password" request;
Service addressing: After the URL is mapped, the gateway layer needs to find the address of the server that can provide the service. For the service cluster, it also needs to implement a load balancing strategy. (Spoiler: In Spring Cloud, Gateway uses Eureka's service discovery mechanism to implement service addressing, and load balancing relies on Ribbon)