A method and device for testing application system based on local virtual registration center

Abstract

The present invention proposes an application system testing method and device based on a local virtual registration center. The method includes: reading system environment variables to obtain an isolation mark; determining whether the isolation mark is turned on, if so, modifying the registration class bytecode and loading it, and if not, loading the registration class; determining whether the isolation mark is turned on, if so, creating a local virtual registration center to perform service localization registration and release, and if not, performing service remote registration and release; creating a message queue, determining whether the isolation mark is turned on, if so, adapting the local message component, and if not, adapting the general message component; initiating a service call, confirming that the isolation mark is turned on, and performing a service call through the local virtual registration center. The present invention can realize service publishing and subscription for multiple developers in multiple environments, isolate message production and consumption from each other, avoid confusion between service calls and message sending and receiving, and improve developer testing efficiency.

Description

Technical Field

[0001] The present invention relates to the field of computer processing technology, and in particular to an application system testing method and device based on a local virtual registration center. Background Art

[0002] Currently, most application system services are implemented based on clusters, that is, a group of servers acts as a cluster to provide services to clients. Figure 1 and 2 As shown in the figure, in a service call based on RPC (Remote Procedure Call), after developing a functional service, the developer will register it with the registration center. The client will pull the list of all registered services from the registration center for local cache, and then select a server to access and implement the service call.

[0003] After developers develop various application system features, they often need to perform unit tests on them to verify their functionality. Conventional technology uses a shared registration center, which can lead to confusion in service calls. For example, developers A and B each complete feature development and register a service. While A intends to call their own registered service for debugging and verification, they instead call B's registered service, leading to confusion in testing under multi-development models.

[0004] like Figure 3 As shown in the figure, for the message queue involved in the service call process, multiple people publishing and consuming messages simultaneously can cause message sending and receiving confusion. For example, developers A and B plan to send a message and then consume it asynchronously, but developer B competes for the message post-processing, causing message processing confusion.

[0005] To avoid testing confusion in a multi-person development model, the previous model required developers to manually add two configuration files for service registration and service calls to specify specific service nodes. When the self-test was completed and the code was formally submitted, the two test configuration files needed to be deleted to prevent impact on the production environment. However, this model of adding configuration files often leads to developers forgetting to add the configuration files during self-testing and forgetting to delete the configuration files when submitting the code, which cannot effectively prevent the occurrence of confusion in service calls and message processing. For example, when the project cycle enters the formal testing phase such as SIT and UAT, incorrect configuration of the configuration files is more likely to lead to unavailability of services in the test environment, message loss, etc., at which time urgent manual intervention is required to troubleshoot environmental problems. In addition, the team's developer turnover is high. When new people join the team, they need to be systematically trained, which wastes a lot of manpower and time. Summary of the Invention

[0006] In view of the above problems, the present invention provides an application system testing method and device based on a local virtual registration center, which solves the problem in the prior art that developers often forget to add configuration files when manually adding configuration files, forget to delete configuration files when submitting codes, and cannot effectively prevent confusion in service calls and message processing.

[0007] To solve the above technical problems, the technical solution adopted by the present invention is: an application system testing method based on a local virtual registration center, which runs on a local client, and the local client interacts with a remote server for data. The method includes the following steps: after the application is started, the system environment variables are read to obtain an isolation mark; it is determined whether the isolation mark is turned on, if so, the registration class bytecode is modified and loaded through ASM technology, if not, the registration class is loaded directly; service is published, it is determined whether the isolation mark is turned on, if so, a local virtual registration center is created, and service localized registration and publication is performed, if not, service remote registration center publication is performed; a message component is created, it is determined whether the isolation mark is turned on, if so, the local message component is adapted, if not, the general message component is adapted; after the application is started, a service call is initiated through the service locator, and it is confirmed that the isolation mark is in the on state, and a service call is performed through the local virtual registration center.

[0008] As a preferred solution, the isolation mark is a customized program startup parameter, and the startup parameter format is Java-D parameter key = parameter value setting parameter; then determining whether the isolation mark is turned on includes: determining whether the parameter key and parameter value setting parameter are equal. If they are equal, the isolation mark is turned on, otherwise, the isolation mark is not turned on.

[0009] As a preferred solution, the creation of a local virtual registration center includes: creating a ConcurrentHashMap key-value set to support concurrent operations; using the fully qualified name of the service contract name as the key name, and the local IP address and port parameters as values ​​to fill the ConcurrentHashMap key-value set; the structure of the local virtual registration center data is a HashMap, the key name is the service contract name, and the value is the local IP address and port parameters.

[0010] As a preferred solution, the message component includes a switch, a routing key and a queue, and the adapting local message component includes: binding the switch, the routing key and the queue with a unique identifier, and the unique identifier is an IP address or a MAC address.

[0011] As a preferred solution, the service call through the local virtual registration center includes: service discovery through the local virtual registration center, and starting the service call through the local IP address and exposed port. When there is a message sending in the call link, the application system will identify the isolation mark and send the message to the message queue bound to the local IP address. At the same time, the application system will monitor the message queue bound to the local IP address and obtain the message for subsequent asynchronous processing.

[0012] As a preferred solution, the method of modifying the registered class bytecode and loading it through ASM technology includes: using a Java virtual machine to modify the original content of the class bytecode during the class loading phase, and then loading it into the memory after modification, so as to achieve the purpose of modifying the original code logic.

[0013] The present invention also provides an application system testing device based on a local virtual registration center, including: an acquisition module, used to read system environment variables and obtain an isolation mark after the application is started; a judgment module, used to determine whether the isolation mark is turned on, if so, modify the registration class bytecode through ASM technology and load it, if not, directly load the registration class; a publishing module, used to publish services, determine whether the bytecode is modified, if so, create a local virtual registration center, and perform service localized registration and publishing, if not, perform service remote registration center publishing; an adaptation module, used to start a message queue, determine whether the isolation mark is turned on, if so, adapt the local message component, if not, adapt the general message component; a calling module, used to initiate a service call through a service locator after the application startup is completed, confirm that the isolation mark is in the on state, and make a service call through the local virtual registration center.

[0014] As a preferred solution, the creation of a local virtual registration center includes: creating a ConcurrentHashMap key-value set to support concurrent operations; using the fully qualified name of the service contract name as the key name, and the local IP address and port parameters as values ​​to fill the ConcurrentHashMap key-value set.

[0015] Compared with the existing technology, the present invention has the following advantages: by creating a local virtual registration center, the registration / call process of different people testing the service is isolated, supporting multiple people to test the service at the same time; by adding unique identifiers to messages in the message queue, messages from different developers are isolated; IP addresses and MAC addresses are hashed and the hash values ​​obtained after processing are used as isolation marks, which not only improves security but also prevents the mark characters from taking up too much storage space. The present invention can achieve multiple environments, multiple developers in the same environment, and isolate service publishing and subscription, message production and consumption, avoid the occurrence of confusion between service calls and message sending and receiving, and improve developer testing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The disclosure of the present invention is illustrated with reference to the accompanying drawings. It should be understood that the drawings are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. In the accompanying drawings, the same reference numerals are used to refer to the same components. Among them:

[0017] Figure 1 It is a schematic diagram of the architecture of the application system in the prior art;

[0018] Figure 2 A schematic diagram of the structure of service publishing and service calling in the prior art;

[0019] Figure 3 This is a schematic diagram of the structure of message publishing and message consumption in the prior art;

[0020] Figure 4 A schematic diagram of the structure of service publishing and service calling according to an embodiment of the present invention;

[0021] Figure 5 This is a schematic diagram of the structure of message publishing and message consumption according to an embodiment of the present invention;

[0022] Figure 6 A schematic diagram of the process of starting an application service according to an embodiment of the present invention;

[0023] Figure 7 The figure is a flow chart of application service calling according to an embodiment of the present invention. DETAILED DESCRIPTION

[0024] It is easy to understand that according to the technical solution of the present invention, without changing the essential spirit of the present invention, a person skilled in the art can propose a variety of interchangeable structural modes and implementation modes. Therefore, the following specific embodiments and drawings are only exemplary descriptions of the technical solution of the present invention and should not be regarded as the entire invention or as a limitation or restriction of the technical solution of the present invention.

[0025] According to one embodiment of the present invention, Figures 4 to 7 A method for testing an application system based on a local virtual registration center is shown. The method runs on a local client, and the local client interacts with a remote server for data. The method includes the following steps:

[0026] (1) After the application is started, the system environment variables are read to obtain the isolation tag. System properties can be set during the Java program startup phase and read during the program loading phase. The isolation tag is a customized program startup parameter in the format of Java – D parameter key = parameter value. For example, the IP address and MAC address can be hashed and the hash value obtained after the hashing is used as the isolation tag.

[0027] (2) Determine whether the isolation flag is turned on. If so, modify the registration class bytecode through ASM technology and load it. If not, directly load the registration class.

[0028] Determining whether the isolation flag is enabled includes determining whether the parameter key and parameter value setting parameters are equal. If they are equal, the isolation flag is enabled; otherwise, the isolation flag is disabled. For example, when a developer launches an application, they set Java-Render = native. During program execution, the render key can be read and determined to be equal to native. If they are, the developer is determined to have enabled the application environment isolation flag for this launch.

[0029] Preferably, in actual work, the development tool integrates a parameter setting panel, which can uniformly set the parameter key and parameter value setting parameters for developers.

[0030] The registered class bytecode is modified and loaded through ASM technology, including: using the Java virtual machine to modify the original content of the class bytecode during the class loading phase, and then loading it into the memory after modification, so as to achieve the purpose of modifying the original code logic.

[0031] It should be understood that ASM technology (i.e., dynamic bytecode update during class loading) involves modifying the original bytecode content before loading it back into memory during the Java virtual machine's class loading phase. This technology modifies the original bytecode content, reloading it to memory after the modifications, thereby modifying the original code logic. For example, the original bytecode logic may be to register with a remote registry, but this logic may be modified to connect to a local registry. The modified program is the embedded program, which is not actually executed at this point, but waits for the actual call to execute the new program logic.

[0032] (3) Publish the service and determine whether the isolation mark is turned on, that is, determine whether the bytecode has been modified. If so, create a local virtual registration center and publish the service locally. If not, publish the service to the remote registration center.

[0033] Among them, creating a local virtual registration center includes: creating a ConcurrentHashMap key-value set to support concurrent operations; using the fully qualified name of the service contract name as the key name, and the local IP address and port parameters as values ​​to fill the ConcurrentHashMap key-value set.

[0034] The structure of the local virtual registry data is HashMap, the key name is the service contract name, and the value is the local IP address and port parameters.

[0035] (4) Create a message component and determine whether the isolation flag is turned on. If so, adapt the local message component; if not, adapt the universal message component.

[0036] After an application connects to an MQ message queue, it automatically creates a message component based on the switch, routing key, and queue parameters. This message component, consisting of the switch, routing key, and queue, is adapted to the local message component, including binding the switch, routing key, and queue to a unique identifier, such as an IP address or MAC address. This ensures that each message component (switch, routing key, and queue) is uniquely declared.

[0037] For example, bind the message component (switch, routing key, queue) parameters to the developer's IP address. Suppose the original public switch, routing key, and queue parameters are:

[0038] rabbitmq.rich.direct.exchange=APPLY-RICH-DIRECT-EXCHANGE

[0039] rabbitmq.rich.direct.queue=APPLY-RICH-QUEUE

[0040] rabbitmq.rich.direct.routingkey=APPLY-RICH-ROUTING-KEY;

[0041] After binding with the developer's IP address and other unique identifiers, it is as follows:

[0042] rabbitmq.rich.direct.exchange=APPLY-RICH-DIRECT-EXCHANGE:10.175.1.116

[0043] rabbitmq.rich.direct.queue=APPLY-RICH-QUEUE:10.175.1.116

[0044] rabbitmq.rich.direct.routingkey=APPLY-RICH-ROUTING-KEY:10.175.1.116.

[0045] It should be noted that the unique identifier of the bound developer is mainly used to distinguish message component parameters and isolate them from each other, and is not limited to the developer's IP address or MAC address.

[0046] (5) After the application is started, a service call is initiated through the service locator, the isolation mark is confirmed to be on, and the service call is made through the local virtual registration center.

[0047] Specifically, the method for confirming that the isolation mark is in the on state is consistent with the above-mentioned application system startup judgment method, that is, when the service locator tool is started, the system property Java-D render=native is set, and the tag render is read during the runtime for value comparison. If render=native, the isolation mark is in the on state.

[0048] Calling a service through the local virtual registry involves discovering the service, obtaining the service's local IP address and port, and then invoking the service via RPC. When a message is sent during the call, the application system identifies the isolation flag and sends the message to the message queue bound to the local IP address. The application system then monitors the message queue bound to the local IP address and retrieves the message for subsequent asynchronous processing.

[0049] The present invention discloses an application system testing method based on a local virtual registration center. On the one hand, it can standardize the local environment of developers to uniformly open the environment isolation mark. When the application system is started, it will automatically identify the isolation mark to create a local virtual registration center and message components, thereby achieving the effect of mutual isolation and facilitating self-testing; on the other hand, the uniform configuration of the isolation mark can isolate multiple environments such as the local environment and the transfer test environment from each other.

[0050] The present invention also provides an application system testing device based on a local virtual registration center, comprising:

[0051] The acquisition module is used to read the system environment variables and obtain the isolation mark after the application starts.

[0052] The determination module is used to determine whether the isolation mark is turned on. If so, the registration class bytecode is modified and loaded through ASM technology. If not, the registration class is loaded directly.

[0053] The publishing module is used to publish services and determine whether the isolation mark is turned on. If so, a local virtual registration center is created to register and publish the service locally. If not, the service is published in the remote registration center.

[0054] Among them, creating a local virtual registration center includes: creating a ConcurrentHashMap key-value set to support concurrent operations; using the fully qualified name of the service contract name as the key name, and the local IP address and port parameters as values ​​to fill the ConcurrentHashMap key-value set.

[0055] The adaptation module is used to create a message component and determine whether the isolation mark is turned on. If so, the local message component is adapted; if not, the universal message component is adapted.

[0056] The calling module is used to initiate a service call through the service locator after the application is started, confirm that the isolation mark is turned on, and make a service call through the local virtual registration center.

[0057] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0058] In summary, the beneficial effects of the present invention include: by creating a local virtual registration center, the registration / calling process of different personnel testing services is isolated, supporting multiple people to test the service at the same time; by adding a unique identifier to the message in the message queue, the messages of different developers are isolated; the IP address and MAC address are hashed, and the hash value obtained after processing is used as an isolation mark, which not only improves security but also avoids the mark characters from taking up too much storage space. The present invention can realize multiple environments, multiple developers in the same environment, service publishing and subscription, and message production and consumption, avoiding the occurrence of confusion between service calls and message sending and receiving, and improving the testing efficiency of developers.

[0059] It should be understood that if the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0060] The technical scope of the present invention is not limited to the contents of the above description. Those skilled in the art can make various deformations and modifications to the above embodiments without departing from the technical idea of ​​the present invention, and these deformations and modifications should all fall within the protection scope of the present invention.

Claims

1. A method for testing an application system based on a local virtual registration center, running on a local client, wherein the local client interacts with a remote server for data, characterized in that: The method comprises the following steps: After the application is started, it reads the system environment variables and obtains the isolation mark; Determine whether the isolation flag is on. If so, modify the registered class bytecode and load it using ASM technology. If not, directly load the registered class. Modifying the registered class bytecode and loading it using ASM technology includes: using a Java virtual machine to modify the original content of the class bytecode during the class loading phase, and then loading the modified content into memory to achieve the purpose of modifying the original code logic. Publish the service and determine whether the isolation flag is on. If so, create a local virtual registration center and publish the service locally. If not, publish the service to the remote registration center. Create a message component and determine whether the isolation flag is on. If so, adapt the local message component; if not, adapt the universal message component. The message component includes a switch, a routing key, and a queue. Adapting the local message component includes: binding the switch, routing key, and queue to a unique identifier, where the unique identifier is an IP address or a MAC address; After the application is started, a service call is initiated through the service locator, the isolation flag is confirmed to be on, and the service call is made through the local virtual registration center; The service call through the local virtual registration center includes: service discovery through the local virtual registration center, and starting the service call through the local IP address and exposed port. When there is a message sent in the call link, the application system will identify the isolation mark and send the message to the message queue bound to the local IP address. At the same time, the application system will monitor the message queue bound to the local IP address and obtain the message for subsequent asynchronous processing.

2. The application system testing method based on the local virtual registration center according to claim 1 is characterized in that: The isolation mark is a customized program startup parameter, and the startup parameter format is Java-D parameter key = parameter value setting parameter; Then determining whether the isolation mark is turned on includes: determining whether the parameter key and the parameter value setting parameter are equal; if they are equal, the isolation mark is turned on; otherwise, the isolation mark is not turned on.

3. The application system testing method based on the local virtual registration center according to claim 1 is characterized in that: The creation of the local virtual registration center includes: creating a ConcurrentHashMap key-value set for supporting concurrent operations; filling the ConcurrentHashMap key-value set with the fully qualified name of the service contract name as the key name and the local IP address and port parameters as the value; The structure of the local virtual registration center data is HashMap, the key name is the service contract name, and the value is the local IP address and port parameters.

4. An application system testing device based on a local virtual registration center, characterized in that: include: The acquisition module is used to read the system environment variables and obtain the isolation mark after the application is started; A determination module is configured to determine whether the isolation flag is on. If so, the registered class bytecode is modified and loaded using the ASM technology. If not, the registered class is loaded directly. The modification and loading of the registered class bytecode using the ASM technology includes: using a Java virtual machine to modify the original content of the class bytecode during the class loading phase, and then loading the modified content into the memory to achieve the purpose of modifying the original code logic. The publishing module is used to publish services and determine whether the isolation flag is turned on. If so, a local virtual registration center is created to register and publish the service locally. If not, the service is published in the remote registration center. An adaptation module is used to create a message component and determine whether the isolation flag is turned on. If so, the local message component is adapted; if not, the universal message component is adapted. The message component includes a switch, a routing key, and a queue. The adaptation of the local message component includes: binding the switch, the routing key, and the queue with a unique identifier, wherein the unique identifier is an IP address or a MAC address; The calling module is used to initiate a service call through the service locator after the application is started, confirm that the isolation mark is in the on state, and make a service call through the local virtual registration center; the service call through the local virtual registration center includes: service discovery through the local virtual registration center, and starting the service call through the local IP address and the exposed port. When there is a message sent in the call link, the application system will identify the isolation mark and send the message to the message queue bound to the local IP address. At the same time, the application system will monitor the message queue bound to the local IP address and obtain the message for subsequent asynchronous processing.

5. The application system testing device based on the local virtual registration center according to claim 4, characterized in that: The creation of the local virtual registration center includes: creating a ConcurrentHashMap key-value set for supporting concurrent operations; filling the ConcurrentHashMap key-value set with the fully qualified name of the service contract name as the key name and the local IP address and port parameters as the value.

Images