Flow playback request method, system and device based on gRPC and medium

Abstract

The invention belongs to the technical field of flow playback, and particularly relates to a flow playback request method, system, device and medium based on gRPC, the flow playback request method is applied to a client, cross-language communication is carried out between the client and a server through gRPC, and the flow playback request method specifically comprises the following steps: monitoring whether a predefined proto file is updated or not; carrying out dynamic compiling according to a proto file of a new version after updating; and updating an internal dynamic client according to the gRPC code obtained after dynamic compiling, and sending a gRPC request to the server through the dynamic client so as to call a remote service of the server to perform flow playback. According to the method, when the proto protocol is changed, shutdown for re-compiling is not needed, protocol change can be dealt with in a manner of compiling the proto protocol file in real time, stub codes do not need to be generated locally, remote communication is not needed in a dynamic client manner, and the operation and maintenance cost is greatly reduced.

Description

Technical Field

[0001] The present invention belongs to the technical field of traffic playback, and in particular relates to a gRPC-based traffic playback request method, system, device, and medium. Background Art

[0002] When using the gRPC (Google Remote Procedure Call) protocol for inter-service communication, it is usually necessary to pre-generate and compile stub classes, which are used to map methods in the gRPC protocol to specific code implementations so that the client can call methods on the server. However, the above solution has the following disadvantages: the stub classes need to be pre-generated and compiled, which increases the complexity of code management; if the proto file changes, the stub class needs to be regenerated and compiled, resulting in service interruption and restart, affecting user experience; the generated stub class takes up storage space; it is impossible to dynamically compile the proto protocol file in real time, and when the proto file needs to be reloaded, the service must be recompiled and restarted; it is not suitable for traffic playback services, and cannot efficiently process a large number of requests and responses, and cannot handle frequently updated proto files. Summary of the invention

[0003] In view of the shortcomings of the prior art described above, the purpose of the present invention is to propose a traffic playback request method that can dynamically compile proto protocol files in real time, without the need to recompile and restart the service, thereby greatly improving the flexibility of the system.

[0004] To achieve the above-mentioned purpose and other related purposes, the present invention provides a gRPC-based traffic replay request method, which is applied to a client, and the client and the server communicate across languages ​​through gRPC. The traffic replay request method includes: monitoring whether a predefined proto file is updated, and dynamically compiling according to the new version of the proto file after the update; updating the internal dynamic client according to the gRPC code obtained after the dynamic compilation, and sending a gRPC request to the server through the dynamic client to call the remote service of the server for traffic replay.

[0005] According to a specific embodiment of the present invention, the steps of monitoring whether a predefined proto file is updated and dynamically compiling according to a new version of the proto file after the update include: monitoring the git repository to identify whether the proto file is updated; after the proto file is updated, obtaining a new version of the proto file and downloading it locally; and dynamically compiling according to the new version of the proto file.

[0006] According to a specific embodiment of the present invention, the step of dynamically compiling according to the new version of the proto file includes: dynamically compiling the new version of the proto file through the Protoc compiler and the gRPC plug-in to generate the gRPC code for the client traffic playback request.

[0007] According to a specific embodiment of the present invention, it also includes: converting the gRPC code of the client traffic playback request into a descriptor file.

[0008] According to a specific embodiment of the present invention, the step of updating the internal dynamic client according to the gRPC code obtained after dynamic compilation includes: generating a FileDescriptor class according to the gRPC code obtained after compilation to describe a complete proto file; obtaining a method-level MethodDescriptor class according to the FileDescriptor class to describe a service method; and updating the dynamic client according to the MethodDescriptor class so that it sends a corresponding gRPC request to the server based on the new version of the proto file.

[0009] According to a specific embodiment of the present invention, the step of obtaining a method-level MethodDescriptor class according to the FileDescriptor class includes: converting the FileDescriptor class into a ServiceResolver class to read the descriptor in the new version of the proto file and extract the locator of the method definition; generating the MethodDescriptor class according to the ServiceResolver class.

[0010] According to a specific embodiment of the present invention, the step of updating the dynamic client according to the MethodDescriptor class includes: updating the dynamic client according to the MethodDescriptor class and a ManagedChannel component of the client.

[0011] The present invention also provides a gRPC-based traffic replay request system, which is applied to a client, and the client and the server communicate across languages ​​through gRPC. The traffic replay request system includes: an update detection module, which is used to monitor whether a pre-defined proto file is updated, and dynamically compile according to the new version of the proto file after the update; a request sending module, which is used to update the internal dynamic client according to the gRPC code obtained after dynamic compilation, and send a gRPC request to the server through the dynamic client to call the remote service of the server for traffic replay.

[0012] The present invention also provides an electronic device, comprising a processor, wherein the processor is coupled to a memory, wherein the memory stores program instructions, and when the program instructions stored in the memory are executed by the processor, the above-mentioned method is implemented.

[0013] The present invention also provides a computer-readable storage medium, comprising a program, and when the program is run on a computer, the computer executes the method as described above.

[0014] The present invention provides a traffic playback request method that does not require pre-compilation of the proto protocol file and is not integrated into the target service in the form of a jar package, and the technical effects embodied are as follows: Real-time dynamic compilation: Compared with the traditional technical solution that requires pre-compilation and generation of stub classes, the present invention realizes real-time dynamic compilation of proto protocol files. There is no need to recompile and restart the service, only reload the proto file, which greatly improves the flexibility and availability of the system.

[0015] Dynamic Client: This paper introduces the concept of dynamic client, which dynamically generates and sends gRPC requests based on the updated proto file. Compared with the method of pre-generating and compiling stub classes, dynamic client simplifies code management and improves code maintainability.

[0016] Avoiding the generation of redundant stub classes: Due to the adoption of dynamic compilation and dynamic client methods, the present invention avoids the generation of redundant stub classes, which not only reduces the complexity of the code, but also saves storage space.

[0017] Non-stop update: The present invention can perform protocol updates without downtime, which is very important for services that need to run for a long time. It also means that the protocol can be updated without affecting the user experience.

[0018] Applicable to traffic replay service: The present invention is particularly suitable for traffic replay service, can handle a large number of requests and responses, and can effectively handle frequently updated proto files, which improves the efficiency and accuracy of the traffic replay service.

[0019] The above advantages can not only improve the flexibility and availability of the system, simplify code management, and save storage space, but also update the protocol without affecting the user experience, improve the efficiency and accuracy of the traffic playback service, and greatly reduce the operation and maintenance costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A flow chart of a specific embodiment of a gRPC-based traffic playback request method provided by the present invention; Figure 2 A structural diagram of a specific embodiment of a gRPC-based traffic playback request system provided by the present invention; Figure 3 The present invention provides a structural block diagram of a specific embodiment of an electronic device. DETAILED DESCRIPTION

[0021] In order to facilitate understanding of the present application, the present application will be described more fully below with reference to the relevant drawings. Embodiments of the present application are provided in the drawings. However, the present application can be implemented in many different forms and is not limited to the embodiments described herein. On the contrary, the purpose of providing these embodiments is to make the disclosure of the present application more thorough and comprehensive.

[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application.

[0023] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0024] In the following description, numerous details are discussed to provide a more thorough explanation of the embodiments of the present invention. However, it is obvious to those skilled in the art that the embodiments of the present invention can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present invention difficult to understand.

[0025] Example 1 This embodiment provides a gRPC-based traffic playback request method, which is applied to the client side, so that the client can dynamically compile the updated proto file in real time and send a gRPC request for traffic playback to the server normally without restarting.

[0026] It is understandable that the client can use the gRPC protocol to remotely call the service method that has been configured in the server, and this requires pre-defining the proto file. The proto file stores the service method and the corresponding calling interface, and then the proto file can be compiled by the Protoc compiler to generate the corresponding gRPC code, and the gRPC code is used to generate the corresponding interface in the client and the server. When the client needs to call the service method, it sends a request to the server through its internal interface, the stub, and serializes the Protobuf data in the request through the ManagedChannel component and then sends it to the server. After receiving the client's request, the server processes the Protobuf data in the request and deserializes it, then performs logical processing on the request, and finally serializes the response and returns it to the client. The client uses the Protobuf data to deserialize the Protobuf data in the response to implement the service method call, thereby completing a complete interface call process.

[0027] Once the proto file is updated, the calling interface of the corresponding service method is adjusted, which requires recompilation and stub generation, which will cause the client service to be interrupted and restarted. This will seriously affect the normal operation of the client in the scenario of traffic playback service, and it will not be able to efficiently process a large number of requests and responses, and it will not be able to cope with frequently updated proto files. Therefore, in this embodiment, the interface in the client, i.e., the stub, is replaced with a dynamic client (‌ DynamicClient ), you can dynamically update and send gRPC requests based on the updated proto file, which greatly simplifies code management compared to pre-generated and compiled stub classes.

[0028] For details, please see Figure 1 As shown, the steps of the gRPC-based traffic playback request method include the following: Step S100, monitoring whether the predefined proto file is updated, and dynamically compiling according to the new version of the proto file after the update.

[0029] Step S200, updates the internal dynamic client according to the gRPC code obtained after dynamic compilation, and sends a gRPC request to the server through the dynamic client to call the remote service of the server for traffic playback.

[0030] In a specific embodiment, it is possible to identify whether the proto file is updated by monitoring the git repository, and after the proto file is updated, it is downloaded to the local computer for loading, and dynamically compiled to update the client's gRPC protocol definition. It should be noted here that when the proto file is updated, the server also needs to update the interface, i.e., the stub, therein, but the method provided in this embodiment is only used to avoid service interruption and restart on the client side, and the stub update process on the server side is not related to traffic playback. Therefore, there are no excessive restrictions on how the server side is updated according to the new version of the proto file. Without departing from the spirit of the present invention, the modifications and embellishments made to the embodiments of the present invention by those skilled in the art still fall within the scope of the invention patent application of the present invention.

[0031] Specifically, in actual applications, the new version of the proto file is dynamically compiled through the Protoc compiler and the gRPC plug-in to generate the gRPC code for the client traffic playback request. It should be noted here that first, the gRPC code needs to be converted into a descriptor file such as .pb.bin, and then the FileDescriptor class is generated based on the descriptor file to describe a complete proto file.

[0032] Among them, FileDescriptor is the abbreviation of "file descriptor", which is an abstract concept used to represent resources such as files and sockets opened in the operating system. In Java, the FileDescriptor class is used to represent the basic properties of these resources, such as file handles, file status, etc. FileDescriptor is a non-negative integer identifier assigned by the operating system to each process to open a file or socket or other resource. In UNIX and Linux systems, this identifier is called a "file descriptor", and in Windows systems it is called a "handle". FileDescriptor is mainly used in low-level programming to help programs interact with the operating system through file descriptors.

[0033] Secondly, the FileDescriptor class file is converted into a ServiceResolver class to read the descriptor in the new version of the proto file and extract the locator of the method definition, and then a method-level MethodDescriptor class is generated according to the ServiceResolver class file to describe the service method.

[0034] Among them, the ServiceResolver class is an important class in Microsoft Azure Service Fabric, which is mainly used to resolve the location information of the service, helping the client find the location of the service and communicate with it. The ServiceResolver class is under the Microsoft.ServiceFabric.Services.Client namespace and is part of the Azure Service Fabric client library. The main function of ServiceResolver is to resolve the location information of the service. In AzureService Fabric, the location information of the service is identified by the Service Endpoint. ServiceResolver helps the client find and connect to the corresponding service by resolving this information. This includes obtaining information such as the IP address and port number of the service so that the client can establish a network connection.

[0035] MethodDescriptor is a class in Java that belongs to the java.beans package. It is used to describe a special method, especially those Java Bean methods that support external access from other components. The MethodDescriptor class inherits from the FeatureDescriptor class and is mainly used to encapsulate the description information of the method and its parameters.

[0036] Finally, the MethodDescriptor class file and the client's ManagedChannel component construct or update the dynamic client dynamicClient.

[0037] Among them, ManagedChannel‌ is an important component in gRPC, which is used to manage the connection between the client and the server. It is an abstract layer that handles the details of network communication, including connection establishment, maintenance, and closing operations, and is used to serialize and deserialize requests and responses.

[0038] Based on the above, after dynamically compiling the proto file, the corresponding gRPC request can be sent through the dynamic client dynamicClient, that is, the new gRPC code obtained by parsing is used to send the request to remotely call the traffic replay service method configured in the server, so as to achieve the flexibility, efficiency, and maintainability of the traffic replay service. Compared with the traditional technical solution for gRPC requests based on Proto protocol files, the technical solution of this embodiment has the advantages of real-time dynamic compilation, dynamic client, avoiding the generation of redundant stub classes, non-stop updates, and suitability for traffic replay services. These advantages can improve the flexibility and availability of the system, simplify code management, and save storage space, while performing protocol updates without affecting the user experience, thereby improving the efficiency and accuracy of the traffic replay service.

[0039] It should be noted that the step division of the above methods is only for clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they contain the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0040] Example 2 See also Figure 2 As shown, this embodiment also provides a gRPC-based traffic playback request system, which is characterized in that it is applied to the client, and the client and the server communicate cross-language through gRPC, and the traffic playback request system includes: An update monitoring module 10 is used to monitor whether a predefined proto file is updated, and dynamically compile according to the new version of the proto file after the update; A request sending module 20 is used to update the internal dynamic client according to the gRPC code obtained after dynamic compilation, and send a gRPC request to the server through the dynamic client to call the remote service of the server for traffic playback; It should be noted that the gRPC-based traffic replay request system provided in the above embodiment and the gRPC-based traffic replay request method provided in the above embodiment 1 belong to the same concept, and the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment and will not be repeated here. In actual applications, the gRPC-based traffic replay request method provided in the above embodiment 1 can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not limited here.

[0041] Example 3 See also Figure 3 As shown, an embodiment of the present application further provides an electronic device, comprising a memory 2, a processor 1, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of any one of the above methods are implemented.

[0042] Among them, the memory includes at least one type of readable storage medium, and the readable storage medium includes flash memory, mobile hard disk, multimedia card, card-type memory (for example: SD or DX memory, etc.), magnetic memory, disk, optical disk, etc. In some embodiments, the memory can be an internal storage unit of the electronic device, such as a mobile hard disk of the electronic device. In other embodiments, the memory can also be an external storage device of the electronic device, such as a plug-in mobile hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device. Further, the memory can also include both an internal storage unit of the electronic device and an external storage device. The memory can not only be used to store application software and various types of data installed in the electronic device, but also can be used to temporarily store data that has been output or is to be output.

[0043] In some embodiments, the processor may be composed of an integrated circuit, for example, a single packaged integrated circuit, or a plurality of packaged integrated circuits with the same or different functions, including one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and a combination of various control chips. The processor is the control core (Control Unit) of the electronic device, which connects the various components of the entire electronic device using various interfaces and lines, and executes various functions of the electronic device and processes data by running or executing programs or modules stored in the memory, and calling data stored in the memory.

[0044] The processor executes the operating system of the electronic device and various installed application programs. The processor executes the application programs to implement the steps in the above method embodiment.

[0045] Exemplarily, the program may be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules may be a series of program instruction segments capable of completing specific functions, which are used to describe the execution process of the program in the electronic device.

[0046] The above-mentioned integrated unit implemented in the form of software function modules can be stored in a computer-readable storage medium. The above-mentioned software function modules are stored in a storage medium and include several instructions for enabling a computer device (which can be a personal computer, a computer device, or a network device, etc.) or a processor to perform part of the functions of various embodiments of the present invention.

[0047] In summary, the present invention provides a traffic playback request method that does not require pre-compilation of the proto protocol file and is not integrated into the target service in the form of a jar package, and the technical effects embodied are as follows: Real-time dynamic compilation: Compared with the traditional technical solution that requires pre-compilation and generation of stub classes, the present invention realizes real-time dynamic compilation of proto protocol files. There is no need to recompile and restart the service, only reload the proto file, which greatly improves the flexibility and availability of the system.

[0048] Dynamic Client: This paper introduces the concept of dynamic client, which dynamically generates and sends gRPC requests based on the updated proto file. Compared with the method of pre-generating and compiling stub classes, dynamic client simplifies code management and improves code maintainability.

[0049] Avoiding the generation of redundant stub classes: Due to the adoption of dynamic compilation and dynamic client methods, the present invention avoids the generation of redundant stub classes, which not only reduces the complexity of the code, but also saves storage space.

[0050] Non-stop update: The present invention can perform protocol updates without downtime, which is very important for services that need to run for a long time. It also means that the protocol can be updated without affecting the user experience.

[0051] Applicable to traffic replay service: The present invention is particularly suitable for traffic replay service, can handle a large number of requests and responses, and can effectively handle frequently updated proto files, which improves the efficiency and accuracy of the traffic replay service.

[0052] The above advantages can not only improve the flexibility and availability of the system, simplify code management, and save storage space, but also update the protocol without affecting the user experience, improve the efficiency and accuracy of the traffic playback service, and greatly reduce the operation and maintenance costs.

[0053] The above embodiments are merely illustrative of the principles and effects of the present invention, and are not intended to limit the present invention. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present invention. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed by the present invention shall still be covered by the claims of the present invention.

Claims

1. A traffic playback request method based on gRPC, characterized in that: Applied to the client, and the client and the server communicate cross-language via gRPC, the traffic playback request method includes: Monitor whether the pre-defined proto file is updated, and dynamically compile according to the new version of the proto file after the update; The internal dynamic client is updated according to the gRPC code obtained after dynamic compilation, and a gRPC request is sent to the server through the dynamic client to call the remote service of the server for traffic playback.

2. According to the gRPC-based traffic playback request method according to claim 1, it is characterized in that: The steps of monitoring whether the pre-defined proto file is updated and dynamically compiling according to the new version of the proto file after the update include: By monitoring the git repository, we can identify whether the proto file is updated; After the proto file is updated, obtain the new version of the proto file and download it locally; Dynamically compile according to the new version of the proto file.

3. The gRPC-based traffic playback request method according to claim 1 or 2, characterized in that: The steps for dynamic compilation based on the new version of the proto file include: The new version of the proto file is dynamically compiled through the Protoc compiler and the gRPC plug-in to generate the gRPC code for the client traffic playback request.

4. The gRPC-based traffic playback request method according to claim 3, characterized in that: Also includes: Convert the gRPC code of the client traffic playback request into a descriptor file.

5. The gRPC-based traffic playback request method according to claim 1, characterized in that: The steps to update the internal dynamic client according to the gRPC code obtained after dynamic compilation include: Generate a FileDescriptor class based on the compiled gRPC code to describe a complete proto file; Obtaining a method-level MethodDescriptor class according to the FileDescriptor class to describe the service method; Update the dynamic client according to the MethodDescriptor class so that it sends the corresponding gRPC request to the server based on the new version of the proto file.

6. The gRPC-based traffic playback request method according to claim 5, characterized in that: The steps of obtaining the method-level MethodDescriptor class according to the FileDescriptor class include: Convert the FileDescriptor class into a ServiceResolver class to read the descriptor in the new version of the proto file and extract the locator of the method definition; The MethodDescriptor class is generated according to the ServiceResolver class.

7. The gRPC-based traffic playback request method according to claim 5, characterized in that: The step of updating the dynamic client according to the MethodDescriptor class comprises: The dynamic client is updated according to the MethodDescriptor class and the ManagedChannel component of the client.

8. A gRPC-based traffic playback request system, characterized in that: Applied to the client, and the client and the server communicate cross-language via gRPC, the traffic playback request system includes: Update detection module, used to monitor whether the pre-defined proto file is updated, and dynamically compile according to the new version of the proto file after the update; The request sending module is used to update the internal dynamic client according to the gRPC code obtained after dynamic compilation, and send a gRPC request to the server through the dynamic client to call the remote service of the server for traffic playback.

9. An electronic device, characterized in that: The method comprises a processor, wherein the processor is coupled to a memory, wherein the memory stores program instructions, and when the program instructions stored in the memory are executed by the processor, the method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that: The invention comprises a program, which, when being executed on a computer, causes the computer to execute the method according to any one of claims 1 to 7.

Images