Tlcp encryption communication tracking method and system based on distributed micro services

Abstract

The application discloses a TLCP encryption communication tracking method and system based on distributed micro services, and relates to the technical field of encryption communication tracking.The TLCP encryption communication tracking method based on distributed micro services comprises the following steps: TLCP handshake request receiving and checking, TLCP handshake request response and encryption communication fault diagnosis.After the server receives an initialization TLCP handshake request, the application checks the carried tracking identifier extension, then the server generates and returns initialization response information containing the server identifier extension, finally, if the TLCP handshake is successfully completed, the tracking identifier of the opposite end is recorded and stored to the log, and the encryption communication fault diagnosis and optimization are performed, otherwise, an alarm notification is sent to the preset personnel, so that the fault judgment accuracy in the TLCP encryption communication tracking is improved, and the problem of low fault judgment accuracy in the TLCP encryption communication tracking caused by large data in the prior art is solved.

Description

Technical Field

[0001] This invention relates to the field of encrypted communication tracing technology, and in particular to a TLCP encrypted communication tracing method and system based on distributed microservices. Background Technology

[0002] Microservice architecture is a way to break down an application into a series of small, independent services, each of which can be developed, deployed, scaled, and managed independently. In a distributed system, these services communicate over a network. Encrypted communication in a microservice architecture typically uses Transport Layer Cryptography (TLCP) to ensure data security and prevent theft or tampering. In a system composed of multiple microservices, a request usually needs to be passed and processed among multiple services before a result is returned. During this process, communication between each service is an independent network request. A failure in any service will affect the service that initially initiated the request. Therefore, quickly locating and identifying which service is experiencing a problem is crucial for troubleshooting.

[0003] To enable link tracing using the Transport Layer Computing (TLCP) protocol, TLCP needs to be extended. Generating a unique trace identifier for each request is a common practice. This trace identifier allows developers to easily view the complete lifecycle of a request, understanding each service node it traverses and potential problem areas. This approach not only helps diagnose potential performance bottlenecks but also effectively supports bug debugging and request path tracing.

[0004] In existing technologies, performance evaluation and risk control usually rely on load balancing and traffic management. Weighted Round Robin (WRR) is a common algorithm in load balancing. Its basic idea is to assign a weight to each service instance, and traffic is distributed according to these weights. Instances with larger weights will handle more traffic, thereby achieving real-time optimization of system load and performance.

[0005] For example, Chinese patent application CN119996208A discloses a Kubernetes elastic scaling method and apparatus based on traffic topology, which includes: obtaining traffic topology elastic rule information and interface request volume data configured for each microservice; querying and calculating the service ratio of the interface request volume data in the link tracing based on the traffic topology elastic rule information and interface request volume data; calculating the scaling ratio based on the service ratio, and performing scaling processing on the corresponding microservice.

[0006] For example, Chinese patent application CN112738044B discloses a multi-protocol link path tracing method and system, which includes: starting from the remote login connection in the destination host and ending with the remote login connection in the source host, tracing back the remote login connection link between the destination host and the source host according to the process of the remote login connection; and splicing the remote login connection links to obtain the complete connection link between the destination host and the source host.

[0007] However, in the process of implementing the inventive technical solution in the embodiments of this application, it was found that the above-mentioned technology has at least the following technical problems:

[0008] In existing technologies, microservice architectures generate a large amount of tracing data with each request. Under high concurrency, this data volume multiplies. When the service load is too heavy, the encryption and decryption process can cause significant performance bottlenecks, leading to timeouts or service unavailability. The computational overhead of encryption protocols affects communication latency, and the use of complex encryption algorithms is unavoidable to ensure communication security, which can cause performance issues, especially under high load.

[0009] Performance bottlenecks and timeouts are often not easily detected directly in encrypted communication, as they are closely related to network bandwidth and service load, while the encryption protocol itself is transparent. Because encryption protocols have a certain impact on performance, troubleshooting may require distributed tracing and performance monitoring tools to distinguish between network latency and encryption latency, increasing the complexity of fault location. Request response times and timeouts may not immediately indicate that they are caused by encrypted communication, potentially leading to misjudgments of timeout faults. Furthermore, the large volume of data can result in low accuracy of fault identification in TLCP encrypted communication tracing. Summary of the Invention

[0010] To address the technical problem of low fault diagnosis accuracy in TLCP encrypted communication tracing due to massive data volumes in existing technologies, this invention provides a TLCP encrypted communication tracing method and system based on distributed microservices. The technical solution is as follows:

[0011] On the one hand, a TLCP encrypted communication tracing method based on distributed microservices is provided. The method includes: S1, after the server receives the initial TLCP handshake request from the client, it checks the tracing identifier extension carried in the initial TLCP handshake request. The initial TLCP handshake request is used to start encrypted communication and perform identity authentication; S2, the server generates and returns initialization response information containing the server identifier extension. The initialization response information is used to ensure that the client receives the information generated by the server; S3, if the TLCP handshake is successfully completed, after the interaction between the server and the client, the obtained peer's tracing identifier is recorded and stored in the log. Based on the monitoring data of each service instance collected, encrypted communication fault diagnosis and communication process optimization are performed. Otherwise, an alarm notification is sent to the preset personnel.

[0012] On the other hand, a TLCP encrypted communication tracing system based on distributed microservices is provided, applying methods such as the TLCP encrypted communication tracing method based on distributed microservices, including: a TLCP handshake request receiving and checking module, a TLCP handshake request response module, and an encrypted communication fault diagnosis module; wherein, the TLCP handshake request receiving and checking module is used to check the trace identifier extension carried in the initial TLCP handshake request after the server receives the initial TLCP handshake request from the client; the TLCP handshake request response module is used to generate and return initialization response information containing the server's identifier extension; the encrypted communication fault diagnosis module is used to store the obtained trace identifier of the other end in the log after the interaction between the server and the client if the TLCP handshake is successfully completed, and to perform encrypted communication fault diagnosis and communication process optimization based on the collected monitoring data of each service instance; otherwise, it sends an alarm notification to the preset personnel.

[0013] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following:

[0014] 1. First, after receiving the initial TLCP handshake request from the client, the server checks the trace identifier extension carried in it to verify the legality and validity of the client's request and establish a traceable chain for subsequent tracing and communication. Then, the server generates and returns initialization response information containing the server's identifier extension, thereby confirming that the connection with the server has been successfully established and that the communication is secure, providing identification information for subsequent encrypted communication tracing. Finally, if the TLCP handshake is successfully completed, after the interaction between the server and the client, the trace identifier of the other end is recorded and stored in the log, and encrypted communication fault diagnosis and optimization are performed. Otherwise, an alarm notification is sent to the preset personnel to promptly identify bottlenecks in the communication process and make adjustments and optimizations to improve the stability and performance of encrypted communication.

[0015] 2. By designing the extension header structure in the protocol extension according to the Type-Length-Value rule, which includes a type field, a length field, and a content field, the protocol parser can explicitly identify and process the extension information. By adding a tracking identifier and a server identifier at the protocol level, the traceability of TLCP encrypted communication between distributed microservices is achieved. The tracking identifier includes a millisecond-level timestamp, an encrypted random number, and a node identifier hash value. This allows communication events to be sorted and time ranges to be filtered based on timestamps during subsequent encrypted communication tracing, thereby ensuring the accuracy and reliability of communication tracing. Finally, the input IP address is hashed using the SM3 hash algorithm, which is executed with hardware acceleration, to obtain the server identifier. This standardizes the data processing and improves the processing efficiency of the server identifier.

[0016] 3. By collecting monitoring data from each service instance, a risk assessment of the tracing link is conducted to determine whether tracing link risk control is necessary to ensure link stability. This helps to identify potential problems early and avoid communication link interruptions due to performance issues. If no tracing link risk control is performed, encrypted communication fault diagnosis is directly performed according to the initial transmission process. Otherwise, after tracing link risk control, encrypted communication fault diagnosis is performed according to the initial transmission process. This avoids encrypted communication failures or performance degradation caused by link instability during communication. Finally, based on the results of the encrypted communication fault diagnosis, it is determined whether to optimize the effectiveness of the encrypted communication fault diagnosis. If no optimization is performed, encrypted communication fault diagnosis is performed according to the initial transmission process to check for potential problems in the encryption process. Otherwise, encrypted communication fault diagnosis is performed according to the optimized transmission process, thereby providing stronger fault diagnosis capabilities and improving the stability of the TLCP encrypted communication link. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating the tracking identifier recording provided in this application embodiment;

[0019] Figure 2 A flowchart illustrating the TLCP encrypted communication tracing method based on distributed microservices provided in this application embodiment;

[0020] Figure 3A flowchart illustrating the establishment of a TLCP connection as provided in the embodiments of this application;

[0021] Figure 4 An interface diagram of the communication list content area in the communication tracing options of the microservice tracing system provided in this application embodiment;

[0022] Figure 5 An interface diagram of the communication details area in the communication tracing options of the microservice tracing system provided in this application embodiment;

[0023] Figure 6 A flowchart for diagnosing encrypted communication faults provided in an embodiment of this application;

[0024] Figure 7 A screenshot of the alarm list content area in the alarm center option of the microservice tracing system provided in this embodiment of the application;

[0025] Figure 8 An interface diagram of the warning details section in the alarm center option of the microservice tracing system provided in this application embodiment;

[0026] Figure 9 This is a schematic diagram of the structure of the TLCP encrypted communication tracing system based on distributed microservices provided in an embodiment of this application. Detailed Implementation

[0027] This application provides a TLCP encrypted communication tracing method and system based on distributed microservices, which solves the problem of low fault judgment accuracy in TLCP encrypted communication tracing caused by the large amount of data in the prior art. After receiving the initial TLCP handshake request from the client, the server checks the trace identifier extension carried in it, and then the server generates and returns initialization response information containing the server identifier extension. Finally, if the TLCP handshake is successfully completed, the trace identifier of the other end is recorded and stored in the log after the interaction between the server and the client, and encrypted communication fault diagnosis and optimization are performed. Otherwise, an alarm notification is sent to the preset personnel, thereby improving the accuracy of fault judgment in TLCP encrypted communication tracing.

[0028] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0029] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0030] In this embodiment of the invention, "of", "corresponding (relevant)" and "corresponding" can sometimes be used interchangeably. It should be noted that when the distinction is not emphasized, their intended meanings are consistent. Sometimes, a subscript such as W1 may be written in a non-subscript form such as W1. When the distinction is not emphasized, their intended meanings are consistent.

[0031] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0032] like Figure 1 The flowchart shown illustrates the process of recording trace identifiers. The specific steps are as follows: The client generates a trace_id (trace identifier) ​​and includes it in the ClientHello message; the server parses the trace_id extension and generates a service_id (server identifier); the server records...<trace_id,service_id> After mapping, a ServerHello message (server greeting message) containing the service_id extension is returned to the client; the client records...<trace_id,service_id> Mapping relationship.

[0033] This invention provides a TLCP encrypted communication tracing method based on distributed microservices. For example... Figure 2 The flowchart shown is for a TLCP encrypted communication tracing method based on distributed microservices. The processing flow of this method may include the following steps:

[0034] S1, after receiving the initial TLCP handshake request from the client, the server checks the trace identifier extension carried in the initial TLCP handshake request (referring to ClientHello) to ensure that the client's initialization request belongs to a valid trace chain and that the processing can continue to be traced on the server. The initial TLCP handshake request is used to initiate encrypted communication and perform authentication. In the ClientHello phase, a trace_id is generated and injected into the extension, and then logs are output to maintain full compatibility with the standard TLCP ClientHello. The Transport Load and Communication Path (TLCP) protocol is a protocol for encrypted communication, primarily used to ensure the security of data transmission, potentially involving handshakes, authentication, encryption, and data integrity verification. In the TLCP protocol, the handshake request is an initialization step, the starting point for establishing a connection between the two communicating parties (client and server). The handshake request typically contains authentication information, encryption parameters, and other content used to initiate encrypted communication. By receiving and checking the initial TLCP handshake request, the legitimacy and validity of the client's request are verified, and a traceable chain is established for subsequent tracing and communication processes, ensuring that the request is not lost or the connection is broken, and that all subsequent processing can be linked to this request.

[0035] S2 involves the server generating and returning an initialization response (ServerHello) containing a server identifier extension. This initialization response ensures the client can receive the information generated by the server. During the ServerHello phase, a server_id extension is generated and injected, then logged, maintaining full compatibility with standard TLCP ServerHello. By generating and returning the initialization response, a two-way communication verification is established between the client and server. The client can confirm that the connection with the server has been successfully established and that communication is secure. The server identifier extension also provides identification information for subsequent tracing, helping to distinguish interactions between different service instances.

[0036] In addition, such as Figure 3The flowchart shown illustrates the TLCP connection establishment process between the client and server. The specific steps are as follows: a) The client sends a ClientHello message to the server, displaying the client's supported cryptographic algorithms; b) The server returns a ServerHello message to the client, selecting the appropriate cryptographic algorithm; c) The server returns a ServerCertificate message to the client, representing the server's site certificate, which the client then authenticates; d) The server returns a ServerKeyExchange message to the client, sending key exchange parameters according to the key exchange algorithm; e) The server returns a CertificateRequest message to the client, requesting the client to submit its certificate for authentication; f) The server... The server returns a ServerHelloDone message to the client, indicating that the server has completed this phase of the operation; g) The client sends a ClientCertificate message to the server, which is the client's digital certificate; h) The client sends a ClientKeyExchange message to the server, which is the client's key exchange data; i) The client sends a ClientCertificateVerify message to the server, which is the client's signature result; j) The client sends a ChangeCipherSpec message and a Finish message to the server, indicating that the client has completed this phase of the handshake operation; k) The server returns a ChangeCipherSpec message and a Finish message to the client, completing the handshake process.

[0037] S3, if the TLCP handshake is successfully completed, after the interaction between the server and the client, the obtained tracking identifier of the other end is recorded and stored in the log. Through collaboration with the transport layer and application layer, monitoring data of each service instance is collected. Based on the collected monitoring data of each service instance, encrypted communication fault diagnosis and communication process optimization are performed. Otherwise, an alarm notification is sent to the preset personnel. By recording the tracking identifier, it is helpful for subsequent problem localization and traffic analysis. By collecting monitoring data of each service instance, the server can identify bottlenecks and faults in the communication process in a timely manner. Through monitoring data analysis, the cause of communication faults can be identified and adjusted and optimized to improve the stability and performance of encrypted communication. If certain conditions are not met (such as handshake failure), an alarm mechanism will be triggered to promptly notify the preset personnel for intervention.

[0038] In this embodiment, data storage for tracing requires a high-performance database (such as ClickHouse), significantly increasing storage costs and resource consumption. Since trace_id and service_id may be lost or tampered with during transmission, it becomes impossible to accurately trace the request path during fault diagnosis, especially in multi-layered proxies or asynchronous requests. It's impossible to determine when and where encryption failures occur, or to accurately track the request lifecycle, making it more difficult to locate problems when encrypted communication is interrupted, particularly in cases of failed encryption handshakes or key negotiation errors. When the service load is too heavy, the encryption and decryption process can cause significant performance bottlenecks, leading to timeouts or service unavailability. The computational overhead of encryption protocols affects communication latency, and the use of complex encryption algorithms is unavoidable to ensure communication security, which can cause performance issues, especially under high load.

[0039] This application ensures secure communication, rapid fault diagnosis and optimization between each service instance in a distributed system through effective tracking identification and encrypted communication fault diagnosis mechanisms, ensuring the stability and efficiency of encrypted communication, thereby improving the accuracy of fault judgment in TLCP encrypted communication tracing.

[0040] like Figure 4 The image shown is an interface diagram of the communication list content area in the communication tracing options of the microservice tracing system, as follows: Figure 5 The interface diagram of the communication details area in the communication tracing options of the microservice tracing system shown here includes: filtering by filter criteria to display a communication list; when the user clicks on a row in the communication list, it expands to display detailed information about that communication; the filter criteria include communication protocol, time range, source service, target service, communication direction, status filtering, keywords, and Trace ID; the communication list includes timestamp, communication service, direction, communication status, and communication duration; the detailed communication information includes the start time, end time, operation status, and alarm events related to each operation during the communication process.

[0041] To further clarify, the tracking identifier extension and the server identifier extension are protocol extensions, indicating that the tracking identifier and the server identifier are not implemented by modifying application logic or adding additional network layers, but are directly extended as part of the TLCP protocol itself, transmitted along with TLCP encrypted communication messages, and are part of the TLCP protocol specification.

[0042] The extension header structure in the protocol extension is designed according to the Type-Length-Value rule, which includes a type field, a length field, and a content field, enabling the protocol parser to explicitly identify and process the extension information.

[0043] The type field is used to identify the data type contained in the extended header, representing the trace identifier (trace_id) and the service identifier (service_id); in this application, the type field is a fixed 2-byte value 0xfefc (trace_id / service_id). The type field clearly distinguishes the trace identifier and the service identifier, avoiding confusion.

[0044] The length field indicates the length of the content field in the extension header. In this application, the length field is a fixed value of 2 bytes, 0x0010.

[0045] The content field represents the tracking identifier and the server identifier stored in big-endian encoding. In this application, the content field is 16 bytes of big-endian encoded data. Big-endian (also known as network byte order) is a storage order of multi-byte data in network transmission. In this order, the most significant byte is stored at the lowest address.

[0046] In this embodiment, by adding a tracking identifier and a server identifier at the protocol level, the traceability of TLCP encrypted communication between distributed microservices is achieved; the tracking information is transmitted together with the business data through the TLCP protocol, sharing an encrypted channel, which improves the transmission efficiency and reliability of the tracking information.

[0047] Furthermore, the tracking identifier includes a millisecond-level timestamp in the first preset byte, an encrypted random number in the second preset byte, and a node identifier hash value in the third preset byte; the tracking identifier is a randomly generated 16-byte hexadecimal string.

[0048] The millisecond-level timestamp of the first preset byte indicates the time when the tracking identifier was generated; in this application, the first preset byte is 8 bytes. Providing time-dimensional information for the tracking identifier facilitates the sorting and filtering of communication events based on timestamps during subsequent encrypted communication tracing. For example, communication records can be filtered based on time ranges, or communication events can be traced back in chronological order, ensuring the accuracy of timing information during communication.

[0049] The encrypted random number in the second preset byte is used to enhance the randomness and security of the tracking identifier; the second preset byte in this application is 4 bytes. Due to the unpredictability of the random number, the tracking identifier is difficult to forge or tamper with, thereby ensuring the accuracy and reliability of communication tracking, preventing malicious attackers from interfering with communication tracking by forging the tracking identifier, and thus enhancing the randomness and security of the tracking identifier.

[0050] The node identifier hash value of the third preset byte is used to identify the node that generated the tracking identifier; in this application, the third preset byte is 4 bytes. The node identifier hash value can accurately distinguish the tracking identifiers generated by different nodes, which facilitates the tracking and analysis of the communication path and determines the initiating node and the nodes traversed by the communication.

[0051] The server identifier is generated as follows: The input IP address is hashed using the SM3 hash algorithm, which is executed via hardware acceleration. The hash value is then converted into a hexadecimal string, and the first four preset bytes of this hexadecimal string are recorded as the server identifier. In this application, the fourth preset byte is 16 bytes. The server identifier refers to performing an SM3 digest on the service IP, converting the digest result into a hexadecimal string, and then taking the first 16 bytes. The SM3 hash algorithm achieves standardized data processing. Its collision resistance ensures a very high probability that different IP addresses will generate different hash values, allowing the server identifier to uniquely identify a server. Furthermore, shortening the length of the server identifier reduces bandwidth consumption and improves processing efficiency, enabling rapid matching and identification.

[0052] The SM3 hash algorithm is executed with accelerated hardware. The hardware is selected by designated personnel, such as by choosing a dedicated encryption hardware unit. This optimizes the SM3 algorithm's computation process and typically accelerates the algorithm's execution through parallel computing, large-scale data caching, and pipelined processing.

[0053] In this embodiment, the randomness and security of the tracking identifier and the server identifier are enhanced through the above steps, preventing the identifier from being forged or tampered with, and ensuring the security and reliability of communication under the distributed microservice architecture; it can also improve the speed of hash operation and improve the overall performance and response speed of encrypted communication.

[0054] like Figure 6 The flowchart for encrypted communication fault diagnosis shown below has the following specific logic: For each service instance, a tracing link risk assessment is performed. If the standard deviation of the tracing link risk coefficient is greater than the preset standard deviation of the tracing link risk coefficient obtained from the preset database, then encrypted communication fault diagnosis is performed according to the initial transmission process after tracing link risk control; otherwise, encrypted communication fault diagnosis is performed directly according to the initial transmission process. After an encrypted communication fault occurs, the fault diagnosis accuracy coefficient is obtained. If the fault diagnosis accuracy coefficient is not greater than the preset fault diagnosis accuracy coefficient obtained from the preset database, then the effectiveness of encrypted communication fault diagnosis is optimized, and encrypted communication fault diagnosis is performed according to the optimized transmission process; otherwise, encrypted communication fault diagnosis is performed according to the initial transmission process.

[0055] Furthermore, this application also includes the following steps:

[0056] Based on the monitoring data collected from each service instance, a tracking link risk assessment is performed to determine whether tracking link risk control should be implemented to ensure link stability. The tracking link risk assessment is used to identify performance bottlenecks in transport layer encrypted communication. The monitoring data is used to monitor the health status of each service instance, including encryption duration, load, and status update duration. By monitoring the data, potential problems can be detected in advance, avoiding communication link interruptions due to performance issues and improving the stability of TLCP encrypted communication.

[0057] If link risk control is not performed, encrypted communication fault diagnosis is performed directly according to the initial transmission process; otherwise, encrypted communication fault diagnosis is performed according to the initial transmission process after link risk control is performed. By tracking link risk control, the link can be proactively optimized to avoid encrypted communication failure or performance degradation caused by link instability during communication, thereby ensuring the stability of the TLCP encrypted communication link.

[0058] Based on the results of encrypted communication fault diagnosis, it is determined whether to optimize the effectiveness of encrypted communication fault diagnosis. If optimization is not performed, encrypted communication fault diagnosis is performed according to the initial transmission process to check for potential problems in the encryption process; otherwise, encrypted communication fault diagnosis is performed according to the optimized transmission process. By optimizing the effectiveness of encrypted communication fault diagnosis, the efficiency of encrypted communication fault investigation can be improved, the response time when faults occur can be reduced, the diagnosis of encrypted communication can be made more accurate, and it can help to solve problems in a timely manner, ensuring the reliability and performance of encrypted communication.

[0059] In this embodiment, by performing risk assessment, control, fault diagnosis, and optimization on the TLCP encrypted communication trace links in the distributed system, the stability and security of encrypted communication can be effectively ensured, stronger fault diagnosis capabilities can be provided, communication latency can be reduced, and data transmission efficiency can be improved. Furthermore, the transparency of TLCP encrypted communication fault tracing is enhanced, providing better monitoring and troubleshooting support for designated personnel.

[0060] Furthermore, a risk assessment of the tracing link is conducted based on the collected monitoring data of each service instance. The specific method is as follows:

[0061] The encryption duration of each service instance is compared with the preset encryption duration obtained from the preset database to obtain an encryption duration comparison coefficient, i.e. In the formula, C 1.n C represents the encryption duration of the nth service instance. 1.0This indicates the preset encryption duration; the encryption duration represents the length of time the service instance performs the encryption operation, obtained by offsetting the recorded timestamps of the encryption operation's end and start. In this application, the comparison processing refers to a ratio operation, and the offset processing refers to a difference operation. Encryption operations may increase CPU load; the longer the encryption duration, the higher the load may be. A longer encryption duration may affect service availability, leading to an increase in the state update time of the service instance. The encryption duration comparison coefficient reflects whether a performance bottleneck exists in the encryption operation.

[0062] The load of each service instance is compared with a preset load obtained from a preset database to obtain a load comparison coefficient. In the formula, C 2.n C represents the load of the nth service instance. 2.0 This represents the preset load. The load is obtained by weighting and coupling the CPU utilization, memory utilization, disk utilization, and bandwidth utilization of each service instance after removing the unit. Performance monitoring tools (such as Prometheus, Grafana, and New Relic) are used to obtain the CPU utilization, memory utilization, disk utilization, and bandwidth utilization of the service instances. The weighting and coupling here refers to assigning a weight to each resource through linear weighting; the weighting coefficients are set by preset personnel. Higher load may slow down the state update process of service instances. The load comparison coefficient reflects the current resource consumption of the service instances.

[0063] The status update duration of each service instance is compared with the preset status update duration obtained from the preset database to obtain a status update duration comparison coefficient. In the formula, C 3.n C represents the state update duration of the nth service instance. 3.0 This indicates the preset state update duration; the state update duration represents the time spent by a recorded service instance when its state changes. The state update duration comparison coefficient reflects the latency of the service instance when performing a state update.

[0064] A tracing link risk balancing factor is introduced to perform weighted coupling processing on the encryption duration comparison coefficient, load comparison coefficient, and state update duration comparison coefficient to obtain the tracing link risk coefficient, thereby quantifying the performance bottleneck in transport layer encrypted communication.

[0065] The specific constraint expression for the tracking link risk coefficient is as follows:

[0066] ;

[0067] In the formula, i represents the type number of the monitoring data for each service instance, i=1 represents the number corresponding to the encryption duration, i=2 represents the number corresponding to the load, i=3 represents the number corresponding to the status update duration, n represents the service instance number, n=1, 2, ..., N, N represents the total number of service instances, C i.n C represents the i-th type of monitoring data corresponding to the n-th service instance. i.0 R1 represents the preset value of the i-th type of monitoring data, R2 represents the risk balance factor of the first tracking link, R3 represents the risk balance factor of the second tracking link, and R3 represents the risk balance factor of the third tracking link.

[0068] It should be added that the tracing link risk balancing factor is obtained from a preset database and set by preset personnel. Specifically, it includes a first tracing link risk balancing factor, a second tracing link risk balancing factor, and a third tracing link risk balancing factor, which represent the degree of influence of the monitoring data of each service instance collected on the tracing link risk coefficient. The sum of the three is 1. For example, the encryption duration and the first tracing link risk balancing factor form an encryption duration balancing mapping set. The real-time encryption duration is input into the corresponding encryption duration balancing mapping set to obtain the first tracing link risk balancing factor. The first tracing link risk balancing factor represents the degree of influence of encryption duration on the tracing link risk coefficient; the second tracing link risk balancing factor represents the degree of influence of load on the tracing link risk coefficient; and the third tracing link risk balancing factor represents the degree of influence of state update duration on the tracing link risk coefficient.

[0069] In this embodiment, by evaluating the encryption duration, load, and status update duration of service instances, performance bottlenecks can be identified and adjusted in advance, ensuring the stability of the encrypted communication link, effectively warning of potential communication failures, and thus taking timely measures to prevent service interruption or performance degradation.

[0070] like Figure 7 The image shown is an interface screenshot of the alarm list content area in the alarm center option of the microservice tracing system, as follows: Figure 8 The screenshot shown illustrates the interface of the warning details section in the alarm center option of the microservice tracing system. Specifically, it includes: filtering by criteria to display an alarm list; when a user clicks on a row in the alarm list, the warning details expand to show the details; the filtering criteria include communication protocol, time range, processing status, warning type, source / target service, sequential filtering, and keywords; the alarm list includes alarm ID, severity, processing status, triggering event, warning type, source / target, summary information, and action (expand to view details); the warning details include alarm ID, severity, processing status, triggering event, warning type, source, detailed description, and associated events, and the alarm is marked as processed / false alarm with a processing note.

[0071] Further, determine whether to implement risk control measures for the tracking link. The specific process is as follows:

[0072] The standard deviation of the tracing link risk coefficient reflects the dispersion of the tracing link risk coefficient of each service instance. The larger the value, the greater the risk difference between service instances. This provides an objective basis for subsequent judgment on whether risk control is needed.

[0073] A1. If the average tracing link risk coefficient of the service instance is greater than the preset tracing link risk coefficient obtained from the preset database, then execute A2; otherwise, directly perform encrypted communication fault diagnosis according to the initial transmission process. The average tracing link risk coefficient represents the average value of the tracing link risk coefficient of all service instances. The preset tracing link risk coefficient and the preset standard deviation of the tracing link risk coefficient are set by preset personnel.

[0074] A2. If the standard deviation of the tracing link risk coefficient is greater than the preset standard deviation of the tracing link risk coefficient obtained from the preset database, then tracing link risk control is performed; otherwise, encrypted communication fault diagnosis is directly performed according to the initial transmission process. Tracing link risk control means dynamically adjusting the load balancing strategy of each service instance based on traffic priority. Traffic priority means mapping the tracing link risk coefficient of each service instance and the preset importance score obtained from the preset database into the traffic priority mapping set. The traffic priority mapping set represents the set of mapping relationships between the tracing link risk coefficient, preset importance score, and traffic priority of each service instance. The preset importance score reflects the relative importance of each service instance and is set by preset personnel. By determining traffic priority, traffic allocation becomes more reasonable, taking into account both the current risk status of the service instances and their importance. It prioritizes important and lower-risk service instances to receive traffic, improving the overall service quality and reliability of the system, balancing the performance of each service instance, optimizing load balancing, and preventing individual service instances from affecting the overall health of the tracing link.

[0075] As a further solution, risk control of the tracking link is implemented as follows: If the total load of all service instances is not greater than the preset total load obtained from the preset database, the traffic priorities are sorted in descending order to obtain a traffic priority sequence, and encrypted communication is performed on the service instances according to the order of the traffic priority sequence; otherwise, weighted round-robin is used to allocate traffic to each service instance according to the traffic priority and corresponding load of each service instance; the preset total load is set by preset personnel.

[0076] When using weighted round-robin to distribute traffic to each service instance, traffic to the service instances is also limited. This can be achieved in the following ways: Rate limiting: Limit the rate to prevent lower-priority service instances from consuming more resources; Delay: Delay the requests until the load is at its lowest; Deny service: Temporarily refuse to process the lowest-priority traffic to ensure that the highest-priority service instances are not affected.

[0077] In this embodiment, by combining the tracking link risk coefficient and load conditions, the weight of service instances can be dynamically adjusted to achieve more refined traffic scheduling and load balancing. Especially when the load is high, restricting service instances with lower traffic priority and dynamically adjusting the load balancing strategy can ensure that service instances with higher traffic priority are processed first. This is beneficial for optimizing the stability of encrypted communication fault diagnosis and the efficiency of resource utilization, while providing a flexible traffic management strategy.

[0078] Furthermore, based on the results of encrypted communication fault diagnosis, it is determined whether to optimize the effectiveness of encrypted communication fault diagnosis. The specific process is as follows:

[0079] After an encrypted communication failure occurs, the fault diagnosis accuracy coefficient is obtained. The fault diagnosis accuracy coefficient represents the value obtained by comparing the result of the fault diagnosis obtained through the distributed tracing system with the result of the fault location obtained by manual or automated tools. It represents the accuracy rate of correctly locating and determining the fault type and location, and reflects the accuracy of the fault diagnosis process.

[0080] If the fault diagnosis accuracy coefficient is not greater than the preset fault diagnosis accuracy coefficient obtained from the preset database, then the effectiveness of encrypted communication fault diagnosis is optimized; otherwise, encrypted communication fault diagnosis is performed according to the initial transmission process. The preset fault diagnosis accuracy coefficient is set by preset personnel. Accurate fault diagnosis can more quickly locate and resolve problems in encrypted communication, reduce the impact of faults on the normal operation of encrypted communication fault diagnosis, and improve the reliability and stability of encrypted communication fault diagnosis. At the same time, optimizing the fault diagnosis process also helps to improve the overall performance of encrypted communication fault diagnosis and avoid repeated diagnosis and misjudgment caused by inaccurate fault diagnosis. Continuing to perform fault diagnosis according to the initial transmission process can avoid unnecessary optimization operations.

[0081] In this embodiment, by accurately determining whether fault diagnosis and optimization are needed, faults in the encrypted communication process can be detected and resolved in a timely manner, reducing the risk of communication interruption and data loss, thereby improving the reliability of TLCP encrypted communication and ensuring the secure and stable transmission of data.

[0082] Furthermore, the specific process for optimizing the effectiveness of encrypted communication fault diagnosis is as follows:

[0083] During the TLCP handshake phase, the server records the mapping relationship between the tracing identifier and the server identifier. By establishing the association between the tracing identifier and the server instance, a foundation is provided for tracing the communication process in the entire distributed tracing system. This enables the rapid location of the specific server involved in the communication, facilitating troubleshooting and performance analysis.

[0084] If a trace identifier exhibits an abnormal state, a new trace identifier is generated on the server side. This new trace identifier is then used in subsequent encrypted communications. The abnormal state information of the trace identifier is recorded in the TLCP layer enhancement log. The TLCP layer enhancement log represents the log after the automatic injection of a preset code into all TLCP layer logs. The preset code is [TLCP-TRACE] trace_id={hex} service_id={hex}. An abnormal state is indicated by a missing or incorrectly formatted header (e.g., the initial request of a service link). Abnormal state information includes, but is not limited to, the new trace identifier and request-related information (such as IP address, request path, etc.). Generating a new trace identifier ensures that encrypted communication can continue normally, preventing communication interruptions due to trace identifier abnormalities. Recording abnormal state information in the TLCP layer enhancement log provides detailed data support for subsequent analysis of the causes of trace identifier abnormalities, helping to promptly identify and resolve potential problems.

[0085] If the tracing identifier is not in an abnormal state, then when the current service instance calls other service instances, the tracing identifier is added to the HyperText Transfer Protocol Request Header (HTTP request header) to ensure that downstream service instances can obtain the tracing identifier of the upstream service instance. This step ensures the tracing identifier is propagated throughout the distributed microservice architecture, linking the request origin to each intermediate service instance and finally to the response, forming a complete request tracing chain for a comprehensive understanding of the request processing.

[0086] Optimizing the effectiveness of encrypted communication fault diagnosis also includes: generating operation identifiers when the server generates trace identifiers. Operation identifiers are used in the distributed tracing system to identify the current operation in the request path, including trace identifier, operation identifier, operation name, start and end time of the operation, supplementary information for each operation, specific events, and trace context information. The trace context information is used to transmit in the distributed tracing system. The generation of operation identifiers enables the distributed tracing system to identify each operation in the request path with finer granularity. Combined with trace identifiers, the status and time consumption of the request at different operation stages can be analyzed more accurately, providing more detailed information for performance optimization and fault location.

[0087] After an encrypted communication failure occurs, time-series data is obtained through a distributed tracing system, and error tags are added. The time-series data records detailed time information of request processing, including but not limited to operation start time, operation end time, and delay. After adding error tags, the time and location of the failure can be quickly located. Combined with other tracing information, the cause of the failure can be analyzed more efficiently, shortening the time for troubleshooting and repair.

[0088] In this embodiment, by combining tracking identifiers, operation identifiers, timing data, and error tags, the location and cause of faults occurring during encrypted communication can be quickly and accurately located, reducing troubleshooting time and improving the availability and stability of encrypted communication fault diagnosis in TLCP encrypted communication tracing, thereby improving fault diagnosis efficiency.

[0089] like Figure 9 The diagram shown is a schematic of the structure of a TLCP encrypted communication tracing system based on distributed microservices provided in this application embodiment. The system includes: a TLCP handshake request receiving and checking module, a TLCP handshake request response module, and an encrypted communication fault diagnosis module.

[0090] First, it should be noted that the TLCP handshake request receiving and checking module is used to check the trace identifier extension carried in the initial TLCP handshake request after the server receives it from the client. By receiving the handshake request, the server begins to establish a secure communication interaction process with the client. Checking the trace identifier extension can obtain the trace information transmitted by the client, providing basic data for tracing and recording the communication path and locating problems throughout the communication process. For example, in a distributed microservice architecture, a client request may be processed by multiple service instances, and the trace identifier can help determine the flow of the request between various services.

[0091] Secondly, it should be noted that the TLCP handshake request response module is used by the server to generate and return initialization response information containing server identifier extensions. Through this module, the client is informed that the server has received the handshake request and is ready to establish a secure connection. The server identifier extension allows the client to identify relevant information about the server, providing an accurate identification basis for subsequent interactions between the client and the server.

[0092] Finally, it should be noted that the encrypted communication fault diagnosis module, if the TLCP handshake is successfully completed, stores the acquired peer tracking identifier in the log after the interaction between the server and the client. Through collaboration with the transport and application layers, it collects monitoring data from each service instance. Based on this collected monitoring data, it performs encrypted communication fault diagnosis and communication process optimization. Otherwise, it sends alarm notifications to pre-defined personnel. By collecting and analyzing monitoring data from each service instance, the encrypted communication fault diagnosis module can promptly identify performance bottlenecks and potential faults in the communication process and perform targeted optimizations, thereby improving the performance and stability of the entire communication system. When the handshake fails, it promptly sends alarm notifications, enabling relevant personnel to respond quickly and handle the problem, avoiding business interruptions due to communication failures, and effectively improving the reliability and availability of the distributed microservice system.

[0093] In summary, this embodiment of the application, upon receiving an initial TLCP handshake request from a client, checks the trace identifier extension carried within it to verify the legality and validity of the client's request, establishing a traceable chain for subsequent tracing and communication. The server then generates and returns initialization response information containing its own identifier extension, confirming that the connection with the server has been successfully established and that communication is secure. This provides identification information for subsequent encrypted communication tracing. Finally, if the TLCP handshake is successfully completed, after interaction between the server and client, the trace identifier of the other end is recorded and stored in the log, and encrypted communication fault diagnosis and optimization are performed. Otherwise, an alarm notification is sent to pre-defined personnel, thereby promptly identifying bottlenecks in the communication process and making adjustments and optimizations to improve the stability and performance of encrypted communication.

[0094] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0095] This invention is described with reference to flowchart illustrations and / or block diagrams of systems, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0096] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0097] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0098] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0099] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

[0100] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0101] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0102] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0103] It should be understood that, in various embodiments of the present invention, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0104] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0105] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0106] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0107] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0108] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A TLCP encrypted communication tracing method based on distributed microservices, characterized in that, The method includes: S1, after the server receives the initial TLCP handshake request from the client, it checks the tracking identifier extension carried in the initial TLCP handshake request, which is used to start encrypted communication and perform identity authentication; S2, The server generates and returns initialization response information containing server identifier extensions, the initialization response information indicating that it is used to ensure that the client receives the information generated by the server; S3. If the TLCP handshake is successfully completed, after the interaction between the server and the client, the obtained tracking identifier of the other end will be recorded and stored in the log. Based on the monitoring data of each service instance collected, encrypted communication fault diagnosis and communication process optimization will be performed. Otherwise, an alarm notification will be sent to the preset personnel. The tracking identifier extension and the server identifier extension are both protocol extensions; The extension header structure in the protocol extension is designed according to the Type-Length-Value rule, which includes a type field, a length field, and a content field. The type field is used to identify the data type contained in the extended header, representing the tracking identifier and the server identifier; The length field indicates the length of the content field in the extended header; The content field represents the tracking identifier and the server identifier stored using big-endian encoding; The tracking identifier includes a millisecond-level timestamp in the first preset byte, an encrypted random number in the second preset byte, and a node identifier hash value in the third preset byte; The first preset byte's millisecond-level timestamp represents the time when the tracking identifier was generated; The encrypted random number of the second preset byte is used to enhance the randomness and security of the tracking identifier; The node identifier hash value of the third preset byte is used to identify the node that generated the tracking identifier; The server identifier is generated by performing a hash operation on the input IP address using the SM3 hash algorithm, which is executed by preset hardware acceleration. The resulting hash value is converted into a hexadecimal string, and the result of the first four preset bytes of the hexadecimal string is recorded as the server identifier.

2. The TLCP encrypted communication tracing method based on distributed microservices according to claim 1, characterized in that: Also includes: Based on the monitoring data collected from each service instance, a tracking link risk assessment is performed, and it is determined whether to perform tracking link risk control to ensure link stability. The tracking link risk assessment is used to identify performance bottlenecks in transport layer encrypted communication. If link risk control is not performed, encrypted communication fault diagnosis is performed directly according to the initial transmission procedure; otherwise, encrypted communication fault diagnosis is performed according to the initial transmission procedure after link risk control is performed. Based on the results of encrypted communication fault diagnosis, determine whether to optimize the effectiveness of encrypted communication fault diagnosis. If not, perform encrypted communication fault diagnosis according to the initial transmission process to check for potential problems in the encryption process; otherwise, perform encrypted communication fault diagnosis according to the optimized transmission process.

3. The TLCP encrypted communication tracing method based on distributed microservices according to claim 2, characterized in that: The risk assessment of the tracing link is performed based on the monitoring data collected from each service instance, and the specific method is as follows: The encryption duration of each service instance is compared with the preset encryption duration obtained from the preset database to obtain an encryption duration comparison coefficient. The encryption duration is obtained by deviating between the timestamp of the end of the encryption operation and the timestamp of the start of the encryption operation. The load comparison coefficient is obtained by comparing the load of each service instance with the preset load obtained from the preset database. The status update duration of each service instance is compared with the preset status update duration obtained from the preset database to obtain a status update duration comparison coefficient. The status update duration represents the time spent by the recorded service instance when its status changes. A tracing link risk balancing factor is introduced to perform weighted coupling processing on the encryption duration comparison coefficient, load comparison coefficient, and state update duration comparison coefficient to obtain the tracing link risk coefficient, thereby quantifying the performance bottleneck in transport layer encrypted communication.

4. The TLCP encrypted communication tracing method based on distributed microservices according to claim 3, characterized in that: The specific process for determining whether to perform risk control measures on the tracking link is as follows: A1. If the average tracing link risk coefficient of the service instance is greater than the preset tracing link risk coefficient obtained from the preset database, then execute A2; otherwise, directly perform encrypted communication fault diagnosis according to the initial transmission process. The average tracing link risk coefficient represents the average value of the tracing link risk coefficients of all service instances. A2. If the standard deviation of the tracking link risk coefficient is greater than the preset standard deviation of the tracking link risk coefficient obtained from the preset database, then tracking link risk control will be performed; otherwise, encrypted communication fault diagnosis will be performed directly according to the initial transmission process. The aforementioned tracking link risk control refers to dynamically adjusting the load balancing strategy of each service instance based on traffic priority; The risk control of the tracking link is as follows: If the total load of all service instances is not greater than the preset total load obtained from the preset database, the traffic priorities are sorted in descending order to obtain a traffic priority sequence, and the service instances are encrypted to communicate according to the order of the traffic priority sequence; otherwise, a weighted round-robin is used to allocate traffic to each service instance according to the traffic priority and corresponding load of each service instance.

5. The TLCP encrypted communication tracing method based on distributed microservices according to claim 2, characterized in that: The specific process for determining whether to optimize the effectiveness of encrypted communication fault diagnosis based on the results of encrypted communication fault diagnosis is as follows: After an encrypted communication failure occurs, a fault diagnosis accuracy coefficient is obtained. The fault diagnosis accuracy coefficient represents the accuracy rate of correctly locating and determining the fault type and location during the fault diagnosis process. If the fault diagnosis accuracy coefficient is not greater than the preset fault diagnosis accuracy coefficient obtained from the preset database, then the effectiveness of encrypted communication fault diagnosis will be optimized; otherwise, encrypted communication fault diagnosis will be performed according to the initial transmission process.

6. The TLCP encrypted communication tracing method based on distributed microservices according to claim 5, characterized in that: The specific process for optimizing the effectiveness of encrypted communication fault diagnosis is as follows: During the TLCP handshake phase, the server records the mapping relationship between the tracking identifier and the server identifier; If the tracking identifier is in an abnormal state, a new tracking identifier is generated on the server side and the new tracking identifier is continued to be used in subsequent encrypted communications. The abnormal state information of the tracking identifier is recorded in the TLCP layer enhanced log, which represents the log after the preset code is automatically injected into all TLCP layer logs. If the tracking identifier is not in an abnormal state, the tracking identifier will be added to the Hypertext Transfer Protocol request header when the current service instance calls other service instances, ensuring that the downstream service instance can obtain the tracking identifier of the upstream service instance.

7. The TLCP encrypted communication tracing method based on distributed microservices according to claim 6, characterized in that: The optimization of the effectiveness of encrypted communication fault diagnosis also includes: When the server generates a trace identifier, an operation identifier is generated. The operation identifier is used in the distributed tracing system to identify the current operation in the request path, including the trace identifier, operation identifier, operation name, start and end time of the operation, supplementary information for each operation, specific events, and tracing context information. After an encrypted communication failure occurs, time-series data is obtained through a distributed tracing system, and error tags are added.

8. A TLCP encrypted communication tracing system based on distributed microservices, using the TLCP encrypted communication tracing method based on distributed microservices as described in any one of claims 1-7, characterized in that, include: TLCP handshake request receiving and checking module, TLCP handshake request response module, and encrypted communication fault diagnosis module; The TLCP handshake request receiving and checking module is used to check the tracking identifier extension carried in the initial TLCP handshake request after the server receives the initial TLCP handshake request from the client. The TLCP handshake request and response module is used to generate and return initialization response information containing server identifier extensions from the server. The encrypted communication fault diagnosis module is used to store the obtained tracking identifier of the other end in the log after the interaction between the server and the client if the TLCP handshake is successfully completed, and to perform encrypted communication fault diagnosis and communication process optimization based on the monitoring data of each service instance collected; otherwise, it sends an alarm notification to the preset personnel.

Images