CN109710223B

CN109710223B - API gateway hot plug system based on distributed KV storage system

Info

Publication number: CN109710223B
Application number: CN201811633587.4A
Authority: CN
Inventors: 鄂海红; 宋美娜; 吴超宇; 陈沅星
Original assignee: Beijing University of Posts and Telecommunications
Current assignee: Beijing University of Posts and Telecommunications
Priority date: 2018-12-29
Filing date: 2018-12-29
Publication date: 2021-03-12
Anticipated expiration: 2038-12-29
Also published as: CN109710223A

Abstract

The invention discloses an API gateway hot plug system based on a distributed KV storage system, which realizes distributed dynamic access micro-service through distributed deployment and comprises the following steps: the API hot plug module comprises an online sub-module and a registration sub-module, and the online sub-module is used for processing the online release function of the API and accessing the API after the API is successfully online; the registration submodule comprises a webpage form registration submodule and a file registration submodule; the API hot-plug module comprises an off-line module and a logout module, wherein the off-line module is used for off-line of the API and forbids access to modify or logout the API after the API is off-line; the logout module is used for removing the API from the hot plug system. And the hot-plugging system is horizontally and dynamically stretched and contracted in a docker container mode. The system has the characteristics of strong consistency, high availability, high performance, high expansion and fault tolerance.

Description

API gateway hot plug system based on distributed KV storage system

Technical Field

The present invention relates to the field of information technology and data service technology, and in particular, to an API (Application Programming Interface) gateway hot plug system based on a distributed KV (Key-Value) storage system.

Background

In the micro-service architecture style, a large application is split to be provided for a plurality of small service systems, which can be self-organized, that is, the small systems can own their own database, framework, even language, etc., and the small systems are usually called by H5, Android, IOS and third party application programs by providing a Rest Api style interface, for example, in an e-commerce system, a commodity detail page is viewed, which contains the title, price, stock, comment, etc. of the commodity, and the data may be located in different micro-service systems for the back end, so that there is no way to rely on the join query of the database to obtain the final result like the traditional single application. At this time, a unified portal is needed to manage service access, and therefore, an API gateway is born. The gateway, as the manager of the service, has to solve the problem of how to access the service dynamically.

The current more sophisticated API gateway scheme is springcloudul, which is based on eureka as a service registry. Kong, a highly available, easily extensible API Gateway project based on the Nginx _ Lua module write, sourced by Mashape corporation, stores service data based on Apache Cassandra/PostgreSQL.

However, at present, eureka registration service has difficulty operating the service in the form of a black box, requiring some intrusion into the service. Only services that meet their specific specifications can make registered access, which is difficult to operate. The Kong installation requires additional complex operations such as database installation configuration, and is not user-friendly. Meanwhile, the horizontal expansion capability is also an important point of the gateway influencing the performance of the gateway. Existing systems do not have a more efficient solution in terms of horizontal scalability.

Disclosure of Invention

The present invention is based on the recognition and discovery by the inventors of the following problems:

many Web applications save data to the RDBMS, from which the application server reads the data and displays it in a browser. However, with an increase in the amount of data and a concentration of accesses, the RDBMS is heavily burdened, the database response deteriorates, and the website display is delayed.

The performance problem is more prominent for API gateways, which change from decentralized to aggregated prior requests due to the existence of the gateway. The gateway is responsible for handling service access requests, proxying and routing services, and the API gateway obviously becomes a bottleneck point of the system. If the gateway architecture is not properly designed, the overall system performance may be degraded. Therefore, how to design the architecture becomes a key point.

The present invention is directed to solving, at least to some extent, one of the technical problems in the related art.

Therefore, the invention aims to provide an API gateway hot plug system based on a distributed KV storage system, the system has the characteristics of strong consistency, high availability, high performance, high expansion and fault tolerance, and the storage of the API can be realized very conveniently and efficiently by using the system.

In order to achieve the above object, an embodiment of the present invention provides an API gateway hot plug system based on a distributed KV storage system, where the hot plug system implements distributed dynamic access microservice through distributed deployment, and includes: the API hot plug module comprises an on-line module and a registration sub-module, wherein the on-line module is used for processing an on-line issuing function of the API and accessing after the API is successfully on-line; the registration submodule comprises a webpage form registration submodule and a file registration submodule, wherein the webpage form registration submodule is used for guiding a user to register a form through a preset webpage form in a preset mode; the file registration submodule is used for performing file registration by filling in a JSON/YML file; the API hot-plug module comprises an off-line module and a logout module, wherein the off-line module is used for off-line of the API and forbids access to modify or logout the API after the API is off-line; the logout module is used for removing the API from the hot plug system.

According to the API gateway hot plug system based on the distributed KV storage system, the technical problems of heavy burden, deteriorated database response, delayed website display and other major influences of the RDBMS are effectively solved through the distributed KV storage system, the problems of dynamic modification of API information and addition and deletion of API fields are solved in a mode that unique service IDs are used as keys and service information JSON is changed into values, and the problem of horizontal expansion is solved by dynamically expanding and contracting the API gateway in a docker container mode. The system has the characteristics of strong consistency, high availability, high performance, high expansion and fault tolerance, and the storage of the API can be realized very conveniently and efficiently by using the system.

In addition, the API gateway hot plug system based on the distributed KV storage system according to the above embodiment of the present invention may further have the following additional technical features:

further, in an embodiment of the present invention, when the API hot-plug module is in the single-node hot-plug mode, the online sub-module is further configured to: clicking a creation API to input API data; inputting API key information, wherein the API key information comprises address, port and path of an API; storing the API data in a http request body in a JSON format, and submitting the API data to a background gateway server; extracting the API key information, inserting an up-down identifier, storing the API key information in a background database, and generating a unique identifier of the API according to the API name and the uuid.

Further, in an embodiment of the present invention, when the API hot plug module is in the single-node hot plug mode, the registration sub-module is further configured to: clicking to upload a yaml file; filling the yaml file, wherein the yaml file comprises one or more of a name corresponding to the API, a label of the API, an address of the API for providing the service, an API parameter description, a response description of the API, a port for providing the service, a request path corresponding to the API, a request method of the API and a type to which the API belongs; clicking to upload the Yaml file, and transmitting the Yaml data to a background server; and the background server performs normalization processing on the Yaml data, inserts an upper and lower line identifier, stores the Yaml data in a background database, and generates a unique API identifier according to the API name and the uuid.

Further, in an embodiment of the present invention, the method further includes: and the packaging module is used for carrying out normalization processing after the form registration and/or the file registration are subjected to data verification so as to package the form registration and/or the file registration into uniform data.

Further, in an embodiment of the present invention, when the API hot plug module is in a multi-node hot plug mode, the API hot plug module is further configured to submit a log, and specifically includes: when an API hot plug request reaches a preset non-Leader server node, forwarding the API hot plug request to a Leader node, generating a log entry of the operation by the Leader node according to the API hot plug request, and then sending a log replication request to a follower by the Leader node to synchronize the log entry; after the Leader node sends the log entry replication request, the feedback of the follower is waited, and after the response of the preset number of the sub-nodes is received, the log entry is modified.

Further, in an embodiment of the present invention, when the API hot plug module is in a multi-node hot plug mode, the API hot plug module is further configured to submit data, which specifically includes: and submitting data after the Leader node modifies the log entry, sending the submitted information of the log entry to each follower, and modifying the data after each follower receives the information.

Further, in an embodiment of the present invention, when the API hot plug module is in the single-node hot plug mode, the offline module is further configured to: entering an ID of an API needing offline, wherein the ID is combined by the APINAME and the uuid; and after obtaining the ID of the API, inquiring whether the corresponding API exists according to the ID, if so, updating data corresponding to the API, and otherwise, ending the process.

Further, in an embodiment of the present invention, when the API hot plug module is in the single-node hot plug mode, the logout module is further configured to: entering an ID of an API needing offline, wherein the ID is combined by the APINAME and the uuid; and after obtaining the ID of the API, inquiring whether the corresponding API exists according to the ID, if so, eliminating data corresponding to the API, and otherwise, ending the process.

Further, in an embodiment of the present invention, when the API hot-plug module is in a multi-node hot-plug mode, the API hot-plug module is further configured to submit a log, which specifically includes: when an API hot plug request reaches a preset non-Leader Server node, forwarding the API hot plug request to a Leader node, generating a log entry of the operation by the Leader node according to the API hot plug request, and then sending a log replication request to a follower by the Leader node to synchronize the log entry; after the Leader node sends the log entry replication request, the feedback of the follower is waited, and after the response of the preset number of the sub-nodes is received, the log entry is modified.

Further, in an embodiment of the present invention, when the API hot-plug module is in the multi-node hot-plug mode, the API hot-plug module is further used for submitting data, which specifically includes: and submitting data after the Leader node modifies the log entry, sending the submitted information of the log entry to each follower, and modifying the data after each follower receives the information.

Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.

Drawings

The foregoing and/or additional aspects and advantages of the present invention will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:

fig. 1 is a schematic structural diagram of an API gateway hot plug system based on a distributed KV storage system according to an embodiment of the present invention;

FIG. 2 is a hot plug flow diagram according to one embodiment of the present invention;

FIG. 3 is a schematic diagram of a web page fill-in form interface according to one embodiment of the invention;

FIG. 4 is a detailed flowchart illustrating the registration of a web form according to an embodiment of the invention;

FIG. 5 is a schematic diagram of a file registration interface according to one embodiment of the invention;

FIG. 6 is a schematic diagram of a document registration workflow according to one embodiment of the invention;

FIG. 7 is a schematic diagram of an on-line publishing of an API according to one embodiment of the invention;

FIG. 8 is a multi-node hot-plug flow diagram according to one embodiment of the present invention;

FIG. 9 is a schematic diagram of log replication under multi-node hot-plug, according to one embodiment of the invention;

FIG. 10 is a schematic diagram of a multi-node hot-plug log entry commit modification, according to one embodiment of the present invention;

FIG. 11 is a schematic diagram of multi-node hot-plug data synchronization, according to one embodiment of the present invention;

FIG. 12 is a single node hot-plug flow diagram according to one embodiment of the present invention;

FIG. 13 is a flow chart of a multi-node hot-plug according to one embodiment of the present invention;

FIG. 14 is a schematic diagram of log replication at a hot-unplug of multiple nodes, according to one embodiment of the invention;

FIG. 15 is a schematic diagram of a log modification commit at a hot unplug of multiple nodes, according to one embodiment of the invention;

FIG. 16 is a data synchronization diagram for multi-node hot-unplug, according to one embodiment of the present invention.

Detailed Description

Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are illustrative and intended to be illustrative of the invention and are not to be construed as limiting the invention.

The API gateway hot plug system based on the distributed KV storage system according to the embodiment of the present invention is described below with reference to the accompanying drawings.

Fig. 1 is a schematic structural diagram of an API gateway hot plug system based on a distributed KV storage system according to an embodiment of the present invention.

As shown in fig. 1, in the API gateway hot plug system 10 based on the distributed KV storage system, the hot plug system 10 implements distributed dynamic access micro-service through distributed deployment, including: API hot-plug module 100 and API hot-plug module 200.

The API hot-plug module 100 includes an online sub-module 110 and a registration sub-module 120, where the online sub-module 110 is configured to process an online publishing function of the API, and access the API after the API is successfully online; the registration submodule 120 includes a web page form registration submodule 121 and a file registration submodule 122, where the web page form registration submodule 121 is configured to guide a user to perform form registration through a preset web page form in a preset manner; the file registration submodule 122 is used to perform file registration by filling in a JSON/YML file. The API hot-plug module 200 includes a logout module 220 and a logout module 210, wherein the logout module 210 is used for logging off the API, and forbids access to modify or logout the API after the API is logged off; the logout module 220 is used to remove APIs from the hot plug system. The system 10 of the embodiment of the invention has the characteristics of strong consistency, high availability, high performance, high expansion and fault tolerance, and the storage of the API can be realized very conveniently and efficiently by using the system.

It can be understood that the API gateway hot plug scheme based on the distributed KV storage system proposed in the embodiment of the present invention is intended to solve the problems of complex definition and high intrusiveness of the above process. The API hot-plug module 100 includes an up-line module 110: processing the online release function of the API, and only after the API is successfully online, the API can be accessed formally; registration submodule 120: the method comprises two sub-modules, namely a web form registration sub-module 121: and the user is guided to register in a single step through the friendly web page table. The file registration sub-module 122: registration is performed by filling in a JSON/YML file. The API hot-plug module 200 includes: the offline module 210: and the offline API inhibits access so as to modify or log off. The logout module 220: formally removing the API in the system 10.

The functional module not only provides functional support for hot plug, but also provides powerful support for robustness of the hot plug system through distributed deployment. The single-machine system often has a single-point bottleneck problem, and has no big problem in the face of low flow and short access, but often shows unsatisfactory under high concurrency, and if a single-point fault occurs, the overall performance of the system is damaged, and even the system can not directly provide work to the outside. The invention has the advantages that the system has reliability and high fault tolerance by carrying out distributed hot plug, and other servers cannot be influenced when one server is down. Meanwhile, the system is very convenient to expand and retract, dynamic expansion can be achieved, and the number of machines can be changed according to actual requirements. The distributed computer system may also have the computing power of multiple computers, allowing for faster processing speeds and better performance than other systems.

The embodiment of the invention mainly explains the technical implementation details of specifically implementing API hot plug through a distributed KV storage system, and is mainly divided into 2 parts, namely the implementation of a hot plug module 100 and a hot plug module 200. Wherein, each module mainly comprises single-node realization (mainly aiming at the realization of functions) and multi-node realization (mainly aiming at the synchronization of multi-node data).

The API gateway hot plug system 10 based on the distributed KV storage system will be described in detail with reference to the following embodiments.

First, the API hot-plug module 100 is explained in detail, where the API hot-plug module 100 includes a single-node hot-plug mode and a multi-node hot-plug mode, where a single node only needs to consider the service function of the core, and does not care about data consistency. For hot plug of an API, two functional modules of online and registration are mainly included. The hot plug flow is shown in fig. 2.

Further, in an embodiment of the present invention, when the API hot-plug module 100 is in the single-node hot-plug mode, the online sub-module 110 is further configured to: clicking a creation API to input API data; inputting API key information, wherein the API key information comprises address, port and path of an API; storing the API data in a http request body in a JSON format, and submitting the API data to a background gateway server; extracting API key information, inserting an up-down identifier, storing the API key information in a background database, and generating a unique identifier of the API according to the API name and the uuid.

Specifically, as shown in fig. 3, the user is guided to register through a friendly operation interface by filling in a web form, which is simple and easy to understand. As shown in fig. 4, the detailed workflow:

a) and clicking the API by the user, and entering an API data entry stage.

b) The input key information comprises address, port and path of the API. The three parts together complete the definition of the API access address, which is the key information of the API route.

c) API data is stored in http request body in JSON format. And submitting to a background gateway server.

d) The gateway server normalizes the data, extracts the API key information in b), inserts an up-down line identifier, stores the up-down line identifier and the extra information in a background database together, and generates a unique identifier of the API according to the API name and the uuid.

Further, in an embodiment of the present invention, when the API hot-plug module is in the single-node hot-plug mode, the registration submodule is further configured to: clicking to upload a yaml file; filling a yaml file, wherein the yaml file comprises one or more of a name corresponding to the API, a label of the API, an address of the API for providing a service, an API parameter description, a response description of the API, a port for providing the service, a request path corresponding to the API, a request method of the API and a type of the API; clicking and uploading the Yaml file, and transmitting the Yaml data to a background server; and the background server performs normalization processing on the Yaml data, inserts the identifiers of the upper line and the lower line, stores the Yaml data in a background database, and generates the unique identifier of the API according to the name of the API and the uuid.

Specifically, the JSON/YML file is filled in and submitted to the system for registration. The document template is shown in fig. 5. As shown in fig. 6, the method specifically includes:

a) the user clicks to upload the yaml file.

b) Fill out the yaml file and the specific data is shown in table 1.

c) The user clicks on the upload file. The Yaml data is transferred to the background.

d) And after the background server obtains the data, performing normalization processing, inserting the online identifier and the offline identifier, storing the online identifier and the additional information in a background database together, and generating the unique identifier of the API according to the API name and the uuid. Wherein, table 1 is an API related term and node attribute interpretation table.

TABLE 1

Name (R)	Description of the invention
		Name	Name corresponding to API
Tags	The API's label
		Address	The API provides addresses of services
Argument	Specification of the API parameters
		Response	Response specification of the API
Port	Service providing port
		Path	API corresponding request path
Method	API request method
		Apitype	Type to which API belongs

Further, in an embodiment of the present invention, the system 10 of an embodiment of the present invention further includes: the module 300 is encapsulated (not specifically identified in the figure). The encapsulation module 300 is configured to perform normalization processing after the form registration and/or the file registration is subjected to data verification, so as to encapsulate the form registration and/or the file registration into uniform data.

Specifically, both file registration and form registration are normalized after data verification. And packaging into unified data. The data are defined as follows:

and (3) packaging the data, finally reaching the destination node, generating an identifier of apinamie + uuid as an API unique identifier, using the identifier as a key, and storing the packaged data as a value in a data warehouse. By using the extra content field, the data defined by the user is converted into the JSON format string, the specific content is not needed to be concerned, any field can be dynamically added, even the object defined by the user can be obtained, and only the JSON format is needed to be met. Can be stored or read serially.

As shown in fig. 7 below, the API entry will become the creation state after registration is successful. The API in the creation state can not be accessed, the API can be used only by being online, APIID is firstly input, after inquiry, if the API is found, corresponding online operation is carried out, and if the API is not found, the flow is ended. The operation is uniformly performed through a web interface.

The specific implementation is as follows: the state of the API is identified by generating an 'on' identification bit through the system, and the operation of going on line is the operation on the identification bit. After registration and online. One API can be normally accessed.

The above embodiment is a case where the API hot-plug module 100 is in a single-node mode, and a case where the API hot-plug module is in a multi-node hot-plug mode is described below, where the only difference in processing on the multiple nodes is the guarantee of consistency between the nodes. Since the traffic operation where the data eventually falls on a single node is the same as the single node traffic operation. The overall flow chart is similar to a single node, as shown in fig. 8.

Further, in an embodiment of the present invention, when the API hot plug module is in the multi-node hot plug mode, the API hot plug module is further configured to submit the log, and specifically includes: when an API hot plug request reaches a preset non-Leader Server node, forwarding the API hot plug request to a Leader node, generating a log entry of the operation by the Leader node according to the API hot plug request, and then sending a log replication request to a blog by the Leader node to synchronize the log entry; after the Leader node sends the log entry replication request, the feedback of the follower is waited, and after the response of the preset number of the sub-nodes is received, the log entry is modified.

In an embodiment of the present invention, when the API hot plug module is in the multi-node hot plug mode, the API hot plug module is further configured to submit data, and specifically includes: and submitting data after the Leader node modifies the log entry, sending the submitted information of the log entry to each follower, and modifying the respective data after each follower receives the information.

In particular, data normalization and single-node processing are consistent across multiple nodes, since the data has not yet reached the registry cluster. But with the following difference, here, because the deployment of multiple nodes is adopted, the load balancing server is used as an entrance, and the load balancing server implementation adopted here is Nginx. And Nginx finally selects a proper registry server according to the load balancing strategy and forwards the request. The registry server consistency is based on raft, with only one leader in the cluster. The remainder being follower. Data synchronization is as follows:

1. log submission

As shown in FIG. 9 below, when an API hot-plug request reaches a non-Leader Server node, the request is forwarded to the Leader, and the Leader node does not immediately add a corresponding API entry, but first generates a log entry (LogEntry) for the operation, such as ADDkey1API 1. The Leader then sends a "logepression" request to its follower. The strip log is synchronized.

As shown in fig. 10, after the Leader sends the log copy request, it waits for the feedback of the follower, and after receiving the responses of most nodes, it will perform the actual modification.

2. Submission of data

As shown in FIG. 11, when the Leader has been modified, the follower is again notified that logentry has committed. And after receiving the request, each follower modifies the data.

Further, the above embodiments are detailed descriptions of the API hot-plug module 100 in the single-node hot-plug mode and the multi-node hot-plug mode. The following describes the situation when the API hot-plug module 200 is in the single-node hot-plug mode and in the multi-node hot-plug mode. As shown in fig. 12, hot plug and hot plug on a single node are similar, and mainly include two function modules, i.e., logout and logoff.

Further, in an embodiment of the present invention, when the API hot plug module is in the single-node hot plug mode, the offline module is further configured to: recording the ID of the API needing offline, wherein the ID is combined by the APINAME and the uuid; and after the ID of the API is acquired, inquiring whether the corresponding API exists according to the ID, if so, updating the data corresponding to the API, and otherwise, ending the process.

Specifically, as shown in fig. 12, the principle of the offline flow is that the API _ ID required to be offline is obtained by logging, and is combined by apinamie + uuid, so that global uniqueness is ensured. And after the id is obtained, firstly, inquiring the API corresponding to the id, if the ID is found, updating the data corresponding to the API, and otherwise, ending the process.

Further, in an embodiment of the present invention, when the API hot plug module is in the single-node hot plug mode, the logout module is further configured to: recording the ID of the API needing offline, wherein the ID is combined by the APINAME and the uuid; and after the ID of the API is acquired, inquiring whether the corresponding API exists according to the ID, if so, eliminating data corresponding to the API, and otherwise, ending the process.

Specifically, as shown in fig. 12, the principle of the logout procedure is that the API _ ID that needs to be offline is obtained by logging, and is combined by apinamie + uuid, so that global uniqueness is ensured. And after the id is obtained, firstly, carrying out API query corresponding to the id, if the ID is found, eliminating data corresponding to the API, and otherwise, ending the process.

Further, in an embodiment of the present invention, when the API hot-plug module is in the multi-node hot-plug mode, the API hot-plug module is further configured to submit the log, and specifically includes: when an API hot plug request reaches a preset non-Leader Server node, the API hot plug request is forwarded to a Leader node, the Leader node generates a log entry of the operation according to the API hot plug request, and then the Leader node sends a log replication request to a follower to synchronize the log entry; after the Leader node sends the log entry replication request, the feedback of the follower is waited, and after the response of the preset number of the sub-nodes is received, the log entry is modified.

In an embodiment of the present invention, when the API hot-plug module is in the multi-node hot-plug mode, the API hot-plug module is further used for submitting data, and specifically includes: and submitting data after the Leader node modifies the log entry, sending the submitted information of the log entry to each follower, and modifying the respective data after each follower receives the information.

Specifically, hot-plugging of multiple nodes is also similar to hot-plugging of multiple nodes, and the consistency of each operation needs to be ensured. The flow chart is shown in fig. 13 below, and the analysis is performed next. Hot-plugging of multiple nodes also requires a load-balancing server to distribute requests to the multi-node cluster. The data flow when API data that needs to be processed comes to a multi-node is as follows:

1. log submission

As shown in fig. 14, when an API hot-plug request reaches a non-Leader Server node, the request is forwarded to the Leader, and the Leader node does not immediately modify the corresponding API Entry, but first generates a Log Entry (Log Entry) of the operation, such as delkey 1. The Leader then sends a "log replay" request to its follower, synchronizing the log.

As shown in fig. 15, after the Leader sends the log copy request, it waits for the feedback of the follower, and after receiving the responses of most nodes, it will perform the actual modification.

2. Submission of modifications

As shown in FIG. 16, when the Leader has been modified, the follower is again notified that logentry has committed. Each follower receives the request and then performs the actual modification.

It should be noted that the hot-plug system of the embodiment of the present invention can achieve distributed dynamic access micro-services, and solve the functional and performance problems at the same time, and the stored service fields can be flexibly and dynamically expanded without modifying the table structure; and flexible and multi-type registration schemes.

According to the API gateway hot plug system based on the distributed KV storage system, provided by the embodiment of the invention, services are stored in a consul-based K/V storage form, and the services belong to zero intrusion. Currently, the service registration is not transparent for the technology that is popular in the industry, such as eureka. There are even specific requirements for the service (such as the service needs to add the @ enabledicoveryclient annotation) that require access to the interior of the service for a few modifications. And the services are corresponding through globally unique keys based on K/V, and the information of the services can be dynamically stored in the V. And changing immediately and taking effect immediately. No particular service implementation needs to be concerned. The implementation mechanism is straightforward and does not require excessive configuration for practical operation. In addition to eureka, there are many other related products, such as kong, which are nginx based. The method needs to be operated skillfully for server-side tools such as nginx and the like, and has a certain threshold for the use of users. The K/V form adopted by the scheme greatly reduces the operation complexity, the user only needs to fill in the API basic information, and the rest information is automatically generated by the system. Eventually a unified portal API is created for user access. And for the API gateway hot plug system, the support of distributed deployment is very good, and the internal components such as a service registration center and the whole API gateway hot plug system outside can be horizontally and dynamically expanded according to the requirements, so that the API gateway hot plug system is convenient to use.

Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "a plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.

In the present invention, unless otherwise expressly stated or limited, the first feature "on" or "under" the second feature may be directly contacting the first and second features or indirectly contacting the first and second features through an intermediate. Also, a first feature "on," "over," and "above" a second feature may be directly or diagonally above the second feature, or may simply indicate that the first feature is at a higher level than the second feature. A first feature being "under," "below," and "beneath" a second feature may be directly under or obliquely under the first feature, or may simply mean that the first feature is at a lesser elevation than the second feature.

In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention, and that variations, modifications, substitutions and alterations can be made to the above embodiments by those of ordinary skill in the art within the scope of the present invention.

Claims

1. An API gateway hot plug system based on a distributed KV storage system is characterized in that the hot plug system realizes distributed dynamic access micro-services through distributed deployment, and comprises: an API hot plug module and an API hot plug module, wherein,

the API hot plug module comprises an online sub-module and a registration sub-module, wherein the online sub-module is used for processing an online release function of the API and accessing after the API is successfully online; the registration sub-module comprises a web page form registration sub-module and a file registration sub-module, wherein,

the webpage form registration submodule is used for guiding a user to perform form registration through a preset webpage form in a preset mode; the file registration submodule is used for performing file registration by filling in a JSON/YML file;

the API hot-plug module comprises an off-line module and a logout module, wherein the off-line module is used for off-line of the API and forbids access to modify or logout the API after the API is off-line; the logout module is used for removing the API from the hot plug system;

when the API hot plug module is in the multi-node hot plug mode, the API hot plug module is further configured to submit a log, and specifically includes: when an API hot plug request reaches a preset non-Leader Server node, forwarding the API hot plug request to a Leader node, generating a log entry of the operation by the Leader node according to the API hot plug request, and then sending a log replication request to a follower by the Leader node to synchronize the log entry; after the Leader node sends a log entry replication request, waiting for feedback of a follower, and modifying the log entry after receiving responses of a preset number of sub-nodes;

when the API hot-plug module is in the multi-node hot-plug mode, the API hot-plug module is further configured to submit a log, and specifically includes: when an API hot plug request reaches a preset non-Leader Server node, forwarding the API hot plug request to a Leader node, generating a log entry of the operation by the Leader node according to the API hot plug request, and then sending a log replication request to a follower by the Leader node to synchronize the log entry; after the Leader node sends a log entry replication request, waiting for feedback of a follower, and modifying the log entry after receiving responses of a preset number of sub-nodes;

wherein, when the API hot plug module is in a single-node hot plug mode, the online sub-module is further configured to:

clicking a creation API to input API data;

inputting API key information, wherein the API key information comprises address, port and path of an API;

storing the API data in a http request body in a JSON format, and submitting the API data to a background gateway server;

extracting the API key information, inserting an up-down identifier, storing the API key information in a background database, and generating a unique identifier of the API according to the API name and the uuid;

wherein, when the API hot-plug module is in the single-node hot-plug mode, the registration sub-module is further configured to:

clicking to upload a yaml file;

filling the yaml file, wherein the yaml file comprises one or more of a name corresponding to the API, a label of the API, an address of the API for providing the service, an API parameter description, a response description of the API, a port for providing the service, a request path corresponding to the API, a request method of the API and a type to which the API belongs;

clicking to upload the Yaml file, and transmitting the Yaml data to a background server;

the background server carries out normalization processing on the Yaml data, inserts an upper and lower line identifier, stores the Yaml data in a background database, and generates a unique API identifier according to the API name and the uuid;

when the API hot plug module is in the multi-node hot plug mode, the API hot plug module is further configured to submit data, and specifically includes:

submitting data after the Leader node modifies the log entry, sending the submitted information of the log entry to each follower, and modifying the data after each follower receives the information;

when the API hot plug module is in the single-node hot plug mode, the offline module is further configured to:

entering an ID of an API needing offline, wherein the ID is combined by the APINAME and the uuid;

and after obtaining the ID of the API, inquiring whether the corresponding API exists according to the ID, if so, updating data corresponding to the API, and otherwise, ending the process.

2. The API gateway hot plug system based on distributed KV storage system of claim 1, further comprising:

and the packaging module is used for carrying out normalization processing after the form registration and/or the file registration are subjected to data verification so as to package the form registration and/or the file registration into uniform data.

3. The API gateway hot plug system according to claim 1, wherein when said API hot plug module is in a single-node hot plug mode, said logout module is further configured to:

and after obtaining the ID of the API, inquiring whether the corresponding API exists according to the ID, if so, eliminating data corresponding to the API, and otherwise, ending the process.

4. The API gateway hot plug system based on the distributed KV storage system of claim 1, wherein when the API hot plug module is in a multi-node hot plug mode, the API hot plug module is further configured to submit data, specifically comprising:

and submitting data after the Leader node modifies the log entry, sending the submitted information of the log entry to each follower, and modifying the data after each follower receives the information.