Share the record | Build NGINX into a powerful API gateway (Part 2)

Original author:Yi Jiuping

Original link:Share the record | Build NGINX into a powerful API gateway (Part 2)

NGINX’s only official Chinese community, all athttp://nginx.org.cn

Editor's note - This article is a shared record of the NGINX Sprint China 2022 Online Conference. Clickhere to watch the full video replay of the conference for free. Since the article is long, it will be published in two parts. Click"Sharing Record | Building NGINX into a Powerful API Gateway (Part 1)" to read the previous article.

In this sharing, we will discuss. This sharing will comprehensively introduce the concepts and functions of API gateways, and how to use NGINX to build a powerful API gateway.

3. Build an API gateway

How to build an API gateway? From an engineering perspective, we still need to comply with some software development laws or some software engineering ideas to complete the entire development process. Generally speaking, development can be completed in 7 major steps:

Gateway function planning: Plan the functions of the API gateway and clarify the functional and non-functional characteristics of the API gateway.
Technical architecture design: Clarify the technical architecture and determine the component architecture of the data plane, control plane and management plane. It is also necessary to clarify the deployment location of the API gateway to ensure the feasibility of its technical architecture.
NGINX configuration design: Clarify the configuration settings of NGINX and which NGINX instructions and configurations are used to implement the gateway function. At this time, manual configuration is required for PoC verification to confirm whether the function is feasible and meets the requirements.
Configuration model design: Allow users who are unfamiliar with NGINX to quickly use the NGINX gateway.
Configuration template development: Implement a template that can automatically render and generate NGINX configuration through model and configuration data.
Control plane development: Control plane development allows the API gateway to support both the NGINX open source version and the commercial version. In addition to supporting Reload, it can also support dynamic API configuration changes.
Functional test verification: Ensure that the functionality of the API gateway actually exists and is available.

3.1 API gateway functional architecture

First of all, the functionality of this API gateway is actually only a subset. As an API gateway, in addition to the reverse proxy function of the API, it also needs to discover backend service instances through integration with registration centers such as Eureka and Nacos. In addition, it is also necessary to clarify the protocols supported by the API, such as HTTP protocol, gRPC protocol, or Web Socket protocol. At the same time, the API needs to have decentralized and domain-based management capabilities, as well as address matching or automated configuration capabilities, so it is necessary to think about how to update Good management API.

The second point requires attention to API security, such as API access control, API authentication methods, etc.

The third point is API flow control. It is necessary to ensure that the API gateway can protect back-end applications as a traffic entrance. It can limit traffic rate, request rewriting, response rewriting, or perform unified error code conversion, and even perform some application optimization. In addition, traffic scheduling needs to be implemented. In addition to the common capabilities of reverse proxy load balancing, grayscale publishing, blue-green publishing capabilities, or traffic calculation capabilities can also be implemented.

3.2 API gateway technical architecture

The picture above is a simple technical architecture design. Of course, this technical architecture is only a blueprint. This experiment did not implement all functions. It mainly realized the capabilities of the data plane and control plane.

The core function of the control plane is to integrate with the configuration center or management plane to obtain configuration data and translate it into NGINX configuration. This process may be to generate the configuration file and then reload it, or it may be to directly call the NGINX API to dynamically load the configuration.

In addition, the function of the gateway control service is mainly to write or modify configurations. In this demonstration, etcd is used to save the configuration, and etcd is used as a database. The configuration is first written to etcd, and then the configuration is converted into NGINX configuration through the Confd execution template.

As a data plane, API gateway, in addition to serving as a reverse proxy for business services, may also interface with two types of services: the first is to interface with the authentication and authorization center for API access authentication or authentication; the other is to interface with The monitoring center implements data plane monitoring

3.3 API gateway configuration design

NGINX has many functions. In order to implement specific functions, these capabilities need to be planned. We can plan it into a directory structure, which needs to be considered according to different dimensions.

For example, whether the configuration is modified frequently, whether it is split according to business dimensions, whether the underlying configuration should be separated from the HTTP service configuration that receives the request, whether the back-end service configuration should be separated, etc. So we need to carry out such planning so that the management of API gateway is simpler and more decoupled.

3.4 API gateway model design

The model determines the architecture of the entire application system. In the API gateway architecture shared this time, we designed an API Gateway model. The above figure divides the model into two colors. We define the dark blue parts as entities, and they have unique ID and independent life cycle, the light blue part is defined as a value object. We use domain-driven thinking to define the model, so there will be a Gateway entity at the top.

Gateway represents a gateway cluster. There are multiple NGINX instances in the cluster. The same Gateway may have different servers. Upstream is easier to understand. As an upstream service, there must be a model describing the upstream service cluster. Member may be created in many ways. It may be manually configured, automatically discovered, or imported from Excel.

For the upstream service cluster (Upstream), we will also have some strategies, generally there are three types of strategies. First, whether to do some traffic load balancing; secondly, whether to maintain the session for certain status sessions to ensure the continuity of the service; finally, whether to do some health check function to detect the availability of back-end services , clarify whether to perform circuit breaker downgrade.

3.5 API gateway control agent development

After the model design is completed, agent development needs to be carried out. In this case sharing, the agent used is Confd, because Confd itself is a configuration change tool, it supports more flexible template functions, and it also supports docking with NoSQL configuration centers such as etcd and Redis. or caching server. In this way we can use it to monitor configuration changes and complete configuration generation and loading.

3.6 API gateway template development

Everyone has learned a lot about the concept of templates. Templates actually use the idea of combining dynamic and static things, putting some static things into the template and converting some dynamic things into variables. If the template is more flexible, you can make some if else judgments, you can also make for loops, and even implement some expansion capabilities, call some instructions, etc.

Functional testing is divided into two dimensions: scenarios and use cases. For example, when testing the TLS offloading scenario, you need to consider whether the certificate has expired and where the certificate is stored. The design of scenarios and use cases must be implemented in conjunction with the overall functional planning.

In addition, there must be a backend service throughout the testing process. A simple application is implemented in the use case. The function of this application is very simple. It is only used for API testing and simply implements services in several business fields. It is mainly to meet the test requirements, so the implementation is not too complicated.

Automated testing tools may also be used, because new functions may be added in subsequent updates. During the process of adding new functions, the availability of the original functions must be ensured, so it is best to automate integration and delivery.

NGINX is the only official Chinese community, all at nginx.org.cn

More NGINX-related technical information, interactive Q&A, series of courses, and event resources:

Open source community official website:Open source web service provider - NGINX open source community

WeChat public account:NGINX solemnly announces its new commitment to the open source community