Service cluster websocket connection and message distribution method under micro-service architecture

Abstract

The embodiment of the invention provides a service cluster websocket connection and message distribution method under a micro-service architecture, a centralized cache is adopted to store a mapping relationship between a user account bound to each cluster server and an ip and a port of a websocket server, and a background server where a websocket is located provides an HTTP interface for sending a message to other business services for calling. The websocket server clusters communicate with each other through an HTTP interface for forwarding a message, once the HTTP interface for sending the message of any websocket server is called, the server where the websocket is located can automatically find the websocket connection of the server or other servers, message sending is completed, and message sending is transparent and non-inductive to a calling end.

Description

Technical Field

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

[0002] In the front-end and back-end communication scenarios based on B / S architecture, in order to have timely communication, the websocket solution is usually chosen. WebSocket is a communication protocol that allows a persistent, two-way communication connection to be established between the client and the server. The following are the main features and advantages of WebSocket technology: 1. Full-duplex communication: WebSocket provides true full-duplex communication, which means that the client and server can send and receive messages at the same time, without the need to establish a new connection for each request like HTTP. 2. Low latency: Since the WebSocket connection remains open once established, data can be transmitted through this connection at any time, thereby reducing latency. 3. Reduced bandwidth consumption: Compared with traditional polling or long polling, WebSocket only requires one handshake to establish a connection, and subsequent message delivery requires only a small overhead, which greatly reduces bandwidth usage. 4. Support for multiple data formats: WebSocket can transmit not only text data, but also binary data, which makes it very suitable for real-time applications such as online games, chat rooms, stock market updates, etc. 5. Cross-platform support: The WebSocket protocol is widely supported, including modern browsers (such as Chrome, Firefox, Safari, and Edge) and various server-side languages ​​​​(such as Java, Node.js, etc.).

[0003] In the case of a monolithic architecture of the backend service, all websocket connections initiated by the frontend (browser) are in this backend service. If the business needs to send a message to the frontend (browser), the corresponding websocket connection can be directly obtained from the local service, and then the sending method can be called; however, if in an application with a large number of users and high concurrency, the backend service is not just one service, but will use microservices and other architectures, and the backend service will be deployed in a cluster. Then, due to the resource limitations of a single server, the websocket connection will be evenly distributed to all cluster servers. If a backend service needs to send a message to a specified frontend, the location of the websocket connection to be sent cannot be determined at this time, and instant communication from the backend to the frontend cannot be achieved. Therefore, under the microservice architecture, how to enable the backend service to correctly locate the websocket connection location for communicating with the frontend and send messages, and how to make it simple and friendly to the sender and caller, is a technical problem that needs to be solved urgently. Summary of the invention

[0004] In response to the problems in the prior art, the present application provides a method for service cluster websocket connection and message distribution under a microservice architecture, so as to realize seamless forwarding and delivery of messages between different services in a WebSocket service cluster environment.

[0005] In order to solve at least one of the above problems, the present application provides the following technical solutions: In a first aspect, the present application provides a method for websocket connection and message distribution of a service cluster under a microservice architecture, which is applied to a websocket server, and the method includes: Authenticate the user account of the logging 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 a first cache; Receive a websocket connection request initiated by a client, and obtain 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 the local memory, and store the mapping relationship between the websocket server and the user account in the second cache; The HTTP interface set on the websocket server is called to receive a message sent by the background business service to the specified user, and to detect whether a mapping relationship between the WebSocket connection session object corresponding to the specified user account is stored in the local memory; if so, 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, and the target websocket server obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends a message to it.

[0006] 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; 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.

[0007] Further, 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: Obtain the IP and port information of the target WebSocket server from the second cache with the user account as a parameter; According to the preset format, concatenate the IP and port information of the target WebSocket server to form the HTTP interface address of the target websocket server; Trigger the call to the HTTP interface of the target websocket server, and forward the message sending request to the HTTP interface of the corresponding target WebSocket server.

[0008] Further, the session identifier is generated by the authentication service using JWT and includes the user account, the validity period, and the digital signature; The step of receiving the websocket connection request initiated by the client and obtaining the corresponding user account from the first cache according to the carried session identifier includes: Parse the session identifier in the request, extract the header and payload of the JWT, and verify the digital signature using the public key provided by the authentication service; Check whether the validity period in the payload has expired; if the verification is passed and not expired, allow the connection to be established; if the verification fails or has expired, reject the connection request and return the corresponding error message to the client.

[0009] Further, the method for websocket connection and message distribution of the service cluster under the microservice architecture further includes: Set a timer in the code for establishing a connection between the client and the WebSocket server, and send a ping frame to the WebSocket server every preset time; Write a scheduled task in the WebSocket server using the scheduled task framework to traverse the memory every preset time to check whether the connection between the user account and the WebSocket connection session object is in an open state; if the connection is closed, remove the corresponding user account from the second cache and remove the WebSocket connection session object corresponding to the user account from the memory.

[0010] Further, the method for websocket connection and message distribution of the service cluster under the microservice architecture further includes: When the second cache updates the mapping relationship between the user account and the WebSocket server, the following two commands are executed: storing the user account and the WebSocket server address and port information into a Hash data structure; storing the user account and the WebSocket server address and port information as key-value pairs into a String data structure and setting an expiration time; It further 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 rule, and then the mapping relationship is stored into the corresponding sharded Key.

[0011] Further, the step of forwarding the message to the HTTP interface of the target websocket server includes: Using a blocking queue to temporarily store the messages that need to be forwarded across nodes. When a message needs to be forwarded, the message object is put into the blocking queue; setting a triggering condition for message forwarding, and when the condition is met, batch sending is triggered; the batch sending is a message body assembled from multiple messages taken out from the blocking queue.

[0012] In a second aspect, the present application provides a device for websocket connection and message distribution of a service cluster under a microservice architecture, including: A connection establishment module, configured to authenticate the user account of the logged-in client through an authentication service and generate a session identifier; establish a mapping relationship between the session identifier and the user account, and store it in a first cache; A connection cache module, configured to receive a websocket connection request initiated by a client, and obtain the corresponding user account from the first cache according to the carried session identifier; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object into local memory, and store the mapping relationship between the websocket server and the user account into a second cache; A message sending module is used to call the HTTP interface set on the websocket server, receive messages sent by the background business service to a specified user, and detect whether there is a mapping relationship of a WebSocket connection session object corresponding to the specified user account stored in the local memory; if so, directly send the message to it; if not, obtain 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, and 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.

[0013] In a third aspect, the present application provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the steps of the method for websocket connection and message distribution of a service cluster under the microservice architecture are implemented.

[0014] In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method for websocket connection and message distribution of a service cluster under the microservice architecture are implemented.

[0015] In a fifth aspect, the present application provides a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the method for websocket connection and message distribution of a service cluster under the microservice architecture are implemented.

[0016] As can be seen from the above technical solutions, the present application provides a method for websocket connection and message distribution of a service cluster under a microservice architecture. A centralized cache is used to store the mapping relationship between the user accounts bound to each cluster server and the IP and port of the websocket server. The background server where the websocket is located provides an HTTP interface for sending messages for other business services to call. The websocket server clusters communicate through an HTTP interface for message forwarding. Once the HTTP interface for sending messages of any one of the websocket servers is called, the websocket server where the websocket is located will automatically find the websocket connection of itself or other servers to complete the message sending, and the message sending is transparent and imperceptible to the calling end. Description of the Drawings

[0017] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can also be obtained based on these drawings.

[0018] Figure 1 It is a schematic flowchart of the method for websocket connection and message distribution in the service cluster under the microservice architecture in the embodiments of the present application; Figure 2 It is a schematic flowchart of establishing a websocket connection in the service cluster under the microservice architecture in the embodiments of the present application; Figure 3 It is a schematic diagram of the session identifier and account mapping hash cache session:account for the method of websocket connection and message distribution in the service cluster under the microservice architecture in the embodiments of the present application; Figure 4 It is a schematic diagram of the user account and websocket service ip, port mapping hash cache websocket:account:server for the method of websocket connection and message distribution in the service cluster under the microservice architecture in the embodiments of the present application; Figure 5 It is a schematic flowchart of message distribution in the service cluster under the microservice architecture in the embodiments of the present application; Figure 6 It is a structural diagram of the device for websocket connection and message distribution in the service cluster under the microservice architecture in the embodiments of the present application; Figure 7 It is a schematic structural diagram of the electronic device in the embodiments of the present application.

[0019] Reference numerals: 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 program storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed implementation manners

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the following will clearly and completely describe the technical solutions in the embodiments of this application with reference to the accompanying drawings in the embodiments of this application. Apparently, the described embodiments are some, but not all, of the embodiments of this application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts shall fall within the scope of protection of this application.

[0021] In the technical solutions of this application, the acquisition, storage, use, processing, etc. of data all comply with the relevant provisions of national laws and regulations.

[0022] Considering the problems existing in the prior art, this application provides a method for websocket connection and message distribution in a service cluster under a microservices architecture. A centralized cache is used to store the mapping relationship between the user accounts bound to each cluster server and the IP and port of the websocket server. The background server where the websocket is located provides an HTTP interface for sending messages for other business services to call. The websocket server clusters communicate through an HTTP interface for message forwarding. Once the HTTP interface for sending messages of any websocket server is called, the websocket server where the websocket is located will automatically find the websocket connection of itself or other servers to complete the message sending, and the message sending is transparent and imperceptible to the calling end.

[0023] To achieve seamless forwarding and delivery of messages 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 microservices architecture. Refer to Figure 1 The method for websocket connection and message distribution in the service cluster under the microservices architecture specifically includes the following content: 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.

[0024] In this embodiment, this step provides the establishment process of the websocket connection. Refer to Figure 2 as shown in Figure 2In the "Login Authentication" sub-process of the websocket server, after a successful login, the authentication service of the websocket server will generate a session identifier and map it to the login account, so that the login user account can be obtained through the session identifier carried by the front-end request in the subsequent process. The mapping information is stored in the hash data type of the redis cache using the HSET command. The key for storing hash is session:account, the field stores the session identifier, and the value stores the user account (the storage data structure refers to Figure 3 as shown).

[0025] In this embodiment, HSET is a command used to operate the hash data type in Redis. The following is a detailed introduction to the HSET command: Command format: HSET key field value [field value ...] Function description: The HSET command allows one or more key-value pairs to be stored in a specified hash table.

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

[0027] Return Value: If the field is newly created and the setting is successful, it returns 1. If the field already exists and the value is updated, it returns 0.

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

[0029] Specifically, when receiving a WebSocket connection request, 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. At the same time, check whether the expiration time in the payload has arrived. If the verification is successful and has not expired, the connection is allowed to be established; if the verification fails or has expired, the connection request is rejected and the corresponding error message is returned to the client. This mechanism can prevent illegal users from impersonating other people's accounts or tampering with session identifiers to obtain connection permissions, improve system security, and reduce the number of queries to the first cache due to invalid session identifiers, reducing the query pressure and resource consumption of the system.

[0030] Optionally, in this embodiment, a custom field X-Request-ID can also be added to the HTTP request header in the code where the client initiates a WebSocket message sending request, and its value is a globally unique request identifier. This identifier can be generated using UUID (Universally Unique Identifier) or other algorithms for generating unique IDs. At the same time, in each processing node of the WebSocket service (such as receiving requests, message forwarding, etc.), modify the log record code to include the value of the X-Request-ID field when recording logs. For example, in the log output statement, record it in the following format: 2023-08-25 10:00:00 [X-Req-12345] User A message starts processing -> forwarded to the node. The processing of the client and the server can achieve context passing of the request, allowing the system to associate the logs of each node through the unique identifier X-Request-ID during the entire process of processing a request, facilitating quick positioning of the complete request process during problem troubleshooting and improving the problem troubleshooting efficiency.

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

[0032] Optionally, continue to refer to Figure 2 As shown, when the front end initiates a websocket connection request, it will carry a session identifier. In the "Receive Websocket Connection Establishment Request" sub-process, use the HGET command of the redis cache to pass the session identifier in Figure 3 cache session:account to obtain the user account mapped by the session. Then, first map the user account and the successfully established websocket connection session within this service. The mapping information is stored in the memory object userSessionMap of the websocket service using the Java HashMap data structure. Its function is that when sending a message, the websocket connection can be found in this service through the user account, and only by obtaining the connection can a message be sent. The key of the HashMap is the user account, and the value is the websocket connection session object. The Java code implementation is: ConcurrentHashMap<String, WebSocketSession> userSessionMap = new ConcurrentHashMap<>(); Since the WebSocket service is clustered, the HashMap memory cache within the service in the previous step only stores the WebSocket connection session objects of some user accounts. When sending messages, to make the caller unaware, message forwarding needs to be implemented within the cluster. To find the target WebSocket service for forwarding, in the "Receive WebSocket Connection Establishment Request" subprocess, the mapping relationship between the IP, port of the current WebSocket server, and the user account also needs to be cached in Redis. The mapping relationship information is stored in the hash data type of 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 and port information of the WebSocket service (for the storage data structure reference Figure 4 )

[0033] Exemplarily, referring to Figure 2 as shown, the specific workflow for establishing and caching the WebSocket connection is as follows: User login authentication: The user initiates a login request at 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 account.

[0034] Session identifier caching: The authentication service uses the HSET command of Redis to store the mapping relationship between the session identifier and the user account in the hash table of Redis. The key of the hash table is session:account, the field is the session identifier, and the value is the user account. The authentication service returns the generated session identifier to the front end, and the front end can store it locally.

[0035] The front end initiates a WebSocket connection request: The front end uses the request carrying the session identifier to initiate a WebSocket connection. The session identifier carried in the request is used by the back end to identify the user's identity. After receiving the request, the WebSocket service obtains the user account corresponding to the session identifier from the session:account hash table through the HGET command of Redis.

[0036] Establish a WebSocket connection: First, verify the user's identity. If the user account is successfully retrieved from Redis, it indicates that the session identifier is valid and the user authentication is passed. Then, the WebSocket service establishes a WebSocket connection with the front end. After the WebSocket service successfully establishes the connection, it creates a mapping relationship in local memory, associating the user account with the WebSocket connection session object. The specific implementation can use Java's ConcurrentHashMap, with the user account as the key and the WebSocket connection session object as the value.

[0037] Store connection information in Redis: To support cross-service message forwarding, the WebSocket service also needs to store the mapping relationship between the IP and port of the current service and the user account in Redis. Use the HSET command to store this information in the websocket:account:server hash table. When other services need to send messages to this user, they can find the IP and port of the target WebSocket service by querying the websocket:account:server hash table, thus achieving cross-service message forwarding.

[0038] Complete connection establishment: Notify the front end of successful connection: The WebSocket service sends a confirmation message to the front end, notifying the front end that the WebSocket connection has been successfully established. After receiving the confirmation message, the front end can start sending and receiving real-time messages through the WebSocket connection.

[0039] In this embodiment, HGET is a command in Redis for operating on the hash data type. The following is a detailed introduction to the HGET command: Command format: HGET key field.

[0040] Function description: The HGET command is used to obtain the value associated with the field stored in the hash set of the specified key.

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

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

[0043] Optionally, in this embodiment, to enhance connection management, a timer is also set in the code for establishing a connection between the front end and the WebSocket service. Every preset time, such as every 30 seconds, a ping frame is sent to the WebSocket service. This operation can be implemented through 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 the @Scheduled annotation in Spring). Every preset time, such as every 5 minutes, the userSessionMap is scanned, and the isOpen status of each WebSocketSession object is checked. If it is in the closed state, the hdel command of Redis is called to remove the corresponding user account (field) from the websocket:account:server Hash data structure, and the WebSocketSession object corresponding to the user account is removed from the userSessionMap in memory. To promptly detect and clean up zombie connections and avoid the ineffective occupation of memory and Redis resources.

[0044] Furthermore, logic can also be added to the WebSocket's close callback method. For example, a close callback listener is added to each WebSocketSession object. When the connection is closed, the hdel command of Redis is called to remove the corresponding user account (field) from the websocket:account:server Hash data structure; the WebSocketSession object corresponding to the user account is removed from the userSessionMap in memory; and a log is recorded, outputting the user account with an abnormally closed connection and the reason for the closure (obtained from the callback parameters). To ensure that when the connection is abnormally closed, the status information in Redis and memory is updated in a timely manner, ensuring the consistency of metadata and avoiding incorrect message sending targets.

[0045] Optionally, in this embodiment, the second cache Redis is further optimized. Specifically, when updating the mapping relationship between the user account and the WebSocket server, in addition to using the HSET command to store the information in the hash data structure of websocket:account:server, the SET command can also be used to store the user account and server information as a key-value pair in a STRING-type key. The name of the key can be set to userA:websocket, and an expiration time can be set, such as 86,400 seconds, that is, 24 hours. This setting makes it more convenient to use the hash structure of HSET when batch querying the server information corresponding to multiple user accounts; while when quickly querying the server information corresponding to a single user account, directly querying the STRING-type key is faster, thus reducing the possible performance pressure during large hash reading.

[0046] Furthermore, in this embodiment, the hot key can be split. Specifically, according to the hash value of the last digit of the user ID, the key of 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, and then the corresponding mapping relationship is stored in 10 different hash keys from websocket:account:server:0 to websocket:account:server:9. By splitting the hot key into multiple shards, the access traffic originally concentrated on a single key can be dispersed to multiple keys to reduce the access pressure on a single key in the Redis cluster.

[0047] Step S103: Invoke the HTTP interface set on the WebSocket server, receive the message sent by the background service to the specified user, and detect whether there is a mapping relationship of the WebSocket connection session object corresponding to the specified user account stored in the local memory; if so, directly send the message to it; if not, obtain 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 obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it.

[0048] In this embodiment, the background WebSocket message sending depends on the WebSocket connection establishment in the first step and the caching of the WebSocket connection and service mapping information in the second step. The specific process can be referred to Figure 5As shown below, the message sending process is described in detail as follows: 1. When the background business service needs to send a message to a specified user, it calls the HTTP interface GET / sendMsgByWebsocket?account={}&msgType={}&msg={} of the websocket service. The interface mainly has three parameters: user account, message type, and message content.

[0049] 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 in-memory object userSessionMap within this service. If there is, it means that the websocket connection of this user is exactly established in the current service, and the message can be directly sent by calling the send method of WebSocketSession.

[0050] 3. If it does not exist in userSessionMap, it means that the websocket connection of this user is established under other websocket services. It is necessary to pass the user account parameter through the HGET command to obtain the ip and port information of the target websocket service from the websocket:account:server cache, and then splice the address of the internal message forwarding HTTP interface of the websocket cluster, such as http: / / {ip}:{port} / forwardSendMsgByWebsocket?account={}&msgType={}&msg={}, and then trigger the call of this forwarding interface.

[0051] The target websocket service obtains the corresponding parameter information in the internal message forwarding interface, directly obtains the WebSocketSession object corresponding to the specified user account from the in-memory object userSessionMap, and then calls the send method of WebSocketSession to send the message.

[0052] Exemplarily, referring to Figure 5 As shown below, the specific working process of background WebSocket message sending is as follows: The business service initiates a message sending request: The business service sends a real-time message to a specific user (such as order status update, new message notification, etc.). The business service calls the HTTP interface provided by the WebSocket service and passes the following parameters: user account: the user who specifies to receive the message; message type: the type of the message, which is used for the front end to distinguish the message processing logic; message content: the actual message content to be sent.

[0053] WebSocket service receives a request: The message sending interface of the WebSocket service receives the parameters (user account, message type, message content) passed by the business service. And it checks the local cache. The WebSocket service first looks up in the userSessionMap (a ConcurrentHashMap that stores the mapping of user accounts to WebSocket connection session objects) in the local memory to see if there is a WebSocketSession object corresponding to the specified user account. If it exists, it means that the user's WebSocket connection is established on the current service instance, and it directly proceeds to the next step; if it does not exist, it means that the user's WebSocket connection is established on other WebSocket service instances, and the following operations are required.

[0054] 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 IP and port information of the WebSocket service instance corresponding to the specified user account from the websocket:account:server hash table. The return value is the IP and port of the target WebSocket service instance.

[0055] Message forwarding: If the IP and port information of the target WebSocket service instance is queried, it means that the user's WebSocket connection is on other service instances. The WebSocket service concatenates the message forwarding HTTP interface address of the target service instance and forwards the message sending request to the target service instance. It calls the forwarding interface of the target service instance through the HTTP client to pass the message sending request.

[0056] The target WebSocket service processes the message: After the target WebSocket service receives the forwarded message sending request, it extracts the user account, message type, and message content from the request parameters. The target service looks up the WebSocketSession object corresponding to the specified user account in the userSessionMap in the local memory. After finding the corresponding WebSocketSession object, it calls its send method to send the message to the user.

[0057] Message delivery: The user's front-end client (such as a browser) receives the message through the WebSocket connection. The front-end makes corresponding processing according to the message type (msgType), such as popping up a notification, updating the page content, etc.

[0058] Optionally, in this embodiment, in the WebSocket service, a blocking queue can also be used to temporarily store messages that need to be forwarded across nodes. For example: LinkedBlockingQueue <message>queue=new LinkedBlockingQueue<>(), when the message needs to be forwarded, the message object is placed in the blocking queue. At the same time, a scheduled task is started or the queue size and time interval are checked after each message is queued. Batch sending can be triggered when any of the following conditions are met, such as the number of messages in the queue reaches 10; the waiting time since the last send exceeds 50ms. In the logic of batch sending, multiple messages are taken out of the blocking queue (for example, 10 messages are taken out at a time), assembled into a batch message body, and sent to the forwarding interface of the target WebSocket service through the HTTP client. This batch pipeline forwarding can reduce the number of HTTP requests across nodes, improve the throughput of message forwarding, and also reduce the impact of network delay on message sending efficiency to a certain extent.

[0059] From the above description, it can be seen that the method of service cluster websocket connection and message distribution under the microservice architecture provided in the embodiment of the present application can store the mapping relationship between the user accounts bound to each cluster server and the IP and port of the websocket server by adopting a centralized cache. The background server where the websocket is located provides an HTTP interface for sending messages for other business service calls. The websocket server clusters communicate through an HTTP interface for message forwarding. Once the HTTP interface for sending messages of any websocket server is called, the server where the websocket is located will automatically find its own or other servers' websocket connection to complete the message sending, and the message sending is transparent and imperceptible to the calling end.

[0060] In order to realize the seamless forwarding and delivery of messages between different services in a WebSocket service cluster environment, the present application provides an embodiment of a device for connecting and distributing service cluster websockets and messages in a microservice architecture, which is used to realize all or part of the method for connecting and distributing service cluster websockets and messages in a microservice architecture. Figure 6 The device for service cluster websocket connection and message distribution under the microservice architecture specifically includes the following contents: 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; The model evaluation module 20 is used to receive a websocket connection request initiated by a client, and obtain 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 the local memory, and store the mapping relationship between the websocket server and the user account in the second cache; The automatic adjustment module 30 is used to call the HTTP interface set on the websocket server, receive the message sent by the background business service to the specified user, and detect whether the mapping relationship of the WebSocket connection session object corresponding to the specified user account is stored in the local memory; if so, send the message directly to it; if not, obtain 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, and the target websocket server obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends a message to it.

[0061] From the above description, it can be seen that the device for service cluster websocket connection and message distribution under the microservice architecture provided in the embodiment of the present application can use a centralized cache to store the mapping relationship between the user accounts bound to each cluster server and the IP and port of the websocket server. The background server where the websocket is located provides an HTTP interface for sending messages for other business service calls. The websocket server clusters communicate through an HTTP interface for message forwarding. Once the HTTP interface for sending messages of any websocket server is called, the server where the websocket is located will automatically find its own or other servers' websocket connection to complete the message sending, and the message sending is transparent and imperceptible to the calling end.

[0062] From the hardware level, in order to realize the seamless forwarding and delivery of messages between different services in a WebSocket service cluster environment, the present application provides an embodiment of an electronic device for realizing all or part of the content of the method for service cluster websocket connection and message distribution under the microservice architecture, and the electronic device specifically includes the following content: A processor, a memory, a communications interface, and a bus; wherein, the processor, the memory, and the communications interface complete communication with each other through the bus; the communications interface is used to implement information transmission between the device for service cluster websocket connection and message distribution under the microservices architecture and related devices such as the core business system, user terminals, and related databases; the logic controller can be a desktop computer, a tablet computer, a mobile terminal, etc., and this embodiment is not limited thereto. 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 the microservices architecture and the embodiments of the device for service cluster websocket connection and message distribution under the microservices architecture, and the content thereof is incorporated herein, and the repeated parts will not be elaborated again.

[0063] It can be understood that the user terminal may include a smart phone, a tablet electronic device, a network set-top box, a portable computer, a desktop computer, a personal digital assistant (PDA), a vehicle-mounted device, a smart wearable device, etc. Among them, the smart wearable device may include smart glasses, a smart watch, a smart bracelet, etc.

[0064] In practical applications, part of the method for service cluster websocket connection and message distribution under the microservices architecture may be executed on the electronic device side as described above, or all operations may be completed in the client device. Specifically, it can be selected according to the processing capacity of the client device and the limitations of the user usage scenario, etc. This application does not make any limitation in this regard. If all operations are completed in the client device, the client device may further include a processor.

[0065] The above-mentioned client device may have a communication module (i.e., a communication unit), and can be communicatively connected to a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side, and in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform communicatively linked to the task scheduling center server. The server may include a single computer device, or may include a server cluster composed of multiple servers, or a server structure of a distributed device.

[0066] Figure 7 This is a schematic block diagram of the system composition of the electronic device 9600 according to an embodiment of the present application. As Figure 7 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 should be noted that this Figure 7 is exemplary; other types of structures can also be used to supplement or replace this structure to implement telecommunication functions or other functions.

[0067] In one embodiment, the method functions of websocket connection and message distribution in the service cluster under the microservices architecture can be integrated into the central processing unit 9100. Among them, the central processing unit 9100 can be configured to perform the following controls: 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. Step S102: 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 therein; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in the local memory, and store the mapping relationship between the websocket server and the user account in the second cache. Step S103: Invoke the HTTP interface set on the websocket server, receive the message sent by the background service to the specified user, and detect whether there is a mapping relationship between the WebSocket connection session object corresponding to the specified user account stored in the local memory; if so, directly send the message to it; if not, obtain 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 obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it.

[0068] As can be seen from the above description, the electronic device provided in the embodiment of the present application uses a centralized cache to store the mapping relationships between the user accounts bound to each cluster server and the IP and port of the websocket server. The background server where the websocket is located provides an HTTP interface for sending messages for other business services to call. The websocket server clusters communicate through an HTTP interface for message forwarding. Once the HTTP interface for sending messages of any one of the websocket servers is called, the server where the websocket is located will automatically find the websocket connection of itself or other servers to complete the message sending, and the message sending is transparent and imperceptible to the calling end.

[0069] In another embodiment, the apparatus for websocket connection and message distribution of a service cluster under a microservices architecture can be separately configured from the central processing unit 9100. For example, the apparatus for websocket connection and message distribution of a service cluster under a microservices architecture can be configured as a chip connected to the central processing unit 9100, and the method functions of websocket connection and message distribution of a service cluster under a microservices architecture can be implemented through the control of the central processing unit.

[0070] As Figure 7 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 should be noted that the electronic device 9600 does not necessarily have to include Figure 7 all the components shown in Figure 7 ; in addition, the electronic device 9600 may further include

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

[0072] Among them, the memory 9140, for example, may be one or more of a buffer, a flash memory, a hard drive, a removable medium, a volatile memory, a non-volatile memory, or other suitable devices. The above information related to failures can be stored, and in addition, programs for executing relevant information can also be stored. And the central processing unit 9100 can execute the programs stored in the memory 9140 to implement information storage or processing, etc.

[0073] The input unit 9120 provides inputs to the central processing unit 9100. The input unit 9120 is, for example, a key or a touch input device. The power supply 9170 is used to supply power to the electronic device 9600. The display 9160 is used for displaying display objects such as images and texts. The display may be, for example, an LCD display, but is not limited thereto.

[0074] The memory 9140 may be a solid-state memory, for example, a read-only memory (ROM), a random access memory (RAM), a SIM card, etc. It may also be a memory that stores information even when power is off, can be selectively erased and has more data. Examples of such a memory are sometimes referred to as EPROMs, etc. The memory 9140 may 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, which is used to store application programs and function programs or the processes for operating the electronic device 9600 by the central processor 9100.

[0075] The memory 9140 may also include a data storage unit 9143, which is used to store 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 of the electronic device for communication functions and / or for performing other functions of the electronic device (such as a messaging application, an address book application, etc.).

[0076] The communication module 9110 is a transmitter / receiver that transmits and receives signals via the antenna 9111. The communication module 9110 (transmitter / receiver) is coupled to the central processor 9100 to provide input signals and receive output signals, which may be the same as in the case of a conventional mobile communication terminal.

[0077] Based on different communication technologies, multiple communication modules 9110 may be provided in the same electronic device, such as a cellular network module, a Bluetooth module, and / or a wireless local area network module, etc. The communication module 9110 (transmitter / receiver) is also coupled to the speaker 9131 and the microphone 9132 via the audio processor 9130 to provide an audio output via the speaker 9131 and receive an audio input from the microphone 9132, thereby implementing normal telecommunication functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. In addition, the audio processor 9130 is also coupled to the central processor 9100, so that recording can be performed on the local machine through the microphone 9132, and the sound stored on the local machine can be played through the speaker 9131.

[0078] The embodiments of the present application also provide a computer-readable storage medium capable of implementing all the steps of the method for websocket connection and message distribution of a service cluster under a microservice architecture in which the execution subject is a server or a client in the above embodiments. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, all the steps of the method for websocket connection and message distribution of a service cluster under a microservice architecture in which the execution subject is a server or a client in the above embodiments are implemented. For example, when the processor executes the computer program, the following steps are implemented: Step S101: authenticating the user account of the client through the authentication service and generating a session identifier; establishing a mapping relationship between the session identifier and the user account, and storing it in a first cache; Step S102: receiving a websocket connection request initiated by a client, and obtaining the corresponding user account from the first cache according to the session identifier carried by the request; storing the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in the local memory, and storing the mapping relationship between the websocket server and the user account in the second cache; Step S103: Call the HTTP interface set on the websocket server, receive the message sent by the background business service to the specified user, and detect whether the mapping relationship of the WebSocket connection session object corresponding to the specified user account is stored in the local memory; if so, send the message to it directly; if not, obtain 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, and the target websocket server obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends a message to it.

[0079] From the above description, it can be seen that the computer-readable storage medium provided in the embodiment of the present application uses a centralized cache to store the mapping relationship between the user accounts bound to each cluster server and the IP and port of the websocket server. The background server where the websocket is located provides an HTTP interface for sending messages for other business service calls. The websocket server clusters communicate through an HTTP interface for message forwarding. Once the HTTP interface for sending messages of any websocket server is called, the server where the websocket is located will automatically find its own or other server's websocket connection to complete the message sending, and the message sending is transparent and imperceptible to the calling end.

[0080] Embodiments of the present application further provide a computer program product capable of implementing all steps in the method for websocket connection and message distribution in a service cluster under a microservice architecture where the execution entity in the above embodiments is a server or a client. When the computer program / instructions are executed by a processor, the steps of the method for websocket connection and message distribution in the microservice architecture are implemented. For example, the computer program / instructions implement the following steps: Step S101: Authenticate the user account of the logged-in client through an authentication service and generate a session identifier; establish a mapping relationship between the session identifier and the user account, and store it in a first cache; Step S102: Receive a websocket connection request initiated by the client, and obtain the corresponding user account from the first cache according to the session identifier carried therein; 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 a second cache; Step S103: Invoke the HTTP interface set on the websocket server, receive a message sent by a background service to a specified user, and detect whether there is a mapping relationship between the WebSocket connection session object corresponding to the specified user account stored in local memory; if so, directly send the message to it; if not, obtain 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 obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends the message to it.

[0081] As can be seen from the above description, the computer program product provided by the embodiments of the present application uses a centralized cache to store the mapping relationships between the user accounts bound to each cluster server and the IP addresses and ports of the websocket servers. The background server where the websocket is located provides an HTTP interface for sending messages for other business services to call. The websocket server clusters communicate through an HTTP interface for message forwarding. Once the HTTP interface for sending messages of any one of the websocket servers is called, the server where the websocket is located will automatically find the websocket connection of itself or other servers to complete the message sending, and the message sending is transparent and imperceptible to the calling end.

[0082] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, an apparatus, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0083] The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (apparatuses), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0084] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing devices to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device that implements the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0085] These computer program instructions can also be loaded onto a computer or other programmable data processing devices, such that a series of operation steps are executed on the computer or other programmable devices to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable devices provide steps for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0086] Specific embodiments are used in the present invention to elaborate on the principles and implementation manners of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the present invention.< / message>

Claims

1. A method for websocket connection and message distribution of a service cluster under a microservice architecture, which is applied to a websocket server, characterized in that The method includes: Authenticating the user account logging in to the client through an authentication service and generating a session identifier; establishing a mapping relationship between the session identifier and the user account, and storing it in a first cache; Receiving a websocket connection request initiated by the client, and obtaining the corresponding user account from the first cache according to the carried session identifier; storing the mapping relationship between the obtained user account and the successfully established WebSocket connection session object in local memory, and storing the mapping relationship between the websocket server and the user account in a second cache; Invoking the HTTP interface set on the websocket server, receiving a message sent by the background service to a specified user, and detecting whether there is a mapping relationship between the WebSocket connection session object corresponding to the specified user account stored in local memory; if so, directly sending the message to it; if not, 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, and 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.

2. The method for websocket connection and message distribution of 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 the 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 the microservice architecture according to claim 1, characterized in that: 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; Splicing the IP and port information of the target WebSocket server into the HTTP interface address of the target websocket server according to a preset format; Trigger the call to the HTTP interface of the target WebSocket server, and forward the message sending request to the corresponding HTTP interface of the target WebSocket server.

4. The method for websocket connection and message distribution of a service cluster 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, the validity period, and the digital signature. The step of receiving the WebSocket connection request initiated by the client and obtaining the corresponding user account from the first cache according to the session identifier carried therein includes: Parse the session identifier in the request, extract the header and payload of the JWT, and verify the digital signature using the public key provided by the authentication service. Check whether the validity period in the payload has expired; if the verification is passed and it has not expired, allow the connection to be established; if the verification fails or it has expired, reject the connection request and return the corresponding error message to the client.

5. The method for service cluster websocket connection and message distribution under the microservice architecture according to claim 1, wherein It also includes: Set a timer in the code for establishing a connection between the client and the WebSocket server, and send a ping frame to the WebSocket server every preset time. Write a scheduled task in the WebSocket server using a scheduled task framework to traverse the memory every preset time to check whether the connection between the user account and the WebSocket connection session object is in an open state. If the connection is closed, remove the corresponding user account from the second cache and remove the WebSocket connection session object corresponding to the user account from the memory.

6. The method for service cluster websocket connection and message distribution under the microservice architecture according to claim 1, characterized in that It also includes: When the second cache updates the mapping relationship between the user account and the WebSocket server, execute the following two commands: store the user account and the WebSocket server address and port information into a Hash data structure; Store the user account and the WebSocket server address and port information as a key-value pair into a String data structure and set an expiration time. 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, construct a new Key name according to the sharding rule, and then store the mapping relationship into the corresponding sharded Key.

7. The method for service cluster websocket connection and message distribution under the 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: Use a blocking queue to temporarily store the messages that need to be forwarded across nodes. When a message needs to be forwarded, put the message object into the blocking queue; set the trigger condition for message forwarding, and when the condition is met, trigger batch sending; the batch sending is a message body assembled from multiple messages taken out of the blocking queue.

8. An apparatus for websocket connection and message distribution of a service cluster under a microservice architecture, characterized in that, The device includes: A connection establishment module, configured to authenticate the user account of the logged-in client through an 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. A connection caching module, which is used to receive a websocket connection request initiated by a client, and obtain its corresponding user account from a first cache according to the carried session identifier; store the mapping relationship between the obtained user account and the successfully established WebSocket connection session object into local memory, and store the mapping relationship between the websocket server and the user account into a second cache; A message sending module, which is used to call the HTTP interface set on the websocket server, receive messages sent by a background service to a specified user, and detect whether there is a mapping relationship of a WebSocket connection session object corresponding to the specified user account stored in local memory; if so, directly send a message to it; if not, obtain 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, and the target websocket server obtains the WebSocket connection session object corresponding to the specified user account from its memory and sends a message to it.

9. An electronic device, comprising a memory, a processor, and a computer program stored on 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 a service cluster under the microservice architecture described in any one of claims 1 to 7.

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

Images