Score query page view capacity expansion method based on OpenTelemetry

Abstract

The invention relates to the technical field of big data processing optimization, in particular to an OpenTelemetry-based score query page view capacity expansion method, which comprises the following steps of: S1, acquiring a login request; s2, transmitting the login request to a server side through a load balancing device through a login query link; s3, unpacking the login request through the server, verifying the user identity and generating a return packet; the method comprises the following steps of: generating a TraceID1 (TraceID1) through OpenTelemetry, and adding a corresponding TraceID1 value into header information of a return packet; s4, the return packet is returned to the client side to obtain the TraceID1; s5, asynchronously calling an IP query request through the client, and carrying the TraceID1 in a request header of the IP query request; s6, transmitting the IP query request carrying the TraceID1 to a load balancing device through an IP query link, unpacking the IP query request to obtain IP address information, and transmitting the IP address information to a server; and S7, receiving and storing the IP address information through the server. According to the score query access volume expansion method, the stability and efficiency of score query access equipment in a high-concurrency application scene can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of big data processing optimization, and particularly relates to a method for expanding the access volume of score query based on OpenTelemetry. Background Art

[0002] Under the background of the rapid development of information technology, the score query system for large-scale examinations (such as the college entrance examination) is a typical high-concurrency application scenario, which poses extremely high requirements on the stability and processing efficiency of the system. High-concurrency applications refer to systems that need to process a large number of user requests simultaneously within a unit of time, and the request volume often shows a pulsed explosive growth. For example, within the first half hour after the release of college entrance examination scores, millions of candidates and parents may initiate score query requests through different clients (including web pages, APPs, mini-programs, etc.). This instantaneous request peak far exceeds the load-bearing capacity of conventional business systems and poses a severe challenge to the underlying architecture.

[0003] Existing score query systems usually adopt a three-layer architecture: client, load balancer cluster, and server cluster. The working principle is as follows: users submit query requests containing user names and passwords through the client, and the requests first reach the load balancing device; the load balancer unpacks the data packets, extracts the user IP address and login credentials, and forwards them to the server; after the server completes the authentication, it performs a database query and stores the user IP address in the log system at the same time. Among them, the acquisition of the IP address plays an important role: on the one hand, abnormal access patterns can be identified through the analysis of IP address distribution. For example, a large number of requests are initiated by the same IP within a short period of time, so as to prevent DDoS attacks or password brute-force cracking behaviors; on the other hand, the binding of the IP address and operation logs provides a key audit clue for tracing illegal behaviors.

[0004] However, in high-concurrency application scenarios, the existing score query systems have the following problems: 1) As the request entry, the load balancer needs to complete computationally intensive operations such as SSL decryption, protocol parsing, and data recombination, and its processing capacity becomes the bottleneck of system performance. 2) Each request needs to repeatedly parse the HTTP header and TLS handshake information, consuming a large amount of CPU resources; 3) The real IP address information of users is easily lost due to proxy server forwarding, and the existing system lacks an efficient IP traceability mechanism. Existing improvement schemes mostly focus on hardware expansion or cache optimization. For example, using an FPGA acceleration card to improve the performance of the load balancer, but such methods have the problems of high hardware upgrade costs and poor scalability, and cannot fundamentally solve the problem.

[0005] Therefore, how to design a method that can adapt to high-concurrency application scenarios and effectively obtain user IP address information is a technical problem that needs to be solved urgently. Summary of the Invention

[0006] In view of the deficiencies of the above-mentioned prior art, the technical problem to be solved by the present invention is: how to provide a method for expanding the query access volume of grades based on OpenTelemetry, so that the data processing volume of the load balancing device can still be greatly reduced in a high-concurrency application scenario, so that the same load balancing device can handle more user query requests and still obtain the real IP address of the user, thereby improving the device stability and efficiency of grade query access in a high-concurrency application scenario.

[0007] To solve the above technical problems, the present invention adopts the following technical solutions:

[0008] A method for expanding the query access volume of grades based on OpenTelemetry, including:

[0009] S1: Obtain the login request sent by the user through the client;

[0010] S2: Transmit the login request through the load balancing device to the server through the login query link;

[0011] S3: Unpack the login request through the corresponding domain name certificate held by the server, verify the user identity and generate a return packet; at the same time, generate TraceID1 for the login request through OpenTelemetry, and add the corresponding TraceID1 value to the header information of the return packet; at the same time, inject the TraceID1 and the corresponding SpanID information into the user access log;

[0012] S4: The return packet is returned to the load balancing device and the login query link in turn, and finally returned to the client; the client obtains TraceID1 from the return packet;

[0013] S5: After the user logs in successfully, send a grade query request through the client; after the grade query request is successful, asynchronously call the IP query request through the client, and carry TraceID1 in the request header of the IP query request;

[0014] S6: When the IP query request carrying TraceID1 is transmitted to the load balancing device through the IP query link, unpack the IP query request through the corresponding domain name certificate held by the load balancing device, obtain the IP address information, and transmit it to the server;

[0015] S7: Receive and store the IP address information through the server.

[0016] Preferably, in step S2, the load balancing device is provided with a login query port; the login request and the grade query request are transmitted to the load balancing device through the login query port, and the login request and the grade query request are transmitted to the server through the load balancing device.

[0017] Preferably, in step S3, the server unpacks the login request to obtain the corresponding user identity information, and verifies the user identity by validating the user identity information.

[0018] Preferably, in step S3, the user identity information and the TraceID1 information injected by OpenTelemetry are appended to the user login log.

[0019] Preferably, in step S6, the load balancer device is provided with an IP query port; the IP query request is transmitted to the load balancer device through the IP query port, and the IP query request is unpacked by the corresponding domain name certificate held by the load balancer device.

[0020] Preferably, in step S6, the load balancer device transmits the unpacked IP address information and the IP query request carrying TraceID1 to the server;

[0021] In step S7, while the server receives and stores the IP address information, OpenTelemetry generates TraceID2 for the IP query request carrying TraceID1.

[0022] Preferably, the IP address information, TraceID1 information, and TraceID2 information are appended to the additional information of the IP request log.

[0023] Preferably, when querying the access log of a specific user, obtain the TraceID1 information injected by OpenTelemetry in the user access log; query the IP request log containing TraceID1 in the additional information of all IP request logs according to the TraceID1 information; obtain the IP address information contained in the IP request log as the real IP address of the specific user.

[0024] Preferably, in step S5, after the user issues a score query request through the client: the score query request is transmitted through the load balancer device to the server through the login query link; the server unpacks the score query request, verifies the user identity, and obtains the user score information and generates a return packet after successful identity verification; at the same time, OpenTelemetry generates a corresponding TraceID for the score query request and adds the corresponding TraceID value to the header information of the return packet; the return packet is sequentially returned to the load balancer device and the login query link and finally returned to the client; the client obtains the user score information from the return packet; when the client obtains the user score information, it indicates that the score query request is successful.

[0025] Preferably, after the user logs in successfully, the client sends multiple score query requests. However, only when the first score query request is successful can the IP query request be asynchronously called through the client, that is, the IP query request is only called once.

[0026] Compared with the prior art, the method for expanding the access volume of score query based on OpenTelemetry in the present invention has the following beneficial effects:

[0027] For the user login and score query requests sent by the client in the present invention, the load balancing device does not perform any processing on the requests, but directly passes them through to the server; for the IP query request, the IP query request is unpacked through the corresponding domain name certificate held by the load balancing device to obtain the IP address information. First, the login and score query requests and the IP address query request are divided into two links, and the login and score query requests are passed through the load balancing device to the server, enabling the functions of user login and score query to be executed preferentially and efficiently, better meeting the user's score query needs, and thus improving the efficiency of score query access in high-concurrency application scenarios. Second, by completely offloading complex computing tasks such as SSL decryption and protocol parsing of the traditional load balancer to the server, the load balancing device only undertakes the TCP layer transparent transmission function, and the complex computing is completed by the powerful processing ability of the server. This can not only further improve the efficiency of score query access, but also greatly reduce the data processing volume of the load balancing device, thereby enhancing the device stability of score query access in high-concurrency application scenarios. Finally, by unpacking the IP query request through the load balancing device to obtain the IP address information, it can effectively prevent the IP address from being tampered with, thereby improving the effectiveness and accuracy of IP address acquisition; at the same time, although the calculations related to the IP query request are executed on the load balancing device, since the IP query request only needs to be executed once (the score query can be executed multiple times), even in high-concurrency application scenarios, the data processing volume of the load balancing device can still be greatly reduced. Therefore, the same load balancing device can handle more user query requests and still obtain the user's real IP address, thereby enhancing the device stability and efficiency of score query access in high-concurrency application scenarios.

[0028] In the execution process of the login and score query requests and the IP address query request in the present invention, the full-link tracking of the IP address is realized through the TraceID generated by OpenTelemetry, which can ensure the originality and non-tamperability of the IP address, thereby improving the effectiveness and accuracy of IP address acquisition. At the same time, through the uniqueness of the TraceID, when an exception occurs, the specific IP address and user information (such as ID number) can be traced and located, thereby improving the traceability of score query access. Description of the Drawings

[0029] In order to make the objectives, technical solutions, and advantages of the invention clearer, the following will further describe the present invention in detail with reference to the accompanying drawings, where:

[0030] Figure 1 It is a schematic flowchart of a method for expanding the query access volume of grades based on OpenTelemetry, where the red line is the conventional line and is invalid in the present invention. Specific embodiments

[0031] In order to make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Usually, the components of the embodiments of the present invention described and illustrated in the accompanying drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed present invention, but merely represents selected embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts fall within the scope of protection of the present invention.

[0032] It should be noted that similar reference numerals and letters indicate similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In the description of the present invention, it should be noted that the orientation or positional relationship indicated by the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. is based on the orientation or positional relationship shown in the figures, or the orientation or positional relationship in which the product of the present invention is usually placed during use. It is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention. In addition, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance. In addition, terms such as "horizontal" and "vertical" do not mean that the components are required to be absolutely horizontal or hanging, but can be slightly inclined. For example, "horizontal" only means that its direction is more horizontal relative to "vertical", and does not mean that the structure must be completely horizontal, but can be slightly inclined. In the description of the present invention, it should also be noted that unless otherwise clearly specified and limited, the terms "set", "install", "connect", "couple" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium, and it can be the communication inside two elements. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific situations.

[0033] The following is a more detailed description through specific embodiments:

[0034] Embodiment:

[0035] This embodiment discloses a method for expanding the query access volume of grades based on OpenTelemetry.

[0036] As Figure 1 shown, the method for expanding the query access volume of grades based on OpenTelemetry includes:

[0037] S1: Obtain the login request sent by the user through the client;

[0038] S2: Transmit the login request through the load balancing device to the server through the login query link;

[0039] S3: Unpack the login request using the corresponding domain name certificate held by the server, verify the user's identity and generate a return packet; at the same time, generate TraceID1 for the login request through OpenTelemetry and add the corresponding TraceID1 value to the header information of the return packet; at the same time, inject the TraceID1 and the corresponding SpanID information into the user access log.

[0040] S4: The return packet is sequentially returned to the load balancer device and the login query link, and finally returned to the client; the client obtains TraceID1 from the return packet.

[0041] S5: After the user logs in successfully, send a score query request through the client; after the score query request is successful, asynchronously call an IP query request through the client and carry TraceID1 in the request header of the IP query request.

[0042] S6: When the IP query request carrying TraceID1 is transmitted to the load balancer device through the IP query link, unpack the IP query request using the corresponding domain name certificate held by the load balancer device, obtain the IP address information, and transmit it to the server.

[0043] S7: Receive and store the IP address information through the server.

[0044] In this embodiment, the server cluster can adopt a distributed stateless design combined with containerized deployment technology to dynamically allocate computing resources to process business logics such as login verification and score query. Compared with the functional coupling between the load balancer and the server in the traditional architecture, the server can give full play to the hardware advantages of multi-core CPUs, caches, etc., and realize pipeline operations for request processing. At the same time, the server can also implement the offloading processing of the TLS protocol stack through a dedicated hardware acceleration module (such as DPDK technology), and cooperate with a batch decryption algorithm to reduce the processing delay of a single request to the microsecond level, avoiding the performance jitter caused by software decryption in the traditional architecture and ensuring stable low latency in high-concurrency scenarios.

[0045] For the user login and score query requests sent by the client, the load balancing device does not process the requests at all, but directly forwards them transparently to the server; for the IP query request, the load balancing device unpacks the IP query request through the corresponding domain name certificate it holds to obtain the IP address information. First, the login and score query requests and the IP address query request are divided into two links, and the login and score query requests are transparently forwarded to the server through the load balancing device, enabling the functions of user login and score query to be executed preferentially and efficiently, better meeting the user's score query needs, and thus improving the efficiency of score query access in high-concurrency application scenarios. Second, by completely offloading complex computing tasks such as SSL decryption and protocol parsing of the traditional load balancer to the server, the load balancing device only undertakes the TCP layer transparent transmission function, and the complex calculations are completed by the powerful processing ability of the server. This can not only further improve the efficiency of score query access, but also greatly reduce the data processing volume of the load balancing device, thereby enhancing the device stability of score query access in high-concurrency application scenarios. Finally, by unpacking the IP query request through the load balancing device to obtain the IP address information, it can effectively prevent the IP address from being tampered with, thus improving the effectiveness and accuracy of IP address acquisition; at the same time, although the calculations related to the IP query request are executed on the load balancing device, since the IP query request only needs to be executed once (score query can be executed multiple times), the data processing volume of the load balancing device can still be greatly reduced even in high-concurrency application scenarios. Therefore, the same load balancing device can handle more user query requests and still obtain the user's real IP address, thereby enhancing the device stability and efficiency of score query access in high-concurrency application scenarios.

[0046] Specifically, usually each user login request and score query request will result in nearly 50 static resource and dynamic resource sessions. According to the conventional path of the prior art, these 50 sessions all need to go through complex calculations such as SSL decryption and protocol parsing of the load balancing device. When the user concurrent access volume reaches a certain value, the number of sessions surges, and the packet processing delay of the load balancing device increases exponentially, resulting in the user response time deteriorating from the millisecond level to the second level, and some requests are even discarded due to timeout. Therefore, the processing ability of the load balancing device becomes the bottleneck of system performance. However, in the present invention, the complex computing tasks of most sessions are completely offloaded to the server and completed by the powerful processing ability of the server; although the calculations related to the IP query request are still executed on the load balancing device, since each user login only generates one IP query request, the amount of calculations such as SSL decryption and protocol parsing executed on the load balancing device is greatly reduced, so the expansion effect on the user concurrent access volume is relatively obvious.

[0047] In the execution process of the login and score query requests and the IP address query request, the present invention realizes the full-link tracking of the IP address through the TraceID generated by OpenTelemetry, which can ensure the originality and immutability of the IP address, thereby improving the effectiveness and accuracy of IP address acquisition. At the same time, through the uniqueness of the TraceID, when an exception occurs, it is possible to trace and locate the specific IP address and user information (such as ID number), thereby improving the traceability of score query access.

[0048] In the specific implementation process, the load balancing device is provided with a login query port; the login request and the score query request are transmitted to the load balancing device through the login query port, and the load balancing device forwards the login request and the score query request to the server.

[0049] The load balancing device is provided with an IP query port; the IP query request is transmitted to the load balancing device through the IP query port, and the IP query request is unpacked by the corresponding domain name certificate held by the load balancing device.

[0050] By setting a login query port and an IP query port on the load balancing device, the present invention enables the login request, the score query request, and the IP query request to enter the load balancing device through different ports respectively, which can avoid misoperations of the load balancing device. Moreover, since the IP query request only needs to be executed once, it can greatly reduce the data processing volume of the load balancing device, thereby improving the device stability and efficiency of score query access.

[0051] In the specific implementation process, the corresponding user identity information (such as user ID number and user login password) is obtained by unpacking the login request by the server, and the user identity is verified by verifying the user identity information.

[0052] In the specific implementation process, the user identity information (such as user ID number) and the TraceID1 information injected by OpenTelemetry are appended to the user login log, that is, the association between the user identity information and the corresponding TraceID1 is established.

[0053] By establishing the association between the user identity information and the corresponding TraceID1, the present invention can realize querying and locating the user identity information through TraceID1; and can assist in realizing the subsequent query of the IP address.

[0054] The load balancing device transmits the unpacked IP address information and the IP query request carrying TraceID1 to the server together;

[0055] While the server receives and stores IP address information, OpenTelemetry generates TraceID2 for an IP query request carrying TraceID1.

[0056] Attach the IP address information, TraceID1 information, and TraceID2 information to the additional information of the IP request log, that is, establish the association between the IP address information and the corresponding TraceID1 and TraceID2.

[0057] When querying the access log of a specific user, obtain the TraceID1 information injected by OpenTelemetry in the user access log; query the IP request log containing TraceID1 from the additional information in all IP request logs according to the TraceID1 information; obtain the IP address information contained in the IP request log as the real IP address of the specific user.

[0058] In the process of executing the login and score query requests and the IP address query request of the present invention, the full-link tracking of the IP address is realized through the TraceID generated by OpenTelemetry, which can ensure the originality and immutability of the IP address, thereby improving the effectiveness and accuracy of IP address acquisition. At the same time, through the association between the user name (such as the ID number) and TraceID1 and the association between TraceID2 and TraceID1, when an exception occurs, the specific IP address and user information (such as the ID number) can be traced and located, thereby improving the traceability of score query access.

[0059] In the specific implementation process, after the user sends a score query request through the client: the score query request is transmitted through the load balancing device to the server through the login query link; the server unpacks the score query request, verifies the user identity, and obtains the user score information and generates a return packet after the identity verification is passed; at the same time, OpenTelemetry generates a corresponding TraceID for the score query request and adds the corresponding TraceID value to the header information of the return packet; the return packet is returned to the load balancing device and the login query link in turn and finally returned to the client; the client obtains the user score information from the return packet; when the client obtains the user score information, it indicates that the score query request is successful.

[0060] After the user logs in successfully, the client sends multiple score query requests, but only the first score query request can asynchronously call the IP query request through the client after it is successful, that is, the IP query request is only called once.

[0061] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit them. Those of ordinary skill in the art should understand that any modifications or equivalent replacements made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions shall be covered by the scope of the claims of the present invention.

Claims

1. A method for expanding the query volume of academic achievements based on OpenTelemetry, characterized in that, Including: S1: Obtain the login request sent by the user through the client; S2: Transmit the login request through the load balancing device to the server end via the login query link; S3: Unpack the login request with the corresponding domain name certificate held by the server end, verify the user identity and generate a return packet; at the same time, generate TraceID1 for the login request through OpenTelemetry, and add the corresponding TraceID1 value to the header information of the return packet; at the same time, inject the TraceID1 and the corresponding SpanID information into the user access log; S4: The return packet is sequentially returned to the load balancing device and the login query link, and finally returned to the client; the client obtains TraceID1 from the return packet; S5: After the user logs in successfully, send a score query request through the client; After the score query request is successful, asynchronously call the IP query request through the client, and carry TraceID1 in the request header of the IP query request; S6: When the IP query request carrying TraceID1 is transmitted to the load balancing device through the IP query link, unpack the IP query request with the corresponding domain name certificate held by the load balancing device, obtain the IP address information, and transmit it to the server end; S7: Receive and store the IP address information through the server end.

2. The method for expanding the query access volume of grades based on OpenTelemetry according to claim 1, wherein: In step S2, the load balancing device is provided with a login query port; the login request and the score query request are transmitted to the load balancing device through the login query port, and the login request and the score query request are transmitted to the server end through the load balancing device.

3. The method for expanding the query volume of grades based on OpenTelemetry according to claim 1, wherein: In step S3, obtain the corresponding user identity information by unpacking the login request through the server end, and verify the user identity by verifying the user identity information.

4. The method for expanding the query volume of examination results based on OpenTelemetry according to claim 3, wherein: In step S3, attach the user identity information and the TraceID1 information injected by OpenTelemetry to the user login log.

5. The method for expanding the query access volume of grades based on OpenTelemetry according to claim 1, characterized in that: In step S6, the load balancing device is provided with an IP query port; The IP query request is transmitted to the load balancing device through the IP query port, and the IP query request is unpacked with the corresponding domain name certificate held by the load balancing device.

6. The method for expanding the access volume of score query based on OpenTelemetry according to claim 3, characterized in that: In step S6, the load balancing device transmits the unpacked IP address information and the IP query request carrying TraceID1 to the server end together; In step S7, while receiving and storing the IP address information through the server end, generate TraceID2 for the IP query request carrying TraceID1 through OpenTelemetry.

7. The method for expanding the query access volume of grades based on OpenTelemetry according to claim 6, characterized in that: Attach the IP address information, TraceID1 information and TraceID2 information to the additional information of the IP request log.

8. The method for expanding the query access volume of grades based on OpenTelemetry according to claim 7, characterized in that: When querying the access logs of a specific user, obtain the TraceID1 information injected by OpenTelemetry in the user access logs; query the IP request logs containing TraceID1 in the additional information of all IP request logs according to the TraceID1 information; obtain the IP address information contained in the IP request logs as the real IP address of the specific user.

9. The method for expanding the query access volume of grades based on OpenTelemetry according to claim 1, wherein: In step S5, after the user sends a score query request through the client: pass the score query request through the load balancing device to the server through the login query link; unpack the score query request by the server, verify the user's identity, and obtain the user's score information and generate a return packet after successful authentication; at the same time, generate a corresponding TraceID for the score query request through OpenTelemetry and add the corresponding TraceID value to the header information of the return packet; The return packet is returned to the load balancing device and the login query link in sequence and finally returned to the client; obtain the user's score information from the return packet through the client; when the client obtains the user's score information, it indicates that the score query request is successful.

10. The method for expanding the query access volume of grades based on OpenTelemetry according to claim 1, wherein: After the user logs in successfully, the client sends multiple score query requests, but only the first score query request can asynchronously call the IP query request through the client after it is successful, that is, the IP query request is only called once.

Images