Micro-service node cascading method and device, and computer readable storage medium

Abstract

Provided in the description are a micro-service node cascading method and device, and a computer readable storage medium. The method can be applied to a source micro-service node for providing audio and video services, and the node is provided with a media processing module XPU and a first cascade module CAS. The method comprises: a first CAS receives routing information from a XPU, and when a source micro-service node and a target micro-service node are determined according to the routing information to be located at different servers, establishes a connection with the target micro-service node according to the routing information; the first CAS selects or creates a first transmission channel, and sends a routing setting request to a second CAS in the target micro-service node; the first CAS receives a routing setting response returned by the second CAS, and when the setting response is successful, determines that the source micro-service node and the target micro-service node are cascaded successfully.

Description

Microservice node cascading method, device, and computer-readable storage medium

[0001] Cross-references

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on September 28, 2023, with application number 202311294358.5 and application name “Microservice Node Cascading Method, Device and Computer-Readable Storage Medium”. The entire contents of the application are incorporated by reference into this application. Technical Field

[0003] This document relates to the field of instant messaging, and more specifically to a microservice node cascading method, device, and computer-readable storage medium. Background Art

[0004] With the development of internet technology, instant messaging (such as video conferencing) has become widely used in people's work and daily lives. Instant messaging applications often require a highly available service platform to provide stable audio and video services. Audio and video services are both compute-intensive and input / output (IO)-intensive, often requiring multiple nodes to collaborate and provide services.

[0005] As shown in Figure 1, current instant messaging service platforms typically use a distributed architecture consisting of a central server and multiple edge servers to build a server cluster. Within the cluster, audio and video services are broken down into multiple capability units—media components—based on their responsibilities and characteristics. These components are implemented as individual microservice nodes (one media component represents one microservice node) to provide more interactive and scalable audio and video services. Node cascading is then used to connect the streams across multiple microservice nodes.

[0006] Currently, the cascading of microservice nodes is organized and implemented by a central server. However, due to the varying hardware resources of different servers in a cluster and the fluctuating network conditions between nodes, this approach, implemented by a central server, presents technical difficulties and complex signaling interactions. This impacts the quality of audio and video services within instant messaging, and requires improvement.

[0007] Summary of the Invention

[0008] The embodiments of this specification provide a microservice node cascading method, device, and computer-readable storage medium to improve the service quality of audio and video services in instant messaging services.

[0009] To solve the above technical problems, the embodiments of this specification are implemented as follows:

[0010] In a first aspect, a microservice node cascading method is provided, which is applied to a source microservice node providing audio and video services, wherein the source microservice node is provided with a media processing module XPU and a first cascading module CAS. The method includes: the first CAS receives routing information from the XPU; when the first CAS determines that the source microservice node and the target microservice node are located on different servers based on the routing information, the first CAS establishes a connection with the target microservice node based on the routing information; the first CAS selects or creates a first transmission channel and sends a routing setting request to a second CAS in the target microservice node, wherein the routing setting request carries the routing information; the first CAS receives a routing setting response returned by the second CAS, and when the setting response is successful, determines that the source microservice node and the target microservice node are successfully cascaded.

[0011] In a second aspect, a microservice node cascading method is provided, which is applied to a target microservice node providing audio and video services. The target microservice node is provided with a second cascading module CAS. The method includes: the second CAS receives a channel pairing request from a first CAS in a source microservice node; the second CAS responds to the channel pairing request and establishes a session for the source microservice node; the second CAS selects or creates a second transmission channel and returns a channel pairing response to the first CAS.

[0012] In a third aspect, a microservice node cascading device is provided, which is applied to a source microservice node that provides audio and video services, wherein the source microservice node is provided with a media processing module XPU and a first cascading module CAS, and the device includes: an information receiving module, used by the first CAS to receive routing information from the XPU; a connection establishing module, used by the first CAS to establish a connection with the target microservice node according to the routing information when it is determined that the source microservice node and the target microservice node are located on different servers according to the routing information; a routing setting request module, used by the first CAS to select or create a first transmission channel and send a routing setting request to the second CAS in the target microservice node, wherein the routing setting request carries the routing information; a response receiving module, used by the first CAS to receive a routing setting response returned by the second CAS, and determine that the cascade of the source microservice node and the target microservice node is successful when the setting response is successful.

[0013] In a fourth aspect, a microservice node cascade device is provided, which is applied to a target microservice node providing audio and video services. The target microservice node is provided with a second cascade module CAS. The device includes: a pairing request receiving module, which is used by the second CAS to receive a channel pairing request from the first CAS in the source microservice node; a session establishment module, which is used by the second CAS to respond to the channel pairing request and establish a session for the source microservice node; and a pairing response module, which is used by the second CAS to select or create a second transmission channel and return a channel pairing response to the first CAS.

[0014] In a fifth aspect, an electronic device is provided, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the method described in the first aspect.

[0015] In a sixth aspect, a computer-readable storage medium is provided, which, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to execute the method as described in any one of the first, second and third aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of this specification or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0017] FIG1 is a schematic diagram of the architecture of an instant messaging service platform in the related art.

[0018] FIG2 is a schematic diagram of the architecture of an instant messaging service platform provided in an embodiment of this specification.

[0019] FIG3 shows a routing setting and a media forwarding model of a cascade module CAS in a microservice node cascade solution provided in an embodiment of this specification.

[0020] FIG4 is a schematic diagram of the control and media logic layers of a CAS provided in an embodiment of this specification.

[0021] FIG5 is a schematic diagram of the mapping relationship between CAS control and media provided in an embodiment of this specification.

[0022] FIG6 is a flow chart of a microservice node cascading method provided in an embodiment of this specification.

[0023] FIG. 7 is a detailed flowchart of step 603 in the embodiment shown in FIG. 6 .

[0024] FIG8 is a schematic diagram of a transmission channel pairing process between a source microservice node and a target microservice node in a microservice node cascading method provided in an embodiment of this specification.

[0025] FIG9 is a schematic diagram of a full routing synchronization process between a target microservice node and a source microservice node in a microservice node cascading method provided in an embodiment of this specification.

[0026] FIG10 is a schematic diagram of a transmission channel deletion process in a microservice node cascading method provided in an embodiment of this specification.

[0027] FIG11 is a schematic diagram of a routing information update process in a microservice node cascading method provided in an embodiment of this specification.

[0028] FIG12 is a flow chart of a microservice node cascading method provided in another embodiment of this specification.

[0029] FIG13 is a schematic diagram of an application example 1 of a microservice node cascading method provided in this specification.

[0030] FIG14 is a schematic diagram of a second application example of a microservice node cascading method provided in this specification.

[0031] FIG15 is a schematic diagram of a third application example of a microservice node cascading method provided in this specification.

[0032] FIG16 is a schematic diagram of the structure of a microservice node cascade device provided in an embodiment of this specification.

[0033] FIG. 17 is a detailed structural diagram of the routing setting request module 1603 in FIG. 16 .

[0034] FIG18 is a schematic structural diagram of a microservice node cascade device provided in another embodiment of this specification.

[0035] FIG19 is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0036] In order to help those skilled in the art better understand the technical solutions in the embodiments of this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in one or more embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this document.

[0037] The terms "first," "second," and the like in this specification and claims are used to distinguish similar objects and are not intended to describe a particular order or precedence. It should be understood that such terms are interchangeable where appropriate, so that the embodiments of this specification can be implemented in orders other than those illustrated or described herein. Furthermore, the term "and / or" in this specification and claims refers to at least one of the connected objects, and the character " / " generally indicates that the connected objects are in an "or" relationship.

[0038] Currently, the cascading of microservice nodes is organized and implemented by a central server. However, due to the varying hardware resources of different servers in the cluster and the fluctuating network conditions between nodes, the solution of implementing microservice node cascading by a central server faces technical difficulties and complex signaling interactions. This has affected the quality of audio and video services within instant messaging services, for example, affecting the real-time performance, media quality, and service carrying capacity of the entire audio and video service. The main issues include:

[0039] 1) Real-time media data: To negotiate port, protocol, and other information on different microservice nodes, the central server needs to issue signaling in a predetermined sequence. This media operation triggers a large number of complex interactions between different nodes, especially signaling transmitted across the public network, which affects the real-time performance of media data.

[0040] 2) Service carrying capacity: To avoid uneven node load, the central server usually distributes tasks according to the load balancing algorithm, which will cause waste of media service resources. The expansion of new nodes will increase the burden on the central server.

[0041] 3) Media Quality: In high-load scenarios, it is difficult for the central server to consider the performance bottleneck of each node when dispatching media tasks, resulting in jitter or even packet loss of node media, affecting the user experience.

[0042] To address at least one of the aforementioned issues, this specification proposes a microservice node cascading method, which is applied to the microservice nodes themselves. In one exemplary embodiment, a cascade module (CAS) is added to each microservice node, which self-organizes to achieve cascading between different microservice nodes. The CAS is a lightweight, independent microservice node cascading proxy system that provides control and media plane interfaces and features self-organizing negotiation, routing retransmission, media robustness against weak networks, and load balancing. It also offers advantages such as strong scalability and adaptability.

[0043] In this specification, a microservice node can be any microservice node that provides microservices in a distributed architecture. For example, a microservice node cascading method proposed in this specification is applicable to audio and video media interaction between microservice nodes (such as media components) in a distributed cloud scenario. Among them, the media processing node (media component) is microserviced and deployed in an independent container, relying on the central server for service registration and service discovery mechanism to integrate the complete service. The service completes the control signaling through the business component, and the media is forwarded between the microservice nodes in the same network segment.

[0044] In an exemplary embodiment, the microservice node may be a media component distributed in a central server or edge servers, such as the media component 211 in the edge server 21 and the media component 221 in the edge server 22 in FIG. 2 .

[0045] As shown in Figure 2, one or more microservice nodes (such as media component 211 and media component 212) can be deployed in an edge server. A microservice node can be equipped with a media processing module (X Process Unit, XPU), a cascade module (CAS), and a content switch bus (CSB). It can be understood that there can be multiple media processing services, so a microservice node can contain multiple core modules, such as a network processing unit and an audio processing unit. As shown in Figure 2, this article uses XPU to refer to various processing modules.

[0046] After adding CAS to microservice nodes, for the central server, the microservice node cascading process described in this specification runs parallel to other central server signaling. The microservice node cascading process does not affect the central server's signaling, which reduces handover latency between microservice nodes and simplifies the signaling process. The central server no longer needs to worry about the interaction process between different microservice nodes. The communication protocol, port, preset resources, and other information between different microservice nodes are self-organized and negotiated by CAS, thereby reducing the complexity of central server control.

[0047] For the internal part of the microservice node (media component), the CAS added in this specification can hide the details of resource allocation, provide an interface for routing settings and media data forwarding, encapsulate relative to each media microservice, and support different modules to send media data that follows the Real-time Transport Protocol (RTP) / Real-time Transport Control Protocol (RTCP), so it can support different microservice nodes for point-to-point communication. The internal modules of the microservice node do not need to pay attention to the configuration differences between nodes, ignore the details of media data forwarding across nodes, and reduce the difficulty of expansion between microservice nodes. It can support a large number of expansions of microservices in the audio and video platform and support interconnection between different types of microservices. Among them, media data includes but is not limited to at least one of audio data and video data.

[0048] FIG3 shows a routing setting and a media forwarding model of a cascade module CAS in a microservice node cascade solution provided in this specification.

[0049] CAS provides routing setting-related interfaces on the control plane and media forwarding interfaces on the media plane. As shown in Figure 3, on the control plane, when the XPU sets an internal route, CAS will directly pass it to the CSB, and the XPU's specified media data will be forwarded directly to the destination XPU through the CSB. For external routes set by the XPU, CAS modifies the route destination to itself, and the XPU's specified media data will be forwarded directly to the CAS through the CSB, and the CAS will then transmit it to the remote end - that is, the microservice node located on another server. The XPU does not need to care whether the destination of the media data is the local XPU or the remote XPU. On the media plane, the source XPU sends the specified RTP / RTCP media packet to the CSB, and the CSB distributes the media packet to the CAS according to the route. The CAS sends it to the specified remote XPU based on the routing information.

[0050] Figure 4 is a schematic diagram of the control and media logic hierarchy of CAS provided in an embodiment of this specification. As shown in Figure 4, from a hierarchical perspective, in addition to the system kernel, CAS is divided into the following three layers: interface layer, service control layer, and network access layer, and contains the following modules:

[0051] 1) Interfaces, including: external routing setting interface and media data forwarding interface.

[0052] 2) Sessions: These manage different connection information, assign tasks to specific transmission channels, and set basic information for media data forwarding on the transmission channels. In addition, sessions also include a routing information cache for temporary storage of routing messages.

[0053] 3) The transmission channel is the smallest media resource management unit, using RTP / RTCP to forward media data and count media transmission and reception. The transmission channel includes a media engine that uses retransmission and error correction algorithms to handle weak network conditions.

[0054] 4) Link, used to exchange messages with the remote end using a connection-based approach and monitor the remote end's connection.

[0055] Figure 5 is a schematic diagram of the mapping relationship between the control and media of CAS provided in an embodiment of this specification. As shown in Figure 5, the session plays a management role in the microservice, and the same session is used to manage nodes with the same IP. The session manages multiple transmission channels on the media side, and the number of transmission channels is determined by the load between the two microservice nodes. According to the different physical configurations of the microservice nodes (including preset resource configurations), the number of working units on each microservice node is different. Due to the different single-core capabilities of the system and the size of the packet receiving and sending buffers, each working unit can only carry a limited number of tasks. The session assigns tasks to different transmission channels based on the current load conditions of both parties. The transmission channels are located on different working units, carry media data forwarding tasks, and receive or send RTP / RTCP streams through designated audio and video ports.

[0056] The above describes the basic knowledge for understanding a microservice node cascading method provided in this specification. The following describes a microservice node cascading method provided in this specification.

[0057] As shown in FIG6 , a microservice node cascading method provided by one embodiment of the present specification can be applied to a source microservice node (it should be noted that the source microservice node here is relative to the target microservice node mentioned below, and the source microservice node can be any microservice node in the cluster, and the target microservice node can be another microservice node in the cluster). The source microservice node is provided with a media processing module XPU and a first cascading module CAS. The method may include the following steps:

[0058] Step 601: The first CAS receives routing information from the XPU.

[0059] The routing information includes: the address of the source microservice node (such as an IP address), media data, and the address of the target microservice node.

[0060] In step 602 , when the first CAS determines according to the routing information that the source microservice node and the target microservice node are located on different servers, the first CAS establishes a connection with the target microservice node according to the routing information.

[0061] Generally speaking, when the address (such as IP address) of the source microservice node in the routing information is consistent with the address of the target microservice node, it can be determined that the routing information is internal routing information, that is, the source microservice node and the target microservice node are located on the same server; otherwise, it can be determined that the routing information is external routing information, that is, the source microservice node and the target microservice node are located on different servers.

[0062] For internal routing information, that is, when the source microservice node and the target microservice node are located on the same server, the media data carried in the routing information can be directly transparently transmitted through the CSB.

[0063] For external routing information, that is, when the source microservice node and the target microservice node are located on different servers, it is necessary to cascade the source microservice node and the target microservice node. In an exemplary embodiment, when the first CAS is in the initial state, a connection can be established with the target microservice node based on the routing information. Then, step 603 is executed.

[0064] Furthermore, when the first CAS is in the initial state, the process of establishing the cascade can be triggered by the routing interface of the control plane of the first CAS, and the routing setting is first performed (i.e., executing step 603). Optionally, the routing setting process meets idempotence, that is, the effect of processing the same routing information multiple times should be equivalent to the effect of processing it once.

[0065] In step 603, the first CAS selects or creates a first transmission channel and sends a routing setting request to the second CAS in the target microservice node, where the routing setting request carries the routing information.

[0066] Optionally, before the first CAS selects or creates the first transmission channel, the method shown in Figure 6 may further include: the first CAS establishing a session with the target microservice node. As described above, sessions can be used to manage different connection information, assign tasks to specific transmission channels, and set basic information for media data forwarding for transmission channels. Of course, establishing a session is not mandatory; connections and transmission channels can also be managed through other means.

[0067] Optionally, after creating the session, the first CAS may also determine whether the versions of the second CAS in the target microservice node match those of the first CAS. If they do not match, the first CAS with a version compatible with the second CAS is selected for routing settings.

[0068] Optionally, the source microservice node is provided with multiple work units, each of which is allocated with preset resources for establishing a transmission channel. The preset resources may include but are not limited to computing (such as CPU) resources, image processing (such as GPU) resources, and network resources.

[0069] On this basis, the first CAS selects or creates the first transmission channel, which may include but is not limited to the following four implementation methods:

[0070] 1) When no transmission channel is established under the session, the first CAS selects a work unit whose remaining preset resources meet current needs to create a first transmission channel.

[0071] 2) When multiple transmission channels have been established under the session, the first CAS selects a transmission channel among the multiple transmission channels that has been successfully paired with the target microservice node as the first transmission channel.

[0072] 3) When multiple transmission channels have been established under the session and the remaining preset resources of the working units where the multiple channels are located do not meet the current needs, the first CAS selects another working unit whose remaining preset resources meet the current needs to create the first transmission channel.

[0073] 4) When multiple transmission channels have been established under the session and the remaining preset resources of all work units do not meet current needs, the first CAS waits for a work unit with idle preset resources to appear and creates under the work unit with idle preset resources.

[0074] Furthermore, after the first CAS successfully selects or creates the first transmission channel, the following situations may occur depending on the status of the first transmission channel:

[0075] 1) If the first transmission channel has been successfully paired with the second transmission channel in the target microservice node, the first CAS is directly triggered to send a routing setting request to the second CAS in the target microservice node.

[0076] 2) If the first transmission channel has been successfully paired with the second transmission channel in the target microservice node, but the routing information sent to the target microservice node is duplicated, the routing information is directly sent or discarded.

[0077] 3) If the first transmission channel has not yet been successfully paired with the second transmission channel in the target microservice node, a channel pairing request is sent to the second CAS. The channel pairing request is used to request the second CAS to select or create a second transmission channel to pair with the first transmission channel. See Figure 7 for the detailed process.

[0078] As shown in FIG7 , after the first CAS successfully selects or creates the first transmission channel (after executing step 6031 ), before sending a routing setting request to the second CAS in the target microservice node (before executing step 6039 ), step 603 may further include:

[0079] In step 6032, the first CAS sends a channel pairing request to the second CAS, where the channel pairing request is used to request the second CAS to select or create a second transmission channel to pair with the first transmission channel.

[0080] Regarding the process of the second CAS creating the second transmission channel, please refer to the description of the process shown in Figure 12 below, which will not be repeated here.

[0081] Step 6033: The first CAS receives a channel pairing response returned by the second CAS.

[0082] For the detailed process of channel pairing, please refer to Figure 8.

[0083] As shown in FIG8 , as an example, the first CAS 81 may include a working unit 811, a control unit 812, and a network adaptation unit 813; the second CAS 82 may include a working unit 821, a control unit 822, and a network adaptation unit 823. Based on this, the channel pairing process may include:

[0084] ① After receiving the routing information from the XPU, the control unit 812 establishes a session between the source microservice node and the target microservice node.

[0085] ② The control unit 812 caches routing information.

[0086] ③ The control unit 812 selects or creates a first transmission channel. After successfully selecting or creating the first transmission channel, the process proceeds to ④.

[0087] ④ The control unit 812 sends a channel pairing request to the control unit 822 via the network adaptation unit 813 and the network adaptation unit 823.

[0088] ⑤ The control unit 822 establishes a session between the target microservice node and the source microservice node.

[0089] ⑥ The control unit 822 selects or creates a second transmission channel.

[0090] ⑦ The control unit 822 creates a working channel corresponding to the second transmission channel in the working unit 821.

[0091] ⑧ The working unit 821 creates a media engine for the working channel.

[0092] ⑨ The control unit 822 sends a channel pairing response to the control unit 812 via the network adaptation unit 823 and the network adaptation unit 813.

[0093] ⑩ The control unit 812 creates a working channel corresponding to the first transmission channel in the working unit 811.

[0094] The working unit 811 creates a media engine for the working channel.

[0095] Other processes, as well as the working unit 811 and the working unit 821 transmit media data to each other according to RTP / RTCP.

[0096] Optionally, step 603 may further include:

[0097] In step 6034, the first CAS determines whether the channel pairing is successful based on the channel pairing response; if so, execute step 6035; otherwise, return to execute step 6031 to reselect or create the first transmission channel. It can be understood that the reselected or created first transmission channel is different from the first transmission channel selected or created last time.

[0098] In step 6035, the first CAS determines whether the receiving route of the source microservice node and the sending route of the target microservice node are consistent based on the verification code in the channel pairing response and the verification code of the source microservice node; if they are consistent, execute step 6039; otherwise, execute step 6036.

[0099] In step 6036, the first CAS sends a full routing synchronization request to the second CAS, wherein the full routing synchronization request is used to request the second CAS to send the first data packet and the second data packet to the source microservice node, wherein the first data packet is the routing information of the target microservice node, and the second data packet is the end packet including the checksum.

[0100] In step 6037, the first CAS receives the first data packet and the second data packet, and updates the check code in the source microservice node after receiving the second data packet.

[0101] Step 6038: The first CAS synchronizes the routing information in the first data packet to the source microservice node.

[0102] For the detailed process of full routing synchronization, please refer to Figure 9.

[0103] As shown in FIG9 , similar to FIG8 , as an example, the first CAS 81 may include a working unit 811, a control unit 812, and a network adaptation unit 813; the second CAS 82 may include a working unit 821, a control unit 822, and a network adaptation unit 823. Based on this, the channel pairing process may include:

[0104] ① The control unit 812 receives the channel pairing response returned by the control unit 822.

[0105] ② Control unit 812 determines whether the source microservice node's receiving route and the target microservice node's sending route are consistent based on the verification code in the channel pairing response and the verification code of the source microservice node. If they are consistent, it sends a route setting request to control unit 822. If not, it executes ③.

[0106] ③ The control unit 812 sends a full routing synchronization request to the control unit 822 via the network adaptation unit 813 and the network adaptation unit 823.

[0107] ④ The control unit 822 finds the previously established session and the previously created second transmission channel.

[0108] ⑤ The control unit 822 sets a retransmission timer.

[0109] ⑥ The control unit 822 sends a full route synchronization response to the control unit 812 via the network adaptation unit 823 and the network adaptation unit 813.

[0110] ⑦ The control unit 812 finds the previously established session and the previously created first transmission channel.

[0111] ⑧ The control unit 812 sets the routing information in the receiving table of the first transmission channel (the routing information table in the receiving direction) to an invalid state to avoid routing according to an erroneous routing information table during synchronization.

[0112] ⑨ The control unit 822 packages and sends the sending table corresponding to the second transmission channel (the routing information table in the sending direction), which specifically corresponds to the first data packet mentioned above.

[0113] ⑩~ The control unit 822 sends a synchronization start packet to a synchronization end packet (second data packet) to the control unit 812 in sequence.

[0114] The control unit 812 clears expired routing information.

[0115] The control unit 812 updates the timestamp of the routing information table when checking that the check codes are consistent.

[0116] The control unit 812 sets the routing information of the working transmission channel in the working unit 811.

[0117] The working unit 811 updates the working routing table.

[0118] The control unit 812 sends a synchronization end response to the control unit 823 .

[0119] The control unit 823 clears the retransmission timer that was set previously.

[0120] Optionally, before sending a routing setting request to the second CAS in the target microservice node (before executing step 6039), the method shown in Figure 6 may also include: the first CAS pre-occupies the preset resources corresponding to the first transmission channel, so that after subsequent pairing is successful, the first transmission channel is used to transmit media data, thereby improving the transmission success rate.

[0121] Furthermore, the method shown in FIG6 may further include: if the channel pairing response fails, the first CAS sets the priority of the first transmission channel to a low priority, releases the pre-occupied preset resources corresponding to the first transmission channel, and triggers the first CAS to reselect or create the first transmission channel. It will be appreciated that if pairing fails, releasing the pre-occupied preset resources corresponding to the first transmission channel can avoid resource waste.

[0122] It can be understood that when a single work unit in CAS is at a performance bottleneck, additional channel creation and resource allocation are involved so that the load of the work unit can be balanced. When CAS sends a single routing information, both sides need to negotiate whether the resources are met (corresponding to the channel pairing process). First, the local (source microservice node) session selects a first transmission channel based on the preset number of resources in the work unit, and pre-occupies the current preset resources; then the other end (target microservice node) confirms that the preset resources in the work unit are sufficient, then creates a second transmission channel, returns a pairing response, and ends the process; otherwise, it returns the amount of available resources for each channel; this end sets the priority of the current first transmission channel to a low priority and releases the pre-occupied resources. Furthermore, this end excludes work units that do not meet resource requirements, reselects new channels, pre-occupies the current preset resources, and re-pairs with the transmission channel of the other end until the process ends.

[0123] Furthermore, the method shown in Figure 6 may also include: the first CAS periodically checking whether the first transmission channel is in an idle state; if the first transmission channel is in an idle state and the idle time exceeds a preset threshold, the first CAS sends a channel deletion request for the second transmission channel to the second CAS, and sets the state of the first transmission channel to unavailable.

[0124] It can be understood that regularly checking and deleting idle pairing channels can avoid wasting resources and thus avoid wasting resources.

[0125] Furthermore, the method shown in Figure 6 may also include: the first CAS receives a channel deletion response returned by the second CAS; if the channel deletion response indicates a successful deletion, the first CAS deletes the first transmission channel; if the channel deletion response indicates a failed deletion, the first CAS updates the status of the first transmission channel to available.

[0126] The detailed process of deleting the successfully paired second transmission channel can be found in FIG10 .

[0127] As shown in FIG10 , similar to FIG8 , as an example, the first CAS 81 may include a working unit 811, a control unit 812, and a network adaptation unit 813; the second CAS 82 may include a working unit 821, a control unit 822, and a network adaptation unit 823. Based on this, the channel deletion process may include:

[0128] ① The control unit 812 is triggered by the timer expiration detection to detect whether the idle time of the first transmission channel has timed out; if so, execute ②; otherwise, continue to wait for the timer expiration detection to be triggered.

[0129] ② The control unit 812 sets the status of the first transmission channel to unavailable.

[0130] ③ The control unit 812 sends a second transmission channel deletion request to the control unit 822 via the network adaptation unit 813 and the network adaptation unit 823.

[0131] ④ The control unit 822 finds the second transmission channel.

[0132] ⑤ The control unit 822 determines whether there is routing information currently on the second transmission channel; if yes, no processing is performed, or a response indicating deletion failure is returned; otherwise, execution is performed ⑥.

[0133] ⑥ The control unit 822 sends a second transmission channel release request to the working unit 821.

[0134] ⑦ Working unit 821 releases the media engine.

[0135] ⑧The control unit 822 releases the second transmission channel.

[0136] ⑨ The control unit 822 sends a channel deletion response to the control unit 812 via the network adaptation unit 823 and the network adaptation unit 813.

[0137] ⑩ The control unit 812 requests the working unit 811 to release the first transmission channel.

[0138] The working unit 811 releases the first transmission channel.

[0139] The control unit 812 releases the first transmission channel.

[0140] That is, if the other end (target microservice node) successfully deletes the second transmission channel, the first transmission channel of the local end (source microservice node) is deleted.

[0141] When the control unit 812 confirms that there is no transmission channel under the current session, it releases the session.

[0142] In step 604 , the first CAS receives the routing setting response returned by the second CAS, and if the setting response is successful, determines that the source microservice node and the target microservice node are successfully cascaded.

[0143] Optionally, after the source microservice node is successfully cascaded with the target microservice node, the first CAS sends the media data carried in the routing information to the target microservice node through the first transmission channel.

[0144] The embodiment shown in Figure 6 provides a microservice node cascading method. The source microservice node can achieve cascading with the target microservice node by adding a first CAS therein. This is a self-organizing cascading method of microservice nodes. This cascading method does not require the participation of a central node and does not involve complex signaling interactions. Therefore, it can improve the quality of audio and video services in instant messaging services.

[0145] Optionally, the method shown in FIG6 may further include: the first CAS adding operations for the routing information to a cache queue, wherein the operations include adding operations and deleting operations, and the operations are sorted by time.

[0146] Furthermore, the method shown in FIG6 may further include: the first CAS receiving and responding to an edit to the cache queue, wherein the edit includes at least one of a deduplication operation and a reverse operation.

[0147] Optionally, after the first transmission channel is successfully paired with the second transmission channel, the process shown in FIG11 may be used to update the routing information when the triggering condition is difficult to meet. The triggering condition may include but is not limited to at least one of the following:

[0148] 1) The XPU in the first CAS sends a routing setup request;

[0149] 2) The timer expires and routing information is cached in the session;

[0150] 3) Receive a channel pairing response from the peer end (second CAS).

[0151] As shown in FIG11 , similar to FIG8 , as an example, the first CAS 81 may include a working unit 811, a control unit 812, and a network adaptation unit 813; the second CAS 82 may include a working unit 821, a control unit 822, and a network adaptation unit 823. Based on this, the routing information update process may include:

[0152] ① When the trigger condition is met, the control unit 812 reads the head node from the cache queue.

[0153] ② The control unit 812 selects the first transmission channel for updating routing information.

[0154] ③ The control unit 812 sends a routing information update request to the control unit 822 via the network adaptation unit 813 and the network adaptation unit 823.

[0155] ④ The control unit 822 finds the session and the corresponding second transmission channel.

[0156] ⑤ The control unit 822 determines whether the preset resources corresponding to the second transmission channel meet the needs; if yes, execute ⑥, otherwise do not update or ignore.

[0157] ⑥ The control unit 822 updates the routing information to the routing information table of the receiving direction of the second transmission channel.

[0158] ⑦ The control unit 822 sends a working transmission channel routing setting request to the working unit 821.

[0159] ⑧ The working unit 821 updates the routing table of the working transmission channel.

[0160] Optionally, it may also include:

[0161] ⑨ The control unit 822 sends a routing information update request to the control unit 812 via the network adaptation unit 823 and the network adaptation unit 813.

[0162] ⑩ The control unit 812 updates the routing information to the routing information table of the sending direction.

[0163] The control unit 812 sends a working transmission channel routing setting request to the working unit 811 .

[0164] The working unit 811 updates the routing table of the working transmission channel.

[0165] The control unit 812 removes the head node in the cache queue.

[0166] The control unit 812 processes the next cache node in the cache queue.

[0167] It should be noted that, in the above, for the source microservice node, if the first transmission channel is used to transmit media data, the working transmission channel is the first transmission channel; for the target microservice node, if the second transmission channel is used to transmit media data, the working transmission channel is the second transmission channel.

[0168] Optionally, the method shown in FIG6 may further include: triggering the first CAS to reselect or create the first transmission channel when an anomaly occurs in the sending network of the first CAS (including but not limited to at least one of a single node anomaly and a network interruption), thereby recreating the transmission channel and performing full routing synchronization. This is a weak network resistance mechanism and a single node anomaly recovery mechanism proposed in this specification, which can further improve service quality.

[0169] As shown in FIG12 , another embodiment of the present specification provides a microservice node cascading method, which can be applied to a target microservice node. The target microservice node is provided with a second cascading module CAS. The method may include:

[0170] Step 1201: The second CAS receives a channel pairing request from the first CAS in the source microservice node.

[0171] Step 1202: The second CAS responds to the channel pairing request and establishes a session for the source microservice node.

[0172] Step 1203: The second CAS selects or creates a second transmission channel and returns a channel pairing response to the first CAS.

[0173] Optionally, the target microservice node is provided with multiple work units, and the work units are allocated preset resources for establishing a transmission channel. The second CAS selects or creates the second transmission channel in the following four ways, including but not limited to:

[0174] 1) When no transmission channel is established under the session, the second CAS selects a work unit whose remaining preset resources meet current needs to create a second transmission channel.

[0175] 2) When multiple transmission channels have been established under the session, the second CAS selects a transmission channel that has been successfully paired with the source microservice node among the multiple transmission channels as the second transmission channel.

[0176] 3) When multiple transmission channels have been established under the session and the remaining preset resources of the working units where the multiple channels are located do not meet the current needs, the second CAS selects another working unit whose remaining preset resources meet the current needs to create a second transmission channel.

[0177] 4) When multiple transmission channels have been established under the session and the remaining preset resources of all work units do not meet the current needs, the second CAS waits for a work unit with idle preset resources to appear and creates under the work unit with idle preset resources.

[0178] Optionally, the method shown in Figure 12 may further include: the second CAS determines whether the sending route of the source microservice node and the receiving route of the target microservice node are consistent based on the verification code in the channel pairing request and the verification code of the target microservice node; when the sending route of the source microservice node and the receiving route of the target microservice node are inconsistent, the second CAS sends a full routing synchronization request to the first CAS, wherein the full routing synchronization request carries a first data packet and a second data packet, wherein the first data packet is the routing information of the sending direction of the target microservice node, and the second data packet is an end packet containing a verification code, and the full routing synchronization request is used to request the first CAS to update the verification code in the source microservice node.

[0179] Furthermore, the method shown in FIG. 12 may further include: when the second CAS fails to select and / or create the second transmission channel, outputting an error log and returning a pairing failure response to the first CAS.

[0180] For the microservice node cascading method shown in Figure 12, cascading with the source microservice node can be achieved by adding a second CAS. This is a self-organizing cascading method of microservice nodes. This cascading method does not require the participation of a central node and does not involve complex signaling interactions. Therefore, it can improve the quality of audio and video services in instant messaging services.

[0181] The following three examples illustrate the implementation effect of a microservice node cascading method provided in this specification.

[0182] Example 1

[0183] The service components of an audio and video conferencing platform are deployed in locations A (corresponding to microservice 1 in Figure 13) and B (corresponding to microservice 2 in Figure 13). Initially, no cascading is performed. A conference is held in location A. Multiple users are located in locations A and B, and access the nearest adjacent server. This conference generates cross-domain cascaded media forwarding. The following steps may be included:

[0184] Step 1: On microservice 1 at location A, the XPU sends routing information to the CAS, which then establishes a session based on the peer IP information.

[0185] Step 2: CAS caches the routing information of XPU and establishes a link to connect to the service at location B.

[0186] Step 3: The CAS in microservice 1 at location A selects the work unit with the most remaining resources to create a new first transmission channel and sends a channel pairing request message to the peer end through the link.

[0187] Step 4: The CAS in microservice 2 at location B selects the work unit with the most remaining resources (60%) to create a second transmission channel and sends a channel pairing response.

[0188] Step 5: The channel pairing between Microservice 1 and Microservice 2 is completed, the routing information is successfully delivered, the cached routing information is cleared, and the work unit in Microservice 1 receives the media data and sends it to Microservice 2.

[0189] The final cascade effect is shown in Figure 13.

[0190] Example 2

[0191] The service components of an audio and video conferencing platform are deployed in locations A and B, respectively. Initially, a cascade connection is established. A meeting is held in location A, involving cascade communication between locations A and B. However, the capacity of a single work unit is insufficient, so CAS allocates additional work units for media forwarding. This may include the following steps:

[0192] Step 1: On microservice 1 at location A, the XPU sends routing information to the CAS and selects the currently used first transmission channel to send routing information to microservice 2 at location B.

[0193] Step 2: The current resources of the second transmission channel created by CAS in microservice 2 at location B are insufficient, and a routing failure response is returned, along with the number of resources currently available for all transmission channels.

[0194] Step 3: The CAS of microservice 1 in location A cannot use the paired first transmission channel, so it creates a new first transmission channel and sends a channel pairing request to microservice 2 in location B.

[0195] Step 4: The CAS in microservice 2 at location B selects the work unit with the most remaining resources to create a second transmission channel and responds to the channel pairing.

[0196] Step 5: The channel pairing at both ends is completed, the routing information is successfully sent, the CAS of microservice 1 in location A clears the cached route, and the working unit in microservice 1 receives the media data and sends it to microservice 2.

[0197] The final cascade effect is shown in Figure 14.

[0198] Example 3

[0199] The service components of a certain audio and video conferencing platform are deployed in locations A and B respectively. Multiple meetings are held in location A, and the multi-capability service in location A reaches a bottleneck. To meet the service call, location A uses the multi-capability service components of locations A and B at the same time, which will generate a cascade of multiple media processing nodes. The specific establishment process is similar to that of Example 1, and the final cascade effect is shown in Figure 15.

[0200] In summary, this specification presents a microservice node cascading method that, compared to the industry's commonly used central server-managed microservice node cascading approach, operates in parallel with the central server's signaling process and supports self-routing and media recovery in network anomaly scenarios, reducing central scheduling pressure and inter-node handover latency. Furthermore, a unified cascading proxy is used within microservices for cross-node media interaction, shielding forwarding details and reducing the complexity of internal microservice calls.

[0201] A microservice node cascading method provided in an embodiment of this specification is introduced above. A microservice node cascading device provided in an embodiment of this specification is described below.

[0202] Figure 16 shows a schematic diagram of the structure of a microservice node cascade device provided in an embodiment of this specification, which can be applied to a source microservice node. As shown in Figure 16, the microservice node cascade device 1600 may include: an information receiving module 1601, a connection establishment module 1602, a route setting request module 1603, and a response receiving module 1604.

[0203] The information receiving module 1601 is configured for the first CAS to receive routing information from the XPU.

[0204] The routing information includes: the address of the source microservice node (such as an IP address), media data, and the address of the target microservice node.

[0205] The connection establishing module 1602 is configured to establish a connection with the target microservice node according to the routing information when the first CAS determines that the source microservice node and the target microservice node are located on different servers according to the routing information.

[0206] Generally speaking, when the address (such as IP address) of the source microservice node in the routing information is consistent with the address of the target microservice node, it can be determined that the routing information is internal routing information, that is, the source microservice node and the target microservice node are located on the same server; otherwise, it can be determined that the routing information is external routing information, that is, the source microservice node and the target microservice node are located on different servers.

[0207] For internal routing information, that is, when the source microservice node and the target microservice node are located on the same server, the media data carried in the routing information can be directly transparently transmitted through the CSB.

[0208] For external routing information, that is, when the source microservice node and the target microservice node are located on different servers, it is necessary to cascade the source microservice node and the target microservice node. In an exemplary embodiment, when the first CAS is in an initial state, a connection can be established with the target microservice node based on the routing information. This then triggers the request sending submodule 1709 in the routing setting request module 1603.

[0209] Furthermore, when the first CAS is in the initial state, the cascade establishment process can be triggered by the routing interface of the control plane of the first CAS, and the routing setting is first performed (i.e., triggering the request sending submodule 1709 in the routing setting request module 1603). Optionally, the routing setting process meets idempotence, that is, the effect of processing the same routing information multiple times should be equivalent to the effect of processing it once.

[0210] The routing setting request module 1603 is configured to enable the first CAS to select or create a first transmission channel and send a routing setting request to the second CAS in the target microservice node, where the routing setting request carries the routing information.

[0211] Optionally, before the first CAS selects or creates the first transmission channel, the apparatus shown in Figure 16 may further include a session establishment module configured to establish a session with the target microservice node through the first CAS. As described above, sessions can be used to manage various connection information, assign tasks to specific transmission channels, and set basic information for media data forwarding for transmission channels. Of course, session creation is not mandatory; connections and transmission channels can also be managed through other means.

[0212] Optionally, after creating the session, the first CAS may also determine whether the versions of the second CAS in the target microservice node match those of the first CAS. If they do not match, the first CAS with a version compatible with the second CAS is selected for routing settings.

[0213] Optionally, the source microservice node is provided with multiple work units, each of which is allocated with preset resources for establishing a transmission channel. The preset resources may include but are not limited to computing (such as CPU) resources, image processing (such as GPU) resources, and network resources.

[0214] On this basis, the first CAS selects or creates the first transmission channel, which may include but is not limited to the following four implementation methods:

[0215] 1) When no transmission channel is established under the session, the first CAS selects a work unit whose remaining preset resources meet current needs to create a first transmission channel.

[0216] 2) When multiple transmission channels have been established under the session, the first CAS selects a transmission channel among the multiple transmission channels that has been successfully paired with the target microservice node as the first transmission channel.

[0217] 3) When multiple transmission channels have been established under the session and the remaining preset resources of the working units where the multiple channels are located do not meet the current needs, the first CAS selects another working unit whose remaining preset resources meet the current needs to create the first transmission channel.

[0218] 4) When multiple transmission channels have been established under the session and the remaining preset resources of all work units do not meet current needs, the first CAS waits for a work unit with idle preset resources to appear and creates under the work unit with idle preset resources.

[0219] Furthermore, after the first CAS successfully selects or creates the first transmission channel, the following situations may occur depending on the status of the first transmission channel:

[0220] 1) If the first transmission channel has been successfully paired with the second transmission channel in the target microservice node, the first CAS is directly triggered to send a routing setting request to the second CAS in the target microservice node.

[0221] 2) If the first transmission channel has been successfully paired with the second transmission channel in the target microservice node, but the routing information sent to the target microservice node is duplicated, the routing information is directly sent or discarded.

[0222] 3) If the first transmission channel has not yet been successfully paired with the second transmission channel in the target microservice node, a channel pairing request is sent to the second CAS. The channel pairing request is used to request the second CAS to select or create a second transmission channel to pair with the first transmission channel. For detailed structure, see Figure 17.

[0223] As shown in FIG17 , after the first CAS successfully selects or creates the first transmission channel (after triggering the channel creation submodule 1701 in the routing setting request module 1603), before sending the routing setting request to the second CAS in the target microservice node (before triggering the request sending submodule 17099 in the routing setting request module 1603), the routing setting request module 1603 is triggered:

[0224] The pairing request submodule 1702 is configured to cause the first CAS to send a channel pairing request to the second CAS, wherein the channel pairing request is used to request the second CAS to select or create a second transmission channel to pair with the first transmission channel.

[0225] The response receiving submodule 1703 is configured for the first CAS to receive the channel pairing response returned by the second CAS.

[0226] The first judgment submodule 1704 is configured to determine, by the first CAS, whether the channel pairing is successful based on the channel pairing response; if so, trigger the second judgment submodule 1705 in the routing setting request module 1603; otherwise, return to trigger the channel creation submodule 1701 in the routing setting request module 1603 to reselect or create the first transmission channel. It will be understood that the reselected or created first transmission channel is different from the first transmission channel selected or created last time.

[0227] The second judgment submodule 1705 is used by the first CAS to determine whether the receiving route of the source microservice node and the sending route of the target microservice node are consistent based on the verification code in the channel pairing response and the verification code of the source microservice node; if they are consistent, the request sending submodule 1709 in the route setting request module 1603 is triggered; otherwise, the synchronization request submodule 1706 in the route setting request module 1603 is triggered.

[0228] The synchronization request submodule 1706 is configured to cause the first CAS to send a full routing synchronization request to the second CAS, wherein the full routing synchronization request is used to request the second CAS to send a first data packet and a second data packet to the source microservice node, wherein the first data packet is routing information in the sending direction of the target microservice node, and the second data packet is a terminal packet including a checksum.

[0229] The data packet receiving submodule 1707 is configured to cause the first CAS to receive the first data packet and the second data packet, and to update the check code in the source microservice node after receiving the second data packet.

[0230] The synchronization submodule 1708 is configured to enable the first CAS to synchronize the routing information in the first data packet to the source microservice node.

[0231] Optionally, before sending a routing setting request to the second CAS in the target microservice node (before triggering the request sending submodule 1709 in the routing setting request module 1603), the device shown in Figure 16 may also include: a resource pre-occupation module, which is used for the first CAS to pre-occupy the preset resources corresponding to the first transmission channel, so that after subsequent pairing is successful, the first transmission channel can be used to transmit media data, thereby improving the transmission success rate.

[0232] Furthermore, the apparatus shown in FIG16 may further include a resource release module configured to, if the channel pairing response fails, cause the first CAS to set the priority of the first transmission channel to a low priority, release the pre-occupied preset resources corresponding to the first transmission channel, and trigger the first CAS to reselect or create the first transmission channel. It will be appreciated that, if pairing fails, releasing the pre-occupied preset resources corresponding to the first transmission channel can avoid resource waste.

[0233] It can be understood that when a single work unit in CAS is at a performance bottleneck, additional channel creation and resource allocation are involved so that the load of the work unit can be balanced. When CAS sends a single routing information, both sides need to negotiate whether the resources are met (corresponding to the channel pairing process). First, the local (source microservice node) session selects a first transmission channel based on the preset number of resources in the work unit, and pre-occupies the current preset resources; then the other end (target microservice node) confirms that the preset resources in the work unit are sufficient, then creates a second transmission channel, returns a pairing response, and ends the process; otherwise, it returns the amount of available resources for each channel; this end sets the priority of the current first transmission channel to a low priority and releases the pre-occupied resources. Furthermore, this end excludes work units that do not meet resource requirements, reselects new channels, pre-occupies the current preset resources, and re-pairs with the transmission channel of the other end until the process ends.

[0234] Furthermore, the apparatus shown in FIG16 may further include: a periodic check module, configured to cause the first CAS to periodically check whether the first transmission channel is in an idle state; and a deletion request module, configured to cause the first CAS to send a channel deletion request for the second transmission channel to the second CAS when the first transmission channel is in an idle state and the idle time exceeds a preset threshold, and to set the state of the first transmission channel to unavailable.

[0235] It can be understood that regularly checking and deleting idle pairing channels can avoid wasting resources and thus avoid wasting resources.

[0236] Furthermore, the apparatus shown in FIG16 may further include: a deletion response receiving module configured for the first CAS to receive a channel deletion response returned by the second CAS; a channel deletion module configured for the first CAS to delete the first transmission channel if the channel deletion response indicates a successful deletion; and a status update module configured for the first CAS to update the status of the first transmission channel to available if the channel deletion response indicates a failed deletion. A response receiving module 1604 configured for the first CAS to receive a route setup response returned by the second CAS and, if the setup response indicates a successful deletion, to determine that the cascade connection between the source microservice node and the target microservice node is successful.

[0237] Optionally, after the source microservice node is successfully cascaded with the target microservice node, the first CAS sends the media data carried in the routing information to the target microservice node through the first transmission channel.

[0238] The embodiment shown in Figure 16 provides a microservice node cascading device. The source microservice node can achieve cascading with the target microservice node by adding a first CAS therein. This is a self-organizing cascading method of microservice nodes. This cascading method does not require the participation of a central node and does not involve complex signaling interactions. Therefore, it can improve the quality of audio and video services in instant messaging services.

[0239] Optionally, the apparatus shown in FIG16 may further include: an operation cache module, configured for the first CAS to add operations for the routing information to a cache queue, wherein the operations include adding operations and deleting operations, and the operations are sorted by time.

[0240] Furthermore, the apparatus shown in FIG. 16 may further include: an editing response module, configured for the first CAS to receive and respond to an edit to the cache queue, wherein the edit includes at least one of a deleting duplicate operation and a reverse operation.

[0241] Optionally, after the first transmission channel is successfully paired with the second transmission channel, the process shown in FIG11 may be used to update the routing information when the triggering condition is difficult to meet. The triggering condition may include but is not limited to at least one of the following:

[0242] 1) The XPU in the first CAS sends a routing setup request;

[0243] 2) The timer expires and routing information is cached in the session;

[0244] 3) Receive a channel pairing response from the peer end (second CAS).

[0245] Optionally, the apparatus shown in FIG16 may further include an anomaly recovery module configured to trigger the first CAS to reselect or create the first transmission channel when an anomaly occurs in the transmission network of the first CAS (including but not limited to at least one of a single-node anomaly and a network interruption), thereby recreating the transmission channel and performing full routing synchronization. This is a weak network resistance mechanism and a single-node anomaly recovery mechanism proposed in this specification, which can further improve service quality.

[0246] The device shown in FIG. 16 can be used to implement various embodiments of the microservice node cascading method shown in FIG. 6 . For related details, please refer to the above method embodiments.

[0247] As shown in Figure 18, another embodiment of the present specification provides a microservice node cascade device 1800, which can be applied to a target microservice node. The target microservice node is provided with a second cascade module CAS. The microservice node cascade device 1800 may include: a pairing request receiving module 1801, a session establishment module 1802 and a pairing response module 1803.

[0248] The pairing request receiving module 1801 is configured for the second CAS to receive a channel pairing request from the first CAS in the source microservice node.

[0249] The session establishing module 1802 is configured for the second CAS to respond to the channel pairing request and establish a session for the source microservice node.

[0250] The pairing response module 1803 is configured to enable the second CAS to select or create a second transmission channel and return a channel pairing response to the first CAS.

[0251] Optionally, the target microservice node is provided with multiple work units, and the work units are allocated preset resources for establishing a transmission channel. The second CAS selects or creates the second transmission channel in the following four ways, including but not limited to:

[0252] 1) When no transmission channel is established under the session, the second CAS selects a work unit whose remaining preset resources meet current needs to create a second transmission channel.

[0253] 2) When multiple transmission channels have been established under the session, the second CAS selects a transmission channel that has been successfully paired with the source microservice node among the multiple transmission channels as the second transmission channel.

[0254] 3) When multiple transmission channels have been established under the session and the remaining preset resources of the working units where the multiple channels are located do not meet the current needs, the second CAS selects another working unit whose remaining preset resources meet the current needs to create a second transmission channel.

[0255] 4) When multiple transmission channels have been established under the session and the remaining preset resources of all work units do not meet the current needs, the second CAS waits for a work unit with idle preset resources to appear and creates under the work unit with idle preset resources.

[0256] Optionally, the device shown in Figure 18 may further include: a judgment module, used by the second CAS to determine whether the sending route of the source microservice node and the receiving route of the target microservice node are consistent based on the verification code in the channel pairing request and the verification code of the target microservice node; a routing synchronization request module, used by the second CAS to send a full routing synchronization request to the first CAS when the sending route of the source microservice node and the receiving route of the target microservice node are inconsistent, wherein the full routing synchronization request carries a first data packet and a second data packet, wherein the first data packet is the routing information of the sending direction of the target microservice node, and the second data packet is an end packet containing a verification code, and the full routing synchronization request is used to request the first CAS to update the verification code in the source microservice node.

[0257] Furthermore, the apparatus shown in FIG. 18 may further include: a failure response module, configured to output an error log and return a pairing failure response to the first CAS when the second CAS fails to select and / or create the second transmission channel.

[0258] For the microservice node cascade device shown in Figure 18, cascading with the source microservice node can be achieved by adding a second CAS therein. This is a self-organizing cascade method of microservice nodes. This cascade method does not require the participation of a central node and does not involve complex signaling interactions. Therefore, it can improve the quality of audio and video services in instant messaging services.

[0259] The device shown in FIG. 18 can be used to implement various embodiments of the microservice node cascading method shown in FIG. 12 . For related details, please refer to the above method embodiments.

[0260] FIG19 is a schematic diagram of the structure of an electronic device according to an embodiment of the present specification. Referring to FIG19 , at the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage device. Of course, the electronic device may also include hardware required for other services.

[0261] The processor, network interface, and memory can be interconnected via an internal bus, such as an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus. These buses can be classified as address buses, data buses, and control buses. For ease of illustration, FIG19 shows only one bidirectional arrow, but this does not imply that there is only one bus or only one type of bus.

[0262] The memory is used to store programs. Specifically, the program may include program code, which includes computer operating instructions. The memory may include internal memory and non-volatile memory, and provides instructions and data to the processor.

[0263] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a microservice node cascade device at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0264] receiving routing information from the XPU;

[0265] When it is determined according to the routing information that the source microservice node and the target microservice node are located on different servers, establishing a connection with the target microservice node according to the routing information;

[0266] Select or create a first transmission channel, and send a routing setting request to the second CAS in the target microservice node, where the routing setting request carries the routing information;

[0267] Receive a routing setting response returned by the second CAS, and if the setting response is successful, determine that the source microservice node and the target microservice node are cascaded successfully.

[0268] Alternatively, the processor executes the program stored in the memory and is specifically configured to perform the following operations:

[0269] Receive a channel pairing request from the first CAS in the source microservice node;

[0270] In response to the channel pairing request, establish a session for the source microservice node;

[0271] A second transmission channel is selected or created, and a channel pairing response is returned to the first CAS.

[0272] The method performed by the microservice node cascade device disclosed in the embodiment shown in Figure 19 of this specification can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in the processor or software instructions. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of this specification can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in conjunction with the embodiments of this specification can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0273] The electronic device can also execute the method shown in Figure 6 or Figure 12, and realize the functions of the microservice node cascade device in the embodiment shown in Figure 6 or Figure 12, and the embodiments of this specification will not be repeated here.

[0274] It is understood that the embodiments described in this specification can be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in at least one application-specific integrated circuit (ASIC), digital signal processor (DSP), digital signal processing device (DSPD), programmable logic device (PLD), field-programmable gate array (FPGA), general-purpose processor, controller, microcontroller, microprocessor, other electronic units for performing the functions described in this specification, or a combination thereof.

[0275] For software implementation, the techniques described in the embodiments of this specification can be implemented by modules (e.g., procedures, functions, etc.) that perform the functions described in the embodiments of this specification. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0276] Of course, in addition to software implementation, the electronic device in this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0277] The embodiments of this specification also provide a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the various processes of the above-mentioned microservice node cascading method embodiment and can achieve the same technical effect. To avoid repetition, it is not repeated here. The computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0278] The embodiments of this specification also provide a computer program product including instructions, and when a computer executes the instructions of the computer program product, the computer executes the above-mentioned microservice node cascading method. Specifically, the computer program product can be run on the above-mentioned network device.

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

[0280] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0281] In the several embodiments provided in this specification, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0282] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0283] In addition, each functional unit in each embodiment of this specification may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0284] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this specification, or the part that contributes to the relevant technology, or the part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of this specification. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0285] The above description is merely a specific embodiment of this specification, but the scope of protection of this specification is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this specification should be included in the scope of protection of this specification. Therefore, the scope of protection of this specification should be based on the scope of protection of the claims.

Claims

1. A microservice node cascading method, applied to a source microservice node providing audio and video services, wherein the source microservice node is provided with a media processing module XPU and a first cascading module CAS, the method comprising: The first CAS receives routing information from the XPU; When the first CAS determines according to the routing information that the source microservice node and the target microservice node are located on different servers, the first CAS establishes a connection with the target microservice node according to the routing information; The first CAS selects or creates a first transmission channel, and sends a routing setting request to a second CAS in the target microservice node, wherein the routing setting request carries the routing information; The first CAS receives the routing setting response returned by the second CAS, and determines that the source microservice node is cascaded successfully with the target microservice node if the setting response is successful.

2. The method according to claim 1, further comprising: The first CAS sends the media data carried in the routing information to the target microservice node through the first transmission channel.

3. The method according to claim 2, before the first CAS selects or creates the first transmission channel, the method further comprises: The first CAS establishes a session for the target microservice node.

4. According to the method of claim 3, the source microservice node is provided with a plurality of working units, and the working units are allocated with preset resources for establishing a transmission channel, wherein: The first CAS selects or creates a first transmission channel, including: In the case that no transmission channel is established under the session, the first CAS selects a working unit whose remaining preset resources meet current needs to create a first transmission channel.

5. The method according to claim 3, wherein: The first CAS selects or creates a first transmission channel, including: In the case where multiple transmission channels have been established under the session, the first CAS selects a transmission channel among the multiple transmission channels that has been successfully paired with the target microservice node as the first transmission channel.

6. According to the method of claim 3, the source microservice node is provided with a plurality of working units, and the working units are allocated with preset resources for establishing a transmission channel, wherein: The first CAS selects or creates a first transmission channel, including: When multiple transmission channels have been established under the session and the remaining preset resources of the working units where the multiple channels are located do not meet current needs, the first CAS selects another working unit whose remaining preset resources meet current needs to create a first transmission channel.

7. According to the method of claim 3, the source microservice node is provided with a plurality of working units, and the working units are allocated with preset resources for establishing a transmission channel, wherein: The first CAS selects or creates a first transmission channel, including: In the case that multiple transmission channels have been established under the session and the remaining preset resources of all work units do not meet the current needs, the first CAS waits for a work unit with idle preset resources to appear, and Created under a unit of work.

8. According to the method according to any one of claims 1 to 7, before the first CAS sends a routing setting request to the second CAS in the target microservice node, the method further comprises: After selecting or creating the first transmission channel, the first CAS sends a channel pairing request to the second CAS, wherein the channel pairing request is used to request the second CAS to select or create a second transmission channel to pair with the first transmission channel; The first CAS receives a channel pairing response returned by the second CAS.

9. The method according to claim 8, before the first CAS sends a routing setting request to the second CAS in the target microservice node, the method further comprises: If the channel pairing response is successful, the first CAS determines whether the receiving route of the source microservice node is consistent with the sending route of the target microservice node according to the verification code in the channel pairing response and the verification code of the source microservice node; When the receiving route of the source microservice node is consistent with the sending route of the target microservice node, the first CAS is triggered to send a route setting request to the second CAS.

10. The method according to claim 9, further comprising: In the case that the receiving route of the source microservice node and the sending route of the target microservice node are inconsistent, the first CAS sends a full route synchronization request to the second CAS, wherein the full route synchronization request is used to request the second CAS to send the first data packet and the second data packet to the source microservice node, wherein the first data packet is the routing information of the sending direction of the target microservice node, and the second data packet is an end packet including a check code; The first CAS receives the first data packet and the second data packet, and updates the check code in the source microservice node after receiving the second data packet.

11. The method according to claim 10, further comprising: The first CAS synchronizes the routing information in the first data packet to the source microservice node.

12. The method according to claim 8, before sending the channel pairing request to the target microservice node, the method further comprises: The first CAS pre-occupies preset resources corresponding to the first transmission channel.

13. The method according to claim 12, further comprising: In the case where the channel pairing response fails, the first CAS sets the priority of the first transmission channel to a low priority, releases the preset resources corresponding to the pre-occupied first transmission channel, and triggers the first CAS to reselect or create a first transmission channel.

14. The method according to claim 10 or 11, further comprising: The first CAS periodically checks whether the first transmission channel is in an idle state; When the first transmission channel is in an idle state and the idle time exceeds a preset threshold, the first CAS sends a channel deletion request for the second transmission channel to the second CAS, and sends the state of the first transmission channel to the second CAS. status is set to Unavailable.

15. The method according to claim 14, further comprising: The first CAS receives a channel deletion response returned by the second CAS; When the channel deletion response indicates that the deletion is successful, the first CAS deletes the first transmission channel; In a case where the channel deletion response indicates deletion failure, the first CAS updates the status of the first transmission channel to available.

16. The method according to any one of claims 1-7, 9-13, 15, further comprising: The first CAS adds the operation for the routing information to a cache queue, wherein the operation includes a adding operation and a deleting operation, and the operations are sorted according to time size.

17. The method according to claim 16, further comprising: The first CAS receives and responds to an edit to the cache queue, wherein the edit includes at least one of a deduplication operation and a reverse operation.

18. The method according to any one of claims 1-7, 9-13, 15, wherein: The source microservice node is also provided with a content switching bus CSB, and the method further includes: When determining that the source microservice node and the target microservice node are located on the same server, the first CAS transparently transmits the media data carried in the routing information through the CSB.

19. The method according to any one of claims 1-7, 9-13, 15, further comprising: When an abnormality occurs in the transmission network of the first CAS, the first CAS is triggered to reselect or create a first transmission channel.

20. A microservice node cascading method, applied to a target microservice node providing audio and video services, wherein a second cascading module CAS is provided in the target microservice node, and the method comprises: The second CAS receives a channel pairing request from the first CAS in the source microservice node; The second CAS responds to the channel pairing request and establishes a session for the source microservice node; The second CAS selects or creates a second transmission channel, and returns a channel pairing response to the first CAS.

21. The method according to claim 20, wherein the target microservice node is provided with a plurality of working units, and the working units are allocated with preset resources for establishing a transmission channel, wherein: The second CAS selects or creates a second transmission channel, including: In the case that no transmission channel is established under the session, the second CAS selects a work unit whose remaining preset resources meet current needs to create a second transmission channel.

22. The method according to claim 20, wherein: The second CAS selects or creates a second transmission channel, including: In the case where multiple transmission channels have been established under the session, the second CAS selects a transmission channel among the multiple transmission channels that has been successfully paired with the source microservice node as the second transmission channel.

23. The method according to claim 20, wherein the target microservice node is provided with a plurality of working units, and the working units are allocated with preset resources for establishing a transmission channel, wherein: The second CAS selects or creates a second transmission channel, including: When multiple transmission channels have been established under the session and the remaining preset resources of the working units where the multiple channels are located do not meet current needs, the second CAS selects another working unit whose remaining preset resources meet current needs to create a second transmission channel.

24. The method according to claim 20, wherein the target microservice node is provided with a plurality of working units, and the working units are allocated with preset resources for establishing a transmission channel, wherein: The second CAS selects or creates a second transmission channel, including: When multiple transmission channels have been established under the session and the remaining preset resources of all work units do not meet current needs, the second CAS waits for the appearance of a work unit with idle preset resources and is created under the work unit with idle preset resources.

25. The method according to any one of claims 20 to 24, further comprising: The second CAS determines whether the sending route of the source microservice node and the receiving route of the target microservice node are consistent according to the verification code in the channel pairing request and the verification code of the target microservice node; When the sending route of the source microservice node and the receiving route of the target microservice node are inconsistent, the second CAS sends a full routing synchronization request to the first CAS, wherein the full routing synchronization request carries a first data packet and a second data packet, wherein the first data packet is the routing information of the sending direction of the target microservice node, and the second data packet is an end packet including a check code, and the full routing synchronization request is used to request the first CAS to update the check code in the source microservice node.

26. The method according to any one of claims 20 to 24, further comprising: When the second CAS fails to select and / or create the second transmission channel, the second CAS outputs an error log and returns a pairing failure response to the first CAS.

27. An electronic device comprising: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method as claimed in any one of claims 1 to 21.

28. A computer-readable storage medium, when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method as claimed in any one of claims 1 to 21.

Images