CN113778647A - Call request processing method, system and test equipment - Google Patents
Call request processing method, system and test equipment Download PDFInfo
- Publication number
- CN113778647A CN113778647A CN202110974834.2A CN202110974834A CN113778647A CN 113778647 A CN113778647 A CN 113778647A CN 202110974834 A CN202110974834 A CN 202110974834A CN 113778647 A CN113778647 A CN 113778647A
- Authority
- CN
- China
- Prior art keywords
- service
- request
- data structure
- service interface
- calling
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Abstract
The invention discloses a processing method, a system and a test device of a call request, wherein the method comprises the following steps: under the condition that a monitoring port receives a calling request, identifying a service interface pointed by the calling request; wherein, the data structure of the call request is consistent with the data structure supported by the service interface; sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request; and encapsulating the service data according to a data structure supported by the service interface, and providing the encapsulated service data to the initiator of the call request. The technical scheme provided by the invention can improve the efficiency and the adaptability of method calling.
Description
Technical Field
The invention relates to the technical field of data processing, in particular to a method, a system and a test device for processing a call request.
Background
In current distributed test environments, call cases between different methods are often involved. For example, python provides rich business functions such as image recognition and machine learning, and ruby may need to call part of the business functions in python when performing an automation test.
In the prior art, the called method is usually compiled into a third-party library, and then the calling process between different methods is realized by calling the third-party library. Taking ruby and python as examples, the python method is typically packaged and brought up with the operating environment of the python method, thus compiling the python method into a third party library of ruby.
The reason why the method is not convenient enough when in use is that if the compiled third-party library does not have the required business function, the author of the third-party library needs to wait for compiling the original business function and compile the compiled business function, so that the business function of the third-party library is updated. The updating of the service function is usually not very timely, and the process of compiling the third-party library is relatively complicated, so that the process of calling the method in the form of the third-party library has large limitation and low efficiency.
Disclosure of Invention
In view of this, embodiments of the present invention provide a method, a system, and a testing device for processing a call request, which can improve efficiency and adaptability of method call.
One aspect of the present invention provides a method for processing a call request, where the method includes: under the condition that a monitoring port receives a calling request, identifying a service interface pointed by the calling request; wherein, the data structure of the call request is consistent with the data structure supported by the service interface; sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request; and encapsulating the service data according to a data structure supported by the service interface, and providing the encapsulated service data to the initiator of the call request.
According to the technical scheme, the method for providing the service function does not need to be compiled into a third-party library, and the data transmission process among different methods is improved, so that the calling among the different methods is realized. In particular, the initiator may encapsulate a data structure for the generated invocation request, where the data structure may be consistent with the data structure supported by the service interface. In this way, the service interface may recognize the invocation request and process the invocation request. After the service data is generated, the service data may be encapsulated into the data structure, so that the initiator can also recognize the fed back service data. In this case, if the service function required by the call request is not currently available, the service function can be written directly locally in the test equipment. After the service function is written, the service function does not need to be compiled, but can be called through the data transmission process, so that the calling efficiency and the adaptability of the method are greatly improved.
In one embodiment, identifying the service interface to which the invocation request is directed includes: and determining a service function corresponding to the call request, and using a service interface for calling the service function as a service interface pointed by the call request.
Different service functions can be called through different service interfaces, so that the response speed of the service functions is improved, and the processing efficiency of calling requests is improved.
In one embodiment, the call request is an http request, and the port identifier of the listening port includes a local IP address and a port number used for receiving the http request.
The monitoring port is arranged in the local test equipment, so that the calling request only needs to be processed in the local test equipment, and the local data is conveniently processed and transmitted.
In one embodiment, the service interface is configured as follows: setting an interface type for the service interface, wherein the interface type is correspondingly consistent with the request mode of the calling request; binding a service function for the service interface; and the data structure of the entry of the business function is consistent with the data structure of the calling request.
After the service interface is generated, the interface type of the service interface may be set, and a corresponding service function may be bound for the service interface. The interface type of the service interface needs to be consistent with the request mode of the call request, and the data structure of the service function, which is entered into the service interface, also needs to be consistent with the data structure of the call request, so that the call request can be processed normally.
In one embodiment, the invocation request is generated by the initiator in the following manner: acquiring a request identifier to be called, encoding the request identifier, and packaging an encoding result into a calling request of a specified data structure; wherein the specified data structure is consistent with the data structure supported by the service interface; and recording request data according to the original data structure of the initiator in the request body of the packaged calling request.
The data structure of the call request generated by the initiator needs to be consistent with the data structure supported by the service interface, so that the call request sent by the initiator can be normally transmitted to the service interface for processing after reaching the monitoring port.
In one embodiment, the method is applied to test equipment of a distributed system; the method further comprises the following steps: configuring a service environment under default directories of first test equipment and second test equipment of the distributed system; creating a virtual operating environment corresponding to the service environment under the test directory of the first test device, packaging the virtual operating environment, and copying the virtual operating environment to the test directory of the second test device; and running the packed virtual running environment in the second test equipment.
In order to ensure the consistency of the test environment in the distributed system, the service environment may be configured under the default directory of a plurality of test devices. Then, the virtual operating environment may be packaged in the test directory of the first test device, and the packaged virtual operating environment may be copied to another test device. Therefore, each testing device in the distributed system has a uniform service environment and a virtual operation environment, and the consistency of the testing environment can be ensured on the premise of ensuring the independence of each testing device.
In one embodiment, the method further comprises: creating a batch script program, wherein the batch script program is used for adding a script for running the service environment into a starting program of a system; and executing the batch script program to start the service environment before processing the call request.
By setting the script for executing the service environment to be started up and self-started, the test environment is started before the distributed test, and a basis is provided for the subsequent processing process of the call request, so that the processing speed of the call request can be improved.
Another aspect of the present invention provides a system for processing a call request, including: the interface identification unit is used for identifying a service interface pointed by a call request under the condition that the call request is received by a monitoring port; wherein, the data structure of the call request is consistent with the data structure supported by the service interface; the request processing unit is used for sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request; and the data encapsulation unit is used for encapsulating the service data according to a data structure supported by the service interface and providing the encapsulated service data to the calling party of the calling request.
Another aspect of the present invention provides a testing device in a distributed system, where the testing device runs a testing thread and a service, where: the test thread is used for generating a call request of a specified data structure and sending the call request to a monitoring port of the test equipment; the business service is used for identifying a business interface pointed by the calling request; wherein the specified data structure is consistent with the data structure supported by the service interface; sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request; and encapsulating the service data according to a data structure supported by the service interface, and providing the encapsulated service data for the test thread.
In one embodiment, the test thread is further configured to obtain a request identifier to be called, encode the request identifier, and package an encoding result into a call request of a specified data structure; and recording the request data according to the native data structure in the request body of the packaged calling request.
In another aspect, the present invention provides a test device in a distributed system, where the test device includes a memory and a processor, the memory is used to store a computer program, and the computer program, when executed by the processor, implements the method for processing a call request described above.
Another aspect of the present invention provides a computer storage medium for storing a computer program, which when executed by a processor implements the method for processing a call request described above.
Drawings
The features and advantages of the present invention will be more clearly understood by reference to the accompanying drawings, which are illustrative and not to be construed as limiting the invention in any way, and in which:
FIG. 1 is a diagram illustrating a method for handling a call request according to an embodiment of the invention;
FIG. 2 is a diagram illustrating the interaction between a ruby thread and a python service in one embodiment of the invention;
FIG. 3 shows a schematic diagram of an environmental deployment in one embodiment of the invention;
FIG. 4 is a functional block diagram of a system for processing a call request in accordance with an embodiment of the present invention;
FIG. 5 shows a schematic diagram of a test apparatus according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be described clearly and completely with reference to the accompanying drawings of the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without inventive step based on the embodiments of the present invention, are within the scope of the present invention.
The processing method of the call request can be applied to a distributed system. In the distributed system, a plurality of test devices may be included, which may perform distributed test tasks. In the application, a ruby test script can be run on each test device, and a python service can be installed at the same time. In practical application, the ruby test script can be run through a test thread in the test equipment, if the ruby test script needs to call the function of the python service in the running process, the ruby thread can initiate a call request to the python service, and after the python service processes the call request to obtain service data, the service data can be fed back to the ruby thread.
Specifically, referring to fig. 1 and fig. 2, a method for processing a call request according to an embodiment of the present application may include the following steps.
S1: under the condition that a monitoring port receives a calling request, identifying a service interface pointed by the calling request; and the data structure of the calling request is consistent with the data structure supported by the service interface.
In the embodiment, in order to enable data transmission between the ruby thread and the python service in the test equipment, the communication mode between the ruby thread and the python service can be improved. Specifically, a native http port may be established in the test device, and then data of the unified data structure may be transferred through the http port, so as to implement a calling process between the ruby thread and the python service.
In this embodiment, different service interfaces may be set for different service functions in the python service. Specifically, a python fastapi manner may be adopted to create a service interface corresponding to each service in the test device. When creating a service interface, the interface attributes of the service interface may be defined. For example, an interface type may be set for the service interface, and the interface type needs to be consistent with a request mode of a call request sent by a ruby thread. In this embodiment, the ruby thread and the python service may communicate with each other through an http request, and the request mode of the http request generally includes a GET mode and a POST mode, so the interface type of the service interface may also be set to a GET/POST mode. In addition, it is also necessary to bind the corresponding service function for the created service interface. The business functions that can be realized by the python service may include image recognition, machine learning, character recognition, and the like. Each service function may be implemented by a background program code, which may be associated with a service interface. Subsequently, when the service interface needs to process the call request, the associated program code may be called to execute the corresponding service function. Therefore, different service interfaces are bound with different service functions, the program code of the background can be accurately called, and the processing efficiency of the calling request is improved.
In this embodiment, after the service function is bound to the service interface, a data structure of input parameters (input parameters) of the service function is further required to be defined. Since the service interface needs to process the call request sent by the ruby thread subsequently, the data structure of the reference of the service function should be consistent with the data structure of the call request. In practice, the ruby thread communicates with the python service via http requests, so the data structure of the entry of the business function can be set as a json data structure. Similarly, the data structure of the service data output by the service interface may also be a json data structure.
In practical application, a data structure for referencing of a BaseModel class may be defined in the python service, and the data structure may be a unified data structure for data communication between the ruby thread and the python service. For example, the data structure may be the json data structure described above. Then, after creating the service interface and binding the service function for the service interface, both the data structure of the entry of the service function and the data structure of the service data output by the service interface may be set to the data structure of the entry in the BaseModel class.
In this embodiment, data transmission is performed locally between the ruby thread and the python service, so a local snoop port may be set in the python service, and the snoop port may be used to receive a call request sent by the ruby thread. In particular, the local listening port may be represented by a port identification. The port identifier usually includes an IP address and a port number, and since the call request is processed locally, the IP address may be set as a local IP address: 127.0.0.1. the type of the invocation request is an http request, so the port number may be set to the port number (e.g. 8080) used for receiving the http request. Thus, the port id of the local snoop port can be expressed as: 127.0.0.1:8080. In addition to defining some basic parameters of the python service when running, the main program entry of the python service can also define the port identification of the snooping port, so that the python service can process the call request received by the snooping port. Certainly, in practical applications, the port identifier of the listening port may also be defined in the interface attribute of the service interface, so that the service interface may identify the port identifier carried in the call request, and thus only process the call request received by the local listening port.
In a specific application scenario, after the service interface is configured as described above, the http request in the form of GET/POST received at the 8080 port in the test equipment may be processed. The monitoring port is arranged in the local test equipment, so that the calling request only needs to be processed in the local test equipment, and the local data is conveniently processed and transmitted.
Through the above process, the python service can listen to the call request sent by the ruby thread. In the case where the snoop port receives a call request, the main program of the python service may first identify the service interface to which the call request is directed. Specifically, the calling request usually carries a function identifier of the called service function, and by identifying the function identifier, the main program of the python service can determine the service function corresponding to the calling request. According to the binding relationship between the service function and the service interface, the service interface for calling the service function can be used as the service interface to which the calling request points. Therefore, different service functions can be called through different service interfaces, so that the response speed of the service functions is increased, and the processing efficiency of calling requests is improved.
S3: and sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request.
In this embodiment, after the python main program identifies the service interface to which the call request is directed, the call request can be transmitted to the corresponding service interface. Of course, in practical applications, the python main program may also extract the instruction or data to be processed from the call request, and transmit the extracted instruction or data to the service interface.
For the call request to be processed, the service interface can call the program code of the background, so as to run the bound service function and process the call request. For example, a ruby thread needs to search a database for a picture having a certain similarity with a target picture, so that data of the target picture or an identifier of the target picture can be carried in a call request sent by the ruby thread to a python service, and meanwhile, a called service function can be defined as picture search (or picture similarity calculation) in the call request. After receiving the call request, the main program of the Python service may extract data or an identifier of a target picture therein, and transmit the data or the identifier of the target picture to a service interface responsible for picture searching. The service interface can call a service function of picture search and process the data or the identification of the target picture, so that the picture similar to the target picture is inquired in the database. The data or identification of the inquired picture can be used as service data generated by the service interface.
S5: and encapsulating the service data according to a data structure supported by the service interface, and providing the encapsulated service data to the initiator of the call request.
In this embodiment, after the service interface processes the call request by calling the service function, the data structure of the generated service data may not be the data structure agreed between the ruby thread and the python service. In view of this, in order to enable the service data to be identified by the ruby thread, the service data provided by the service interface needs to be encapsulated according to the data structure supported by the service interface. For example, the traffic data may be encapsulated into a json data structure. Thus, the encapsulated service data can be normally identified by the Ruby thread of the initiator of the call request.
For example, after a business interface in the python service calls a business function of picture search and queries pictures similar to a target picture, the generated business data may be coordinates of the pictures obtained by the queries (the coordinates are used for representing the positions of the pictures in the database), and then the coordinates of the pictures may be encapsulated into data in json format and provided to a ruby thread.
In the present embodiment, the ruby thread also needs to be improved to some extent when generating a call request. Specifically, referring to fig. 2, a function encapsulation layer may be defined in the ruby, and the function encapsulation layer may encapsulate an outgoing call request, so that the call request sent to the python service can conform to the data structure of the entry of the python service. In the function encapsulation layer, a request manner of the call request may be defined. Since the call request is an http request, the request mode of the call request may be a GET/POST mode of http.
In practical application, the Http request can be sent by adopting the method of Net in the Net/Http header file of ruby, i.e. Http type. Specifically, the ruby thread may obtain a request identifier to be called, which may be a URL, and then may encode the request identifier using a uri. Subsequently, the encoding result can be encapsulated as a call request specifying a data structure by Net:: HTTP:: post. When the encoding result is encapsulated, the request header, the request body and the request format may be encapsulated. The request header is used to record description information of the call request, for example, the length of data in the request body, a protocol followed by the call request, and the like may be recorded. The request data may be recorded in the request body in a ruby's native data structure. For example, the request data in the request body may be a ruby hash structure. The request format may be consistent with the data structure of the entry specified by the python service. For example, it may be a data structure for entry of a BaseModel class specified in the traffic interface of the python service. After the encapsulation of the call request is completed, a start method may be invoked to send the call request to the snoop port of the python service.
In this way, the ruby thread and the python service can both encapsulate the transmitted data, so that the ruby thread and the python service can transmit data in json format of http request. After receiving the service data fed back by the python service, the Ruby thread can continue to perform subsequent service logic according to the content in the test script.
Therefore, the technical solution provided by the above embodiment does not need to compile the method providing the service function into a third-party library, but realizes the call between different methods by improving the data transmission process between different methods. In particular, the initiator may encapsulate a data structure for the generated invocation request, where the data structure may be consistent with the data structure supported by the service interface. In this way, the service interface may recognize the invocation request and process the invocation request. After the service data is generated, the service data may be encapsulated into the data structure, so that the initiator can also recognize the fed back service data. In this case, if the service function required by the call request is not currently available, the service function can be written directly locally in the test equipment. After the service function is written, the service function does not need to be compiled, but can be called through the data transmission process, so that the calling efficiency and the adaptability of the method are greatly improved.
Considering that the test environments of the test devices in the distributed system are independent from each other, in order to effectively test the distributed tasks, it is usually necessary to maintain the consistency of the operating environments of the test devices. In view of this, in one embodiment, test environments in various test devices of a distributed system may be configured synchronously.
Referring to FIG. 3, the configuration of the test environment may include two steps: firstly, installing a python main program in each test device so as to complete the deployment of a basic service environment; and secondly, deploying virtual operating environments required by actual test items in each test device.
Taking the first test device and the second test device in the distributed system as an example, in order to ensure that the same service environment is deployed in the first test device and the second test device, the service environment may be configured in a silent installation manner under the default directory of the first test device and the second test device. In particular, the manner of silent installation may be implemented by the command of/quick TargetDir ═ c: \ python 3. Wherein quiet represents the commander of the silent installation, TargetDir represents the commander of the default directory, and c: \ python3 represents the default directory. Of course, in practical applications, the default directory may be a customized directory as long as the same default directory is used in the first test device and the second test device. In this way, the basic service environments in the first test device and the second test device can be guaranteed to be consistent by means of silent installation.
In practical applications, the version of the library used may not be consistent for different test items. For example, one test item uses a version of django 2.2, and another test item uses a version of django 3.0. The versions of the libraries employed in the first test device and the second test device should be consistent when executing the same distributed test item. The version of the library may be determined by the virtual execution environment. In this embodiment, a virtual operating environment corresponding to a service environment may be created in a test directory of a first test device, and after being packaged, the virtual operating environment may be copied to a test directory of a second test device, so that it is ensured that the virtual operating environments in the two test devices are also consistent. Specifically, the test directory may be, for example, c: \ autotest, and the instruction to create the virtual runtime environment may be python-m venv [ environment name ]. When the virtual operating environment is packaged, self-decompression type insert can be adopted, so that after the packaged virtual operating environment is copied to a second testing device, the virtual operating environment can be decompressed to a test directory of c:. By running the packed virtual execution environment in the second test device, a corresponding virtual execution environment can be deployed in the second test device.
Through the processing mode, each testing device in the distributed system has a uniform service environment and a virtual operation environment, so that the consistency of the testing environment can be ensured on the premise of ensuring the independence of each testing device.
In one embodiment, in order to improve the processing efficiency of the test task, the deployment process of the service environment may be started automatically when the test device is powered on. In particular, a batch script program may be created in the test equipment. In the batch script program, a disk on which a program of the business environment is located may be defined. For example, if the program of the business environment is on a C disk (system disk), the corresponding program can be executed directly on the C disk. And if the programs of the service environment are in other disks, switching to the corresponding disk to process. In addition, in the batch script program, a folder where the program of the service environment is located can be further defined, so that the program of the service environment to be executed can be finally located by combining the disk and the folder.
When the batch script program is executed, the script for running the service environment can be added into a starting program of the system. For example, a script running the business environment may be added to the startup program of the start menu of the windows system. Therefore, after the test equipment is started, the batch processing script program can be automatically executed, so that the corresponding service environment is started before the call request is processed, and the call request can be directly processed in the following process.
Therefore, the script for executing the service environment is set to be started up and started up, so that the test environment is started up before the distributed test, a basis is provided for the subsequent processing process of the call request, and the processing speed of the call request can be improved.
Referring to fig. 4, an embodiment of the present application provides a system for processing a call request, where the system includes:
the interface identification unit is used for identifying a service interface pointed by a call request under the condition that the call request is received by a monitoring port; wherein, the data structure of the call request is consistent with the data structure supported by the service interface;
the request processing unit is used for sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request;
and the data encapsulation unit is used for encapsulating the service data according to a data structure supported by the service interface and providing the encapsulated service data to the calling party of the calling request.
Referring to fig. 2, an embodiment of the present application further provides a testing device in a distributed system, where the testing device runs a testing thread and a service, where:
the test thread is used for generating a call request of a specified data structure and sending the call request to a monitoring port of the test equipment;
the business service is used for identifying a business interface pointed by the calling request; wherein the specified data structure is consistent with the data structure supported by the service interface; sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request; and encapsulating the service data according to a data structure supported by the service interface, and providing the encapsulated service data for the test thread.
In one embodiment, the test thread is further configured to obtain a request identifier to be called, encode the request identifier, and package an encoding result into a call request of a specified data structure; and recording the request data according to the native data structure in the request body of the packaged calling request.
Referring to fig. 5, an embodiment of the present application further provides a testing device in a distributed system, where the testing device includes a memory and a processor, the memory is used to store a computer program, and the computer program, when executed by the processor, implements the method for processing the call request.
An embodiment of the present application further provides a computer storage medium, where the computer storage medium is used to store a computer program, and when the computer program is executed by a processor, the computer program implements the method for processing the call request.
In the present application, the processor may be a Central Processing Unit (CPU). The Processor may also be other general purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components, or a combination thereof.
The memory, which is a non-transitory computer readable storage medium, may be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions/modules corresponding to the methods of the embodiments of the present invention. The processor executes various functional applications and data processing of the processor by executing non-transitory software programs, instructions and modules stored in the memory, that is, the method in the above method embodiment is realized.
The memory may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created by the processor, and the like. Further, the memory may include high speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory optionally includes memory located remotely from the processor, and such remote memory may be coupled to the processor via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
It will be understood by those skilled in the art that all or part of the processes of the methods of the above embodiments may be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic Disk, an optical Disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a Flash Memory (Flash Memory), a Hard Disk (Hard Disk Drive, abbreviated as HDD), a Solid State Drive (SSD), or the like; the storage medium may also comprise a combination of memories of the kind described above.
Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations fall within the scope defined by the appended claims.
Claims (12)
1. A method for processing a call request, the method comprising:
under the condition that a monitoring port receives a calling request, identifying a service interface pointed by the calling request; wherein, the data structure of the call request is consistent with the data structure supported by the service interface;
sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request;
and encapsulating the service data according to a data structure supported by the service interface, and providing the encapsulated service data to the initiator of the call request.
2. The method of claim 1, wherein identifying the service interface to which the invocation request is directed comprises:
and determining a service function corresponding to the call request, and using a service interface for calling the service function as a service interface pointed by the call request.
3. The method according to claim 1, wherein the call request is an http request, and the port identifier of the listening port comprises a native IP address and a port number used for receiving the http request.
4. The method of claim 1, wherein the service interface is configured as follows:
setting an interface type for the service interface, wherein the interface type is correspondingly consistent with the request mode of the calling request;
binding a service function for the service interface; and the data structure of the entry of the business function is consistent with the data structure of the calling request.
5. The method of claim 1, wherein the invocation request is generated by the initiator in the following manner:
acquiring a request identifier to be called, encoding the request identifier, and packaging an encoding result into a calling request of a specified data structure; wherein the specified data structure is consistent with the data structure supported by the service interface; and recording request data according to the original data structure of the initiator in the request body of the packaged calling request.
6. The method of claim 1, wherein the method is applied to test equipment of a distributed system; the method further comprises the following steps:
configuring a service environment under default directories of first test equipment and second test equipment of the distributed system;
creating a virtual operating environment corresponding to the service environment under the test directory of the first test device, packaging the virtual operating environment, and copying the virtual operating environment to the test directory of the second test device;
and running the packed virtual running environment in the second test equipment.
7. The method of claim 6, further comprising:
creating a batch script program, wherein the batch script program is used for adding a script for running the service environment into a starting program of a system;
and executing the batch script program to start the service environment before processing the call request.
8. A system for processing a call request, the system comprising:
the interface identification unit is used for identifying a service interface pointed by a call request under the condition that the call request is received by a monitoring port; wherein, the data structure of the call request is consistent with the data structure supported by the service interface;
the request processing unit is used for sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request;
and the data encapsulation unit is used for encapsulating the service data according to a data structure supported by the service interface and providing the encapsulated service data to the calling party of the calling request.
9. A test device in a distributed system, wherein a test thread and a service run in the test device, wherein:
the test thread is used for generating a call request of a specified data structure and sending the call request to a monitoring port of the test equipment;
the business service is used for identifying a business interface pointed by the calling request; wherein the specified data structure is consistent with the data structure supported by the service interface; sending the calling request to the service interface so as to process the calling request through the service interface and generate service data corresponding to the calling request; and encapsulating the service data according to a data structure supported by the service interface, and providing the encapsulated service data for the test thread.
10. The test equipment according to claim 9, wherein the test thread is further configured to obtain a request identifier to be called, and after encoding the request identifier, encapsulate an encoding result as a call request of a specified data structure; and recording the request data according to the native data structure in the request body of the packaged calling request.
11. A test device in a distributed system, the test device comprising a memory for storing a computer program and a processor, the computer program, when executed by the processor, implementing the method of any of claims 1 to 7.
12. A computer storage medium for storing a computer program which, when executed by a processor, implements a method as claimed in any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110974834.2A CN113778647A (en) | 2021-08-24 | 2021-08-24 | Call request processing method, system and test equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110974834.2A CN113778647A (en) | 2021-08-24 | 2021-08-24 | Call request processing method, system and test equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113778647A true CN113778647A (en) | 2021-12-10 |
Family
ID=78838848
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110974834.2A Pending CN113778647A (en) | 2021-08-24 | 2021-08-24 | Call request processing method, system and test equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113778647A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114553852A (en) * | 2022-02-28 | 2022-05-27 | 傲普(上海)新能源有限公司 | Rapid uploading method based on asynchronous industrial file server |
-
2021
- 2021-08-24 CN CN202110974834.2A patent/CN113778647A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114553852A (en) * | 2022-02-28 | 2022-05-27 | 傲普(上海)新能源有限公司 | Rapid uploading method based on asynchronous industrial file server |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8978023B2 (en) | Canonical mechanism for securely assembling features into a mobile application | |
| US9942307B2 (en) | Web application script migration | |
| WO2016192556A1 (en) | Interface invoking method, device and terminal | |
| CN110413288B (en) | Application deployment method, device, server and storage medium | |
| CN110365751B (en) | Service processing method, device and equipment of gateway system | |
| CN111176626B (en) | Cross-programming-language code calling method and device, medium and equipment | |
| EP2948846A1 (en) | Resource calling for hybrid applications | |
| CN109240697B (en) | Call processing method and device and storage medium | |
| CN110365724B (en) | Task processing method and device and electronic equipment | |
| US11023558B1 (en) | Executing functions on-demand on a server utilizing web browsers | |
| CN109254765B (en) | Timing task management method, device, computer equipment and storage medium | |
| CN107977260B (en) | Task submitting method and device | |
| CN111930531B (en) | Data processing, data production and data consumption methods, devices, equipment and media | |
| CN108804100B (en) | Method and device for creating interface element, storage medium and mobile terminal | |
| CN107273226B (en) | Method and device for integrating components in android system and calling integrated components | |
| CN113778647A (en) | Call request processing method, system and test equipment | |
| CN109729121B (en) | Cloud storage system and method for realizing custom data processing in cloud storage system | |
| CN111679828B (en) | Data processing method and device, electronic equipment and storage medium | |
| WO2021093671A1 (en) | Task processing method, system, apparatus and device, and computer readable storage medium | |
| CN111651169A (en) | Block chain intelligent contract operation method and system based on web container | |
| CN110825373A (en) | Dynamic method and device for mobile terminal | |
| CN111581578B (en) | Interface request processing method and device | |
| CN109597952B (en) | Webpage information processing method, system, electronic equipment and storage medium | |
| CN112714148A (en) | Interface configuration method, device, equipment and medium | |
| CN112612474A (en) | Product transplanting method and device, storage medium and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |