Service registration access method based on logically strong isolation device

Abstract

The application discloses a service registration access method based on a logic strong isolation device, belongs to the technical field of data transmission, and comprises the following steps: S1, registering basic messages of service nodes on both sides of the logic strong isolation device into a cross-region database based on an HTTP protocol, and then generating a node data table; S2, inserting a request instruction into the cross-region database based on a first fragmentation time period of a CPU, and determining the service node corresponding to each request instruction based on the node data table; S3, processing each request instruction based on the service node corresponding to each request instruction, and then generating an HTTP response corresponding to each request instruction; and S4, inserting the HTTP response into the cross-region database based on a second fragmentation time period of the CPU, and returning each HTTP response to the service node corresponding to each HTTP response based on the node data table. The method solves the problem of row-level lock competition caused by the concurrent consumption of cross-region database data by multiple service nodes.

Description

Technical Field

[0001] This invention relates to the field of data transmission technology, specifically to a service registration and access method based on a logically strong isolation device. Background Technology

[0002] In distributed systems, data is often distributed across different regions or nodes. When service nodes in different regions need to access database data located in other regions, multi-node and multi-threaded methods are typically used to concurrently process tasks in order to improve system processing capacity and response speed. For example, a high-frequency database writing method and apparatus based on multi-threaded asynchronous processing, patent number CN118467591A, involves creating and initializing a multi-threaded table writer object; obtaining the table structure of the database to be written; creating a set of threads and corresponding cache queues, with each thread connecting to the database system and monitoring the status of its corresponding cache queue; setting a threshold for the number of writes expected in a single cache queue and a time threshold for the maximum write interval; asynchronously inserting data through the multi-threaded table writer object; determining the table type and partition type based on the table structure; for partitioned tables, inserting data of different partition types into different cache queues; cyclically executing the threads; triggering the write conditions of the cache queue based on the number and time thresholds; sending the data in the cache queue to the database system for data insertion through the threads; and finally clearing the cache queue. This improves write efficiency and reduces data write latency. However, in the above solution, when multiple threads or nodes consume database data concurrently, row-level lock contention can easily occur. Summary of the Invention

[0003] To address the issue of row-level lock contention caused by multiple service nodes concurrently consuming cross-region database data in existing technologies, this invention provides a service registration and access method based on a logically strong isolation device. According to information in the node's data table, request and response instructions are precisely assigned to the corresponding service nodes. Service nodes only access and process the data rows they need, reducing the possibility of multiple service nodes accessing the same data row simultaneously. By utilizing CPU fragmentation time for batch processing of request instructions and HTTP responses, the number of operations on the cross-region database is reduced. The combination of these two methods solves the row-level lock contention problem caused by multiple service nodes concurrently consuming cross-region database data. Simultaneously, by reducing the number of cross-region database operations, data processing efficiency is improved, ensuring the high efficiency and stability of cross-region interactions.

[0004] To address the aforementioned technical problems, this invention provides a service registration and access method based on a logically strong isolation device, comprising the following steps:

[0005] S1: Based on the HTTP protocol, the basic messages of the service nodes on both sides of the logically strong isolation device are registered in the cross-region database, thereby generating a node data table;

[0006] S2: Based on the first fragment time period of the CPU, the request instruction is inserted into the cross-region database, and the service node corresponding to each request instruction is determined based on the node data table;

[0007] S3: Process each request instruction based on the service node corresponding to each request instruction, and then generate the corresponding HTTP response for each request instruction;

[0008] S4: Based on the second fragment time period of the CPU, the HTTP response is inserted into the cross-region database, and based on the node data table, each HTTP response is returned to the service node corresponding to each HTTP response.

[0009] By adopting the above technical solution, the present invention has the following advantages:

[0010] Based on the information in the node data table, request and response instructions are precisely assigned to the corresponding service nodes. Service nodes will only access and process the data rows they need, avoiding the situation where multiple service nodes access the same data row at the same time. At the same time, by combining CPU fragment time, request instructions and HTTP responses are processed in batches, which significantly reduces the number of operations on cross-region databases. By reducing the number of cross-region database operations, data processing efficiency is improved, ensuring the efficiency and stability of cross-region interaction.

[0011] By encapsulating cross-regional database access operations with the standard HTTP protocol, the process of cross-regional data interaction is simplified, security is improved, and it is easy to integrate into the existing network architecture, thus having good compatibility.

[0012] This solves the problem of row-level lock contention caused by multiple service nodes concurrently consuming data from cross-region databases.

[0013] Preferably, the basic information of the service node includes at least the IP address and worker thread number of the service node.

[0014] Preferably, S1 includes:

[0015] S11: Design the registration interface based on the basic messages of the service node;

[0016] S12: Construct an HTTP request based on the basic messages and HTTP protocol of the service node;

[0017] S13: Send the HTTP request to the registration interface. Determine if the request body contains the service node's basic information. If it does, generate the node data table; otherwise, continue with S12. The service node's basic information is the core data for service registration and discovery, including key information such as the service node's IP address, port number, and service type. When designing the registration interface, the format and transmission method of this basic information must be clearly defined so that service nodes can successfully register their information to the cross-region database. By determining whether the HTTP request body contains the service node's basic information, errors or inconsistencies in the node data table due to incomplete data are avoided, thus ensuring the accuracy and reliability of service node information in the cross-region database. Avoiding the generation of node data tables based on incomplete data also means avoiding wasting database resources storing invalid or erroneous data, improving resource utilization.

[0018] Preferably, S2 includes:

[0019] S21: Determine whether it is within the first fragment time period of the CPU. If it is within the first fragment time period of the CPU, obtain the request instruction. If it is not within the first fragment time period of the CPU, batch insert the information of all request instructions obtained in the previous first fragment time period of the CPU into the cross-region database to generate the request instruction table.

[0020] S22: Compare the request instruction table with the node data table to obtain the first comparison result, and determine the service node corresponding to each request instruction based on the first comparison result. The first fragment time is any time period during which the CPU processes data other than the request instructions. By using batch insertion, the number of operations on the cross-region database can be reduced. At the same time, combined with the comparison mechanism, data processing efficiency is improved, while ensuring the efficiency and stability of cross-region interaction.

[0021] Preferably, S22 includes:

[0022] S221: Compare the request data in the request instruction table with the node data in the node data table, mark the request instruction corresponding to the successfully matched request data as a valid instruction, and determine the service node corresponding to the valid instruction based on the node data corresponding to the valid instruction.

[0023] S222: Record the request data that fails to match and generate a first record table. Update the node data table based on the first record table. By comparing the request data in the request instruction table with the node data in the node data table, it can be verified whether the request instruction points to the correct service node, avoiding sending the request instruction to a non-existent or inappropriate service node, ensuring the accuracy and validity of the service request. Recording the request data that fails to match and generating the first record table ensures the accuracy and real-time performance of the node data table.

[0024] Preferably, S3 includes:

[0025] S31: Determine whether to operate on the target data based on the status of the target data corresponding to the request instruction received by the service node. If no operation is performed on the target data, monitor the status of the target data. If the status of the target data changes, continue to execute S31. If an operation is performed on the target data, obtain the operation result and continue to execute S32.

[0026] S32: Generate the HTTP response corresponding to the request command based on the operation result. By determining the status of the target data before performing the operation, data consistency is improved, and resource utilization is optimized.

[0027] Preferably, in S31, determining whether to operate on the target data based on the status of the target data corresponding to the request instruction received by the service node includes:

[0028] If the target data corresponding to the request instruction is in the state of "modifying", it means that no operation has been performed on the target data. If the target data corresponding to the request instruction is in any state other than "modifying", it means that an operation has been performed on the target data.

[0029] Preferably, S4 includes:

[0030] S41: Determine whether it is within the second fragment time period of the CPU. If it is within the second fragment time period of the CPU, obtain the HTTP response. If it is not within the second fragment time period of the CPU, batch insert the information of all HTTP responses obtained in the previous second fragment time period of the CPU into the cross-region database to generate a response instruction table.

[0031] S42: Compare the response instruction table with the node data table to obtain the second comparison result, and determine the service node corresponding to each HTTP response based on the second comparison result. The second fragment time is any time period during which the CPU processes data other than HTTP responses. By using batch insertion, the number of operations on the cross-region database can be reduced. At the same time, combined with the comparison mechanism, data processing efficiency is improved, while ensuring the efficiency and stability of cross-region interaction.

[0032] Preferably, S42 includes:

[0033] S421: Compare the response data in the response instruction table with the node data in the node data table, mark the HTTP response corresponding to the successfully matched response data as a valid response, and determine the service node corresponding to the valid response based on the node data corresponding to the valid response.

[0034] S422: Record unmatched HTTP responses to generate a second record table, and update the node data table based on the second record table. By comparing the response data in the response instruction table with the node data in the node data table, it can be verified whether the HTTP response points to the correct service node, avoiding sending the HTTP response to a non-existent or inappropriate service node, ensuring the accuracy and validity of the service request. Recording unmatched HTTP responses and generating a second record table ensures the accuracy and real-time performance of the node data table.

[0035] Preferred options also include:

[0036] The system records the number of times each node in the node data table successfully matches the requested data in the request instruction table. Nodes whose number of successful matches exceeds a preset number are stored in memory. Frequent readings of node data from the database can put significant pressure on the cross-region database. By storing node data that meets the criteria in memory, the number of accesses to the cross-region database can be reduced, thereby alleviating the pressure on the cross-region database and improving response speed.

[0037] The beneficial effects of this plan are:

[0038] Based on the information in the node data table, request and response instructions are precisely assigned to the corresponding service nodes. Service nodes will only access and process the data rows they need, avoiding the situation where multiple service nodes access the same data row at the same time. At the same time, by combining CPU fragment time, request instructions and HTTP responses are processed in batches, which significantly reduces the number of operations on cross-region databases. By reducing the number of cross-region database operations, data processing efficiency is improved, ensuring the efficiency and stability of cross-region interaction.

[0039] By encapsulating cross-regional database access operations with the standard HTTP protocol, the process of cross-regional data interaction is simplified, security is improved, and it is easy to integrate into the existing network architecture, thus having good compatibility.

[0040] This solves the problem of row-level lock contention caused by multiple service nodes concurrently consuming data from cross-region databases. Attached Figure Description

[0041] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings.

[0042] Figure 1 This is a flowchart illustrating the service registration and access method based on a logically strong isolation device according to the present invention.

[0043] Figure 2 This is a flowchart illustrating the cross-regional data interaction process of the service registration and access method based on a logically strong isolation device according to the present invention.

[0044] Figure 3 This is a schematic diagram of service node registration for the service registration and access method based on a logically strong isolation device according to the present invention. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only one preferred embodiment of this invention and are only used to explain this invention. They do not limit the scope of protection of this invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0046] Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations (or steps) as sequential processes, many of the operations (or steps) can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but it may also have additional steps not included in the figures; the process may correspond to a method, function, procedure, subroutine, subroutine, etc.

[0047] Example 1:

[0048] like Figure 1 As shown, the service registration and access method based on a logically strong isolation device includes the following steps:

[0049] S1: Based on the HTTP protocol, the basic messages of the service nodes on both sides of the logically strong isolation device are registered in the cross-region database, thereby generating a node data table.

[0050] The basic information of the service node includes at least the service node's IP address and worker thread number.

[0051] S1 includes:

[0052] S11: Design the registration interface based on the basic messages of the service node;

[0053] S12: Construct an HTTP request based on the basic messages and HTTP protocol of the service node;

[0054] S13: Send the HTTP request to the registration interface, determine whether the request body of the HTTP request contains the basic information of the service node, if it does, generate the node data table, if it does not, continue to execute S12.

[0055] The registration interface's name, request method, and URL path are determined. The interface is designed based on the service node's IP address and worker thread ID, allowing service nodes to register. Basic service node information is encapsulated into HTTP requests and sent to the registration interface via HTTP. Upon receiving an HTTP request, the registration interface checks if the request body contains the IP address and worker thread ID. Requests lacking either are retransmitted. A node data table is only generated when all received HTTP requests contain both the IP address and worker thread ID in their request bodies. By checking the request body for service node information, errors and inconsistencies in the node data table due to incomplete data are avoided, ensuring the accuracy and reliability of service node information across different database regions. Avoiding the generation of node data tables based on incomplete data also prevents the waste of database resources storing invalid or erroneous data, improving resource utilization.

[0056] S2: Based on the first fragment time period of the CPU, the request instruction is inserted into the cross-region database, and the service node corresponding to each request instruction is determined based on the node data table.

[0057] S2 includes:

[0058] S21: Determine whether it is within the first fragment time period of the CPU. If it is within the first fragment time period of the CPU, obtain the request instruction. If it is not within the first fragment time period of the CPU, batch insert the information of all request instructions obtained in the previous first fragment time period of the CPU into the cross-region database to generate the request instruction table.

[0059] S22: Compare the request instruction table with the node data table to obtain the first comparison result, and determine the service node corresponding to each request instruction based on the first comparison result.

[0060] S22 includes:

[0061] S221: Compare the request data in the request instruction table with the node data in the node data table, mark the request instruction corresponding to the successfully matched request data as a valid instruction, and determine the service node corresponding to the valid instruction based on the node data corresponding to the valid instruction.

[0062] S222: Record the request data that failed to match and generate the first record table, and update the node data table based on the first record table.

[0063] The first fragmented time period is any time during which the CPU processes requests other than request commands. The upstream caller batch inserts all request commands within this first fragmented time period into the cross-region database to generate a request command table. Request commands include the service name, method name, parameters, etc. The downstream listener compares the request command table with the node data table to obtain the first comparison result. It then batch pulls the first comparison result, marking the request commands corresponding to successfully matched request data as valid commands. Based on the node data corresponding to the valid commands, it determines the service node corresponding to the valid command. If a comparison fails, it means that the service node corresponding to the unmatched request data is not registered in the node data table, so the node data table is updated. By comparing the request data in the request command table with the node data in the node data table, it verifies whether the request command points to the correct service node, avoiding sending request commands to non-existent or inappropriate service nodes, ensuring the accuracy and validity of service requests. Unmatched request data is recorded and a first record table is generated, ensuring the accuracy and real-time performance of the node data table.

[0064] S3: Process each request instruction based on the service node corresponding to each request instruction, and then generate the corresponding HTTP response for each request instruction.

[0065] S3 includes:

[0066] S31: Determine whether to operate on the target data based on the status of the target data corresponding to the request instruction received by the service node. If no operation is performed on the target data, monitor the status of the target data. If the status of the target data changes, continue to execute S31. If an operation is performed on the target data, obtain the operation result and continue to execute S32.

[0067] S32: Generate the HTTP response corresponding to the request instruction based on the operation result.

[0068] In S31, determining whether to operate on the target data based on the status of the target data corresponding to the request instruction received by the service node includes:

[0069] If the target data corresponding to the request instruction is in the state of "modifying", it means that no operation has been performed on the target data. If the target data corresponding to the request instruction is in any state other than "modifying", it means that an operation has been performed on the target data.

[0070] If user A reads product information with product ID 123, and user B modifies product information with product ID 123, and product information with product ID 123 is stored in a cross-region database, when user A initiates a read request to read product information with product ID 123, the service node, upon receiving the request, first checks the status of product information with product ID 123. Assuming the status is currently "modifying," it waits for the modification to complete. Once the modification is complete and the status becomes "readable," the service node can then read the product information with product ID 123. Similarly, if user B initiates a read request to modify product information with product ID 123, the service node, upon receiving the request, first checks the status of product information with product ID 123, which is also "readable." In this state, the product information can be modified. By first determining the target data status before performing operations, data consistency is improved, and resource utilization is optimized.

[0071] S4: Based on the second fragment time period of the CPU, the HTTP response is inserted into the cross-region database, and based on the node data table, each HTTP response is returned to the service node corresponding to each HTTP response.

[0072] S4 includes:

[0073] S41: Determine whether it is within the second fragment time period of the CPU. If it is within the second fragment time period of the CPU, obtain the HTTP response. If it is not within the second fragment time period of the CPU, batch insert the information of all HTTP responses obtained in the previous second fragment time period of the CPU into the cross-region database to generate a response instruction table.

[0074] S42: Compare the response instruction table with the node data table to obtain the second comparison result, and determine the service node corresponding to each HTTP response based on the second comparison result.

[0075] S42 includes:

[0076] S421: Compare the response data in the response instruction table with the node data in the node data table, mark the HTTP response corresponding to the successfully matched response data as a valid response, and determine the service node corresponding to the valid response based on the node data corresponding to the valid response.

[0077] S422: Record the HTTP responses that fail to match and generate a second record table, then update the node data table based on the second record table.

[0078] The second fragment of CPU time refers to any time period during which the CPU processes data other than HTTP responses. Downstream listeners batch insert all HTTP responses within this second fragment into the cross-region database to generate a response instruction table. HTTP responses include request instruction IDs and response data. Upstream listeners compare the response instruction table with the node data table to obtain a second comparison result. They then batch-fetch these second comparison results, marking successfully matched HTTP responses as valid responses. Based on the node data corresponding to valid responses, they determine the service node corresponding to each valid response. If a comparison fails, it means the service node corresponding to the unmatched HTTP response is not registered in the node data table, so the node data table is updated. By comparing the response data in the response instruction table with the node data in the node data table, it verifies whether the HTTP response points to the correct service node, avoiding sending HTTP responses to non-existent or inappropriate service nodes. Unmatched HTTP responses are recorded and a first record table is generated, ensuring the accuracy and real-time performance of the node data table.

[0079] Also includes:

[0080] The system records the number of times each node in the node data table successfully matches the requested data in the request instruction table. Nodes whose number of successful matches exceeds a preset number are stored in memory. Frequent readings of node data from the database can put significant pressure on the cross-region database. By storing node data that meets the criteria in memory, the number of accesses to the cross-region database can be reduced, thereby alleviating the pressure on the cross-region database and improving response speed.

[0081] like Figure 2As shown, it includes two parts: the request initiation side and the request response side. On the request initiation side, after the request command is initiated, a batch request database entry process is executed. The batch request database entry process includes: a batch request blocking queue, using the take() loop to retrieve request commands from the blocking queue until the first CPU fragment time expires, and batching the batch request commands accumulated within the first CPU fragment time (i.e., the CPU time slice) into the database to generate a request command table. Simultaneously with the batch request database entry process, a batch request response polling listener is performed. The batch request response polling listener includes: a batch request blocking queue, using the take() loop to retrieve request command IDs from the blocking queue until the first CPU fragment time expires, and using the batch request command IDs accumulated within the first CPU fragment time (i.e., the CPU time slice), i.e., the request IDs, to batch query the HTTP response results from the response command table in the cross-region database (i.e., the database), and simultaneously write the timeout results and normal results to the HTTP response listening queue to obtain the response result table. While the request initiating side is running, the request response side also starts running simultaneously. On the request response side, batch request command polling listens, which includes obtaining the service ID, IP, and thread ID of the current service node, executing business requests in batches using an asynchronous linear pool, proxying business service calls, writing HTTP responses (i.e., the results returned by calling the business interface), and executing the batch HTTP response database entry process. The batch HTTP response database entry process includes: a batch response blocking queue, using the take() loop to retrieve HTTP responses from the blocking queue until the second CPU time slice expires, and batch entering the accumulated batch HTTP responses within the second CPU time slice into the database to generate a response command table.

[0082] like Figure 3 As shown, the cross-region server is an intranet database, and the service node is an intranet-internet cross-region proxy service node. In the intranet environment, the information of the new service node (including the service name, IP, MAC, time, and thread_num) is registered in the intranet database and also registered in the cache. When the intranet and internet databases are under heavy load, the cache can be accessed directly, which further solves the row-level lock contention problem. At the same time, the "registration" component in the external network will periodically send heartbeat messages to the service registration module in the intranet to indicate that it is still active and wants to maintain a synchronized state.

[0083] To verify the effectiveness and feasibility of this invention, the following tests were conducted:

[0084] Performance testing: Simulate the processing of a large number of requests and responses in a high-concurrency environment, and record the processing time and system resource consumption.

[0085] Stability testing: Run cross-regional interactive component services for an extended period of time to observe their stability and data consistency performance.

[0086] Security testing: Simulate various attack methods to verify the effectiveness of the security protection measures of this invention.

[0087] By implementing the specific steps of this invention, the security, performance, and stability of cross-regional data interaction have been successfully improved.

[0088] The specific embodiments described above are preferred embodiments of the service registration and access method based on a logically strong isolation device of the present invention, and are not intended to limit the specific scope of the present invention. The scope of the present invention includes, but is not limited to, these specific embodiments. All equivalent changes made in accordance with the shape and structure of the present invention are within the protection scope of the present invention.

Claims

1. A service registration and access method based on a logically strong isolation device, characterized in that, Includes the following steps: S1: Based on the HTTP protocol, the basic messages of the service nodes on both sides of the logically strong isolation device are registered in the cross-region database, thereby generating a node data table; S2: Based on the first fragment time period of the CPU, the request instruction is inserted into the cross-region database, and the service node corresponding to each request instruction is determined based on the node data table; S3: Process each request instruction based on the service node corresponding to each request instruction, and then generate the corresponding HTTP response for each request instruction; S4: Based on the second fragment time period of the CPU, the HTTP response is inserted into the cross-region database, and based on the node data table, each HTTP response is returned to the service node corresponding to each HTTP response.

2. The service registration and access method based on a logically strong isolation device according to claim 1, characterized in that, The basic information of the service node includes at least the service node's IP address and worker thread number.

3. The service registration and access method based on a logically strong isolation device according to claim 1, characterized in that, S1 includes: S11: Design the registration interface based on the basic messages of the service node; S12: Construct an HTTP request based on the basic messages and HTTP protocol of the service node; S13: Send the HTTP request to the registration interface, determine whether the request body of the HTTP request contains the basic information of the service node, if it does, generate the node data table, if it does not, continue to execute S12.

4. The service registration and access method based on a logically strong isolation device according to claim 1, characterized in that, S2 includes: S21: Determine whether it is within the first fragment time period of the CPU. If it is within the first fragment time period of the CPU, obtain the request instruction. If it is not within the first fragment time period of the CPU, batch insert the information of all request instructions obtained in the previous first fragment time period of the CPU into the cross-region database to generate the request instruction table. S22: Compare the request instruction table with the node data table to obtain the first comparison result, and determine the service node corresponding to each request instruction based on the first comparison result.

5. The service registration and access method based on a logically strong isolation device according to claim 4, characterized in that, S22 includes: S221: Compare the request data in the request instruction table with the node data in the node data table, mark the request instruction corresponding to the successfully matched request data as a valid instruction, and determine the service node corresponding to the valid instruction based on the node data corresponding to the valid instruction. S222: Record the request data that failed to match and generate the first record table, and update the node data table based on the first record table.

6. The service registration and access method based on a logically strong isolation device according to claim 1, characterized in that, S3 includes: S31: Determine whether to operate on the target data based on the status of the target data corresponding to the request instruction received by the service node. If no operation is performed on the target data, monitor the status of the target data. If the status of the target data changes, continue to execute S31. If an operation is performed on the target data, obtain the operation result and continue to execute S32. S32: Generate the HTTP response corresponding to the request instruction based on the operation result.

7. The service registration and access method based on a logically strong isolation device according to claim 6, characterized in that, In S31, determining whether to operate on the target data based on the status of the target data corresponding to the request instruction received by the service node includes: If the target data corresponding to the request instruction is in the state of "modifying", it means that no operation has been performed on the target data. If the target data corresponding to the request instruction is in any state other than "modifying", it means that an operation has been performed on the target data.

8. The service registration and access method based on a logically strong isolation device according to claim 1, characterized in that, S4 includes: S41: Determine whether it is within the second fragment time period of the CPU. If it is within the second fragment time period of the CPU, obtain the HTTP response. If it is not within the second fragment time period of the CPU, batch insert the information of all HTTP responses obtained in the previous second fragment time period of the CPU into the cross-region database to generate a response instruction table. S42: Compare the response instruction table with the node data table to obtain the second comparison result, and determine the service node corresponding to each HTTP response based on the second comparison result.

9. The service registration and access method based on a logically strong isolation device according to claim 8, characterized in that, S42 includes: S421: Compare the response data in the response instruction table with the node data in the node data table, mark the HTTP response corresponding to the successfully matched response data as a valid response, and determine the service node corresponding to the valid response based on the node data corresponding to the valid response. S422: Record the HTTP responses that fail to match and generate a second record table, then update the node data table based on the second record table.

10. The service registration and access method based on a logically strong isolation device according to claim 5, characterized in that, Also includes: Record the number of times each node data in the node data table is successfully compared with the request data in the request instruction table, and store the node data in the node data table that has been successfully compared with the request data in the request instruction table more than a preset number of times into memory.

Images