Method for websocket connection and message distribution of service cluster under micro-service architecture

Abstract

The embodiment of the application provides a method for service cluster websocket connection and message distribution under a micro-service architecture, a centralized cache is used to store the mapping relationship of the user account bound by each cluster server and the IP and port of the websocket server, the websocket server provides an HTTP interface for sending messages to other business service calls, the websocket server clusters communicate through a message forwarding HTTP interface, once the HTTP interface for sending messages of any websocket server is called, the websocket server will automatically find the websocket connection of itself or other servers, complete message sending, and the message sending is transparent and non-sensing to the calling end.

Description

Technical Field

[0001] This application relates to the field of data processing, specifically to a method for websocket connection and message distribution in a service cluster under a microservice architecture. Background Technology

[0002] In front-end and back-end communication scenarios based on a B / S architecture, timely communication is crucial, and WebSocket is often chosen. WebSocket is a communication protocol that allows persistent, bidirectional communication connections between clients and servers. Here are the main features and advantages of WebSocket technology: 1. Full-duplex communication: WebSocket provides true full-duplex communication, meaning that clients and servers can send and receive messages simultaneously without needing to establish a new connection for each request, unlike HTTP. 2. Low latency: Because a WebSocket connection remains open once established, data can be transmitted through this connection at any time, reducing latency. 3. Reduced bandwidth consumption: Compared to traditional polling or long polling, WebSocket only requires a single handshake to establish a connection, and subsequent message passing incurs minimal overhead, significantly reducing bandwidth usage. 4. Support for multiple data formats: WebSocket can transmit not only text data but also binary data, making it ideal for real-time applications such as online games, chat rooms, and stock market updates. 5. Cross-platform support: The WebSocket protocol has been widely supported, including modern browsers (such as Chrome, Firefox, Safari and Edge) and various server-side languages ​​(such as Java, Node.js and so on).

[0003] In a monolithic backend architecture, all WebSocket connections initiated by the frontend (browser) reside within this single backend service. When a business logic requires sending a message to the frontend (browser), it simply retrieves the corresponding WebSocket connection from the local service and calls the send method. However, in a high-user, high-concurrency application, the backend service might be multi-functional, employing a microservices architecture and clustered deployment. Due to resource limitations of a single server, WebSocket connections are evenly distributed across all cluster servers. If a backend service needs to send a message to a specific frontend, the location of the WebSocket connection for that message cannot be determined, hindering real-time communication between the backend and frontend. Therefore, in a microservices architecture, ensuring that the backend service correctly locates the WebSocket connection for communication with the frontend and sends messages, while maintaining simplicity and user-friendliness for the sending caller, is a pressing technical challenge. Summary of the Invention

[0004] To address the problems in the existing technology, this application provides a method for WebSocket connection and message distribution in a service cluster under a microservice architecture, so as to realize seamless forwarding and delivery of messages between different services in a WebSocket service cluster environment.

[0005] To solve at least one of the above problems, this application provides the following technical solution:

[0006] Firstly, this application provides a method for websocket connection and message distribution in a service cluster under a microservice architecture, applied to a websocket server, the method comprising:

[0007] The authentication service authenticates the user account of the logged-in client and generates a session identifier; a mapping relationship between the session identifier and the user account is established and stored in the first cache;

[0008] Receive a WebSocket connection request initiated by a client, and retrieve the corresponding user account from the first cache based on the session identifier carried by the client; store the mapping relationship between the retrieved user account and the successfully established WebSocket connection session object in local memory, and store the mapping relationship between the WebSocket server and the user account in the second cache;

[0009] The system calls the HTTP interface set on the WebSocket server to receive messages sent by the backend business service to the specified user, and checks whether there is a mapping relationship between the WebSocket connection session object corresponding to the specified user account stored in the local memory. If there is, it sends a message directly to the specified user account. If not, it retrieves the information of the target WebSocket server corresponding to the specified user account from the second cache, and forwards the message to the HTTP interface of the target WebSocket server. The target WebSocket server retrieves the WebSocket connection session object corresponding to the specified user account from its memory and sends a message to it.

[0010] Furthermore, the mapping relationship between the session identifier and the user account is stored in the hash data type of the first cache using the HSET command; the key for storing the hash is session:account, the field stores the session identifier, and the value stores the user account.

[0011] The mapping relationship between the user account and the successfully established WebSocket connection session object is stored in the memory of the WebSocket server using a HashMap data structure; the key of the HashMap is the user account, and the value is the WebSocket connection session object.

[0012] The mapping relationship between the WebSocket server and the user account is stored in the hash data type of the second cache using the HSET command; the key for storing the hash is websocket:account:server, the field stores the user account information, and the value stores the IP and port information of the WebSocket service.

[0013] Furthermore, the step of retrieving information about the target WebSocket server corresponding to the specified user account from the second cache and forwarding the message to the HTTP interface of the target WebSocket server includes:

[0014] Retrieve the IP and port information of the target WebSocket server from the second cache using the user account as a parameter;

[0015] The HTTP interface address of the target WebSocket server is constructed by concatenating the IP address and port information of the target WebSocket server according to a pre-defined format.

[0016] This triggers a call to the target WebSocket server's HTTP interface, forwarding the message sending request to the corresponding target WebSocket server's HTTP interface.

[0017] Furthermore, the session identifier is generated by the authentication service using JWT and includes the user account, validity period, and digital signature;

[0018] The step of receiving a WebSocket connection request initiated by a client and retrieving the corresponding user account from the first cache based on the session identifier carried by the request includes:

[0019] The session identifier in the request is parsed, the JWT header and payload are extracted, and the digital signature is verified using the public key provided by the authentication service.

[0020] Check if the validity period in the payload has expired; if the verification passes and the payload has not expired, allow the connection to be established; if the verification fails or the payload has expired, reject the connection request and return the corresponding error information to the client.

[0021] Furthermore, the method for websocket connection and message distribution in the service cluster under the microservice architecture also includes:

[0022] Set a timer in the code that establishes a connection between the client and the WebSocket server to send a ping frame to the WebSocket server at preset intervals;

[0023] Write a scheduled task using a scheduled task framework in the WebSocket server. At preset intervals, iterate through memory to check whether the connection between the user account and the WebSocket connection session object is open. If the connection is closed, remove the corresponding user account from the second cache and remove the WebSocket connection session object corresponding to that user account from memory.

[0024] Furthermore, the method for websocket connection and message distribution in the service cluster under the microservice architecture also includes:

[0025] When updating the mapping relationship between user accounts and WebSocket servers, the second cache executes the following two commands: stores the user account and WebSocket server address and port information into a Hash data structure; stores the user account and WebSocket server address and port information as key-value pairs into a String data structure and sets an expiration time.

[0026] It also includes: the second cache is sharded according to the hash value of the user account; when storing the mapping relationship between the user account and the server, a new key name is constructed according to the sharding rules, and then the mapping relationship is stored in the corresponding shard key.

[0027] Furthermore, the step of forwarding the message to the HTTP interface of the target WebSocket server includes:

[0028] A blocking queue is used to temporarily store messages that need to be forwarded across nodes. When a message needs to be forwarded, the message object is put into the blocking queue. The triggering condition for message forwarding is set. When the condition is met, batch sending is triggered. The batch sending refers to the message body composed of multiple messages taken from the blocking queue.

[0029] Secondly, this application provides a device for websocket connection and message distribution in a service cluster under a microservice architecture, comprising:

[0030] The connection establishment module is used to authenticate the user account of the login client through the authentication service and generate a session identifier; establish a mapping relationship between the session identifier and the user account, and store it in the first cache;

[0031] The connection caching module is used to receive the WebSocket connection request initiated by the client, and retrieve the corresponding user account from the first cache according to the session identifier carried by the request; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in local memory, and store the mapping relationship between the WebSocket server and the user account in the second cache.

[0032] The message sending module is used to call the HTTP interface set on the WebSocket server, receive messages sent by the backend business service to the specified user, and check whether there is a mapping relationship of WebSocket connection session object corresponding to the specified user account stored in the local memory. If there is, the message is sent directly to it; if not, the information of the target WebSocket server corresponding to the specified user account is obtained from the second cache, and the message is forwarded to the HTTP interface of the target WebSocket server. The target WebSocket server obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it.

[0033] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method for websocket connection and message distribution of a service cluster under the microservice architecture.

[0034] Fourthly, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method for websocket connection and message distribution in a service cluster under the microservice architecture.

[0035] Fifthly, this application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the method for websocket connection and message distribution in a service cluster under the microservice architecture.

[0036] As can be seen from the above technical solution, this application provides a method for service cluster WebSocket connection and message distribution under a microservice architecture. It uses a centralized cache to store the mapping relationship between user accounts bound to each cluster server and the IP and port of the WebSocket server. The backend server where the WebSocket is located provides an HTTP interface for sending messages for other business services to call. The WebSocket server cluster communicates with each other through a message forwarding HTTP interface. Once the HTTP interface for sending messages of any WebSocket server is called, the WebSocket server will automatically find its own or other server's WebSocket connection to complete the message sending. Moreover, the message sending is transparent and imperceptible to the calling end. Attached Figure Description

[0037] 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, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a flowchart illustrating the method for websocket connection and message distribution in a service cluster under a microservice architecture as described in this application embodiment.

[0039] Figure 2 A schematic diagram illustrating the process of establishing a WebSocket connection for a service cluster under the microservice architecture in this application embodiment;

[0040] Figure 3 This is a schematic diagram illustrating the session identifier and account mapping hash caching of the service cluster websocket connection and message distribution method under the microservice architecture in this application embodiment;

[0041] Figure 4 This is a schematic diagram illustrating the user account and websocket service IP, port mapping, hash caching of websocket:account:server in the service cluster websocket connection and message distribution method under the microservice architecture in this application embodiment;

[0042] Figure 5 A schematic diagram illustrating the message distribution process for the service cluster under the microservice architecture in this application embodiment;

[0043] Figure 6This is a structural diagram of the device for service cluster websocket connection and message distribution under the microservice architecture in this application embodiment;

[0044] Figure 7 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.

[0045] Figure label:

[0046] Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation

[0047] 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.

[0048] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0049] In view of the problems existing in the prior art, this application provides a method for service cluster WebSocket connection and message distribution in a microservice architecture. It adopts a centralized cache to store the mapping relationship between user accounts bound to each cluster server and the IP and port of the WebSocket server. The backend server where the WebSocket is located provides an HTTP interface for sending messages for other business services to call. The WebSocket server cluster communicates with each other through a message forwarding HTTP interface. Once the message sending HTTP interface of any WebSocket server is called, the WebSocket server will automatically find its own or other server's WebSocket connection to complete the message sending. Moreover, the message sending is transparent and imperceptible to the calling end.

[0050] To achieve seamless message forwarding and delivery between different services in a WebSocket service cluster environment, this application provides an embodiment of a method for WebSocket connection and message distribution in a service cluster under a microservice architecture. See [link to embodiment]. Figure 1The method for websocket connection and message distribution in the service cluster under the microservice architecture specifically includes the following:

[0051] Step S101: Authenticate the user account of the login client through the authentication service and generate a session identifier; establish the mapping relationship between the session identifier and the user account, and store it in the first cache.

[0052] In this embodiment, this step provides the process for establishing a WebSocket connection, refer to... Figure 2 As shown, in Figure 2 In the "login authentication" sub-process, after successful login, the WebSocket server's authentication service generates a session identifier and maps it to the login account. This facilitates the retrieval of the logged-in user account in subsequent processes using the session identifier carried in frontend requests. The mapping information is stored in a Redis cached hash data type using the HSET command. The key for storing the hash is `session:account`, the field stores the session identifier, and the value stores the user account (see storage data structure). Figure 3 (As shown).

[0053] In this embodiment, HSET is a Redis command used to operate on hash data types. The following is a detailed description of the HSET command:

[0054] Command format: HSET key field value [field value ...]

[0055] Function Description: The HSET command allows you to store one or more key-value pairs into a specified hash table.

[0056] Parameter description: key: The name of the hash table. field: The field name in the hash table. value: The value corresponding to the field.

[0057] Return value: Returns 1 if the field is newly created and set successfully. Returns 0 if the field already exists and its value has been updated.

[0058] Optionally, in this embodiment, the session identifier can be generated by the authentication service using JWT, and includes the user account, validity period, and digital signature. The header describes information such as the signature algorithm used; the payload contains declarations such as the user account and token expiration time, which are crucial for message distribution; the signature is used to verify the integrity and authenticity of the token, preventing the session identifier from being tampered with, thereby ensuring that only legitimate users can establish a WebSocket connection through authentication.

[0059] Specifically, when a WebSocket connection request is received, the WebSocket server first parses the session identifier in the request, extracts the JWT header and payload, and verifies the signature using the public key provided by the authentication service. Simultaneously, it checks if the expiration time in the payload has expired. If the verification passes and the session identifier has not expired, the connection is allowed; if the verification fails or the session identifier has expired, the connection request is rejected and a corresponding error message is returned to the client. This mechanism prevents unauthorized users from impersonating others or tampering with the session identifier to gain connection privileges, improving system security and reducing the number of times the first cache is queried due to invalid session identifiers, thus reducing system query pressure and resource consumption.

[0060] Optionally, in this embodiment, a custom field X-Request-ID can be added to the HTTP request header in the code that initiates the WebSocket message sending request on the client side. The value of X-Request-ID is a globally unique request identifier. This identifier can be generated using UUID (Universally Unique Identifier) ​​or other algorithms for generating unique IDs. Simultaneously, in each processing node of the WebSocket service (such as request reception, message forwarding, etc.), the logging code is modified to include the value of the X-Request-ID field when logging. For example, the log output statement can be recorded in the following format: 2023-08-25 10:00:00 [X-Req-12345] User A's message started processing -> forwarded to node. This client-server processing enables contextual transmission of the request, allowing the system to associate the logs of each node throughout the entire request processing process using the unique identifier X-Request-ID. This facilitates quick location of the complete request flow during troubleshooting, improving troubleshooting efficiency.

[0061] Step S102: Receive the websocket connection request initiated by the client, and retrieve the corresponding user account from the first cache according to the session identifier carried by the client; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in local memory, and store the mapping relationship between the websocket server and the user account in the second cache.

[0062] Optional, continue to refer to Figure 2 As shown, when the frontend initiates a WebSocket connection establishment request, it carries a session identifier. In the sub-process of "receiving WebSocket connection establishment request", the HGET command cached in Redis is used to pass the session identifier. Figure 3The `session:account` method retrieves the user account mapped to the session. Then, it maps the user account to the successfully established WebSocket connection session within the service. This mapping information is stored in the WebSocket service's in-memory object `userSessionMap` using a Java HashMap data structure. Its purpose is to allow the service to find the WebSocket connection using the user account when sending messages, ensuring a connection can be obtained before sending messages. The HashMap's key is the user account, and the value is the WebSocket connection session object. The Java code implementation is `ConcurrentHashMap`.<String,WebSocketSession> userSessionMap = new ConcurrentHashMap<>();

[0063] Since the WebSocket service is clustered, the HashMap cache within the service in the previous step only stores WebSocket connection session objects for a portion of user accounts. To ensure that the message is sent without the caller's awareness, message forwarding needs to be implemented within the cluster. Therefore, in order to find the target WebSocket service for forwarding, the "receiving WebSocket connection establishment request" sub-process also needs to cache the mapping relationship between the current WebSocket server's IP address, port, and user account in Redis. This mapping relationship information is stored in a hash data type in the Redis cache using the HSET command. The key for storing the hash is websocket:account:server, the field stores the user account information, and the value stores the IP address and port information of the WebSocket service (see storage data structure). Figure 4 ).

[0064] For example, refer to Figure 2 As shown, the specific workflow for establishing and caching a WebSocket connection is as follows:

[0065] User login authentication: The user initiates a login request on the front end, and the back end authentication service verifies the user's identity. After successful login, the authentication service generates a session identifier and associates it with the user's account.

[0066] Session ID caching: The authentication service uses Redis's HSET command to store the mapping between session IDs and user accounts in a Redis hash table. The key of the hash table is session:account, the field is the session ID, and the value is the user account. The authentication service returns the generated session ID to the frontend, which can then store it locally.

[0067] The frontend initiates a WebSocket connection request: The frontend uses a request carrying a session identifier to initiate a WebSocket connection. The session identifier carried in the request is used by the backend to identify the user. After receiving the request, the WebSocket service retrieves the user account corresponding to the session identifier from the session:account hash table in Redis using the HGET command.

[0068] Establishing a WebSocket connection: First, the user's identity is verified. If the user account is successfully retrieved from Redis, the session identifier is valid, and user authentication is successful. Then, the WebSocket service establishes a WebSocket connection with the frontend. After a successful connection establishment, the WebSocket service creates a mapping in local memory, associating the user account with the WebSocket connection session object. Specifically, Java's ConcurrentHashMap can be used, with the user account as the key and the WebSocket connection session object as the value.

[0069] Storing connection information in Redis: To support cross-service message forwarding, the WebSocket service also needs to store the mapping relationship between the current service's IP and port and user accounts in Redis. The HSET command is used to store this information in the websocket:account:server hash table. When other services need to send messages to this user, they can query the websocket:account:server hash table to find the target WebSocket service's IP and port, thus achieving cross-service message forwarding.

[0070] Connection established: The WebSocket service sends an acknowledgment message to the frontend, notifying it that the WebSocket connection has been successfully established. Upon receiving the acknowledgment message, the frontend can begin sending and receiving real-time messages through the WebSocket connection.

[0071] In this embodiment, HGET is a Redis command used to manipulate hash data types. The following is a detailed introduction to the HGET command:

[0072] Command format: HGET key field.

[0073] Function Description: The HGET command is used to retrieve the value associated with a field stored in a hash set containing a specified key.

[0074] Parameter description: key: The name of the hash table. field: The name of the field in the hash table.

[0075] Return value: If the given field exists in the hash set, return the value corresponding to that field. If the field does not exist, return nil.

[0076] Optionally, in this embodiment, to enhance connection management, a timer is set in the code that establishes the connection between the frontend and the WebSocket service. Every preset time, such as 30 seconds, a ping frame is sent to the WebSocket service. This operation can be implemented using the `send` method of the WebSocket API, for example: `websocket.send(JSON.stringify({ type:'ping'}))`. On the WebSocket server side, a scheduled task is written using a scheduled task framework (such as Spring's `@Scheduled` annotation). Every preset time, such as 5 minutes, the `userSessionMap` is scanned to check the `isOpen` state of each WebSocketSession object. If it is closed, the Redis `hdel` command is called to remove the corresponding user account (field) from the `websocket:account:server` hash data structure and remove the corresponding WebSocketSession object from the `userSessionMap` in memory. This ensures timely detection and cleanup of zombie connections, preventing the ineffective occupation of memory and Redis resources.

[0077] Furthermore, logic can be added to the WebSocket close callback method. For example, a close callback listener can be added to each WebSocketSession object. When the connection is closed, the Redis hdel command is called to remove the corresponding user account (field) from the websocket:account:server hash data structure; the WebSocketSession object corresponding to that user account is removed from the userSessionMap in memory; and a log is recorded, outputting the user account whose connection was abnormally closed and the reason for the closure (obtained from the callback parameters). This ensures that the state information in Redis and memory is updated in a timely manner when the connection is abnormally closed, guaranteeing the consistency of metadata and avoiding incorrect message sending targets.

[0078] Optionally, this embodiment also optimizes the second cache, Redis. Specifically, when updating the mapping relationship between user accounts and WebSocket servers, in addition to using the HSET command to store the information in the websocket:account:server hash data structure, the SET command can also be used simultaneously to store the user account and server information as key-value pairs in a STRING type key. The key name can be set to userA:websocket, and an expiration time can be set, such as 86400 seconds, or 24 hours. This setting makes it more convenient to use the HSET hash structure when batch querying server information corresponding to multiple user accounts; while when quickly querying server information corresponding to a single user account, directly querying the STRING type key is faster, thereby reducing the performance pressure that may occur when reading large hashes.

[0079] Furthermore, in this embodiment, the hotspot key can be further split. Specifically, based on the hash value of the last digit of the user ID, the key `websocket:account:server` is split into multiple shards. For example, the hashCode of the user ID can be modulo 10 to obtain 10 shard identifiers from 0 to 9. Then, the corresponding mapping relationships are stored in 10 different hash keys from `websocket:account:server:0` to `websocket:account:server:9`. By splitting the hotspot key into multiple shards, the access traffic that was originally concentrated on a single key can be distributed across multiple keys, thereby reducing the access pressure on a single key in the Redis cluster.

[0080] Step S103: Call the HTTP interface set on the WebSocket server to receive the message sent by the backend business service to the specified user, and check whether there is a mapping relationship of WebSocket connection session object corresponding to the specified user account stored in the local memory; if there is, send the message directly to it; if not, retrieve the information of the target WebSocket server corresponding to the specified user account from the second cache, and forward the message to the HTTP interface of the target WebSocket server. The target WebSocket server retrieves the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it.

[0081] In this embodiment, the background WebSocket message sending relies on the WebSocket connection establishment in the first step and the caching of WebSocket connection and service mapping information in the second step. For details, please refer to [link / reference needed]. Figure 5As shown below, the message sending process is described in detail:

[0082] 1. When a backend business service needs to send a message to a specified user, it calls the WebSocket message sending HTTP interface GET / sendMsgByWebsocket?account={}&msgType={}&msg={}. The interface mainly has three parameters: user account, message type, and message content.

[0083] 2. After receiving the above three parameters, the message sending interface of the WebSocket service checks whether there is a WebSocketSession object corresponding to the specified user account in the userSessionMap in the internal memory of this service. If there is, it means that the WebSocket connection of this user was established in the current service. You can directly call the send method of WebSocketSession to send the message.

[0084] 3. If the user is not found in the userSessionMap, it means that the user's WebSocket connection was established under another WebSocket service. In this case, the user account parameters need to be passed via the HGET command to obtain the IP and port information of the target WebSocket service from the websocket:account:server cache. Then, the address of the WebSocket cluster's internal message forwarding HTTP interface is concatenated, such as http: / / {ip}:{port} / forwardSendMsgByWebsocket?account={}&msgType={}&msg={}, and then the call to this forwarding interface is triggered.

[0085] The target WebSocket service obtains the corresponding parameter information from its internal message forwarding interface, retrieves the WebSocketSession object corresponding to the specified user account directly from the memory object userSessionMap, and then calls the WebSocketSession's send method to send the message.

[0086] For example, refer to Figure 5 As shown, the specific workflow for sending WebSocket messages in the background is as follows:

[0087] The business service initiates a message sending request: The business service sends real-time messages (such as order status updates, new message notifications, etc.) to a specific user. The business service calls the HTTP interface provided by the WebSocket service, passing the following parameters: User account: Specifies the user to receive the message; Message type: The type of message used by the front end to distinguish message processing logic; Message content: The actual message content to be sent.

[0088] The WebSocket service receives requests: The WebSocket service's message sending interface receives the parameters (user account, message type, message content) passed by the business service. It then checks the local cache. The WebSocket service first searches in the local memory's userSessionMap (a ConcurrentHashMap that stores the mapping between user accounts and WebSocket connection session objects) to see if a WebSocketSession object corresponding to the specified user account exists. If it exists, it means that the user's WebSocket connection was established on the current service instance, and the process proceeds directly to the next step; if it does not exist, it means that the user's WebSocket connection was established on another WebSocket service instance, and further operations are required.

[0089] To query the target WebSocket service instance: If the corresponding WebSocketSession object is not found in the local cache, the WebSocket service uses the Redis HGET command to query the websocket:account:server hash table for the IP and port information of the WebSocket service instance corresponding to the specified user account. The return value is the IP and port of the target WebSocket service instance.

[0090] Message forwarding: If the IP and port information of the target WebSocket service instance are found, it indicates that the user's WebSocket connection is on another service instance. The WebSocket service appends the message forwarding HTTP interface address of the target service instance and forwards the message sending request to the target service instance. The message sending request is then passed to the target service instance by calling the forwarding interface through an HTTP client.

[0091] The target WebSocket service processes the message: After receiving the forwarded message send request, the target WebSocket service extracts the user account, message type, and message content from the request parameters. The target service then searches for the WebSocketSession object corresponding to the specified user account in its local memory's userSessionMap. Once the corresponding WebSocketSession object is found, its send method is called to send the message to the user.

[0092] Message delivery: The user's front-end client (such as a browser) receives the message via a WebSocket connection. The front-end processes the message according to its type (msgType), such as displaying a notification or updating page content.

[0093] Optionally, in this embodiment, a blocking queue can also be used in the WebSocket service to temporarily store messages that need to be forwarded across nodes. For example: LinkedBlockingQueue <message>`queue = new LinkedBlockingQueue<>()` adds message objects to the blocking queue when message forwarding is needed. Simultaneously, a scheduled task or checking the queue size and time interval after each message enqueue can trigger batch sending when either of the following conditions is met: the number of messages in the queue reaches 10; or the waiting time since the last send exceeds 50ms. The batch sending logic involves retrieving multiple messages (e.g., 10 at a time) from the blocking queue, assembling them into a single batch message body, and sending it to the target WebSocket service's forwarding interface via an HTTP client. This batch pipeline forwarding reduces the number of HTTP requests across nodes, improves message forwarding throughput, and also mitigates the impact of network latency on message sending efficiency to some extent.

[0094] As can be seen from the above description, the method for service cluster websocket connection and message distribution under microservice architecture provided in this application embodiment can store the mapping relationship between user accounts bound to each cluster server and the IP and port of the websocket server by using a centralized cache. The backend server where the websocket is located provides an HTTP interface for sending messages for other business services to call. The websocket server cluster communicates with each other through a message forwarding HTTP interface. Once the HTTP interface for sending messages of any websocket server is called, the websocket server will automatically find its own or other server's websocket connection to complete the message sending. Moreover, the message sending is transparent and imperceptible to the calling end.

[0095] To achieve seamless message forwarding and delivery between different services in a WebSocket service cluster environment, this application provides an embodiment of an apparatus for implementing all or part of the method for service cluster WebSocket connection and message distribution in a microservice architecture. See [link to relevant documentation]. Figure 6 The device for websocket connection and message distribution in the service cluster under the microservice architecture specifically includes the following components:

[0096] The feature fusion module 10 is used to authenticate the user account of the login client through the authentication service and generate a session identifier; establish a mapping relationship between the session identifier and the user account, and store it in the first cache;

[0097] The model evaluation module 20 is used to receive the websocket connection request initiated by the client, and obtain the corresponding user account from the first cache according to the session identifier carried by the client; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in local memory, and store the mapping relationship between the websocket server and the user account in the second cache.

[0098] The automatic adjustment module 30 is used to call the HTTP interface set on the WebSocket server, receive messages sent by the backend business service to the specified user, and check whether there is a mapping relationship of WebSocket connection session object corresponding to the specified user account stored in the local memory. If there is, the message is sent directly to it; if not, the information of the target WebSocket server corresponding to the specified user account is obtained from the second cache, and the message is forwarded to the HTTP interface of the target WebSocket server. The target WebSocket server obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it.

[0099] As can be seen from the above description, the device for service cluster websocket connection and message distribution under microservice architecture provided in this application embodiment can use centralized caching to store the mapping relationship between user accounts bound to each cluster server and the IP and port of the websocket server. The backend server where the websocket is located provides an HTTP interface for sending messages for other business services to call. The websocket server cluster communicates with each other through a message forwarding HTTP interface. Once the HTTP interface for sending messages of any websocket server is called, the websocket server will automatically find its own or other server's websocket connection to complete the message sending. Moreover, the message sending is transparent and imperceptible to the calling end.

[0100] From a hardware perspective, in order to achieve seamless message forwarding and delivery between different services in a WebSocket service cluster environment, this application provides an embodiment of an electronic device for implementing all or part of the method for service cluster WebSocket connection and message distribution under the microservice architecture. The electronic device specifically includes the following components:

[0101] The system comprises a processor, memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to transmit information between the device for service cluster WebSocket connection and message distribution under a microservice architecture and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the method for service cluster WebSocket connection and message distribution under a microservice architecture, and the embodiments of the device for service cluster WebSocket connection and message distribution under a microservice architecture, the contents of which are incorporated herein by reference, and repeated details will not be described again.

[0102] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0103] In practical applications, the methods for WebSocket connection and message distribution in a microservice architecture service cluster can be executed on the electronic device side as described above, or all operations can be completed on the client device. The choice can be made based on the processing power of the client device and the limitations of the user scenario. This application does not impose any limitations on this. If all operations are completed on the client device, the client device may further include a processor.

[0104] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0105] Figure 7 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 7 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 7 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0106] In one embodiment, the methods and functionalities for WebSocket connection and message distribution in a microservice architecture can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following controls:

[0107] Step S101: Authenticate the user account of the logged-in client through the authentication service and generate a session identifier; establish a mapping relationship between the session identifier and the user account, and store it in the first cache;

[0108] Step S102: Receive the websocket connection request initiated by the client, and retrieve the corresponding user account from the first cache according to the session identifier carried by the client; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in local memory, and store the mapping relationship between the websocket server and the user account in the second cache;

[0109] Step S103: Call the HTTP interface set on the WebSocket server to receive the message sent by the backend business service to the specified user, and check whether there is a mapping relationship of WebSocket connection session object corresponding to the specified user account stored in the local memory; if there is, send the message directly to it; if not, retrieve the information of the target WebSocket server corresponding to the specified user account from the second cache, and forward the message to the HTTP interface of the target WebSocket server. The target WebSocket server retrieves the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it.

[0110] As can be seen from the above description, the electronic device provided in this application embodiment uses a centralized cache to store the mapping relationship between user accounts bound to each cluster server and the IP and port of the WebSocket server. The backend server where the WebSocket is located provides an HTTP interface for sending messages for other business services to call. The WebSocket server cluster communicates with each other through a message forwarding HTTP interface. Once any WebSocket server's HTTP interface for sending messages is called, the WebSocket server will automatically find its own or other server's WebSocket connection to complete the message sending. Moreover, the message sending is transparent and imperceptible to the calling end.

[0111] In another implementation, the device for websocket connection and message distribution of the service cluster under the microservice architecture can be configured separately from the central processing unit 9100. For example, the device for websocket connection and message distribution of the service cluster under the microservice architecture can be configured as a chip connected to the central processing unit 9100, and the method and function of websocket connection and message distribution of the service cluster under the microservice architecture can be implemented through the control of the central processing unit.

[0112] like Figure 7 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 7 All components shown; in addition, the electronic device 9600 may also include Figure 7 For components not shown, please refer to existing technologies.

[0113] like Figure 7 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.

[0114] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0115] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0116] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0117] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0118] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 (transmitter / receiver) is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0119] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 (transmitter / receiver) is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 9130 is coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored audio via the speaker 9131.

[0120] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the method for websocket connection and message distribution of a service cluster under a microservice architecture where the execution subject is a server or client, as described in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the method for websocket connection and message distribution of a service cluster under a microservice architecture where the execution subject is a server or client, as described in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0121] Step S101: Authenticate the user account of the logged-in client through the authentication service and generate a session identifier; establish a mapping relationship between the session identifier and the user account, and store it in the first cache;

[0122] Step S102: Receive the websocket connection request initiated by the client, and retrieve the corresponding user account from the first cache according to the session identifier carried by the client; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in local memory, and store the mapping relationship between the websocket server and the user account in the second cache;

[0123] Step S103: Call the HTTP interface set on the WebSocket server to receive the message sent by the backend business service to the specified user, and check whether there is a mapping relationship of WebSocket connection session object corresponding to the specified user account stored in the local memory; if there is, send the message directly to it; if not, retrieve the information of the target WebSocket server corresponding to the specified user account from the second cache, and forward the message to the HTTP interface of the target WebSocket server. The target WebSocket server retrieves the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it.

[0124] As can be seen from the above description, the computer-readable storage medium provided in this application embodiment uses a centralized cache to store the mapping relationship between user accounts bound to each cluster server and the IP and port of the WebSocket server. The backend server where the WebSocket is located provides an HTTP interface for sending messages for other business services to call. The WebSocket server cluster communicates with each other through a message forwarding HTTP interface. Once any WebSocket server's HTTP interface for sending messages is called, the WebSocket server will automatically find its own or other server's WebSocket connection to complete the message sending. Moreover, the message sending is transparent and imperceptible to the calling end.

[0125] Embodiments of this application also provide a computer program product capable of implementing all steps of the method for websocket connection and message distribution of a service cluster under a microservice architecture where the execution subject is a server or client, as described in the above embodiments. When executed by a processor, this computer program / instruction implements the steps of the method for websocket connection and message distribution of a service cluster under a microservice architecture. For example, the computer program / instruction implements the following steps:

[0126] Step S101: Authenticate the user account of the logged-in client through the authentication service and generate a session identifier; establish a mapping relationship between the session identifier and the user account, and store it in the first cache;

[0127] Step S102: Receive the websocket connection request initiated by the client, and retrieve the corresponding user account from the first cache according to the session identifier carried by the client; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in local memory, and store the mapping relationship between the websocket server and the user account in the second cache;

[0128] Step S103: Call the HTTP interface set on the WebSocket server to receive the message sent by the backend business service to the specified user, and check whether there is a mapping relationship of WebSocket connection session object corresponding to the specified user account stored in the local memory; if there is, send the message directly to it; if not, retrieve the information of the target WebSocket server corresponding to the specified user account from the second cache, and forward the message to the HTTP interface of the target WebSocket server. The target WebSocket server retrieves the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it.

[0129] As can be seen from the above description, the computer program product provided in this application uses a centralized cache to store the mapping relationship between user accounts bound to each cluster server and the IP and port of the WebSocket server. The backend server where the WebSocket is located provides an HTTP interface for sending messages for other business services to call. The WebSocket server cluster communicates with each other through a message forwarding HTTP interface. Once any WebSocket server's HTTP interface for sending messages is called, the WebSocket server will automatically find its own or other server's WebSocket connection to complete the message sending. Moreover, the message sending is transparent and imperceptible to the calling end.

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

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

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

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

[0134] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.< / message>

Claims

1. A method for websocket connection and message distribution in a service cluster under a microservice architecture, applied to a websocket server, characterized in that, The method includes: The authentication service authenticates the user account of the logged-in client and generates a session identifier; a mapping relationship between the session identifier and the user account is established and stored in the first cache; Receive a WebSocket connection request initiated by a client, and retrieve the corresponding user account from the first cache based on the session identifier carried by the client; store the mapping relationship between the retrieved user account and the successfully established WebSocket connection session object in local memory, and store the mapping relationship between the WebSocket server and the user account in the second cache; The system calls the HTTP interface set on the WebSocket server to receive messages sent by the backend business service to the specified user, and checks whether there is a mapping relationship between the WebSocket connection session object corresponding to the specified user account stored in the local memory. If there is, it sends a message directly to the specified user account. If not, it retrieves the information of the target WebSocket server corresponding to the specified user account from the second cache, and forwards the message to the HTTP interface of the target WebSocket server. The target WebSocket server retrieves the WebSocket connection session object corresponding to the specified user account from its memory and sends a message to the specified user account. The step of retrieving information about the target WebSocket server corresponding to the specified user account from the second cache and forwarding the message to the HTTP interface of the target WebSocket server includes: Retrieve the IP and port information of the target WebSocket server from the second cache using the user account as a parameter; The HTTP interface address of the target WebSocket server is constructed by concatenating the IP address and port information of the target WebSocket server according to a pre-defined format. This triggers a call to the target WebSocket server's HTTP interface, forwarding the message sending request to the corresponding target WebSocket server's HTTP interface.

2. The method for websocket connection and message distribution in a service cluster under a microservice architecture according to claim 1, characterized in that: The mapping relationship between the session identifier and the user account is stored in the hash data type of the first cache using the HSET command; the key for storing the hash is session:account, the field stores the session identifier, and the value stores the user account. The mapping relationship between the user account and the successfully established WebSocket connection session object is stored in the memory of the WebSocket server using a HashMap data structure; the key of the HashMap is the user account, and the value is the WebSocket connection session object. The mapping relationship between the WebSocket server and the user account is stored in the hash data type of the second cache using the HSET command; the key for storing the hash is websocket:account:server, the field stores the user account information, and the value stores the IP and port information of the WebSocket service.

3. The method for service cluster websocket connection and message distribution under a microservice architecture according to claim 1, characterized in that, The session identifier is generated by the authentication service using JWT and includes the user account, validity period, and digital signature. The step of receiving a WebSocket connection request initiated by a client and retrieving the corresponding user account from the first cache based on the session identifier carried by the request includes: The session identifier in the request is parsed, the JWT header and payload are extracted, and the digital signature is verified using the public key provided by the authentication service. Check if the validity period in the payload has expired; if the verification passes and the payload has not expired, allow the connection to be established; if the verification fails or the payload has expired, reject the connection request and return the corresponding error information to the client.

4. The method for service cluster websocket connection and message distribution under a microservice architecture according to claim 1, characterized in that, Also includes: Set a timer in the code that establishes a connection between the client and the WebSocket server to send a ping frame to the WebSocket server at preset intervals; Write a scheduled task using a scheduled task framework in the WebSocket server to traverse memory at preset intervals to check whether the connection between the user account and the WebSocket connection session object is open. If the connection has been closed, remove the corresponding user account from the second cache and remove the WebSocket connection session object corresponding to that user account from memory.

5. The method for service cluster websocket connection and message distribution under a microservice architecture according to claim 1, characterized in that, Also includes: When updating the mapping relationship between user accounts and WebSocket servers, the second cache executes the following two commands: stores the user account and WebSocket server address and port information into a Hash data structure; Store the user account and WebSocket server address and port information as key-value pairs in a String data structure, and set an expiration time; It also includes: the second cache is fragmented based on the hash value of the user account; When storing the mapping relationship between user accounts and servers, a new key name is constructed according to the sharding rules, and then the mapping relationship is stored in the corresponding shard key.

6. The method for service cluster websocket connection and message distribution under a microservice architecture according to claim 1, characterized in that, The step of forwarding the message to the HTTP interface of the target WebSocket server includes: A blocking queue is used to temporarily store messages that need to be forwarded across nodes. When a message needs to be forwarded, the message object is put into the blocking queue. The triggering condition for message forwarding is set. When the condition is met, batch sending is triggered. The batch sending refers to the message body composed of multiple messages taken from the blocking queue.

7. A device for websocket connection and message distribution in a service cluster under a microservice architecture, characterized in that, The device includes: The connection establishment module is used to authenticate the user account of the login client through the authentication service and generate a session identifier; establish a mapping relationship between the session identifier and the user account, and store it in the first cache; The connection caching module is used to receive the WebSocket connection request initiated by the client, and retrieve the corresponding user account from the first cache according to the session identifier carried by the request; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in local memory, and store the mapping relationship between the WebSocket server and the user account in the second cache. The message sending module is used to call the HTTP interface set on the WebSocket server, receive messages sent by the backend business service to a specified user, and check whether a mapping relationship of the WebSocket connection session object corresponding to the specified user account is stored in the local memory. If it exists, the message is sent directly to it; if not, the information of the target WebSocket server corresponding to the specified user account is obtained from the second cache, and the message is forwarded to the HTTP interface of the target WebSocket server. The target WebSocket server obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it. The step of obtaining the information of the target WebSocket server corresponding to the specified user account from the second cache and forwarding the message to the HTTP interface of the target WebSocket server includes: obtaining the IP and port information of the target WebSocket server from the second cache with the user account as a parameter; concatenating the IP and port information of the target WebSocket server to form the HTTP interface address of the target WebSocket server according to a pre-set format; triggering the call to the HTTP interface of the target WebSocket server and forwarding the message sending request to the corresponding HTTP interface of the target WebSocket server.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method for websocket connection and message distribution of service cluster under microservice architecture as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method for websocket connection and message distribution in a service cluster under a microservice architecture as described in any one of claims 1 to 6.

Images