From simple to deep understanding of Linglong platform unified access service - Monet

1. Background introduction

As an intelligent design platform, Linglong is easy to understand and has a visual operation. At the same time, it has a large number of templates and materials to save a lot of drawing time for users, merchants or business teams to reduce costs and increase efficiency.

As more and more users use it, and the business continues to grow, this also brings challenges to Linglong's server.

The current structure of Linglong server is composed of multiple platforms as shown in the figure, and each platform has its own domain name. As the business grows, each time a platform is launched to expand the function, the drawbacks of this model are also revealed.

For back-end students, creating a new platform requires docking login and permissions; the API functions provided are not centrally managed, and it is not clear whether the APIs being developed are provided repeatedly; the developed APIs also need to limit the current flow or limit the flow of their own in some business scenarios. Degraded; global API monitoring is missing.

For the operation and maintenance students, it is necessary to create a new domain name mapping for each platform developed by the back-end students (and also need to apply for a certificate).

For front-end students, in order to reuse some API functions, it is necessary to connect multiple domain names, and also distinguish between test and production environment domain names, which leads to front-end students need to maintain a batch of domain names in the project.

According to the above scenarios, we can conclude that there is a lack of unified API entry and management (unified domain name), unified authentication, unified flow control, and unified monitoring.

How to solve the above architectural pain points? We need a service on the business platform to receive front-end requests and forward them to the corresponding back-end platform. It can also perform user authentication and permission verification for each request, and can accurately limit and downgrade the API. API request response exceptions are monitored and reported.

This service is about to come out: API Gateway, and named: Monet . Below I will introduce this gateway middleware service.

---

2. Technical selection

Once Monet's needs were identified, we began technology selection.

base frame selection

Newton said that if others see me further, it is because I stand on the shoulders of giants. So we need to stand on the shoulders of giants to see further. Then Monet is the same, you need to choose a gateway framework and expand on this basis.

Technical selection needs to be considered from the perspectives of language system, community activity, scalability, and performance. We selected two categories from the more active communities: non-Java language gateways: Nginx, Kong, Traefik; Java language gateways: Spring Cloud Gateway and Spring Cloud Zuul 2.

Since the backend is developed using Java's Spring ecosystem, the programming language consistency is more inclined to components developed in the Java language. Therefore, there are two gateways to choose from in the Spring ecosystem, namely: Spring Cloud Gateway and Spring Cloud Zuul 2

Spring Cloud Gateway is an official gateway, and Zuul 2 is an open source gateway from Netfix. There is no gap between the two in actual production performance. Spring Cloud Gateway is based on Spring 5.0, Spring Boot 2.0 and Project Reactor, providing a simple and effective API gateway for services; Zuul 1 is based on synchronous IO and Zuul 2 is based on Netty Server asynchronous IO , are all components in the Spring Cloud ecosystem. Here are some differences between the two:

gateway	Spring Cloud Gateway	Spring Cloud Zuul 2
Ease of use	Simple to use	few references
maintainability	Spring series is highly scalable, easy to configure, and maintainable	poor maintainability
maturity	The Spring community is mature, but the Gateway resources are less	Open source soon, little information

Compared with the two, Spring Cloud Gateway has the advantage of access. So we finally chose Spring Cloud Gateway as the basic framework

---

3. Implementation

In the previous introduction, we need Monet to complete unified API entry and management, unified authentication, unified flow control and unified monitoring. Next, we will introduce the implementation one by one.

Unified API entry and management

Unified API entry

The unified API entry is relatively simple. We only need to resolve a domain name to Monet. Monet is implemented based on Spring Cloud Gateway, and the request can be forwarded to the corresponding service through routing configuration. Here is a description of the problems we encountered in the implementation process. First, there are two types of routing configurations for Spring Cloud Gateway: project configuration files and code-based routing configurations.

Both of the above have the disadvantage that once the routing configuration is changed, the Monet service needs to be restarted, which is not preferable in the actual production environment.

After inquiring some information, it is found that routing configuration information can be obtained through the RouteDefinitionRepository interface, and we can obtain routing configuration information from the database. When we change the routing configuration, trigger the Spring Cloud Gateway routing configuration reload event to allow Monet Get the latest routing configuration to achieve the effect of dynamic routing, so we can expand to the following process:

Unified API Management

Why do API management? API management is mainly to avoid repeated API construction and API security.

How does Monet identify which API the request URI belongs to? To know that the URI directory in the Restful API has parameters, it is difficult for Monet to identify which API it is, but it is not incomprehensible.

The prefix tree data structure can be used for API parsing and matching. The prefix tree is also called the word search tree, which is typically used in statistics, sorting, etc., using the common prefix of strings to reduce query time and minimize unnecessary string comparisons , thereby increasing the matching speed. Schematic diagram of the tree structure after splitting the API URI part into a string:

<img src="https://storage.360buyimg.com/neos-static-files/4d4b53db-d989-48e9-8de0-ad075c7bb313.png" title="" alt="" width="306">

We implement API parsing and supervision by implementing GlobalFilter of Spring Cloud Gateway, exporting API information through back-end services and importing it into the gateway console (using Zookeeper to store API information). The API parsing filter also obtains and caches API information from Zookeeper. To the matching API, it can only respond to 404. If the API can match, the parsed result will be put into the context, which is convenient for subsequent filters to obtain the API information for the next step, such as permission verification, etc.;

At the same time, we will also establish an audit system on the gateway console, and the API can be launched only after the project leader audits it.

Unified authentication

Unified authentication is also divided into two parts: user authentication and authority verification.

User Authentication

In order to make the back-end service not need to pay attention to the login process, the user login authentication process only needs to be completed in Monet. Like the API parsing filter, user authentication is also implemented through GlobalFilter to form a Monet filter. After user authentication is completed, each request can be read. Get the relevant information of the user and put it into the context, which is convenient for later filters or back-end services to obtain. as the picture shows:

permission check

In order to allow the back-end service to centrally manage permissions, a set of permissions system is specially formed, and a service is responsible for it, and each service permission can be formed by customizing the permission service according to the needs of the back-end service, and the permission service is not there. This is too much to tell. Since the previous API analysis has been able to obtain the API information and the user information obtained by user authentication, we can verify the permissions of the current user.

Unified flow control

Since the current limiting and fusing components are very mature, we directly select the current limiting and fusing components supported by Spring Cloud Gateway. The current limiting and fusing components supported are: Hystrix and Sentinel . The difference between the two components:

Function	Sentinel	Hystrix
maturity	Active community and comprehensive documentation	Maintenance has stopped
circuit breaker downgrade strategy	Based on response time, exception ratio, number of exceptions	based on anomaly ratios
Real-time statistics implementation	sliding window	sliding window
Dynamic rule configuration	Supports multiple data sources	Supports multiple data sources
Extensibility	multiple extension points	Plug-in form
Limiting	Based on QPS, support current limit based on call relationship	priority support
traffic shaping	Support preheating mode, constant speed mode, preheating queuing mode (traffic rules can be configured)	not support
System adaptive protection	support	not support

According to the above functional differences, we finally choose Sentinel. Sentinel has rich functions. At the same time, we can put the relevant current limiting and fuse configuration rules into Zookeeper to facilitate our configuration on the gateway console. Through Sentinel, users, IPs, or API levels can be limited. flow or fuse downgrade capability.

Unified monitoring

API monitoring is also relatively simple. It also implements GlobalFilter and after the API is parsed, gets the API information and records the request information for reporting, such as API request time, response time and other data. In order to be able to adapt to various monitoring systems, a set of monitoring interfaces is defined here, and different monitoring systems can be implemented only by implementing this interface. For example, if the internal version is connected to the internal monitoring system of JD.com, the corresponding one is an independent one. At the same time, it can be connected to another set of monitoring platforms according to the monitoring interface, which is more scalable.

The above is the complete Monet architecture.

4. Summary

We first describe the project background and technology selection by introducing the pain points of the current architecture, and implement unified entry and API management, unified authentication, unified flow control, and unified monitoring in Monet based on Spring Cloud Gateway. Although the above functions have been completed, there are still many areas that need to be expanded, such as: API management audit process, access to non-Java services, Access logs, etc.