KR20220059814A - Api request processing system - Google Patents

Abstract

The present invention relates to a system for processing an API request. The system for processing the API request according to the present invention comprises: a service execution part comprising a microservice zone wherein an API service always maintains a response waiting state, and a serverless service zone that executes an invoke for the API service so that the relevant API service is terminated after being executed; and an API gateway that receives an API service request signal from the outside, and transmits the relevant API service request signal to at least one among the microservice zone and the serverless service zone through an analysis for the received API service request signal. Therefore, the present invention is capable of increasing user satisfaction.

Description

API request processing system {API REQUEST PROCESSING SYSTEM}

The present invention relates to an API request processing system, and more particularly, to a system processing a serverless-based API service request.

Conventionally, it has been common to build and operate a server in order to provide a specific service online to customers.

However, for each service provider to directly operate a server in this way, not only a physical space is required, but also an operating manpower to operate the server is inevitably a burden.

In order to solve this inconvenience, a serverless system has been recently proposed.

Serverless refers to a cloud development model that allows developers to build and run applications without the need to manage servers.

Of course, servers exist in the serverless model, but unlike in application development, it is abstracted away, in which case the cloud provider handles the day-to-day tasks of provisioning, maintaining, and scaling the server infrastructure, and the developer is responsible for the deployment. All you need to do is package your code into a container.

After a serverless application is deployed, it automatically scales up or down as needed.

The advantage of these public cloud providers' serverless offerings is that they are typically metered on-demand via an event-based execution model, so there is no cost to the serverless functions when they are idle.

On the other hand, when creating a new application, set up a single development environment (OS is RedHat, JDK1.8, Mysql5.7, etc.) and start making a small application. Then, as new functions are added to the application, the amount of code increases. Even one module becomes huge.

In this case, even if there is a bug, it is not easy to find the error, and even a small change can affect many parts and cause a bigger error.

In order to solve these conventional problems, recently, the case of distributing or operating a necessary application under the concept of microservices is increasing.

Microservices architecture means that one application is divided into several small applications, and each application is composed of small and independent services.

When an API service request signal is received from the outside that each microservice maintains a state in which it can immediately respond to an external request, it performs a function to respond by performing a corresponding function.

However, no system has been proposed in which the operation of such microservices and the operation of the aforementioned serverless service are processed together so far.

In other words, the operation of the serverless service basically invokes and executes the corresponding service in response to the external API service request signal and terminates the corresponding service when the processing is finished. The difference is that it is always maintained in an operable state (that is, resource allocation and occupation) and is operated in a form that immediately processes an API service request signal received from the outside.

However, since the operation of these serverless services and the operation of microservices each have their pros and cons, it is possible to operate in the form of a serverless service for a specific API service or to operate in the form of a microservice for resource efficiency and service This may be important in terms of user convenience, but in the past, a system in which microservices and serverless services are operated at the same time has not been proposed.

Publication No. 10-2020-0063360

The present invention has been devised to satisfy the above conventional needs, and an object of the present invention is to provide a system that enables a predetermined API service to be operated in the form of a microservice or a serverless service according to specific conditions.

In order to achieve the above object, the API request processing system according to the present invention is a microservice zone in which the API service always maintains a response standby state, and a server that executes an invoke for the API service so that the API service is executed and then terminates it a service execution unit including a lease service zone; and an API gateway that receives an API service request signal from the outside, and transmits a corresponding API service request signal to either the micro service zone or the serverless service zone through analysis of the received API service request signal. .

Here, the service execution unit transmits information on the installation zone of the newly registered API service whenever a new API service is registered in the microservice zone or the serverless service zone, and corresponds to each API service from the service execution unit Further comprising a service registry for storing information on the installation zone to be installed, the API gateway may transmit an API service request signal to any one of the micro service zone and the serverless service zone with reference to the information stored in the service registry. .

The method may further include an API service redistributing unit redistributing at least one API service registered in the microservice zone to the serverless service zone with reference to the API service call log record through the API gateway.

Here, the API service that automatically creates and builds the source and properties of the API service according to the definition of the API standard input by the user, and distributes the built API service to either the micro service zone or the serverless service zone of the service execution unit. It may further include a generator.

As described above, according to the present invention, since a predetermined API service can be operated in the form of a microservice or a serverless service according to specific conditions, resources can be efficiently used and user satisfaction is increased.

In other words, fast processing speed (response speed) can be achieved by operating in the microservice zone for services that frequently make API calls, and also, by operating in the serverless service zone for services that do not frequently make API calls, resources can be used efficiently.

1 is a functional block diagram of an API request processing system according to an embodiment of the present invention;
Figure 2 is a view comparing the form of data registered in the service registry of the API request processing system of Figure 1 with the prior art,
3 and 4 are control flow diagrams of the API request processing system of FIG. 1,
5 to 8 are diagrams for explaining a process in which source codes are automatically generated and built according to API specification definitions.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

Hereinafter, each embodiment according to the present invention is merely an example for helping the understanding of the present invention, and the present invention is not limited to these embodiments. In particular, the present invention may be composed of a combination of at least any one of individual components, individual functions, or individual steps included in each embodiment.

A functional block of the API request processing system 100 according to an embodiment of the present invention is shown in FIG. 1 .

As shown in the figure, the API request processing system 100 includes a service execution unit 110 and an API gateway 120 . As a service register, it may be configured to include an API service creation unit 140 and an API service redistribution unit 150 .

In this embodiment, the API service request signal is a signal to request a predetermined response or to perform a predetermined function to the serverless service or microservice, and the API service refers to a service that processes this API service request signal. As such, it may correspond to a predetermined function or a predetermined independent application, and since the API service request signal and the API service itself correspond to known technologies, a more detailed description will be omitted.

The service execution unit 110 performs a specific function according to an API service request signal received from the outside, and also performs a function of registering at least one API service to process each API service request signal.

Here, the service execution unit 110 may receive the API service request signal via the API gateway 120 .

The service execution unit 110 may be provided with a micro service zone and a serverless service zone, where the micro service zone means an area in which the API service always maintains a response standby state, and the serverless service zone is an area in which the API service maintains a standby state to which resources are not allocated, and refers to an area where the API service is executed and then terminated by executing an invoke for the API service.

That is, the micro service zone of the service execution unit 110 can be executed immediately in response to an external API service request signal for the registered API service, but the serverless service zone is a kind of service zone through the invoke process for the registered API service. It can be executed after performing the activation process.

In particular, the serverless service zone is different in that the registered API service is automatically shut down after it is executed, whereas the microservice zone is always in a waiting state for the registered API service.

For example, if the service execution unit 110 is operated through a cloud company, costs are continuously incurred for each API service registered in the microservice zone, and each API service registered in the serverless service zone is executed. It will only cost you in the moment.

The service execution unit 110 also performs a function of transmitting information on the installation zone of the newly registered API service whenever a new API service is registered in the microservice zone or the serverless service zone.

That is, in the micro service zone of the service execution unit 110, when a new API service is registered, the micro service zone information is matched with the newly registered API service identifier and transmitted to the service registry 130 to be stored, and serverless. When a new API service is registered, the service zone may be transmitted to the service registry 130 by matching the serverless service zone information with the newly registered API service identifier to be stored.

On the other hand, the registration of the API service may be made according to the request of the API service generating unit 140 , and a more detailed description thereof will be provided later.

The service registry 130 performs a function of storing information about the installation zone corresponding to each API service from the service execution unit 110 as described above.

For example, the service registry 130 has a database table, stores and manages the identifier of each API service by matching information on the area (ie, micro service zone or serverless service zone) in which the corresponding API service is registered. can do.

An example of information registered in the service registry 130 is shown in FIG. 2(b).

For reference, FIG. 2(a) is an example of information registered in the conventional service registry 130, and FIG. 2(b) shows that a type field for dividing a storage area has been added when compared with this conventional registration information. can Furthermore, as shown in FIG. 2(b) , an Invoke command field may be further added.

The API gateway 120 receives an API service request signal from the outside and transmits it to the service execution unit 110 .

Here, the API gateway 120 may receive an API service request signal from a user terminal, a database system, a file storage, etc. At this time, through analysis of the received API service request signal, between the micro service zone and the serverless service zone It can perform a function of determining to which direction the API service request signal is to be transmitted.

For example, the API gateway 120 uses the information stored in the service registry 130 to check the area in which the API service corresponding to the currently received API service request signal is registered, and uses the confirmed result. The API service request signal can be delivered to the microservice zone or to the serverless service zone.

The API gateway 120 also performs a function of accumulating and recording the call details whenever each API service request signal is received as described above.

The API service redistribution unit 150 refers to the API service call log record through the API gateway 120 and moves and relocates the API service registered in the microservice zone or the API service registered in the serverless service zone to another zone. carry out

For example, when the API service request signal for using the API service registered in the microservice zone is less than or equal to the preset number of times during the preset period, the API service redistribution unit 150 moves and arranges the API service to the serverless service zone. As another example, if the API service request signal for using the API service registered in the serverless service zone is greater than or equal to the preset number of times during the preset period, the function of moving the API service to the microservice zone can be performed.

On the other hand, the API service creation unit 140 automatically creates and builds the source and properties of the API service according to the definition of the API standard input by the user, and connects the built API service with the microservice zone of the service execution unit 110 and the microservice zone of the service execution unit 110 . It performs the function of deploying to one of the serverless service zones.

That is, when the user simply defines the API standard, the API service generating unit 140 automatically generates the source code itself of the API service and automatically performs the process of building and distribution.

A more detailed description of the process performed by the API service generating unit 140 will be described later.

3 shows an overall process in which the API request processing system 100 registers an API service and the corresponding API service is executed according to an external request.

When the API service is registered (step S1), the API request processing system 100 registers the API service, checks the registered installation zone (micro service zone or serverless service zone), and stores the matching (step S3) ).

When an API service request signal is received from the outside (step S5), the zone in which the API service to process the API service request signal is installed is checked using previously matched and stored information (step S7).

As a result of checking, if the corresponding API service is registered in the microservice zone (step S9), the corresponding API service request signal is transmitted to the microservice zone (step S11), and accordingly, the API service requests the API service in the microservice zone The function according to the signal is immediately performed (step S13).

As a result of checking, if the corresponding API service is registered in the serverless service zone (step S15), the corresponding API service request signal is transmitted to the serverless service zone (step S17), and accordingly, the corresponding API service is invoked in the serverless service zone and after being executed (step S19), processing according to the API service request signal is performed (step S21), and after the processing is performed, the corresponding API service is terminated (step S23).

4 is a flowchart illustrating a process in which an API service registered in a microservice zone is redistributed to a serverless service zone in the API request processing system 100 according to an embodiment of the present invention.

The API request processing system 100 analyzes the call log corresponding to the API service request (step S31) and selects an API service request signal with a low frequency (step S33).

For example, the API request processing system 100 may select five lower-order API service request signals having a low number of calls from among the API service request signals.

Next, it is determined whether the API service for processing the selected API service request signal is registered in the microservice zone (step S35).

If the determination result is registered in the microservice zone, the API request processing system 100 processes the corresponding API service to be redistributed to the serverless service zone (step S37).

Accordingly, even the API service registered in the initial microservice zone is moved to the serverless service zone if the call frequency is low.

Since the API service moved to the serverless service zone does not maintain an immediate response waiting state, when an API service request signal is received from the outside, it goes through the Invoke process and is activated before response processing, and then the API service is terminated. is as described above.

Meanwhile, a process performed by the API service generation unit 140 of the API request processing system 100 is shown in FIGS. 5 to 8 .

First, FIG. 5 shows an example of a window in which an API standard is defined by a user.

5 is a page for setting New API Mapper, which may appear as a pop-up dialog, and Request/Response operates as a tap menu and may have the same screen configuration.

The From, To items are for defining application/json, application/xml, text/plain, etc., and when the data type is application/json or application/xml, the Data Path setting can be activated.

Each segment can be added by the user and converted into a packet according to the generated segment order.

6 shows a source structure diagram that is automatically generated according to information input by a user, and FIG. 7 shows contents for explaining the mapping data format.

In the first area 141 of FIG. 7 , as access information, the type here may be sync/async, and the protocol may be HTTP, TCP/IP, or the like.

Looking at the second area 142 of FIG. 7 , the type may be application/json, application/xml, text/plain, etc., and dataPath indicates the data start position to be used in the json/xml document, for example, /api It can also be written as a path like /data.

In addition, From defines the specification of the requested data, id is a unique value of the value and is defined to refer to the value in to, type may define string/integer, etc., and key is json/xml type It means data to obtain a value from the document of

The content defined may be different depending on the type of text. In the case of Json/Xml, it can be type and key, and in the case of Text, it can be type and length.

length can be consecutively listed as byte-length data to obtain a value in a text-type document.

Meanwhile, looking at the third area 143 of FIG. 7 , it can be seen that a full text to be transmitted as legacy is defined.

Here, Id is to use the value of from if there is the same id in from, and if there is not, value must be defined, type is to distinguish string/integer, Key is to indicate key value in json/xml type document, Value is used when directly entering a value without using the value of from.

8 shows an example of automatic conversion from Request-from to Request-to.

In the conversion example of FIG. 8 , it is assumed that the data length is the same as the data length set above, and when the data is smaller than the set data length, the remaining digits are assumed and 0 is filled.

The length defined in the text type indicates the length of bytes, and the converted data can actually be converted into a hex value and transmitted.

Meanwhile, it goes without saying that the process of performing each of the above-described embodiments may be performed by a program or application stored in a predetermined recording medium (eg, computer-readable). Here, the recording medium includes an electronic recording medium such as a random access memory (RAM), a magnetic recording medium such as a hard disk, and an optical recording medium such as a compact disk (CD).

In this case, the program stored in the recording medium may be executed on hardware such as a computer or smart phone to perform each of the above-described embodiments. In particular, at least one of the functional blocks of the API request processing system 100 according to the present invention described above may be implemented by such a program or application.

In addition, the present invention is not limited to the specific embodiments described above, but can be practiced with various modifications and modifications within the scope without departing from the gist of the present invention. It will be apparent that such modifications and variations are included in the present invention provided they fall within the scope of the appended claims.

100: API request processing system 110: service execution unit
120: API gateway 130: service registry
140: API service creation unit 150: API service redistribution unit

Claims (4)

a service execution unit including a microservice zone in which the API service always maintains a response standby state and a serverless service zone in which the API service is executed and then terminated by executing an invoke for the API service;
and an API gateway that receives an API service request signal from the outside and transmits a corresponding API service request signal to either the micro service zone or the serverless service zone through analysis of the received API service request signal. API request processing system. According to claim 1,
The service execution unit transmits information on the installation zone of the newly registered API service whenever a new API service is registered in the microservice zone or the serverless service zone,
Further comprising a service registry for storing information about the installation zone corresponding to each API service from the service execution unit,
The API gateway refers to the information stored in the service registry, the API request processing system, characterized in that for transferring the API service request signal to any one of the micro service zone and the serverless service zone. According to claim 1,
API service redistribution unit for redistributing at least one API service registered in the microservice zone to the serverless service zone by referring to the API service call log record through the API gateway. . According to claim 1,
An API service creation unit that automatically creates and builds the source and properties of the API service according to the API specification definition input by the user, and distributes the built API service to either the micro service zone or the serverless service zone of the service execution unit. API request processing system, characterized in that it further comprises.

Images