Shulou(Shulou.com)06/02 Report--

Author: A Fei, Senior R & D Engineer, Application Platform Infrastructure

In the microservice architecture, different microservices can have different network addresses, and each microservice completes a user request by calling each other, and the client may complete a user request by calling the interface of N microservices. Therefore, adding an API gateway between client and server becomes the inevitable choice for most microservice architectures.

API gateways also play a crucial role in the microservices practice of push. On the one hand, API gateway is the only entrance to push micro-service system; on the other hand, API gateway realizes the common requirements of many back-end services, avoiding repeated construction.

Design and Implementation of Push Microservice Gateway

Microservices are primarily based on Docker and Kubernetes practices. At the bottom of the microservices architecture is a privately deployed Kubernetes cluster, on top of which application services are deployed.

The application service system is divided into three layers, the top layer is the gateway layer, followed by the business layer, and the bottom layer is the basic layer service. When deploying application services, we used Kubernetes namespaces to isolate products from different product lines. In addition to application services, Kubernetes clusters are also deployed with Consul for configuration management, Kube-DNS for service registration and discovery, and some auxiliary systems for application and cluster management.

The following is a diagram of a push microservices architecture.

The functional requirements of API Gateway are mainly as follows:

To support the configuration of multiple products, provide different ports for different products;

Dynamic routing;

URI rewriting;

registration and discovery of services;

Load Balancer;

Safety-related requirements, such as session verification;

Flow control;

Link tracing;

A/B Testing。

After researching existing gateway products on the market, our technical team found that they were not very suitable for individual microservices systems. First, the management of push configuration is based on Consul, and most gateway products need to be configured based on some DB storage; second, most gateway products provide more general functions, which also reduces the complexity and flexibility of configuration; third, most gateway products are difficult to directly integrate into the push microservice architecture.

In the end, we chose OperResty and Lua for self-research gateway. In the process of self-research, we also borrowed some designs from other gateway products, such as Kong and Orange plug-in mechanism.

The plug-in design of each API gateway is shown below.

OpenResty processes requests in several stages. The plug-ins of the API gateway are mainly processed in the six stages of Set, Rewrite, Access, Header_filter, Body_filter and Log. Each plug-in can play a corresponding role in one or more stages. After a request arrives at the API gateway, the gateway will select plug-ins for the request according to the configuration, and then further filter out plug-ins matching the rules according to the rules of each plug-in, and finally instantiate the plug-ins and process the traffic accordingly.

We can understand this process by example, as shown in the figure above, localhost:8080/api/demo/test/hello After the request arrives at the gateway, the gateway will determine the product information according to the host and port, and extract the URI(/api/demo/test/hello), and then filter out the plugins to be used according to the specific configuration of the product-Rewrite_URI, Dyups and Auth. Then filter according to the rule configuration of each plug-in. After filtering, only Rewrite_URI and Dyups are selected. Both plug-ins are then instantiated to process the request at various stages. When the request is forwarded to the backend service, the URI is rewritten to "/demo/test/hello" and the upstream is set to "prod1-svc1." After the request is processed by the backend service, the response is returned to the client via the gateway, which is how the plug-in is designed and worked. To optimize performance, we defer plug-in instantiation until the request actually starts to be processed, until then the gateway filters out plug-ins that do not need to be executed through product configurations and rules. It can also be seen from the figure that the rule configuration of each plug-in is very simple, and there is no uniform format, which also ensures that the plug-in configuration is simple and flexible.

The configuration of gateway is hot updated through Consul and Consul-Template. After the configuration is updated on Consul, Consul-Template will pull it down in real time and update it in the following two ways.

(1) Update the configuration to shared-dict by calling the Update API.

(2) Update the configuration file, using Reload OpenResty to update the configuration file.

The main functions provided by the push microservice gateway 1. Dynamic routing

Dynamic routing involves three aspects: service registration, service discovery and request forwarding.

As shown in the figure below, service registration and discovery are implemented based on Kubernetes Service and Kube-DNS. In Consul, a service mapping table is maintained. Each microservice applied corresponds to a Service on Kubernetes. Each Service created will add an entry to the service mapping table on Consul (which will be updated to the shared memory of the gateway in real time). Every time the gateway receives a request, it will query the specific backend service (i.e. Service name in Kubernetes) from the service mapping table and perform dynamic routing. Kube-DNS can resolve the domain name of Service to ClusterIP inside Kubernetes, and Service proxies multiple pods, which will forward traffic evenly to different pods.

2. flow control

Traffic control is achieved primarily through a backend service called Counter and a flow control plug-in in the gateway. Counter is responsible for storing the number of access requests and limits, and supports counting by time dimension. The flow control plug-in is responsible for intercepting traffic and calling the interface of Counter for overrun query. If Counter returns a request exceeding the limit, the gateway will directly refuse access to realize the function of time limit. Combined with the time dimension, the requirement of frequency limit can be realized. At the same time, the flow control plug-in updates the count in Counter by outputting log information to the fluent-bit, and the fluent-bit aggregation counts.

3. link tracing

The link tracing of the whole microservice architecture is based on Zipkin, a distributed link tracing system. The ultimate link tracing capability is achieved by installing Zipkin plug-ins in gateways and introducing Zipkin middleware in backend services. The specific architecture is shown in the figure below.

4. A/B testing

In the implementation of A/B testing, there are several key points:

(1) All policy information is configured on Consul and takes effect in real time in the memory of each microservice through Consul-Template;

(2) Each policy specifies whether A or B should be invoked when invoking a microservice (default is A);

(3) Implement A/B plug-in in gateway, when request arrives at gateway, A/B policy applicable to request can be determined by A/B plug-in configuration rules;

(4) The gateway will pass the A/B policy applicable to the request through the URL parameter;

(5) Each microservice selects the right service to access through the passed down policy.

The following figure shows the invocation chain in two scenarios.

summary

The above is the design of a push micro service gateway and the realization of its main functions. After that, each technical team will continue to improve the elastic design of API gateway, so that it can reduce the impact of failure when it occurs; at the same time, we will continue to integrate the gateway with DevOps platform to ensure that when the gateway is iteratively updated, there will be more automated testing to ensure quality and achieve faster deployment.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.