Communication connection method and device, electronic equipment and storage medium

Abstract

The application provides a communication connection method and device, electronic equipment and storage medium, and belongs to the technical field of computers. The method comprises the following steps: in the case that a main thread receives a connection request sent by any client, determining an authentication task based on the connection request, and delivering the authentication task to a worker thread pool, wherein the main thread returns immediately after delivery to continue processing the next connection request; receiving a verification result returned by the worker thread pool after verifying the authentication task successfully; generating an authentication token based on the verification result and determining a target node; and sending a connection request carrying the authentication token to the target node to enable the client to perform communication connection with the target node. Thus, the non-blocking connection processing of the gateway can be realized, thereby ensuring the system stability and response performance in a large-scale communication connection scenario, simplifying the communication connection establishment process, and improving the overall service quality.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication connection method, apparatus, electronic device and storage medium. Background Technology

[0002] The WebSocket protocol, as a full-duplex communication protocol, has been widely used in the field of real-time communication. In the process of establishing a WebSocket connection based on a gateway architecture, the gateway is responsible for receiving client handshake requests, performing authentication checks, and routing legitimate requests to backend service nodes to establish a communication connection.

[0003] In existing technologies, current communication connection methods mainly employ synchronous processing. This means that after receiving a request, the main thread directly performs authentication operations (such as token parsing, signature verification, and permission queries), and only after authentication is complete does it perform routing and connection forwarding. In this synchronous processing mode, the time consumed by authentication operations (especially when remote calls are involved) can cause the main thread to be blocked, preventing it from processing handshake requests from other clients in a timely manner. This results in increased connection establishment delays and decreased system throughput. Summary of the Invention

[0004] The purpose of this application is to provide a communication connection method, apparatus, electronic device, and storage medium to solve the technical problem in the prior art where the authentication operation, especially when remote calls are involved, causes the main thread to be blocked, making it impossible to process handshake requests from other clients in a timely manner, resulting in increased connection establishment delays and decreased system throughput. The specific technical solution is as follows: In a first aspect of this application, a communication connection method is provided, applied to a gateway, the gateway including a main thread and a worker thread pool, the method comprising: When the main thread receives a connection request from any client, it determines an authentication task based on the connection request and submits the authentication task to the worker thread pool. The main thread returns immediately after submission to continue processing the next connection request. The main thread is used to receive connection requests. The worker thread pool refers to a set of worker threads pre-created in the gateway for asynchronously executing time-consuming tasks. Receive the verification result returned by the worker thread pool after the authentication task is successfully verified; An authentication token is generated based on the verification result, and the target node is determined; Send a connection request carrying the authentication token to the target node to enable the client to establish a communication connection with the target node; If a timeout occurs when sending the connection request carrying the authentication token to the target node or an error response is received, and the failure counter corresponding to the target node meets the preset circuit breaker conditions, the state machine corresponding to the target node will be switched to the circuit breaker state. When the state machine corresponding to the target node is in the circuit-broken state for a preset sleep time window, the state machine corresponding to the target node is switched to the half-open state.

[0005] In an optional implementation, determining the authentication task based on the connection request includes: Extract authentication information from the connection request; The authentication information is encapsulated to generate the authentication task.

[0006] In one optional implementation, determining the target node includes: Get the list of nodes; Determine the real-time load metrics for each candidate node in the node list, including the number of connections, CPU utilization, and memory usage. Based on the real-time load metrics of each candidate node, determine the comprehensive weight corresponding to each candidate node; The target node is determined from the candidate nodes based on the comprehensive weights corresponding to each candidate node.

[0007] In an optional implementation, the method further includes: Get the set of nodes; Maintain a corresponding state machine for any node in the node set, the state machine including a healthy state, a circuit breaker state, and a half-open state; When the connection request carrying the authentication token to the target node times out or an error response is received, the failure counter corresponding to the target node is updated. The failure counter corresponding to the target node satisfies the preset circuit breaker condition as follows: the failure counter accumulates to a preset circuit breaker threshold within a preset time window.

[0008] In an optional implementation, the method further includes: When the state machine corresponding to the target node switches to a half-open state, a probe request is sent to the target node whose state machine is in a half-open state according to a preset probe frequency. If the detection is successful, the state machine corresponding to the target node will be restored from the half-open state to the healthy state. If the detection fails, the target node will be reverted to the circuit breaker state.

[0009] In an optional implementation, generating an authentication token based on the verification result includes: Obtain the user identity information and permission information from the verification result; The user identity information and the permission information are encapsulated according to a preset encryption algorithm to generate the authentication token.

[0010] In an optional implementation, generating an authentication token based on the verification result includes: Obtain the user identity information and permission information from the verification result; The user identity information and the permission information are encapsulated according to a preset encryption algorithm to generate the authentication token.

[0011] In an optional implementation, the connection request carrying the authentication token is generated through the following steps: The authentication token is added to the protocol field of the request header of the connection request to obtain the connection request carrying the authentication token.

[0012] In an optional implementation, after the client establishes a communication connection with the target node, the method further includes: Control the periodic exchange of heartbeat messages between the target node and the client; If no heartbeat message is received from the client within the preset heartbeat time, the communication connection is deemed to have failed.

[0013] In a second aspect of this application, a communication connection device is also provided for a gateway, the gateway including a main thread and a worker thread pool, the device comprising: The request-response module is used to determine an authentication task based on the connection request when the main thread receives a connection request from any client, and to submit the authentication task to the worker thread pool. The main thread returns immediately after submission to continue processing the next connection request. The verification result receiving module is used to receive the verification result returned by the worker thread pool after the authentication task is successfully verified; The target node determination module is used to generate an authentication token based on the verification result and determine the target node; The communication connection module is used to send a connection request carrying the authentication token to the target node so that the client can establish a communication connection with the target node.

[0014] In a third aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the communication connection method described in any one of the first aspects above.

[0015] In a fourth aspect of the embodiments of this application, a storage medium is also provided, the storage medium storing instructions that, when run on a computer, cause the computer to execute any of the communication connection methods described in the first aspect above.

[0016] In a fifth aspect of the embodiments of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the communication connection methods described in the first aspect above.

[0017] The technical solution provided in this application is applied to a gateway. The gateway includes a main thread and a worker thread pool. When the main thread receives a connection request from any client, it determines an authentication task based on the connection request and submits the authentication task to the worker thread pool. The main thread returns immediately after submission to continue processing the next connection request. It then receives the verification result returned by the worker thread pool after successfully verifying the authentication task; generates an authentication token based on the verification result and determines the target node; and sends a connection request carrying the authentication token to the target node to enable communication between the client and the target node. This technical solution, by separating the authentication logic from the gateway's main thread and entrusting it to an independent worker thread pool, allows the main thread to return immediately after submitting the authentication task without blocking and waiting for the authentication result, thus enabling it to continue processing subsequent client connection requests. By utilizing only the existing worker thread pool within the gateway, authentication decoupling can be achieved, significantly reducing the probability of main thread blocking during connection establishment and avoiding connection timeouts or throughput reductions due to authentication delays. Simultaneously, since the main thread only generates an authentication token and completes routing decisions based on the verification result after successful authentication, backend services avoid repeatedly executing the same authentication logic, reducing computational overhead on backend nodes. Furthermore, through the asynchronous collaboration mechanism between the main thread and the worker thread pool, the gateway can maintain stable connection receiving capabilities in high-concurrency scenarios, achieving higher system throughput and lower connection establishment latency compared to traditional synchronous authentication schemes. This enables non-blocking connection processing by the gateway, ensuring system stability and response performance in large-scale communication connection scenarios, while simplifying the communication connection establishment process and improving overall service quality. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0021] Figure 1 A schematic diagram illustrating the implementation process of a communication connection method provided in this application embodiment; Figure 2 A schematic diagram illustrating the implementation process of another communication connection method provided in this application embodiment; Figure 3 A schematic diagram illustrating the implementation process of a method for determining a target node provided in an embodiment of this application; Figure 4 A schematic diagram illustrating the implementation process of another method for determining a target node provided in this application embodiment; Figure 5 This is a schematic diagram of the structure of a communication connection system provided in an embodiment of this application; Figure 6 A schematic diagram illustrating an asynchronous authentication and connection establishment process provided for an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a communication connection device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0024] The communication connection method provided in this application will be further explained and described below with reference to the accompanying drawings and specific embodiments. The embodiments do not constitute a limitation on the embodiments of the present invention.

[0025] To address the technical problem in existing synchronous processing models where the authentication operation (especially when remote calls are involved) can block the main thread, preventing timely processing of handshake requests from other clients, thus increasing connection establishment delays and reducing system throughput, this application provides a communication connection method applied to a gateway. The gateway includes a main thread and a worker thread pool. Upon receiving a connection request from any client, the main thread determines an authentication task based on the connection request and submits the authentication task to the worker thread pool. The main thread immediately returns after submission to continue processing the next connection request. It then receives the verification result returned by the worker thread pool after successfully verifying the authentication task; generates an authentication token based on the verification result and determines the target node; and sends a connection request carrying the authentication token to the target node to enable communication between the client and the target node.

[0026] This technical solution decouples authentication logic from the gateway's main thread and delegates it to an independent worker thread pool. The main thread returns immediately after submitting the authentication task, without blocking and waiting for the authentication result, thus enabling it to continue processing subsequent client connection requests. Authentication decoupling is achieved solely using the existing worker thread pool within the gateway, significantly reducing the probability of main thread blocking during connection establishment and preventing connection timeouts or throughput drops due to authentication delays. Simultaneously, since the main thread only generates an authentication token and completes routing decisions based on the verification result after successful authentication, backend services avoid repeatedly executing the same authentication logic, reducing computational overhead on backend nodes. Furthermore, through the asynchronous collaboration mechanism between the main thread and the worker thread pool, the gateway can maintain stable connection receiving capabilities in high-concurrency scenarios, achieving higher system throughput and lower connection establishment latency compared to traditional synchronous authentication schemes. This enables non-blocking connection processing by the gateway, ensuring system stability and response performance in large-scale communication connection scenarios, while simplifying the communication connection establishment process and improving overall service quality.

[0027] like Figure 1The diagram shown is a schematic representation of an implementation flow of a communication connection method provided in this application embodiment. Applied to a gateway, the gateway includes a main thread and a worker thread pool, and specifically may include the following steps: S101: When the main thread receives a connection request from any client, it determines the authentication task based on the connection request and submits the authentication task to the worker thread pool. The main thread returns immediately after submission to continue processing the next connection request.

[0028] The aforementioned gateway refers to a network access node located between the client and the server. It is responsible for uniformly receiving, authenticating, routing, and controlling traffic for client connection requests, and has functions such as protocol conversion, security protection, and load balancing. For example, a WebSocket access gateway cluster.

[0029] The aforementioned main thread refers to the I / O (Input / Output) thread in the gateway that is responsible for listening to and receiving client connection requests. Its core responsibility is to quickly receive connection requests and dispatch tasks, without performing time-consuming operations, in order to ensure high throughput.

[0030] The aforementioned worker thread pool refers to a set of worker threads pre-created in the gateway, used to asynchronously execute time-consuming tasks (such as authentication logic), decoupled from the main thread, and to avoid blocking I / O threads.

[0031] The aforementioned client refers to the user terminal device that initiates the connection request, such as a smartphone, in-vehicle terminal, or web browser, used to establish a persistent communication channel with the backend service.

[0032] The connection request mentioned above refers to the initial handshake request sent by the client to the gateway to establish a WebSocket connection. It may include information such as the request line, header fields, and authentication credentials.

[0033] The aforementioned authentication task refers to an executable unit encapsulated by the gateway based on the authentication information (such as authentication tokens and signatures) carried in the connection request. It includes logic such as authentication token parsing, signature verification, and permission query, and is used for subsequent asynchronous verification.

[0034] In this embodiment, upon receiving a connection request from any client, the main thread of the execution entity determines an authentication task based on the connection request and submits the authentication task to a worker thread pool. The main thread returns immediately after submission to continue processing the next connection request. This step, by separating the authentication logic from the main thread to an independent worker thread pool and allowing the main thread to return immediately after task submission, achieves a non-blocking request receiving mechanism. In high-concurrency scenarios, the main thread can continuously process a large number of connection requests, avoiding main thread blocking and connection timeouts caused by synchronous authentication. This significantly improves the gateway's connection receiving throughput and reduces the average connection establishment latency.

[0035] As an optional implementation, the worker thread pool can be a dynamically scalable thread pool that can automatically add or reclaim worker threads based on the current length of the queue of authentication tasks to be processed, in order to balance resource consumption and processing efficiency.

[0036] As for the specifics of how the authentication task is determined based on the connection request, this will be explained below. Figure 2 The process shown will be explained in detail here.

[0037] S102, Receive the verification result returned by the worker thread pool after the verification and authentication task is successful.

[0038] The aforementioned verification and authentication tasks refer to the specific verification process performed by worker threads in the worker thread pool on the authentication task, including but not limited to operations such as token signature verification, expiration time check, and user permission query.

[0039] The above verification and authentication task is successful, meaning that all verification steps have passed, confirming that the client's identity is legitimate, the token is valid and has access rights, and there are no abnormalities or rejection conditions.

[0040] The above verification result refers to the data object returned to the main thread after the worker thread pool completes authentication. It may include a success flag, user identity information, and extended attributes carried in the token.

[0041] In this embodiment, the main thread receives the verification result returned by the worker thread pool after the verification and authentication task is successful. At this time, the authentication credentials carried in the connection request initiated by the client are legal and valid, the client's identity has passed the gateway's preliminary security verification, and it is qualified to continue to establish a communication connection.

[0042] In another embodiment of this application, if the main thread does not receive the verification result returned by the worker thread pool, it indicates that the verification and authentication task has failed (e.g., invalid token signature, expired credentials, insufficient permissions) or the task execution has timed out (e.g., the worker thread pool is busy, or the authentication service is slow to respond). To ensure the real-time response of the gateway and avoid long waiting times for the client, an authentication failure response (e.g., HTTP 401 Unauthorized or a custom error code) will be returned, terminating the current connection process, and failure logs or alarms may be selectively recorded.

[0043] As an optional implementation, the main thread can set a timeout timer (e.g., 500 milliseconds) when submitting the authentication task. If no verification result is received within the timeout period, the thread will proactively determine that the authentication has failed and return a timeout error response to the client. At the same time, it will cancel or ignore any subsequent verification results that may be returned to prevent resource leaks.

[0044] As an alternative implementation, the worker thread pool returns a verification result containing the specific reason for failure (such as token expiration, signature error, or lack of permissions) when verification fails. The main thread returns the corresponding error code and prompt information to the client based on the reason for failure, which facilitates differentiated processing by the client (such as guiding the user to log in again or refresh the token).

[0045] S103: Generate an authentication token based on the verification result and determine the target node.

[0046] The aforementioned authentication token refers to a short-lived encrypted credential generated by the gateway after successful authentication. It is used to prove the client's legitimate identity to the backend service and may contain user identity information, permission scope, expiration time, etc., to avoid the backend service performing repeated authentication. For example, an authentication token in JWT format with a validity period of 30 seconds.

[0047] The aforementioned target node refers to the backend service instance selected by the gateway that is responsible for establishing the actual connection with the client. For example, a server in a WebSocket microservice cluster (IP: 10.0.1.5, Port: 8080).

[0048] In this embodiment, after obtaining the verification result returned by the worker thread pool, if the verification result indicates successful authentication, an authentication token is generated based on the verification result, and the target node is determined. If the verification result indicates authentication failure, the client connection is rejected and an exception response is returned.

[0049] As for the specifics of how authentication tokens are generated based on verification results, please refer to the following text. Figure 2 The process shown will be explained in detail here.

[0050] Similarly, the specific method for determining the target node will be explained below. Figure 3 or Figure 4 The process shown will be explained in detail here.

[0051] S104, send a connection request carrying an authentication token to the target node to enable the client to establish a communication connection with the target node.

[0052] The aforementioned communication connection refers to the connection established between the client and the target node (such as a WebSocket persistent connection), which supports full-duplex, low-latency data transmission and is used for subsequent message push and real-time interaction. For example, a persistent connection established between the client and a WebSocket microservice via the RFC 6455 protocol.

[0053] In this embodiment of the application, a connection request carrying an authentication token is sent to the target node so that the client can establish a communication connection with the target node.

[0054] Based on the above description of the technical solution provided in the embodiments of this application, the solution is applied to a gateway. The gateway includes a main thread and a worker thread pool. When the main thread receives a connection request from any client, it determines an authentication task based on the connection request and submits the authentication task to the worker thread pool. The main thread returns immediately after submission to continue processing the next connection request. The main thread receives the verification result returned by the worker thread pool after successfully verifying the authentication task. Based on the verification result, it generates an authentication token and determines the target node. The main thread then sends a connection request carrying the authentication token to the target node to enable the client to establish a communication connection with the target node.

[0055] This technical solution decouples authentication logic from the gateway's main thread and delegates it to an independent worker thread pool. The main thread returns immediately after submitting the authentication task, without blocking and waiting for the authentication result, thus enabling it to continue processing subsequent client connection requests. Authentication decoupling is achieved solely using the existing worker thread pool within the gateway, significantly reducing the probability of main thread blocking during connection establishment and preventing connection timeouts or throughput drops due to authentication delays. Simultaneously, since the main thread only generates an authentication token and completes routing decisions based on the verification result after successful authentication, backend services avoid repeatedly executing the same authentication logic, reducing computational overhead on backend nodes. Furthermore, through the asynchronous collaboration mechanism between the main thread and the worker thread pool, the gateway can maintain stable connection receiving capabilities in high-concurrency scenarios, achieving higher system throughput and lower connection establishment latency compared to traditional synchronous authentication schemes. This enables non-blocking connection processing by the gateway, ensuring system stability and response performance in large-scale communication connection scenarios, while simplifying the communication connection establishment process and improving overall service quality.

[0056] like Figure 2 The diagram shown is a schematic representation of an implementation flow of another communication connection method provided in this application. Figure 2 exist Figure 1 Building upon this foundation, the paper details how to determine the authentication task based on the connection request and how to generate an authentication token based on the verification result, which may include the following: S201: When the main thread receives a connection request from any client, it extracts authentication information from the connection request.

[0057] The authentication information mentioned above refers to the credential data carried by the client in the connection request to prove its identity and access rights, used for subsequent legitimacy verification. Authentication information may include, but is not limited to: tokens, digital signatures, timestamps, client identifiers, random numbers, etc.

[0058] In this embodiment of the application, when the main thread receives a connection request sent by any client, it extracts authentication information from the connection request to authenticate the connection request.

[0059] As an optional implementation, if the connection request does not carry valid authentication information (such as missing the Authorization header or the header being empty), the main thread can directly refuse the connection and return a 401 Unauthorized response to the client. In this case, the subsequent authentication task will not be executed.

[0060] As an alternative implementation, after extracting the authentication information, the main thread can perform a format pre-validation, such as checking whether the token is the expected three-part JWT structure and whether the timestamp is a valid number. If the format is obviously incorrect, the connection can be rejected directly, avoiding submitting invalid tasks to the worker thread pool and saving thread resources.

[0061] As another optional implementation, for requests carrying multiple authentication information (such as both a token and a signature), the main thread can extract and encapsulate them into the same authentication task, which can then be verified by the worker thread pool in sequence or in combination, thereby enhancing the flexibility of authentication.

[0062] As another alternative implementation, after the main thread extracts the authentication information, it can de-identify sensitive information (such as the token) and record it (e.g., only record the first and last few digits) for log output to avoid security risks.

[0063] S202 encapsulates the authentication information and generates an authentication task.

[0064] The above encapsulation refers to packaging the extracted authentication information and other necessary context (such as client information and request identifier) ​​into an independently executable task object (i.e., authentication task).

[0065] In this embodiment of the application, authentication information can be encapsulated to generate an authentication task.

[0066] Specifically, the main thread can create an authentication task object instance through a constructor or factory method, and assign the authentication information extracted in step S201 (such as Token, digital signature, timestamp, client identifier, random number, etc.) to the corresponding attributes of the authentication task object instance. Simultaneously, request context information such as the client network address, global request identifier, and request reception timestamp can also be encapsulated into the authentication task object instance, thereby generating a complete authentication task that can be asynchronously executed by the worker thread pool.

[0067] S203, the authentication task is submitted to the worker thread pool, where the main thread returns immediately after submission to continue processing the next connection request.

[0068] In this embodiment of the application, this step is similar to step S101 above, and will not be described in detail here.

[0069] S204: Receive the verification result returned by the worker thread pool after the verification and authentication task is successful.

[0070] In this embodiment of the application, this step is similar to step S102 above, and will not be described in detail here.

[0071] S205, retrieve user identity information and permission information from the verification result.

[0072] The aforementioned user identity information refers to data used to uniquely identify client users, such as user identifiers and device identifiers.

[0073] The aforementioned permission information refers to data describing the resources or scope of operations that the connection request is authorized to access.

[0074] In this embodiment of the application, user identity information and permission information are obtained from the verification result.

[0075] Specifically, after receiving the validation result object returned by the worker thread pool, the main thread can call the access methods (such as getter methods) provided in the validation result to retrieve the various encapsulated data fields. The validation result may contain a success flag, error code, user identity information, permission information, extended attributes, etc. Pre-defined user identity fields, such as userId, deviceId, and openId, are read from the validation result object. If the validation result only contains a unique identifier (such as the sub field), the value of that field is used directly as the user identity information. Pre-defined permission fields, such as roles (roles list), permissions (permission set), and scope (authorization scope), are read from the validation result object. If the permission information in the validation result is in encrypted or encoded form (such as a Base64 encoded permission string), the main thread needs to decode it before retrieving it.

[0076] In addition, the main thread can perform necessary data validation on the extracted user identity and permission information, such as checking whether the userId is not empty and conforms to the expected format, and whether the permission list is within the defined legal range. Simultaneously, it can perform type conversion according to the gateway's internal data format requirements.

[0077] As an optional implementation, if the verification result does not explicitly provide permission information (e.g., only a user identifier is provided), the main thread can temporarily refrain from obtaining the permission information and instead encapsulate the user identifier into an authentication token. The target node can then query the permissions based on the user identifier. This reduces the burden on the gateway.

[0078] As another optional implementation, after obtaining the user's identity information, the main thread can query whether there is a recent permission snapshot of the user in the local cache. If it exists and has not expired, the permission information in the cache can be used directly to avoid frequently reading from the verification results or repeatedly calling the authentication service.

[0079] As another alternative implementation, for scenarios requiring fine-grained access control, the main thread can retain the original access data in the verification result without any trimming, and directly encapsulate it into the authentication token for final judgment by the backend node.

[0080] S206: According to the preset encryption algorithm, the user's identity information and permission information are encapsulated to generate an authentication token.

[0081] The aforementioned preset encryption algorithm refers to the cryptographic algorithm pre-agreed between the gateway and the backend service, used to encapsulate user identity and authorization information into an unforgeable and securely transmit authentication token. This algorithm can be a symmetric encryption algorithm (such as AES-256), an asymmetric encryption algorithm, or a hash-based message authentication code standard. The choice of the preset encryption algorithm can balance security, performance, and ease of backend parsing. For example, HMAC-SHA 256 can be used to sign the JSON payload containing user information to generate a JWT-formatted authentication token.

[0082] In this embodiment of the application, user identity information and permission information can be encapsulated according to a preset encryption algorithm to generate an authentication token.

[0083] S207, Determine the target node.

[0084] In this embodiment of the application, this step is similar to step S103 above, and will not be described in detail here.

[0085] S208, send a connection request carrying an authentication token to the target node so that the client can establish a communication connection with the target node.

[0086] In this embodiment, a connection request carrying an authentication token can be sent to the target node to enable the client to establish a communication connection with the target node. Specifically, after the gateway completes the generation of the authentication token and the selection of the target node, it can forward the client's WebSocket handshake request to the target node through an internal HTTP client or TCP connection, carrying the authentication token in the forwarding request. After verifying the authentication token, the target node completes the protocol upgrade, thereby realizing a direct long-term connection, i.e., a communication connection, between the client and the target node.

[0087] As an optional implementation, a connection request carrying an authentication token can be generated by adding the authentication token to the protocol field of the request header of the connection request. For example, a custom field, X-Pre-Auth-Token, can be added to the forwarded HTTP request header. <jwt>Or place it in Authorization:Bearer <jwt>In the field, the target node reads the token from the header for verification.

[0088] It should be noted that after the client and target node establish a communication connection, this connection can be monitored. Specifically, the target node and client can periodically exchange heartbeat messages. If no heartbeat message is received from the client within a preset heartbeat time, it indicates that the client may have gone offline abnormally, the network has been interrupted, or the connection has been closed, and the communication connection is considered to have failed. After a failure is determined, the target node can perform one or more of the following operations: release the memory and network resources associated with the connection, delete the mapping relationship between the client identifier and the authentication task from the distributed cache (such as Redis), and send a user offline status notification to the business system through an asynchronous message channel to ensure eventual consistency of the system state.

[0089] like Figure 3 The diagram shown is a schematic representation of the implementation flow of a method for determining a target node according to an embodiment of this application. Figure 3 exist Figure 1 , Figure 2 Based on this, a detailed description is given of how to determine the target node, which may include the following: S301, Get the node list.

[0090] The above node list refers to the set of backend service nodes that are currently active in the service registry and can be used to establish communication connections. Each node contains metadata such as its network address, service name, version number, and real-time load metrics.

[0091] In this embodiment, to perform dynamic load balancing routing, it is necessary to first obtain a list of currently available backend WebSocket microservice nodes. Therefore, the node list can be obtained from the service registry. Specifically, the gateway subscribes to node change events from the service registry at startup and maintains a locally cached list of nodes. When a routing decision needs to be made (such as after receiving a client's connection request and completing authentication), the gateway directly reads the list of all currently healthy nodes from the local cache, without needing to query the registry in real time each time, thus reducing network latency and registry pressure.

[0092] As an optional implementation, the gateway can periodically (e.g., every 5 seconds) actively pull the node list from the service registry and update the local cache, while listening for push notifications from the registry to achieve near real-time synchronization of node changes.

[0093] As an alternative implementation, nodes that have been circuit-broken or marked as unhealthy can be removed from the node list, leaving only nodes with a status of "healthy" or "half-open" to avoid forwarding traffic to faulty nodes.

[0094] S302, determine the real-time load metrics for each candidate node in the node list. The real-time load metrics include the number of connections, CPU utilization, and memory usage.

[0095] The aforementioned real-time load metrics refer to quantitative data reflecting the current resource usage pressure and connection load of candidate nodes, used to assess the node's workload. Real-time load metrics are typically collected periodically by the nodes themselves and reported to the service registry.

[0096] The number of connections mentioned above refers to the number of communication connections that a candidate node has currently established, which reflects the load capacity of that candidate node.

[0097] The CPU utilization rate mentioned above refers to the proportion of CPU (Central Processing Unit) resources occupied by the candidate node per unit time, which is used to reflect the computational busyness of the candidate node.

[0098] The aforementioned memory utilization rate refers to the proportion of memory resources used by the candidate node during runtime, which reflects the degree of memory resource strain on the candidate node.

[0099] In this embodiment of the application, the real-time load indicators of each candidate node in the node list can be determined. The real-time load indicators include the number of connections, CPU utilization, and memory usage.

[0100] Specifically, each candidate node can automatically collect its own connection count, CPU utilization, and memory usage at a preset period (e.g., 1 second) and report them to the service registry center; the gateway can obtain the real-time load indicators corresponding to each candidate node by synchronizing the latest load data from the service registry center.

[0101] It should be noted that if a candidate node fails to report real-time load metrics in a timely manner (e.g., it has not been updated for more than 2 reporting cycles), it can be marked as "unknown load" and its overall weight can be temporarily reduced, or it can be removed directly from the candidate nodes until a new and valid real-time load metric is received.

[0102] S303 determines the comprehensive weight of each candidate node based on its real-time load index.

[0103] The aforementioned comprehensive weight refers to a comprehensive evaluation value calculated based on the number of connections, CPU utilization, and memory usage. It is used to quantify the node load. The higher the weight, the lighter the node load and the more suitable it is to accept new connections.

[0104] In this embodiment of the application, the comprehensive weight of each candidate node is determined based on the real-time load index of each candidate node.

[0105] As an optional implementation, the weighting can be calculated using the following formula: ; in, Let be the comprehensive weight of the i-th candidate node; Let i be the number of connections corresponding to the i-th candidate node; Let be the CPU utilization rate corresponding to the i-th candidate node; Let be the memory usage rate corresponding to the i-th candidate node; , , This is a preset weighting coefficient, with a value greater than 0, used to adjust the degree of influence of each indicator. Let be the maximum number of connections that the i-th candidate node can handle. Let be the upper limit threshold for CPU utilization corresponding to the i-th candidate node. This is the upper limit threshold for the memory usage rate corresponding to the i-th candidate node.

[0106] For example, if =0.5、 =0.3、 =0.2, current number of connections for the candidate node =200、 =1000, CPU utilization =40% =80%, memory usage =30% If the weight is 70%, then the overall weight of that node is... =0.5×(1-200 / 1000)+0.3×(1-40% / 80%)+0.2×(1-30% / 70%)≈0.66.

[0107] S304. Determine the target node from among the candidate nodes based on the comprehensive weights corresponding to each candidate node.

[0108] In this embodiment of the application, the target node can be determined from the candidate nodes according to the comprehensive weight corresponding to each candidate node.

[0109] Specifically, the comprehensive weights of all candidate nodes can be sorted, and the candidate node with the highest comprehensive weight can be selected as the target node; if there are nodes with the same comprehensive weight, a round-robin method can be used to select the best one.

[0110] It should be noted that after determining the comprehensive weight of each candidate node in step S304 above, the comprehensive weight can be adjusted according to the device type of the client to achieve accurate matching between device type and node resources, thereby improving connection stability and service adaptability. Based on this, determining the target node may include the following steps: Step 1: Determine the device type corresponding to the client.

[0111] In this embodiment, device identification information can be extracted from the connection request initiated by the client, and the device type corresponding to the client can be identified based on the device identification information; wherein, the device type includes, but is not limited to, vehicle terminal, smartphone, desktop terminal, Internet of Things device, etc.

[0112] Step 2: Obtain the node type corresponding to each candidate node.

[0113] In this embodiment, the node type of each candidate node can be read from the node metadata maintained by the service registry. The node type is divided according to the node hardware configuration, performance specifications, and service adaptation scenarios, such as high computing power node, general node, low power node, and vehicle-specific node.

[0114] Step 3: For any candidate node, determine the corrected weight coefficient corresponding to the candidate node based on the device type of the client and the node type of the candidate node.

[0115] In this embodiment, for any candidate node, a corrected weight coefficient is determined based on the device type of the client and the node type of the candidate node. Specifically, a matching mapping relationship between device type and node type can be established in advance, and the corrected weight coefficient of the candidate node is determined based on this matching mapping relationship.

[0116] Step 4: Adjust the comprehensive weight of the candidate node based on the adjusted weight coefficient to obtain the adjusted comprehensive weight of the candidate node.

[0117] In this embodiment of the application, the comprehensive weight corresponding to the candidate node can be corrected based on the corrected weight coefficient to obtain the corrected comprehensive weight corresponding to the candidate node.

[0118] Specifically, the corrected comprehensive weight can be obtained by multiplying the comprehensive weight corresponding to the candidate node by the corrected weight coefficient.

[0119] For example, if the overall weight of a candidate node is 0.66 and the corrected weight coefficient is 1.2, then the corrected overall weight is 0.66 × 1.2 = 0.792.

[0120] Step 5: Determine the target node from among the candidate nodes based on the corrected comprehensive weights corresponding to each candidate node.

[0121] In this embodiment, the target node is determined from the candidate nodes according to the modified comprehensive weight corresponding to each candidate node. Specifically, the modified comprehensive weights corresponding to each candidate node can be sorted, and the candidate node with the highest modified comprehensive weight can be selected as the target node; if there are multiple candidate nodes with the same modified comprehensive weight, a round-robin method can be used to select the best one.

[0122] Furthermore, to enhance the system's fault tolerance and high availability, a state machine-based fault circuit breaking and recovery mechanism is introduced. Specifically, this may include: obtaining a set of nodes; maintaining a corresponding state machine for any node in the set, where the state machine includes a healthy state, a circuit-broken state, and a half-open state; updating the failure counter corresponding to the target node when a connection request carrying an authentication token to the target node times out or an error response is received; and switching the state machine corresponding to the target node to the circuit-broken state when the failure counter accumulates to a preset circuit-broken threshold within a preset time window.

[0123] It should be noted that if a connection request carrying an authentication token to the target node times out or an error response is received, and the failure counter of the target node meets the preset circuit breaker conditions, the state machine of the target node will be switched to the circuit breaker state. When the state machine of the target node remains in the circuit breaker state for a preset sleep time window, it will be switched to the half-open state. The preset circuit breaker conditions for the failure counter of the target node include: the failure counter accumulating to a preset circuit breaker threshold within a preset time window.

[0124] The aforementioned node set refers to the collection of all backend service nodes managed by the gateway. These backend service nodes are used to establish actual communication connections with clients. The node set can be obtained from the service registry, and the addition, deletion, and status changes of nodes are synchronized in real time.

[0125] The aforementioned state machine describes and manages the different stages of backend node states during the fault-breaking and recovery process. The states of the state machine switch unidirectionally or cyclically according to preset conditions. The state machine can be implemented based on a finite state machine model, maintaining an independent state record for each node. The healthy state refers to a node in a normal working state, capable of receiving and processing connection requests normally. Nodes in a healthy state are included in the node list, participate in routing decisions, and the gateway can forward connection requests to them normally. For example, a newly started node or a node that has never experienced a fault initially has a healthy state in its state machine. The circuit-breaking state refers to a node being temporarily isolated due to consecutive failures and no longer receiving new connection requests. Nodes in the circuit-breaking state are removed from the node list, and the gateway suspends forwarding any connection requests to them to avoid resource waste and increased latency caused by continuously requesting faulty nodes. For example, if a node fails three times consecutively within 10 seconds, its state machine will switch to the circuit-breaking state, and subsequent connection requests will no longer be routed to that node. The half-open state refers to a tentative recovery phase that a node enters after being in the circuit-breaking state for a certain period. Nodes in a half-open state are not immediately restored to a healthy state. Instead, they are allowed to receive a limited number of probe requests or at a specific frequency to verify whether the node has truly recovered. For example, after a node remains in a circuit-broken state for 30 seconds, its state machine switches to a half-open state. At this time, the gateway will send probe requests to the node at a preset probe frequency to assess its availability.

[0126] The aforementioned failure timer is a counter variable used to record the cumulative number of failures of a node within a preset time window. The failure counter increments by 1 each time a request forwarding to a node times out or an error response is received; it can be reset to zero or decayed after the node successfully processes the request or the preset time window has elapsed. The failure counter can be maintained independently for each node. For example, the initial value of the failure counter maintained for a node can be 0, increasing to 1 after the first failure, 2 after the second failure, and so on.

[0127] The aforementioned preset time window refers to a sliding time interval used to count failures. Only failures occurring within this time window will be accumulated and included in the circuit breaker decision. The length of the preset time window can be configured according to the system's requirements for fault sensitivity. For example, the preset time window can be set to 10 seconds, meaning the gateway will count the number of failures that occurred on the node within the last 10 seconds, and failure records older than 10 seconds will be ignored or not included in the current window.

[0128] The preset circuit breaker threshold refers to the minimum number of failures required to trigger the state machine to switch from a healthy state to a circuit breaker state. The preset circuit breaker threshold can be configured based on the node's performance metrics and business importance. A smaller threshold means the system is more sensitive to failures; a larger threshold means the system has a higher tolerance for occasional failures. For example, the preset circuit breaker threshold can be set to 3 failures, meaning that when a node accumulates 3 failures within a preset time window (e.g., 10 seconds), the circuit breaker is triggered, and the node's state machine switches to the circuit breaker state.

[0129] For example, a gateway maintains a set of nodes, including node A (address 10.0.1.5:8080). The gateway maintains a state machine for node A, initially in a healthy state, and a failure counter, initially set to 0. The preset time window is set to 10 seconds, and the preset circuit breaker threshold is set to 3 failures. When the gateway forwards the first client connection request to node A, a timeout occurs, and the gateway updates node A's failure counter to 1. Five seconds later, the gateway forwards a second connection request to node A, which also times out, and the failure counter is updated to 2. Three seconds later, the gateway forwards a third connection request to node A, and again receives an error response (e.g., HTTP 503), updating the failure counter to 3. At this point, the failure counter has accumulated to the preset circuit breaker threshold of 3 failures within the 10-second preset time window. The gateway switches node A's state machine from a healthy state to a circuit breaker state and removes node A from the list of available nodes. After this, new connection requests will no longer be routed to node A, thus avoiding increased connection latency and a degraded user experience caused by continuously sending requests to the faulty node.

[0130] Furthermore, the fault circuit breaking and recovery mechanism provided in this application embodiment also includes: when the state machine corresponding to the target node is in the circuit-broken state for a preset sleep time window, the state machine corresponding to the target node is switched to a half-open state; when the state machine corresponding to the target node is switched to a half-open state, a probe request is sent to the target node whose state machine is in the half-open state according to a preset probe frequency; if the probe is successful, the state machine corresponding to the target node is restored from the half-open state to the healthy state; if the probe fails, the target node is rolled back to the circuit-broken state.

[0131] The aforementioned preset sleep time window refers to the duration required for the target node to wait from entering the circuit breaker state to beginning its recovery attempt. Within the sleep time window, the target node remains in the circuit breaker state, not accepting any connection requests, giving it sufficient buffer time to complete self-repair (such as restarting, releasing resources, and processing backlogged tasks). The length of the sleep time window can be configured based on the target node's historical failure rate and business importance. For example, the preset sleep time window can be set to 30 seconds, meaning the target node is eligible to enter the half-open state and accept recovery probes only after maintaining the circuit breaker state for 30 seconds.

[0132] The preset probe frequency mentioned above refers to the time interval at which the gateway sends probe requests to target nodes in a half-open state. The probe frequency determines how quickly the target node recovers: a higher frequency results in more timely node recovery but increases the system's probe overhead; a lower frequency results in lower probe overhead but increases the latency of target node recovery. The probe frequency can be configured according to the system's real-time requirements and resource conditions. For example, the preset probe frequency can be set to once every 10 seconds, meaning the gateway sends a probe request to a node in a half-open state every 10 seconds.

[0133] The probe request mentioned above refers to a lightweight request used by the gateway to detect whether the target node has returned to normal working status. The probe request can be an HTTP HEAD request, an HTTP GET request (accessing a health check endpoint, such as / health), a TCP connection probe, or a custom protocol probe message. The probe request should be low-overhead and have a fast response time to avoid placing additional burden on the target node. For example, the gateway can send an HTTP GET request to the target node's / health endpoint, expecting to receive an HTTP 200 response within 2 seconds.

[0134] A successful probe means that the gateway receives a correct response from the target node within the preset timeout period. The criteria for determining a successful probe can be defined based on the target node's health check interface and may include: a success status code (such as HTTP 2xx), a response body content that conforms to the expected format, and a response time that does not exceed the timeout threshold. For example, if the gateway sends a probe request to the target node and receives an HTTP 200 response within 2 seconds, with the response body containing the "status": "ok" field, then the probe is considered successful.

[0135] The probe failure mentioned above indicates that the gateway failed to receive the expected correct response from the target node. Specific situations that may lead to a probe failure include: request timeout (no response received within the preset timeout period), receiving an error status code (such as HTTP 5xx), response content not conforming to the expected format, connection being refused, etc. For example, if the gateway sends a probe request to the target node and does not receive any response after waiting for 3 seconds, or receives an HTTP 503 Service Unavailable response, then the probe is considered to have failed.

[0136] For example, suppose the gateway maintains a state machine for node A, which has entered a circuit breaker state due to consecutive failures. The preset sleep time window is set to 30 seconds, the preset probe frequency is set to once every 10 seconds, the probe request is an HTTP GET request to http: / / 10.0.1.5:8080 / health, and the timeout is set to 2 seconds. Node A enters the circuit breaker state at time T0. After 30 seconds, at time T0+30s, node A's state machine switches to a half-open state. The gateway immediately sends the first probe request at the 0th second after the switch (i.e., at time T0+30s), initiating an HTTP GET request to http: / / 10.0.1.5:8080 / health. If an HTTP 200 response is received within 2 seconds, the probe is considered successful, node A's state machine is restored from the half-open state to the healthy state, node A is re-added to the list of available nodes, and can normally receive client connection requests. If the first probe fails (e.g., request timeout or HTTP 503 error), node A is rolled back to the circuit breaker state, and the sleep time window restarts (i.e., waits another 30 seconds). After 30 seconds, node A switches back to the half-open state, and the gateway continues to send probe requests every 10 seconds, repeating this cycle until the probe succeeds or manual intervention occurs. If node A successfully recovers to a healthy state and then experiences consecutive failures again, triggering the circuit breaker, the above process is repeated.

[0137] Through the aforementioned half-open detection and state recovery mechanism, this application can automatically detect the recovery status of faulty nodes without introducing additional manual intervention, and promptly reintegrate the nodes into the service cluster after they have recovered. Simultaneously, by configuring a sleep time window, the additional pressure on nodes caused by frequent detection is avoided; and through a fallback mechanism, it is ensured that nodes do not prematurely take on traffic before they are fully recovered, thereby guaranteeing the overall stability and high availability of the system.

[0138] like Figure 4 The diagram shown is a schematic representation of the implementation flow of another method for determining a target node provided in this application. Figure 4 exist Figure 1 , Figure 2 Based on this, a detailed description is given of how to determine the target node, which may include the following: S401, parse the level label carried in the connection request.

[0139] The aforementioned level labels refer to the identification information carried in the client connection request, used to characterize the client's service level or priority category. Level labels can be used to distinguish clients of different quality levels, such as premium users, regular users, internal service calls, and free users.

[0140] In this embodiment, the level tag carried in the connection request is parsed. Specifically, upon receiving a connection request from a client, a preset level tag field can be read from the connection request, such as X-Level:VIP, X-Priority:high, or grade:gold. If the connection does not explicitly carry a level tag, it can be processed according to the default level (such as normal). The level tag can be a string type, or an enumeration value or a numeric code (such as 1, 2, and 3 corresponding to different levels).

[0141] S402, obtain the node list and determine the level attribute of each candidate node in the node list.

[0142] The aforementioned grade attributes are used to characterize the service level and resource guarantee capabilities of candidate nodes, such as high-priority nodes, standard nodes, and basic nodes.

[0143] In this embodiment of the application, a node list can be obtained, and the level attribute of each candidate node in the node list can be determined.

[0144] The process of obtaining the node list is similar to step S103 described above, and will not be repeated here in this embodiment.

[0145] S403, compare the level label with the level attributes of each candidate node to determine at least one matching node.

[0146] In this embodiment, the client's level label can be matched and compared with the level attributes of each candidate node to filter out nodes whose level attributes match the level label, and these nodes are then used as matching nodes. For example, high-level clients correspond to high-priority nodes, and ordinary-level clients correspond to standard nodes, ensuring that high-priority clients obtain high-level node resources.

[0147] S404, determine the target node from at least one matching node based on the real-time load metrics corresponding to each matching node.

[0148] In this embodiment, a target node is determined from at least one matching node based on the real-time load indicators corresponding to each matching node. This step is similar to S302-S304 described above, and will not be repeated here.

[0149] It should be noted that a gateway can maintain a state machine for any node in the node list. The initial state of the state machine is "healthy," and a corresponding failure counter is configured. When a timeout occurs or an error response is received when the gateway forwards a request to a backend service node, the failure counter is incremented by 1. When the failure counter accumulates to the circuit breaker threshold (e.g., 3 times) within a preset time window (e.g., 10 seconds), the circuit breaker is triggered: the state of the node's state machine is switched to "circuit breaker," and the node is removed from the node list; the state is synchronized to all gateways via the registry center or broadcast message.

[0150] After maintaining a dormant state for a specified time window (e.g., 30 seconds) during the circuit breaker state, the node's state is changed to "half-open". The gateway sends probe requests to nodes in the "half-open" state at a preset probe frequency (e.g., once every 10 seconds). If the probe is successful, the connection warm-up phase begins: the node's initial comprehensive weight is set to 10% of the actual weight calculated based on real-time load metrics, and then increased by 10% every 10 seconds until the actual weight value is reached. At this point, the node's state is restored to "healthy". If the probe fails, the node's state is rolled back to "circuit breaker" and the dormant time window is reset. This mechanism enables faulty nodes to be detected and traffic cut off within seconds, preventing the fault from spreading; at the same time, the half-open probe and connection warm-up achieve smooth recovery, preventing instantaneous traffic surges after recovery.

[0151] Furthermore, the communication connection method provided in this application embodiment is illustrated with specific examples: like Figure 5 The diagram shown is a structural schematic of a communication connection system provided in an embodiment of this application.

[0152] The communication connection system includes a client layer, a WS gateway, WS microservices, a KAFKA message queue, business services, and a foundation layer.

[0153] The client layer includes one or more clients (such as...) Figure 5 In this context, clients 1, 2, ..., N are user terminal devices used to initiate WebSocket connection requests and establish persistent communication channels with backend services. Clients can include, but are not limited to, smartphones, in-vehicle terminals, web browsers, and IoT devices. When initiating a connection request, the client includes authentication information, such as an Authorization Token and signature information, in the HTTP handshake header for subsequent authentication and permission verification by the gateway layer.

[0154] A WS gateway includes one or more gateway instances (such as...) Figure 5 The WS Gateway 1, WS Gateway 2, ..., WS Gateway N in the system serve as the unified entry point for client access. They are responsible for receiving WebSocket handshake requests from clients, performing asynchronous authentication, making dynamic routing decisions, and maintaining the health status of backend nodes. After completing client authentication, the gateway generates a pre-authentication token and carries this token when forwarding connection requests to backend WebSocket microservice nodes using a private protocol. This achieves transparent transmission of authentication results, avoiding the backend service from repeatedly executing complete authentication logic (such as remote permission queries). The backend only needs to verify the token's signature and validity to quickly complete identity verification. Each gateway instance further includes the following core modules: Connection receiving module: Composed of the main thread, it is responsible for listening to and receiving connection requests from clients. After receiving a request, it extracts authentication information and encapsulates it into an authentication task, which is then submitted to an independent authentication thread pool. The main thread returns immediately after submission to continue processing the next connection request, thus achieving non-blocking reception.

[0155] The authentication thread pool consists of a pre-created set of worker threads used to asynchronously execute authentication tasks, including token signature verification, expiration time verification, and user permission queries. After authentication is complete, the verification result is returned to the main thread.

[0156] The routing decision-maker selects the optimal target node from healthy WebSocket microservice nodes based on real-time load metrics and a dynamic weighting algorithm. The routing decision-maker synchronizes the node list and its real-time load metrics from the service registry and performs calculations and selections based on a comprehensive weighting formula.

[0157] Health status management (state maintainer): This function maintains a state machine for each backend node, including healthy state, circuit breaker state, and half-open state. The state maintainer is responsible for updating the failure counter, triggering circuit breakers, performing half-open probes, and managing the connection warm-up process.

[0158] It should be noted that the WS gateway can subscribe to the service registry in the base layer to obtain the list of WebSocket microservice nodes in real time, and pull the real-time load indicators of each node, including the number of connections, CPU utilization, and memory usage, to provide data support for dynamic routing decisions.

[0159] WS microservices include one or more WebSocket microservice nodes (such as...) Figure 5 The WebSocket microservice node (WS node 1, WS node 2, ..., WS node N) is responsible for establishing actual WebSocket long-lived connections with clients, maintaining connection sessions, performing message pushes, and periodically reporting load metrics. Each WebSocket microservice node further includes the following core modules: Connection Management Module: Used to receive handshake requests forwarded by the gateway, verify the validity of the pre-authentication token; complete the upgrade handshake from HTTP to WebSocket protocol, establish a persistent long connection with the client, and maintain the lifecycle of the connection, including connection establishment, keep-alive (heartbeat detection), connection termination, etc.

[0160] Session management module: Used to register client connection information (such as the mapping relationship between client identifier and instance identifier) ​​into a distributed cache (such as Redis) to form a routing table, so that other instances or business services can locate the node currently connected to the client.

[0161] Metrics Reporter: Used to periodically (e.g., every 1 second) collect real-time load metrics of the node itself, including the current number of connections, CPU utilization, memory usage, etc., and report these metrics to the service registry center for the gateway to make dynamic routing decisions.

[0162] The message push module is used to receive messages from business services or message queues. It determines the instance that the target client is currently connected to by by querying the routing table. If the target is on the same instance, the message is pushed directly. If it is on another instance, the message is forwarded across instances through an internal interface.

[0163] Token verifier: Used to receive pre-authentication tokens forwarded by the gateway, verify the signature, validity period, and user identity; after successful verification, it performs a protocol upgrade, eliminating the need to repeatedly call the business authentication interface and reducing backend pressure.

[0164] The business service comprises one or more business service nodes, responsible for handling specific business logic, including message processing (construction and sending), user permission management, user online status management, and instant messaging logic. The business service communicates decoupled from the WebSocket microservice via an asynchronous message channel (such as Kafka). The business service sends messages to be pushed to a message queue, which is then consumed and the actual push is executed by the WebSocket microservice.

[0165] The base layer provides the infrastructure support required for system operation, specifically including the following components: Service registry centers (such as Nacos, Consul, and Eureka) are used to store a list of backend WebSocket microservice nodes and their real-time (periodically reported) load metrics. They also receive periodic reports from the WebSocket microservices regarding CPU, connection count, memory, and other information for each node. They support automatic node registration and discovery and push node state change events to the gateway. Service registry centers are a core dependency for dynamic routing and service discovery.

[0166] Distributed caches (such as Redis): These are used to store the mapping between client identifiers and WebSocket microservice instance identifiers, forming a global routing table. Additionally, distributed caches can also be used to store tokens, user session information, etc., supporting cross-instance data sharing and high-performance read / write operations.

[0167] Offline message storage (such as ElasticSearch, Redis): Used to temporarily store messages from offline clients, which are then pushed back once the client is back online. Offline messages can be automatically cleaned up based on the configured message time-to-live (TTL), preventing storage resources from growing indefinitely.

[0168] Database: Used for persistent storage of user information, permission configurations, message logs, device files and business configurations, providing data backup and query capabilities, and supporting the persistence of business logic.

[0169] Message queues (such as Kafka and RocketMQ) are used to implement asynchronous communication between business services and WebSocket microservices, decoupling business logic from the connection layer. Business services send messages to the message queue, and the WebSocket microservice subscribes to the corresponding topic to consume them, thus achieving asynchronous and reliable message transmission. It also supports asynchronous message storage, event-driven communication, and broadcast message push, ensuring that messages are not lost, can be retried, and are traceable.

[0170] like Figure 6 The diagram shown is a flowchart illustrating an asynchronous authentication and connection establishment process provided in an embodiment of this application. This process divides the WebSocket connection establishment process into three core stages: Stage 1: Asynchronous authentication process; Stage 2: Dynamic routing decision; and Stage 3: Connection establishment and token pass-through, achieving non-blocking authentication, load-balanced routing, and secure backend connection establishment.

[0171] Phase 1: Asynchronous authentication process: The client initiates a WebSocket handshake request to the access gateway, carrying an Authorization Token in the request header as an authentication credential.

[0172] After receiving the request, the main thread (I / O thread) of the access gateway extracts the token and encapsulates it into an authentication task.

[0173] After the main thread submits the authentication task to a separate authentication thread pool, it immediately returns and continues to process the next client request, thus achieving non-blocking of the main thread.

[0174] The authentication thread pool asynchronously performs token verification, including signature verification, expiration time check, and user permission verification.

[0175] If authentication fails, the gateway directly returns a 401 Unauthorized response to the client, and the process ends; if authentication succeeds, the user information is returned to the main thread, and the process proceeds to the next stage.

[0176] Phase Two: Dynamic Routing Decision: The main thread of the access gateway sends a request to the routing decision-maker to select a backend WebSocket node. The routing decision-maker obtains the latest load information of all healthy WebSocket nodes from the service registry, including the current number of connections, CPU utilization, and memory utilization. The service registry returns a list of node loads.

[0177] The routing decision-maker calculates the comprehensive weight of each node based on a preset multi-dimensional weight formula: ; in, Let be the overall weight of the i-th node; Let i be the number of connections corresponding to the i-th node; Let be the CPU utilization rate corresponding to the i-th node; This represents the memory usage rate corresponding to the i-th node; , , This is a preset weighting coefficient, with a value greater than 0, used to adjust the degree of influence of each indicator. Let be the maximum number of connections that the i-th node can handle. Let be the upper limit threshold for CPU utilization corresponding to the i-th node. This is the upper limit threshold for the memory usage rate corresponding to the i-th node.

[0178] The routing decision-maker uses a weighted round-robin algorithm to select the optimal backend node based on the calculated weights and returns the address of the selected backend node to the access gateway main thread.

[0179] Phase 3: Connection Establishment and Token Transmission. The access gateway's main thread generates a pre-authentication token, which contains user information, client identifier, and a short validity period, and is signed using the gateway's private key. The access gateway carries the pre-authentication token and forwards the connection request to the backend WebSocket node. The backend WebSocket node verifies the signature, user information, and validity period of the pre-authentication token. After successful verification, it executes the subsequent process. The backend WebSocket node returns a 101 SwitchingProtocols response to the access gateway, completing the WebSocket protocol upgrade.

[0180] The backend WebSocket node writes the mapping relationship between the client identifier (clientId) and its own instance identifier (instanceId) into Redis to form a global routing table for subsequent message push and cross-instance forwarding.

[0181] The access gateway sends a successful connection confirmation to the client, and the persistent communication channel between the client and the backend WebSocket node is officially established.

[0182] Corresponding to the above method embodiments, this application also provides a communication connection device applied to a gateway, the gateway including a main thread and a worker thread pool, such as... Figure 7 As shown, the device may include a request response module 601, a verification result receiving module 702, a target node determination module 703, and a communication connection module 704.

[0183] The request response module 701 is used by the main thread to determine the authentication task based on the connection request when it receives a connection request from any client, and to submit the authentication task to the worker thread pool. The main thread returns immediately after submission to continue processing the next connection request. The verification result receiving module 702 is used to receive the verification result returned by the worker thread pool after the verification and authentication task is successful. The target node determination module 703 is used to generate an authentication token based on the verification result and determine the target node; The communication connection module 704 is used to send a connection request carrying an authentication token to the target node so that the client can establish a communication connection with the target node.

[0184] This application also provides an electronic device, such as... Figure 8 As shown, it includes a processor 801, a communication interface 802, a memory 803, and a communication bus 804. The processor 801, communication interface 802, and memory 803 communicate with each other via the communication bus 804. Memory 803 is used to store computer programs; In one embodiment of this application, when the processor 801 executes a program stored in the memory 803, it performs the following steps: When the main thread receives a connection request from any client, it determines the authentication task based on the connection request and submits the authentication task to the worker thread pool. The main thread returns immediately after submission to continue processing the next connection request. It receives the verification result returned by the worker thread pool after the authentication task is successfully verified. It generates an authentication token based on the verification result and determines the target node. It sends a connection request carrying the authentication token to the target node to enable the client to establish a communication connection with the target node.

[0185] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0186] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0187] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0188] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0189] In another embodiment provided in this application, a storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute any of the communication connection methods described in the above embodiments.

[0190] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the communication connection methods described in the above embodiments.

[0191] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application 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 storage medium or transmitted from one 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., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The 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 integrates one or more 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 (e.g., solid state disk (SSD)).

[0192] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0193] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0194] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the protection scope of this application.< / jwt> < / jwt>

Claims

1. A communication connection method, characterized in that, Applied to a gateway, which includes a main thread and a worker thread pool, the method includes: When the main thread receives a connection request from any client, it determines an authentication task based on the connection request and submits the authentication task to the worker thread pool. The main thread returns immediately after submission to continue processing the next connection request. The main thread is used to receive connection requests. The worker thread pool refers to a set of worker threads pre-created in the gateway, which are used to asynchronously execute time-consuming tasks, including authentication logic. Receive the verification result returned by the worker thread pool after the authentication task is successfully verified; An authentication token is generated based on the verification result, and the target node is determined; Send a connection request carrying the authentication token to the target node to enable the client to establish a communication connection with the target node; If a timeout occurs when sending the connection request carrying the authentication token to the target node or an error response is received, and the failure counter corresponding to the target node meets the preset circuit breaker conditions, the state machine corresponding to the target node will be switched to the circuit breaker state. When the state machine corresponding to the target node is in the circuit-broken state for a preset sleep time window, the state machine corresponding to the target node is switched to the half-open state.

2. The method according to claim 1, characterized in that, Determining the authentication task based on the connection request includes: Extract authentication information from the connection request; The authentication information is encapsulated to generate the authentication task.

3. The method according to claim 1, characterized in that, Determine the target node, including: Get the list of nodes; Determine the real-time load metrics for each candidate node in the node list, including the number of connections, CPU utilization, and memory usage. Based on the real-time load metrics of each candidate node, determine the comprehensive weight corresponding to each candidate node; The target node is determined from the candidate nodes based on the comprehensive weights corresponding to each candidate node.

4. The method according to claim 1, characterized in that, The method further includes: Get the set of nodes; Maintain a corresponding state machine for any node in the node set, the state machine including a healthy state, a circuit breaker state, and a half-open state; When the connection request carrying the authentication token to the target node times out or an error response is received, the failure counter corresponding to the target node is updated. The failure counter corresponding to the target node satisfies the preset circuit breaker condition as follows: the failure counter accumulates to a preset circuit breaker threshold within a preset time window.

5. The method according to claim 1, characterized in that, The method further includes: When the state machine corresponding to the target node switches to a half-open state, a probe request is sent to the target node whose state machine is in a half-open state according to a preset probe frequency. If the detection is successful, the state machine corresponding to the target node will be restored from the half-open state to the healthy state. If the detection fails, the target node will be reverted to the circuit breaker state.

6. The method according to claim 1, characterized in that, Generate an authentication token based on the verification result, including: Obtain the user identity information and permission information from the verification result; The user identity information and the permission information are encapsulated according to a preset encryption algorithm to generate the authentication token.

7. The method according to claim 1, characterized in that, A connection request carrying the authentication token is generated through the following steps: The authentication token is added to the protocol field of the request header of the connection request to obtain the connection request carrying the authentication token.

8. The method according to claim 1, characterized in that, After the client establishes a communication connection with the target node, the following steps are also included: Control the periodic exchange of heartbeat messages between the target node and the client; If no heartbeat message is received from the client within the preset heartbeat time, the communication connection is deemed to have failed.

9. A communication connection device, characterized in that, Applied to a gateway, the gateway including a main thread and a worker thread pool, the device includes: The request-response module is used by the main thread to determine an authentication task based on the connection request when it receives a connection request from any client, and to submit the authentication task to the worker thread pool. The main thread returns immediately after submission to continue processing the next connection request. The main thread is used to receive connection requests. The worker thread pool refers to a set of worker threads pre-created in the gateway for asynchronously executing time-consuming tasks, including authentication logic. The verification result receiving module is used to receive the verification result returned by the worker thread pool after the authentication task is successfully verified; The target node determination module is used to generate an authentication token based on the verification result and determine the target node; A communication connection module is used to send a connection request carrying the authentication token to the target node so that the client can establish a communication connection with the target node. If a timeout occurs when sending the connection request carrying the authentication token to the target node or an error response is received, and the failure counter corresponding to the target node meets the preset circuit breaker conditions, the state machine corresponding to the target node will be switched to the circuit breaker state. When the state machine corresponding to the target node is in the circuit-broken state for a preset sleep time window, the state machine corresponding to the target node is switched to the half-open state.

10. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images