A distributed framework implementation method, electronic device, and storage medium

Abstract

The present application relates to the field of Internet of Things technology, and specifically discloses a method for implementing a distributed framework, an electronic device, and a storage medium, including: when any physical node in a distributed system responds to a startup request of a distributed application, the physical node intercepts the startup request to obtain information about the device to be scheduled, and when triggering distributed device scheduling based on the information of the device to be scheduled, the target node and target device are selected according to a preset scheduling strategy; in response to the physical node being the target master node or the target slave node, the target master node or the target slave node locally creates a logical device corresponding to the target device, and performs cross-node communication based on the logical device. The present application solves the problem of flexible cross-end calling of various distributed devices without the upper-layer application being aware of it, and can meet the needs of various cross-end combination scenario services.

Description

Technical Field

[0001] The present application relates to the field of Internet of Things technology, and specifically provides a method for implementing a distributed framework, an electronic device, and a storage medium. Background Art

[0002] With the continuous evolution of mobile Internet and the Internet of Things, the ecological integration, information flow and computing power sharing of car digital cockpits and devices such as mobile phones have become the trend of future development.

[0003] Emerging distributed systems, from the underlying kernel / driver, to the distributed soft bus and multi-device virtualization, and then to the upper-level distributed applications, comprehensively build a new distributed system and application ecosystem. Figure 1 This diagram shows a logic diagram of a mainstream emerging distributed system. Distributed application A on node A can call devices on nodes A, B, and C. Similarly, distributed application B supports transactions between nodes B and C and can also call devices on nodes A, B, and C.

[0004] These emerging distributed systems have the following limitations:

[0005] 1. Distributed systems are highly dependent on the underlying software and hardware collaboration and kernel drivers, and the underlying systems must be in the same ecosystem.

[0006] 2. The underlying system of the independent ecosystem is incompatible with other mainstream mobile phone and PC operating systems.

[0007] 3. The upper-layer application API of the independent ecosystem is incompatible with other mainstream mobile phone and PC operating systems.

[0008] The above limitations make it impossible for existing massive stock applications to flexibly call distributed devices across nodes. Summary of the Invention

[0009] In order to overcome the above-mentioned defects, the present application provides a method for implementing a distributed framework, a distributed system and a storage medium, which use the native system to realize the seamless cross-terminal sharing of devices by applications.

[0010] In a first aspect, the present application provides a method for implementing a distributed framework, which is applied to a distributed system, wherein the distributed system includes multiple physical nodes for implementing the distributed framework, and is characterized in that the method includes:

[0011] When any physical node in the distributed system responds to a startup request of a distributed application, the physical node intercepts the startup request to obtain information of a device to be scheduled, and when triggering distributed device scheduling based on the information of the device to be scheduled, selects a target node and a target device according to a preset scheduling policy;

[0012] The target nodes include a target master node and at least one target slave node, the target master node is used to execute the distributed application, and the target slave node is used to provide a target device required to execute the distributed application;

[0013] In response to the physical node being the target master node or the target slave node, the target master node or the target slave node locally creates a logical device corresponding to the target device and performs cross-node communication based on the logical device.

[0014] In some embodiments, after intercepting the start request, the physical node further comprises: acquiring static configuration resource information, the static configuration resource information including user-specified resource information and resource information configured by the system background;

[0015] The selecting of target nodes and target devices according to the preset scheduling strategy includes: determining whether the information of the device to be scheduled matches the static configuration resource information; if so, selecting the target nodes and target devices according to the preset static scheduling strategy; otherwise, selecting the target nodes and target devices according to the preset dynamic scheduling strategy.

[0016] Preferably, the method further comprises: the plurality of physical nodes used to implement the distributed framework pre-collect and save respective resource status information; the resource status information at least includes distributed device information, node system load status information and network link status information;

[0017] The selecting of the target node and the target device according to the preset static scheduling strategy includes: determining the target node and the target device that meet the scheduling requirements according to the resource information specified by the user or the resource information configured in the system background and the resource status information collected in advance;

[0018] The selecting of target nodes and target devices according to the preset dynamic scheduling strategy includes: combining the pre-collected resource status information, traversing the resources corresponding to the information of the device to be scheduled to determine the target nodes and target devices that meet the scheduling requirements.

[0019] In some implementation schemes, the target slave node locally creates a logical device corresponding to the target device, and performs cross-node communication based on the logical device, including:

[0020] The target slave node locally creates a logical device corresponding to the target device, starts a local distributed application based on its own native system, and connects the logical device to the native system of the target master node;

[0021] The target master node locally creates a logical device corresponding to the target device, and performs cross-node communication based on the logical device, including:

[0022] The target master node locally creates a logical device corresponding to the target device, continues to start the distributed application based on its own native system, obtains a device resource mapping table, determines the logical device according to the device resource mapping table, and uses the target device provided by the target slave node based on the logical device.

[0023] Preferably, after the target master node locally creates a logical device corresponding to the target device, the step further includes:

[0024] The target master node updates the device resource mapping table; the device resource mapping table is used to store the mapping relationship between the application ID of the distributed application and the logical device.

[0025] In some implementation schemes, the physical node intercepting the start request to obtain information about the device to be scheduled includes:

[0026] The physical node intercepts the startup request, obtains the application ID of the distributed application according to the startup request, and parses the application file description information corresponding to the application ID to obtain the device type and business service quality parameters of the device to be scheduled;

[0027] The method further includes: the physical node determining whether to trigger distributed device scheduling according to the device type and the business service quality parameter.

[0028] Preferably, the method further comprises: the target master node and the target slave node synchronizing the state of the distributed application in real time based on a preset application lifecycle management policy, wherein the state at least includes a start state, a pause state and a stop state.

[0029] Preferably, the target master node and the target slave node synchronize the state of the distributed application in real time based on a preset application lifecycle management policy, including:

[0030] When the distributed applications on all target slave nodes are in the startup state, the distributed application on the target master node is synchronized to the startup state;

[0031] When the distributed application on the target master node is in a stopped state or a paused state, the distributed applications on all target slave nodes are synchronized to a stopped state or a paused state;

[0032] When the target device on any target slave node has its resources seized, the distributed application on the target master node will be triggered to enter a pause state.

[0033] In a second aspect, the present application provides an electronic device comprising a processor and a storage device, wherein the storage device is suitable for storing multiple program codes, and the program codes are suitable for being loaded and run by the processor to execute the distributed framework implementation method described in any one of the technical solutions of the above-mentioned distributed framework implementation method.

[0034] In a third aspect, the present application provides a computer-readable storage medium storing a plurality of program codes, wherein the program codes are suitable for being loaded and run by a processor to execute the distributed framework implementation method described in any one of the technical solutions of the above-mentioned distributed framework implementation method.

[0035] The above one or more technical solutions of this application have at least one or more of the following beneficial effects:

[0036] In the technical solution of the present application, when any physical node in the distributed system responds to a startup request of a distributed application, it intercepts the startup request to obtain information about the device to be scheduled. When it is determined that the distributed device scheduling is triggered based on the information of the device to be scheduled, the target node and target device are selected according to the preset scheduling policy. In response to the physical node being a target master node or a target slave node, the target master node or the target slave node locally creates a logical device corresponding to the target device and performs cross-node communication based on the logical device. The distributed framework proposed in the present application comprehensively judges and abstracts a more general target master node for executing distributed applications and a target slave node for providing distributed device capabilities based on the preset scheduling policy, and abstracts the distributed device required to execute the distributed application, namely the target device, into a logical device, which can shield the details of the underlying physical device, thereby simplifying the distributed device management and scheduling of the framework. The distributed framework of the present application is also designed so that after the target master node and the target slave node create the logical device, they start the distributed application based on the native system for cross-node communication, thereby maximizing the use of existing resources and solving the problem of flexible cross-end calling of various distributed devices without the upper-layer application being aware of it, which can meet the needs of various cross-end combination scenario services. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The disclosure of this application will be more easily understood with reference to the accompanying drawings. Those skilled in the art will readily appreciate that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of this application. Furthermore, similar numbers in the figures represent similar components, where:

[0038] Figure 1 It is a logical diagram of the implementation method of an existing mainstream distributed framework;

[0039] Figure 2It is a distributed framework logic diagram of this application;

[0040] Figure 3 This is a flowchart of the main steps of a distributed framework implementation method of this application;

[0041] Figure 4 This is a schematic diagram of the process of intercepting applications and using distributed devices in this application;

[0042] Figure 5 It is a schematic diagram of a distributed scheduling process of the present application;

[0043] Figure 6 This is a schematic diagram of a logical device abstraction and distributed transmission process of this application;

[0044] Figure 7 This is a schematic diagram of a distributed application declaration lifecycle management process of this application. DETAILED DESCRIPTION

[0045] Some embodiments of the present application are described below with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are only used to explain the technical principles of the present application and are not intended to limit the scope of protection of the present application.

[0046] In the description of this application, "module" and "processor" may include hardware, software, or a combination of both. A module may include hardware circuitry, various suitable sensors, communication ports, and memory. It may also include software components, such as program code, or a combination of software and hardware. A processor may be a central processing unit, a microprocessor, an image processor, a digital signal processor, or any other suitable processor. A processor has data and / or signal processing capabilities. A processor may be implemented in software, hardware, or a combination of both. Non-transitory computer-readable storage media include any suitable medium capable of storing program code, such as magnetic disks, hard disks, optical disks, flash memory, read-only memory, random access memory, etc. The term "A and / or B" refers to all possible combinations of A and B, such as only A, only B, or both A and B. The terms "at least one of A or B" or "at least one of A and B" have similar meanings to "A and / or B" and may include only A, only B, or both A and B. The singular forms "a" and "the" may also include the plural forms.

[0047] Here we first explain some terms involved in this application.

[0048] Distributed system: refers to a system consisting of a group of computer nodes (or physical nodes) that communicate through a network and coordinate work to complete a common task.

[0049] Physical node: It is a basic concept in computer networks and refers to the physical devices in the network. Physical nodes can be computers, routers, switches or other network devices. They are usually tangible and touchable entities.

[0050] A distributed framework is a way of designing and organizing computer systems, aiming to connect multiple independent computer nodes so they can work together to accomplish tasks. The core of a distributed framework is the design approach of distributing system components across different computers, enabling them to communicate and collaborate over a network to achieve a common goal. In this architecture, each computer node operates independently and interacts with each other through message passing or shared state, aiming to improve system performance, reliability, and scalability.

[0051] Distributed application: refers to an application or service that is distributed on different computers and works together to complete a task through a network.

[0052] Native system: A computer operating system can be understood as an ecosystem. A native system refers to an operating system that has not been modified, cracked, or optimized.

[0053] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application can be combined with each other if there is no conflict.

[0054] See attached Figure 2 , is a logical diagram of a distributed framework provided by the present application, which exemplarily shows three physical nodes, namely node A, node B and node C, and the application scenario is: the distributed application A of node A calls device B of node B and device C of node C through the native system. In this application scenario, the distributed framework of the present application abstracts node A that executes the distributed application as the master node (hereinafter referred to as the Host node), and abstracts node B and node C that provide distributed device capabilities as slave nodes (hereinafter referred to as the Guest node). Figure 2 ①②③④⑤ in the figure exemplify the key technical points in the implementation of the distributed framework of this application, as follows:

[0055] ① Leverage native operating systems to provide cross-device call capabilities for distributed devices, maximizing the use of existing ecosystem resources. Typical native mobile operating systems include iOS, Android, and Hongmeng, while PC native operating systems include macOS, Windows, and Linux.

[0056] ② Based on the node functions of executing applications and providing device capabilities, the distributed framework abstracts more general host nodes and guest nodes, such as Host node A, Guest node B, and Guest node C shown in the figure.

[0057] ③The distributed framework dispatches the request to the Guest node.

[0058] ④ The Guest node starts the Guest application through the native system to provide the Host node with the distributed devices to be used, such as device B and device C shown in the figure.

[0059] ⑤The Guest node connects distributed devices to the native system of the Host node through distributed transmission and logical device abstraction.

[0060] In practice, a distributed application running on a single host node can utilize devices on multiple guest nodes. The concepts of host and guest are specific to a single distributed application; a single physical node can serve as both a host and a guest. For example, a physical node running distributed application X can also share its devices with application Y on another node. This physical node acts as both the host node for application X and the guest node providing distributed device capabilities for application Y.

[0061] For example, consider a scenario where a mobile phone, a car computer, and NBOX collaborate to play a game. The phone runs the game, the car computer screen displays the game interface, and the NBOX is connected to a joystick. In this scenario, the phone is the host node, and the car computer and NBOX are guest nodes. In another navigation scenario, the NBOX runs a map navigation app, the car computer screen displays the navigation interface, and the car computer also provides GPS navigation and navigation audio playback through the speakers. In this scenario, the NBOX is the host node and the car computer is the guest node. For the first game application, the NBOX is the guest node; for the second map navigation application, the NBOX is the host node.

[0062] See attached Figure 3 , is a distributed framework implementation method provided by this application, which realizes the above key technical points and solves the problem of flexible cross-node calling of various distributed devices without the upper-layer application being aware of it, and can meet the needs of various cross-end combination scenarios in the future. Figure 3 As shown, the implementation method of the distributed framework provided in this application is applied to a distributed system, and the distributed system includes multiple physical nodes for implementing the distributed framework. The implementation method of the distributed framework of this application mainly includes the following steps S11 and S12.

[0063] Step S11: When any physical node in the distributed system responds to a startup request of a distributed application, the physical node intercepts the startup request to obtain information about the device to be scheduled. When triggering distributed device scheduling based on the information about the device to be scheduled, the physical node selects a target node and a target device according to a preset scheduling policy.

[0064] The target nodes include a target master node and at least one target slave node. The target master node is used to execute a distributed application, and the target slave node is used to provide a target device required to execute the distributed application.

[0065] Step S12: In response to the physical node being the target master node or the target slave node, the target master node or the target slave node locally creates a logical device corresponding to the target device, and performs cross-node communication based on the logical device.

[0066] In an embodiment of the present application, for the target master node executing the distributed application, calling the logical device is the same as calling the local device, but the logical device will send the processing processes such as data reception and transmission, device control, etc. to the target slave node for interaction. In this way, the upper-level applications and services do not need to consider the details such as the underlying devices and network transmission, and the implementation is simpler. This application abstracts the logical device and shields the details of the underlying physical devices, which can achieve the effect of simplifying the distributed device management and scheduling of the framework.

[0067] Based on the above step S11, the physical node intercepts the startup request to obtain information about the device to be scheduled, including: the physical node intercepts the startup request, obtains the application ID of the distributed application according to the startup request, and parses the application file description information corresponding to the application ID to obtain the device type and business service quality parameters of the device to be scheduled; wherein, the resource requested by the startup request can be a single device or a group of devices with application scenario dependencies (such as screen and touch screen, speaker, etc.). Accordingly, the physical node can determine whether to trigger distributed device scheduling based on the device type and business service quality parameters. Specifically: the physical node determines whether the local device can simultaneously meet the device type and business service quality parameters. If they do, distributed device scheduling will not be triggered, and the physical node responds to the normal (non-distributed) startup request of the application; if they do not meet, distributed device scheduling will be triggered. Taking the playing of QQ Music on a mobile phone as an example, if QQ Music is started normally, distributed scheduling will not be triggered, and the mobile phone will directly play QQ Music. If distributed devices are shared between the mobile phone and the car cockpit, the mobile phone is the host node executing the QQ Music application, the car cockpit is the guest node, and the target device is the car speaker, which carries the sound playback. When the distributed QQ Music application is started on the mobile phone, the mobile phone music is played on the car speaker through distributed scheduling.

[0068] Furthermore, in step S11, the distributed application startup request may be a local application startup request or a cross-end application startup request. When the physical node responds to the distributed application startup request, the process of intercepting the startup request may include: the physical node intercepting the startup request based on the system permissions of the system where the local or cross-end application to be launched resides. After intercepting the startup request, when determining to trigger distributed device scheduling, the host node and the guest node are selected according to a preset scheduling policy.

[0069] In one application scenario, both physical nodes, NBOX and the vehicle computer, are brand A products and both support the Host service, meaning they have system permissions to intercept applications. When a map is launched on the vehicle computer, the vehicle computer system intercepts the application launch request and, based on a preset scheduling policy, schedules the application to the NBOX when it determines the NBOX system load is lower. The end result is that the NBOX serves as the Host node, running the map application, while the vehicle computer that originally launched the map serves as the Guest node, providing only device functions such as display and touchscreen.

[0070] In one application scenario, Brand A's NBOX and the in-vehicle computer are two physical nodes with system permissions to intercept applications. Brand B's phone, as a physical node, cannot intercept applications and therefore lacks system permissions. In actual applications, Brand B's phone can install a guest SDK app to provide distributed device capabilities for use by Brand A's NBOX and in-vehicle app. Specifically, when Brand B responds to an application launch request, it displays the app icons of Brand A's NBOX and in-vehicle computer, both with application interception permissions, through the guest app interface. The user then selects a node by clicking an icon in the guest app window. The phone then sends its location information to the selected Brand A NBOX or in-vehicle computer to intercept applications and perform distributed scheduling. Brand B's phone itself does not participate in application interception; it performs some message forwarding and supports distributed device calls through the guest app.

[0071] Furthermore, the distributed device scheduling in the embodiment of the present application can support both static scheduling and dynamic scheduling, and the preset scheduling policy includes a preset static scheduling policy and a preset dynamic scheduling policy. Specifically: in the above step S11, after the physical node intercepts the startup request, it also includes: obtaining static configuration resource information, the static configuration resource information includes user-specified resource information and resource information configured by the system background; accordingly, the target node and target device selected according to the preset scheduling policy includes: determining whether the information of the device to be scheduled matches the static configuration resource information, and if so, selecting the target node and target device according to the preset static scheduling policy; otherwise, selecting the target node and target device according to the preset dynamic scheduling policy. In actual applications, the multiple physical nodes used to implement the distributed framework will pre-collect and save their respective resource status information so that when distributed scheduling is performed according to the preset scheduling policy, the appropriate target node and target device can be determined in combination with the pre-collected resource status information. In this embodiment, the resource status information includes at least distributed device information, node system load status information, and network link status information. The pre-collected resource status information of each node can be uniformly saved in a distributed storage system, such as a file system, a database, etc.

[0072] The following describes static scheduling and dynamic scheduling.

[0073] For static scheduling, the target nodes and target devices are selected according to the preset static scheduling strategy. Specifically, the target nodes and target devices that meet the scheduling requirements are determined based on the resource information specified by the user or the resource information configured in the system background and the resource status information collected in advance. In a specific implementation, when the physical node intercepts the startup request of the distributed application, it can obtain the user's specified information on the service nodes and devices, that is, the static configuration resource information. For example, when the system desktop starts the distributed application, it provides the user with a list of service nodes and devices to be selected in the interface, and the user selects the target node and target device; the physical node determines whether the nodes and devices specified or configured by the static configuration resource information meet the scheduling requirements in combination with the pre-collected resource status information. If the scheduling requirements are met, the nodes and devices specified or configured by the static configuration resource information are determined as the target nodes and target devices, and the QoS of the resources already in use is updated if necessary (for example, adjusting the coding rate, transmission type, etc.); if the scheduling requirements are not met, the scheduling request failure is returned.

[0074] For example, a mobile phone, a vehicle computer, and an NBOX need to call a distributed speaker to play audio. For static scheduling, the mobile phone is designated as the master node, the vehicle computer as the slave node, and the vehicle computer's speaker as the designated device based on user-specified resource information. The vehicle computer's speaker availability is determined based on the vehicle computer's node system load and network connection status. If the availability conditions are met, the mobile phone is determined as the target master node, and the vehicle computer and speaker are determined as the target slave node and target device that meet the scheduling requirements. The vehicle computer's speaker resources are then configured and used. If the designated vehicle computer node and speaker device do not meet the availability conditions, no further nodes or devices are searched, and the call fails.

[0075] For dynamic scheduling, the target node and target device are selected according to the preset dynamic scheduling strategy. Specifically: in combination with the resource status information collected in advance, the resources corresponding to the information of the device to be scheduled are traversed to determine the target node and target device that meet the scheduling requirements. In a specific implementation, the physical node can find all the resources, i.e., nodes and devices, corresponding to the device to be scheduled based on its information, and traverse all nodes and devices. During the traversal process, it is determined whether each node and device meets the scheduling requirements based on the resource status information, until the nodes and devices that meet the scheduling requirements are found and determined as the target nodes and target devices. If necessary, the QoS of the resources already in use is updated (for example, adjusting the coding rate, transmission type, etc.); if the target node and target device that meet the scheduling requirements are still not found after the traversal is completed, the call request failure is returned.

[0076] Taking mobile phones, car computers, and NBOX as examples, for dynamic scheduling, all corresponding resources (including nodes and devices) are found according to the information of the device to be scheduled, and the mobile phone is determined as the target master node from the found resources based on the resource status information, and all devices in the resources are traversed. Assume that the car computer speaker is retrieved first, and whether the car computer speaker is available is determined based on the car computer node system and network status. If the availability conditions are met, the car computer and the speaker are designated as the target slave node and target device, and the car computer speaker resources are continued to be configured and used; if the car computer speaker does not meet the availability conditions, continue to retrieve and determine whether the NBOX speaker is available; if the availability conditions are met, designate the NBOX and the speaker as the target slave node and target device, and continue to configure and use the NBOX speaker resources; if the NBOX speaker does not meet the availability conditions and there are no other candidate nodes and distributed speaker devices, this call fails.

[0077] Based on the above step S12, the target slave node locally creates a logical device corresponding to the target device, and performs cross-node communication based on the logical device, including: the target slave node locally creates a logical device corresponding to the target device, starts a local distributed application based on its own native system, and docks the logical device to the native system of the target master node.

[0078] The target master node locally creates a logical device corresponding to the target device, and performs cross-node communication based on the logical device, including: the target master node locally creates a logical device corresponding to the target device, continues to launch the distributed application based on its own native system, obtains a device resource mapping table, determines a logical device based on the device resource mapping table, and uses the target device provided by the target slave node based on the logical device. Accordingly, after the target master node locally creates the logical device corresponding to the target device, the target master node also includes the step of updating the device resource mapping table; the device resource mapping table is used to store the mapping relationship between the application ID of the distributed application and the logical device.

[0079] Furthermore, the implementation method of the distributed framework provided in the embodiment of the present application may also include the following step S13.

[0080] Step S13: The target master node and the target slave node synchronize the state of the distributed application in real time based on a preset application lifecycle management policy, where the state includes at least a start state, a pause state, and a stop state.

[0081] In a specific embodiment, the target master node and the target slave node synchronize the state of the distributed application in real time based on a preset application lifecycle management policy, including:

[0082] When the distributed applications on all target slave nodes are in the startup state, the distributed application on the target master node is synchronized to the startup state;

[0083] When the distributed application on the target master node is in a stopped state or a paused state, the distributed applications on all target slave nodes are synchronized to a stopped state or a paused state;

[0084] When the target device on any target slave node has its resources preempted, the distributed application on the target master node will be triggered to enter a pause state.

[0085] It's understandable that if the target device whose resources were preempted is restored, the target master node resumes application execution, and all target slave nodes also resume application execution, meaning the state of the distributed applications on the target master and target slave nodes changes to the started state. For example, if a high-priority application in the native system exits and releases the preempted device, all distributed applications on the host and guest nodes of the distributed framework will resume execution.

[0086] For example, a mobile phone is the host node, and the car head unit is the guest node, providing distributed speakers. The phone runs the QQ Music app, and the car head unit's speakers play the music. If a call comes in on the phone, and the call is for a higher-priority application, the phone notifies the car head unit to pause QQ Music. When the call ends, the phone notifies the car head unit to resume playing QQ Music.

[0087] In order to have a deeper understanding of the implementation method of the distributed framework provided by this application, the following will be combined with Figures 4 to 7 The distributed framework implementation method involves a detailed description of the process of intercepting applications and using distributed devices, the distributed scheduling process, the logical device abstraction and distributed transmission process, and the application lifecycle management process.

[0088] See attached Figure 4 , Figure 4 The process of intercepting applications and using distributed devices is shown. Processes 1-5 in the figure are:

[0089] ①Intercept the startup request of the local or cross-end application to be started through the system desktop, and obtain the device type, service quality parameters (QoS), application ID (app ID), static configuration resource information, etc., including:

[0090] a. Parse the application file description information (such as Manifest) to extract the device type and QoS required by the application / service;

[0091] b. Record the information used to deliver the start request, namely the distributed application context information required, such as appI d, etc.;

[0092] c. Obtain resource information specified by the user or resource information configured by the system background;

[0093] In addition, you can also intercept the application to be launched through the application launcher (Launcher);

[0094] ② Determine whether to trigger distributed scheduling. The specific process includes:

[0095] a. If distributed devices are not required, the native system starts the application normally.

[0096] b. If a distributed device needs to be called, the native system dispatches the device to Guest node B through the distributed framework.

[0097] ③Configure and start the host node and guest node device resources, including:

[0098] a. Guest node B starts the application and configures local device B;

[0099] b. Create logical device B on the host node and logical device B on the guest node;

[0100] c. The logical device B of the host node is connected to the local device B of the guest node through distributed transmission.

[0101] ④The distributed framework maintains the device resource mapping table, which includes:

[0102] a. Update the mapping relationship between application ID and logical device stored in the device resource mapping table.

[0103] ⑤ The native system of the target Host node desktop (or Launcher) continues to start the application. When the framework service involves the use of distributed device resources, the native system chooses to use the distributed device by searching the device resource mapping table.

[0104] See attached Figure 5 , Figure 5 A distributed scheduling process is shown. The processes 1-5 in the figure correspond to:

[0105] ① Collect and store resource status information of each node in advance;

[0106] ② Determine the scheduling triggered by the application startup request;

[0107] ③Static scheduling;

[0108] ④Dynamic scheduling;

[0109] ⑤ Create a logical device, connect the logical device between the host node and the guest node, and the host node and the guest node connect and update the logical device to their respective native systems.

[0110] This application abstracts the various physical devices used for distributed scheduling into logical devices to simplify the management of distributed devices.

[0111] Logical devices mainly support two types of functions:

[0112] (1) Create cross-node communication links according to different application requirements and the transmission types supported by the underlying layer.

[0113] Distributed transmission technology supports wired transmission and wireless transmission. Based on the specific wired and wireless distributed transmission technologies, it completes the distributed transmission link establishment and ultimately carries the control and data communication of distributed devices.

[0114] Typical wired transmission methods include USB, HDMI, DP, A2B, etc. Typical wireless transmission methods include Wi-Fi, Bluetooth, infrared, Star Flash, 3G / 4G / LTE / 5G / 6G, etc.

[0115] (2) Through the native system framework device service, the data sent and received by the logical device is connected to the native system.

[0116] See attached Figure 6 , Figure 6 The process of logical device abstraction and distributed transmission is shown. The corresponding processes 1-4 in the figure are:

[0117] ① Obtain the device type based on distributed scheduling, as well as the transmission type that carries distributed device data.

[0118] The priority of distributed transmission is generally based on the principle of wired transmission > wireless transmission, high-speed transmission > low-speed transmission. For example, when there are USB connections and Wi-Fi connections at the same time, the USB transmission type is used first.

[0119] ② Create logical device instances on the host node and guest node respectively.

[0120] Logical devices only provide limited public APIs for opening, closing, connecting, disconnecting, configuring, and querying. Upper-layer distributed device services can operate underlying physical devices similarly to file calls, eliminating the need to worry about the complex underlying distributed transmission interconnection, device control, and device data transmission and processing. In the distributed framework, guest nodes can be triggered to create logical devices via RPC messages, and RPC messages can be used to control the logical device's opening, closing, connection, port, configuration, and query.

[0121] ③ Create cross-node communication links according to different transmission types.

[0122] ④Through the native system framework device service, the data sent and received by the logical device is connected to the native system.

[0123] See attached Figure 7 , Figure 7 The figure shows the distributed application lifecycle management process. Steps 1-5 in the figure are:

[0124] ① After the host node intercepts the distributed application, it starts the application of the guest node through scheduling.

[0125] ② After all guest node applications are in the startup state, the distributed application of the host node is in the startup state.

[0126] ③ The native system's high-priority application seizes the resources of the guest node's application, and the guest node's application enters a suspended state.

[0127] ④The distributed framework notifies the distributed applications of the Host node and the applications of other Guest nodes to enter the pause state.

[0128] ⑤The distributed application A of the host node exits and enters the stopped state. The distributed framework notifies the applications of other guest nodes to exit and enter the stopped state.

[0129] By synchronizing the application lifecycle between the host and guest nodes and using the native system frameworks of the host and guest nodes to resolve shared device conflicts, the design and development of distributed frameworks can be simplified.

[0130] It will be understood by those skilled in the art that all or part of the processes in the method for implementing the above-mentioned embodiments of the present application can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above-mentioned various method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file or some intermediate form. The computer-readable storage medium may include: any entity or device, medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory, random access memory, electric carrier signal, telecommunication signal and software distribution medium that can carry the computer program code. It should be noted that the content contained in the computer-readable storage medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable storage media do not include electric carrier signals and telecommunication signals.

[0131] Furthermore, the present application also provides an electronic device.

[0132] In an embodiment of an electronic device according to the present application, the electronic device mainly includes a processor and a storage device. The storage device can be configured to store a program for executing the distributed framework implementation method of the above-mentioned method embodiment, and the processor can be configured to execute the program in the storage device, which includes but is not limited to the program for executing the distributed framework implementation method of the above-mentioned method embodiment. For ease of explanation, only the parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method section of the embodiment of the present application.

[0133] In the embodiment of the present application, the electronic device may be a control device device formed by various electronic devices. In some possible implementations, the electronic device may include multiple storage devices and multiple processors. The program for executing the implementation method of the distributed framework of the above-mentioned method embodiment can be divided into multiple subroutines, and each subroutine can be loaded and run by the processor to execute different steps of the implementation method of the distributed framework of the above-mentioned method embodiment. Specifically, each subroutine can be stored in different storage devices respectively, and each processor can be configured to execute the program in one or more storage devices to jointly implement the implementation method of the distributed framework of the above-mentioned method embodiment, that is, each processor executes different steps of the implementation method of the distributed framework of the above-mentioned method embodiment respectively to jointly implement the implementation method of the distributed framework of the above-mentioned method embodiment.

[0134] The aforementioned multiple processors may be processors deployed on the same device. For example, the aforementioned electronic device may be a high-performance device composed of multiple processors, and the aforementioned multiple processors may be processors configured on the high-performance device. Furthermore, the aforementioned multiple processors may also be processors deployed on different devices. For example, the aforementioned electronic device may be a server cluster, and the aforementioned multiple processors may be processors on different servers in the server cluster.

[0135] Furthermore, the present application also provides a computer-readable storage medium.

[0136] In a computer-readable storage medium embodiment according to the present application, the computer-readable storage medium can be configured to store a program for executing the implementation method of the distributed framework of the above-mentioned method embodiment, and the program can be loaded and run by the processor to implement the implementation method of the above-mentioned distributed framework. For ease of explanation, only the parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present application. The computer-readable storage medium can be a storage device formed by various electronic devices. Optionally, the computer-readable storage medium in the embodiment of the present application is a non-transitory computer-readable storage medium.

[0137] Thus far, the technical solutions of the present application have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of the present application is obviously not limited to these specific embodiments. Without departing from the principles of the present application, those skilled in the art may make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will fall within the scope of protection of the present application.

Claims

1. A method for implementing a distributed framework, applied to a distributed system, wherein the distributed system includes a plurality of physical nodes for implementing the distributed framework, characterized in that: The method comprises: When any physical node in the distributed system responds to a startup request of a distributed application, the physical node intercepts the startup request to obtain information of a device to be scheduled, and when triggering distributed device scheduling based on the information of the device to be scheduled, selects a target node and a target device according to a preset scheduling policy; The target nodes include a target master node and at least one target slave node, the target master node is used to execute the distributed application, and the target slave node is used to provide a target device required to execute the distributed application; In response to the physical node being the target slave node, the target slave node locally creates a logical device corresponding to the target device, starts a local distributed application based on its own native system, and connects the logical device to the native system of the target master node to perform cross-node communication based on the logical device; In response to the physical node being the target master node, the target master node locally creates a logical device corresponding to the target device, continues to start the distributed application based on its own native system, obtains a device resource mapping table, determines the logical device according to the device resource mapping table, and uses the target device provided by the target slave node based on the determined logical device to perform cross-node communication based on the logical device.

2. The method according to claim 1, wherein: After intercepting the startup request, the physical node further comprises: acquiring static configuration resource information, the static configuration resource information including user-specified resource information and system background configured resource information; The selecting of target nodes and target devices according to the preset scheduling strategy includes: determining whether the information of the device to be scheduled matches the static configuration resource information; if so, selecting the target nodes and target devices according to the preset static scheduling strategy; otherwise, selecting the target nodes and target devices according to the preset dynamic scheduling strategy.

3. The method according to claim 2, wherein: The method further includes: the plurality of physical nodes used to implement the distributed framework pre-collecting and storing respective resource status information; the resource status information at least includes distributed device information, node system load status information and network link status information; The selecting of the target node and the target device according to the preset static scheduling strategy includes: determining the target node and the target device that meet the scheduling requirements according to the resource information specified by the user or the resource information configured in the system background and the resource status information collected in advance; The selecting of target nodes and target devices according to the preset dynamic scheduling strategy includes: combining the pre-collected resource status information, traversing the resources corresponding to the information of the device to be scheduled to determine the target nodes and target devices that meet the scheduling requirements.

4. The method according to claim 1, wherein: After the target master node locally creates a logical device corresponding to the target device, the method further includes: The target master node updates the device resource mapping table; the device resource mapping table is used to store the mapping relationship between the application ID of the distributed application and the logical device.

5. The method according to claim 1, wherein The physical node intercepting the startup request to obtain information of the device to be scheduled includes: The physical node intercepts the startup request, obtains the application ID of the distributed application according to the startup request, and parses the application file description information corresponding to the application ID to obtain the device type and business service quality parameters of the device to be scheduled; The method further includes: the physical node determining whether to trigger distributed device scheduling according to the device type and the business service quality parameter.

6. The method according to claim 1, wherein: The method further includes: the target master node and the target slave node synchronizing the state of the distributed application in real time based on a preset application lifecycle management policy, where the state includes at least a start state, a pause state, and a stop state.

7. The method according to claim 6, characterized in that: The target master node and the target slave node synchronize the state of the distributed application in real time based on a preset application lifecycle management policy, including: When the distributed applications on all target slave nodes are in the startup state, the distributed application on the target master node is synchronized to the startup state; When the distributed application on the target master node is in a stopped state or a paused state, the distributed applications on all target slave nodes are synchronized to a stopped state or a paused state; When the target device on any target slave node has its resources seized, the distributed application on the target master node will be triggered to enter a pause state.

8. An electronic device comprising a processor and a storage device, wherein the storage device is adapted to store a plurality of program codes, wherein: The program code is suitable for being loaded and run by the processor to execute the method for implementing the distributed framework according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a plurality of program codes, characterized in that: The program code is suitable for being loaded and run by a processor to execute the implementation method of the distributed framework according to any one of claims 1 to 7.

Images