1. What is a service gateway

Service gateway = route forwarding + filter

1. Routing and forwarding: receive all external requests and forward them to the back-end microservices;

2. Filter: A series of cross-cutting functions can be completed in the service gateway, such as authority verification, current limiting and monitoring, etc., which can be completed through filters (in fact, routing and forwarding are also realized through filters).

2. Why do you need a service gateway

The above-mentioned cross-cutting function (take permission verification as an example) can be written in three places:

• Each service implements itself

• Write to a public service, and then all other services depend on this service

• Write to the pre-filter of the service gateway, all requests come over for permission verification

The first one has obvious shortcomings and is basically not used; the second one is much better than the first one, and the code development will not be redundant, but there are two disadvantages:

• Since each service introduces this public service, it is equivalent to introducing the same permission verification code in each service, which increases the jar package size of each service for no reason, especially for deployment using docker images For scenarios, the smaller the jar, the better;

• Since each service introduces this public service, it may be more difficult for us to upgrade this service later, and the more functions the public service has, the harder it is to upgrade. And assuming we change the permission verification method in the public service, If we want all services to use the new permission verification method, we need to repackage all the previous services, compile and deploy.

The service gateway can just solve such problems:

• Write the logic of permission verification in the filter of the gateway, the back-end service does not need to pay attention to the code of permission verification, so the logic of permission verification will not be introduced into the jar package of the service, and the size of the jar package will not be increased;

• If you want to modify the logic of permission verification, you only need to modify the permission verification filter in the gateway, without upgrading all existing microservices.

So, a service gateway is needed! ! !

3. Service gateway technology selection

The microservice architecture after introducing the service gateway is as above, and generally includes three parts: service gateway, open-service and service.

1. Overall process

• The service gateway, open-service and service are registered to the registration center when they start ;

• When a user makes a request, he directly requests the gateway, and the gateway performs intelligent routing and forwarding (including service discovery, load balancing) to open-service, which includes operations such as permission verification, monitoring, and current limiting.

• open-service aggregates the internal service response, returns it to the gateway, and the gateway returns it to the user

2. Points to note when introducing gateways

• The gateway is added, and there is an extra layer of forwarding (the original user request can directly access the open-service), and the performance will drop a little (but not much, usually, the performance of the gateway machine will be very good, and the access between the gateway and the open-service is usually It is intranet access, the speed is very fast);

• The single point problem of the gateway: In the entire network call process, there must be a single point, which may be a gateway, nginx, DNS server, etc. To prevent the gateway from being a single point, you can hang another nginx in front of the gateway layer. The performance of nginx is extremely high, and it will basically not be hung. After that, the gateway service can continue to add machines. But such a request is forwarded twice, so the best way is to deploy the gateway single-point service on a powerful machine (estimate the configuration of the machine through pressure testing), and the performance comparison between nginx and zuul, according to foreign According to the experiment done by a friend of mine, the difference is not much, zuul is an open source framework used as a gateway open sourced by netflix;

• The gateway should be as light as possible.

3. Basic functions of the service gateway

• Smart Routing: Receive

  external

  All requests are forwarded to the backend external service open-service;

• Note: We only forward external requests, and requests between services do not go through the gateway, which means that full link tracking, internal service API monitoring, fault tolerance between internal service calls, and intelligent routing cannot be completed at the gateway; of course, you can also All service calls go through the gateway, so almost all functions can be integrated into the gateway, but in this case, the pressure on the gateway will be heavy and overwhelmed.

• Permission verification: Only verify the user's request to the open-service service, not the internal request of the service. Is it necessary to verify the request inside the service?

• API monitoring: only monitor requests passing through the gateway, and some performance indicators of the gateway itself (for example, gc, etc.);

• Current limiting: Cooperate with monitoring to perform current limiting operation;

• Unified collection of API logs: similar to an aspect aspect, recording related logs when the interface enters and exits

• . . . follow-up supplement

The above functions are the basic functions of the gateway, and the gateway can also realize the following functions:

• A|B test: A|B test is a relatively large thing, including background experiment configuration, data embedding point (see conversion rate) and distribution engine. In the service gateway, the distribution engine can be implemented, but in fact the distribution engine will call Internal services, so if it is based on the architecture in the above figure, it is best to make the shunt engine in open-service, not in the service gateway.

• . . . follow-up supplement

4. Technology selection

The author plans to build a lightweight service gateway by himself, and the technology selection is as follows:

• Development language: java + groovy, the advantage of groovy is that the gateway service can dynamically add filters to realize some functions without restarting;

• Microservice basic framework: springboot;

• Gateway basic components: netflix zuul;

• Service registry: consul;

• Permission verification: jwt;

• API monitoring: prometheus + grafana;

• API unified log collection: logback + ELK;

• Stress test: Jmeter;

• . . . follow-up supplement

In the subsequent introduction, each knowledge point will be gradually introduced, and a lightweight service gateway will be completed! ! !