Connection method and apparatus, internet of things system, and electronic device

Abstract

Embodiments of the present disclosure provide a connection method and apparatus, an Internet of Things system, and an electronic device. The method comprises: receiving a first scheduling request sent by a device, the first scheduling request carrying a device identifier of the device; determining a target MQTT Broker instance from an MQTT Broker cluster according to a preset scheduling policy; acquiring network connection information of the target MQTT Broker instance, and generating an access token corresponding to the device identifier and used for connecting to the target MQTT Broker instance; and returning the network connection information of the target MQTT Broker instance and the access token to the device, such that the device establishes an MQTT connection with the target MQTT Broker instance on the basis of the network connection information and the access token.

Description

A connection method, device, Internet of Things system, and electronic device

[0001] Cross-reference to related applications

[0002] This application is based on and claims priority to Chinese Patent Application No. 202510353459.8, filed on March 24, 2025, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure relates to the field of communication technology, and in particular to a connection method, apparatus, Internet of Things system, and electronic device. Background Technology

[0004] Message Queuing Telemetry Transport (MQTT) is a lightweight publish / subscribe messaging protocol designed for low-bandwidth, unstable network environments and widely used in the Internet of Things (IoT) field.

[0005] The MQTT protocol is based on a publish / subscribe mechanism, which allows clients to flexibly send and receive messages. The MQTT broker acts as an intermediary, receiving messages from publishers and forwarding them to the appropriate subscribers based on subscription relationships. Clients acting as publishers can send messages with specific topics to the MQTT broker instance. Clients acting as subscribers can subscribe to topics of interest from the MQTT broker instance and then receive messages forwarded by the MQTT broker instance that match the subscribed topics. Summary of the Invention

[0006] This disclosure provides a connection method, apparatus, Internet of Things system, and electronic device.

[0007] In a first aspect, this disclosure provides a connection method applied to a scheduling service instance, wherein the scheduling service instance is deployed independently of an MQTT Broker cluster, and the scheduling service instance is used to schedule MQTT Broker instances in the MQTT Broker cluster, wherein the MQTT Broker cluster includes at least two MQTT Broker instances. The method includes:

[0008] The receiving device sends a first scheduling request, the first scheduling request carrying the device identifier of the device;

[0009] Based on the pre-defined scheduling strategy, determine the target MQTT Broker instance in the MQTT Broker cluster;

[0010] Obtain the network connection information of the target MQTT Broker instance, and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance;

[0011] The network connection information and access token of the target MQTT Broker instance are returned to the device so that the device can establish an MQTT connection with the target MQTT Broker instance based on the network connection information and access token.

[0012] Secondly, this disclosure provides a connection method applied to an MQTT Broker instance, wherein the MQTT Broker instance is deployed in an MQTT Broker cluster, and the MQTT Broker cluster includes at least two MQTT Broker instances. The method includes:

[0013] The system receives an MQTT connection request sent by a requesting end, the MQTT connection request carrying the requesting end identifier and access token; the requesting end may be a device or a client.

[0014] Based on the access token corresponding to the pre-stored requester identifier, the access token carried in the MQTT connection request is verified to determine whether to establish an MQTT connection with the requester.

[0015] If it is determined that an MQTT connection has been established with the requesting end, after the MQTT connection is successfully established, the MQTT connection information established with the requesting end is saved in the stored connection information.

[0016] Thirdly, this disclosure provides a connection device applied to a scheduling service instance, which is deployed independently of an MQTT Broker cluster. The scheduling service instance is used to schedule MQTT Broker instances in the MQTT Broker cluster, which includes at least two MQTT Broker instances. The device includes:

[0017] The first request receiving module is used to receive a first scheduling request sent by the device, wherein the first scheduling request carries the device identifier of the device.

[0018] The target broker determination module is used to determine the target MQTT Broker instance in the MQTT Broker cluster according to the preset scheduling strategy;

[0019] The target information acquisition module is used to acquire the network connection information of the target MQTT Broker instance and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance;

[0020] The target information return module is used to return the network connection information and access token of the target MQTT Broker instance to the device, so that the device can establish an MQTT connection with the target MQTT Broker instance based on the network connection information and access token.

[0021] Fourthly, this disclosure provides a connection device applied to an MQTT Broker instance, the MQTT Broker instance being deployed in an MQTT Broker cluster, the MQTT Broker cluster including at least two MQTT Broker instances, the device comprising:

[0022] The request receiving module is used to receive MQTT connection requests sent by a requesting end, wherein the MQTT connection request carries the requesting end identifier and access token; the requesting end may be a device or a client.

[0023] The token verification module is used to verify the access token carried in the MQTT connection request based on the access token corresponding to the pre-stored requester identifier, and to determine whether to establish an MQTT connection with the requester.

[0024] The connection information storage module is used to store the MQTT connection information established with the requesting end in the stored connection information after the MQTT connection is successfully established, when it is determined that an MQTT connection has been established with the requesting end.

[0025] Fifthly, this disclosure provides an Internet of Things (IoT) system, comprising devices, a scheduling service instance, and an MQTT Broker cluster. The scheduling service instance is deployed independently of the MQTT Broker cluster. The scheduling service instance is used to schedule MQTT Broker instances within the MQTT Broker cluster. The MQTT Broker cluster includes at least two MQTT Broker instances, wherein:

[0026] The device is configured to send a first scheduling request to the scheduling service instance, wherein the first scheduling request carries the device identifier of the device;

[0027] The scheduling service instance is used to receive a first scheduling request sent by the device, determine a target MQTT Broker instance in the MQTT Broker cluster according to a preset scheduling policy, obtain the network connection information of the target MQTT Broker instance, and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance; and return the network connection information and access token of the target MQTT Broker instance to the device.

[0028] The device is also used to establish an MQTT connection with the target MQTT Broker instance based on the network connection information and the access token.

[0029] In a sixth aspect, this disclosure provides an electronic device comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory stores executable instructions that cause the processor to perform the steps of the connection method described above. Attached Figure Description

[0030] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments of this disclosure will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 is a flowchart of the steps of an embodiment of the connection method of this disclosure;

[0032] Figure 2 is a structural block diagram of an embodiment of the Internet of Things system disclosed herein;

[0033] Figure 3 is a flowchart illustrating the steps of a device access scheduling service example in an embodiment of this disclosure.

[0034] Figure 4 illustrates the token authentication process when the device establishes a connection with the target MQTT Broker instance in an embodiment of this disclosure.

[0035] Figure 5 is a schematic diagram of the processing flow after the device establishes an MQTT connection with the target MQTT Broker instance in an embodiment of this disclosure;

[0036] Figure 6 is a flowchart of the steps of another embodiment of the connection method of this disclosure;

[0037] Figure 7 is a structural block diagram of an embodiment of the connection device of this disclosure;

[0038] Figure 8 is a structural block diagram of another embodiment of the connection device disclosed herein;

[0039] Figure 9 is a schematic diagram of the structure of the electronic device provided in this disclosure;

[0040] Figure 10 is a flowchart of some steps in an embodiment of the connection method of this disclosure;

[0041] Figure 11 is a flowchart of some steps in an embodiment of the connection method of this disclosure;

[0042] Figure 12 is a flowchart of some steps of an embodiment of the connection method of this disclosure. Detailed Implementation

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

[0044] The terms "first," "second," etc., used in this disclosure and its claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this disclosure can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In embodiments of this disclosure, the term "multiple" refers to two or more, and other quantifiers are similar.

[0045] As the number of connected devices increases and the scale of business expands, a single MQTT Broker instance cannot meet the requirements of high concurrency and high availability.

[0046] With the increasing number of devices connected, MQTT Broker instances urgently need to be clustered to support the networking communication needs of more devices. For example, multiple MQTT Broker instances can be deployed, and load balancing can be achieved based on DNS (Domain Name System) services. Each MQTT Broker instance communicates internally to exchange messages, providing a complete and unified cluster service to the outside world. Specifically, when a device initiates a connection request, the DNS service can return the IP address of an available MQTT Broker instance according to preset rules (such as round-robin or random selection), thereby distributing the device's connection request across different MQTT Broker instances.

[0047] However, as the number of MQTT Broker instances increases, the communication between each MQTT Broker instance in the MQTT Broker cluster also increases, resulting in complex links between pairs of MQTT Broker instances and making troubleshooting difficult. In addition, message routing between MQTT Broker instances also consumes a lot of resources, affecting the efficient operation of the cluster.

[0048] Referring to Figure 1, a flowchart of a connection method embodiment of the present disclosure is shown, applied to a scheduling service instance. The scheduling service instance is deployed independently of the MQTT Broker cluster. The scheduling service instance is used to schedule MQTT Broker instances in the MQTT Broker cluster. The MQTT Broker cluster includes at least two MQTT Broker instances. The method may include the following steps:

[0049] Step 101: Receive a first scheduling request sent by the device, wherein the first scheduling request carries the device identifier of the device;

[0050] Step 102: Determine the target MQTT Broker instance in the MQTT Broker cluster according to the preset scheduling strategy;

[0051] Step 103: Obtain the network connection information of the target MQTT Broker instance, and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance;

[0052] Step 104: Return the network connection information and access token of the target MQTT Broker instance to the device, so that the device can establish an MQTT connection with the target MQTT Broker instance based on the network connection information and access token.

[0053] The connection method of this disclosure can be applied to Internet of Things (IoT) systems. The Internet of Things (IoT) refers to a network that connects various physical devices via the Internet to achieve data exchange and communication. These devices typically embed sensors, software, and other technologies to collect and share data. The core objective of the IoT is to achieve intelligent interaction between devices, improving efficiency and convenience. In this disclosure, the IoT system may include devices, scheduling service instances, and an MQTT Broker cluster, wherein the MQTT Broker cluster includes at least two MQTT Broker instances.

[0054] The MQTT Broker cluster refers to a service cluster consisting of at least two MQTT Broker instances. An MQTT Broker instance is a virtual entity of server software implementing the MQTT protocol, responsible for receiving, storing, and forwarding messages from devices or clients. For example, it receives messages from publishers and routes them accurately to subscribers who have subscribed to the corresponding topics. In practice, both devices and clients can be publishers or subscribers.

[0055] An MQTT Broker instance can be a process running in a specific environment (such as a server, container, etc.). This disclosure does not limit the deployment method of the MQTT Broker instance. For example, the MQTT Broker instance can be deployed on a physical server, virtual machine, cloud server, or containerized environment.

[0056] The device can be a physical or virtual entity that communicates with an MQTT Broker instance via the MQTT protocol, and can publish or subscribe to messages. This disclosure does not limit the specific type of the device. For example, the device can be a sensor device, such as a temperature sensor, humidity sensor, light sensor, air quality sensor, etc.; it can also be a smart camera, smart switch, smart door lock, or other smart devices.

[0057] Furthermore, the IoT system may also include a client, which may be software or an application that communicates with an MQTT Broker instance via the MQTT protocol, or it may be the device itself or other systems. This disclosure does not limit the specific type of the client. For example, the client may be a smartphone, tablet, personal computer, etc.

[0058] An example application scenario is that a smart camera (device) can collect video data and publish video event messages on different topics to an MQTT Broker instance via the MQTT protocol. A user's smartphone, acting as a client, can subscribe to these specific video event messages from the smart camera's MQTT Broker instance. The MQTT Broker instance then forwards these specific video event messages to the smartphone.

[0059] In a camera surveillance scenario, a video event refers to a set of relevant information triggered and recorded when the camera detects a specific situation. Video events include detecting someone entering or leaving the monitored area, detecting object movement, or detecting the appearance of smoke or flames, etc., and this disclosure does not limit the scope of such events.

[0060] The video event message may contain a link address pointing to the corresponding video data, through which the video data that generated the corresponding video event can be accessed.

[0061] This disclosure implements load balancing by scheduling MQTT Broker instances in an MQTT Broker cluster using a scheduling service instance. The implementation of the scheduling service instance is not limited. For example, the scheduling service instance can be a containerized service developed based on Spring Boot, deployed in a Kubernetes container, providing a unified scheduling service interface, and can be pre-configured with different scheduling strategies. Kubernetes containers typically run within a cluster, managed and communicating through resources such as Pods and Services. Ingress can provide a unified external access point for these containerized applications running within the cluster, routing external Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) requests to the corresponding service, thereby reaching the backend containerized application.

[0062] The scheduling service instance can be based on a microservices architecture. A microservices architecture breaks down a complex software system into multiple functionally independent, autonomous microservices, each of which can be independently developed, deployed, scaled, and maintained. In practice, different scheduling service instances may be responsible for scheduling different types of tasks, such as computational tasks and data transmission tasks. A microservices architecture can decompose these different types of scheduling functions into different microservices, each focusing on its own task, improving the overall system's performance and reliability. These microservices interact through lightweight communication mechanisms (such as HTTP, message queues, etc.) to collaboratively complete the system's business functions.

[0063] For example, embodiments of this disclosure can deploy a scheduling service instance of a microservice architecture in a Kubernetes container. Kubernetes can provide a runtime environment and management mechanism for the implementation of a microservice architecture, and can easily manage issues such as communication between microservices, service discovery, and load balancing.

[0064] Furthermore, the scheduling service instance can be any one of the scheduling service clusters, which may include at least one scheduling service instance and provide a unified scheduling service interface to the outside world. Each scheduling service instance can be a microservice in a microservice architecture.

[0065] When a device needs to establish an MQTT connection with an MQTT Broker instance, it first sends a first scheduling request to the scheduling service instance. The first scheduling request can be an HTTP request.

[0066] Furthermore, the scheduling service cluster provides a unified scheduling service interface to the outside world. After receiving the first scheduling request sent by the device through the scheduling service interface, the first scheduling request is sent to a certain scheduling service instance in the scheduling service cluster through a polling method.

[0067] In one example, the scheduling service cluster consists of multiple scheduling service instances, each of which is a stateless instance deployed in a Kubernetes container, providing a unified scheduling service interface to the outside world. Kubernetes is a platform for managing containerized applications. In this embodiment, a custom scheduling service is deployed as a containerized application in a Kubernetes container. Kubernetes is responsible for managing the lifecycle of these containers, including creation, deployment, scaling, and monitoring. Kubernetes provides Ingress service instances, which are primarily responsible for routing external HTTP / HTTPS requests to internal Kubernetes services (such as scheduling service instances) according to configuration rules, such as using a round-robin approach. Devices can access the custom scheduling service interface by sending a first scheduling request (which can be an HTTP or HTTPS request). Furthermore, this embodiment can deploy a gateway on Kubernetes, and the first scheduling request first arrives at the gateway. The gateway performs HTTP signature authentication on the first scheduling request. Only the first scheduling request that passes HTTP signature authentication can be forwarded to the Kubernetes Ingress service instance, which then routes it to the scheduling service instance. This serves to protect internal services and verify the legitimacy of requests. HTTP signature authentication is a mechanism to enhance the security of HTTP requests. By signing key information in the request, the origin and integrity of the request can be verified. This disclosure does not limit the specific methods of HTTP signature authentication.

[0068] After receiving the first scheduling request from the device, the scheduling service instance determines the allocatable target MQTT Broker instance in the MQTT Broker cluster according to a preset scheduling policy. The preset scheduling policy can be set according to the actual scenario. For example, the preset scheduling policy may include at least a load balancing policy, such as a minimum connections policy, a minimum resource consumption policy, a shortest response time policy, and a business logic policy. Specifically, the minimum connections policy allocates the request to the MQTT Broker instance with the fewest current connections; the minimum resource consumption policy allocates the request to the MQTT Broker instance with the lowest current resource consumption; the shortest response time policy allocates the request to the MQTT Broker instance with the shortest response time; and the business logic policy allocates the request to a specific MQTT Broker instance based on different business logic or data characteristics. This disclosure does not limit the specific content of the preset scheduling policy.

[0069] After determining the target MQTT Broker instance, the scheduling service instance obtains the network connection information of the target MQTT Broker instance, such as the public IP address and port number of the target MQTT Broker instance, and generates an access token corresponding to the device identifier for accessing the target MQTT Broker instance; it then returns the network connection information and the access token to the device, so that the device can establish an MQTT connection with the target MQTT Broker instance based on the network connection information and the access token.

[0070] After the device successfully establishes an MQTT connection with the target MQTT Broker instance, the device can publish messages to or subscribe to messages from the target MQTT Broker instance.

[0071] This embodiment of the disclosure uses a scheduling service instance to schedule each MQTT Broker instance in an MQTT Broker cluster, thereby achieving MQTT Broker instance clustering to meet the access needs of massive devices and improve the communication capabilities of the IoT system. The scheduling service instance is deployed independently and connects only to devices; each device connects only to a specific MQTT Broker instance. Which MQTT Broker instance a device connects to depends on the scheduling service instance. The MQTT Broker instances in the MQTT Broker cluster are independent and connectionless to each other, eliminating the need to establish complex pairwise internal communication links, reducing link complexity and resource consumption.

[0072] In practice, a binding relationship can be pre-established between a device and a client. Thus, the bound device and the client can publish or subscribe to messages through the same MQTT Broker instance.

[0073] For example, if a binding relationship has been established between device A and client A, device A can establish an MQTT connection with MQTT Broker A and publish messages on a specific topic to MQTT Broker A. Client A can also establish an MQTT connection with MQTT Broker A and subscribe to messages on the same topic published by device A. Conversely, client A can also publish messages on a specific topic to MQTT Broker A, and device A can subscribe to messages on the same topic published by client A. However, if no binding relationship has been established between device A and client B, client B cannot establish an MQTT connection with MQTT Broker A and therefore cannot subscribe to messages on the same topic published by device A. This ensures the security and privacy of user data.

[0074] Furthermore, before using the preset scheduling strategy, the device can be preferentially allocated MQTT Broker instances that are already connected to the client and have a binding relationship with it.

[0075] In some embodiments of this disclosure, as shown in FIG10, before determining the target MQTT Broker instance in the MQTT Broker cluster according to a preset scheduling policy, the method may further include:

[0076] Step S11: Based on the device identifier, query the bound clients that have a binding relationship with the device;

[0077] Step S12: In the stored connection information, query whether there is any MQTT connection information established by the bound client; the stored connection information includes MQTT connection information established between each MQTT Broker instance and the device or client in the MQTT Broker cluster;

[0078] Step S13: If there is an MQTT connection information established by the bound client, then determine the MQTT Broker instance that has established an MQTT connection with the bound client as the target MQTT Broker instance.

[0079] The step of determining the target MQTT Broker instance in the MQTT Broker cluster according to the preset scheduling strategy may include:

[0080] If there is no bound client that has a binding relationship with the device, or if there is no MQTT connection information established by the bound client, then the target MQTT Broker instance is determined in the MQTT Broker cluster according to the preset scheduling policy.

[0081] Upon receiving the first scheduling request from a device, the scheduling service instance first determines whether a bound client exists that is already associated with that device. If a bound client does exist, it further queries whether that bound client has already established an MQTT connection with an MQTT Broker instance. If the bound client has already established an MQTT connection with an MQTT Broker instance, that MQTT Broker instance is directly identified as the target MQTT Broker instance. This allows devices and clients with a binding relationship to be connected to the same MQTT Broker instance.

[0082] To reduce link complexity and resource consumption, in this embodiment of the disclosure, no internal communication links are established between each MQTT Broker instance in the MQTT Broker cluster, and MQTT Broker instances do not interact with each other. Therefore, in order to enable devices and clients with a binding relationship to communicate via MQTT Broker instances, this embodiment of the disclosure connects devices and clients with a binding relationship to the same MQTT Broker instance.

[0083] For example, client A and device A have established a binding relationship. Device A sends a first scheduling request to the scheduling service instance. The scheduling service instance allocates an MQTT Broker instance (let's call it Broker1) to device A, and device A establishes an MQTT connection with Broker1. Subsequently, client A also establishes an MQTT connection with Broker1 through the scheduling service instance. That is, client A and device A establish MQTT connections with the same MQTT Broker instance (Broker1). Client A and device A can communicate via message through Broker1, such as publishing or subscribing to messages. If device A disconnects from Broker1 due to an exception or other reason, but client A still maintains a connection with Broker1, device A resends the first scheduling request to the scheduling service instance. The scheduling service instance can find in its stored connection information that client A, which is bound to device A, has established an MQTT connection with Broker1. Therefore, it can directly determine Broker1 as the target MQTT Broker instance, allowing device A to quickly re-establish an MQTT connection with Broker1.

[0084] The stored connection information may include MQTT connection information established between each MQTT Broker instance in the MQTT Broker cluster and a device or client. Further, an MQTT connection can be represented by a key-value pair, which includes the identification information of the two peers establishing the MQTT connection. For example, the MQTT connection information established between device A and Broker1 can be a key-value pair consisting of the device identifier of device A and the device identifier of Broker1. The MQTT connection information established between client A and Broker1 can be a key-value pair consisting of the user identifier of client A and the device identifier of Broker1.

[0085] This disclosure does not limit the storage location of the stored connection information. For example, after an MQTT Broker instance in the MQTT Broker cluster successfully establishes an MQTT connection with a device or client, the MQTT Broker instance can save the MQTT connection information between the MQTT Broker instance and the device or client to a pre-configured database, thus obtaining the stored connection information. This disclosure does not limit the form of the pre-configured database; it can be a local database or a cloud database, etc. For example, the pre-configured database can be a Remote Dictionary Server (Redis) service cluster. Redis is an open-source, in-memory data structure storage system that can be used as a database, cache, and message broker.

[0086] It should be noted that the stored connection information can be dynamically updated based on the actual connection status. When an MQTT Broker instance successfully establishes an MQTT connection with a device or client, the corresponding MQTT connection information is added to the stored connection information; when an MQTT Broker instance disconnects from a device or client, the corresponding MQTT connection information is deleted from the stored connection information.

[0087] If the scheduling service instance finds that there is no bound client with a binding relationship to the device, or that there is no established MQTT connection information for the bound client, then it determines the target MQTT Broker instance in the MQTT Broker cluster based on the preset scheduling policy.

[0088] For example, when device A sends the first scheduling request, client A has not established an MQTT connection with any MQTT Broker instance, or, after device A disconnects its MQTT connection with Broker1, client A also disconnects its MQTT connection with Broker1. In this case, the scheduling service instance can allocate a target MQTT Broker instance to device A based on a pre-defined scheduling policy.

[0089] This disclosure does not limit the content of the preset scheduling strategy, which is pre-configured in the scheduling service instance. The preset scheduling strategy can be a single scheduling strategy or a combination of multiple scheduling strategies.

[0090] In some embodiments, the preset scheduling strategy may include a preset load balancing strategy. Further, the preset load balancing strategy may include any one of the following: least connections strategy, minimum resource consumption strategy, shortest response time strategy, business logic strategy, etc. The embodiments disclosed herein are not limited to this.

[0091] In some embodiments, the preset scheduling policy may include a preset targeting policy. The preset targeting policy is used to send a first scheduling request from a specified device to a specified MQTT Broker instance; that is, upon receiving a first scheduling request from a specified device, the target MQTT Broker instance is determined to be the specified MQTT Broker instance. The specified device can be a device identified by a specified device identifier; or, the specified device can be all devices under a specified device type. The specified MQTT Broker instance can be a specific MQTT Broker instance specified in an MQTT Broker cluster. This disclosure does not limit how the device and the specified MQTT Broker instance are specified, and can meet diverse needs in different scenarios.

[0092] Furthermore, the embodiments of this disclosure can be applied to scenarios involving multi-level MQTT Broker clusters. A multi-level MQTT Broker cluster is an architecture that organizes multiple MQTT Broker clusters into a hierarchical structure to meet the needs of large-scale, high-reliability, and complex message communication. Multiple MQTT Broker clusters can be divided according to their geographical location (region). For example, the preset targeting policy can be used to send a first scheduling request sent by a device to the MQTT Broker cluster in the region to which the device belongs, and then further determine the target MQTT Broker instance in the MQTT Broker cluster in the region to which the device belongs based on a preset load balancing policy.

[0093] Through the embodiments disclosed herein, targeted scheduling of devices can be achieved to meet the business needs of different requirements and complex scenarios.

[0094] In some embodiments of this disclosure, as shown in FIG12, the method may further include:

[0095] Step S31: Receive a second scheduling request sent by the client, wherein the second scheduling request includes the user identifier of the client and the device identifier of the specified device;

[0096] Step S32: Based on the user identifier and the device identifier of the specified device, query whether the client and the specified device have a binding relationship;

[0097] Step S33: If the client and the specified device have a binding relationship, then query the stored connection information to see if there is any MQTT connection information established by the specified device.

[0098] Step S34: If an MQTT connection has been established with the specified device, return the network connection information and access token of the MQTT Broker instance that has established an MQTT connection with the specified device to the client; if no MQTT connection has been established with the specified device, return a request failure message to the client.

[0099] When a client establishes an MQTT connection with an MQTT Broker instance through a scheduling service instance, it sends a second scheduling request to the scheduling service instance. This second scheduling request includes the client's user identifier and the device identifier of a specified device. The specified device is the device through which the client needs to communicate via the MQTT Broker instance.

[0100] The scheduling service instance queries whether the client and the specified device have a binding relationship based on the user identifier and the device identifier of the specified device. In some embodiments, this disclosure may pre-store the binding relationship between the device and the client in a pre-built database, such as a Redis service cluster. The scheduling service instance can query the stored binding relationships in the Redis service cluster to determine whether a binding relationship exists between the user identifier and the device identifier of the specified device.

[0101] If a binding relationship exists, the system further queries whether the specified device has established an MQTT connection with a certain MQTT Broker instance. Specifically, based on the device identifier of the specified device, the system queries the stored connection information to see if there is any MQTT connection information established by the specified device. If the stored connection information contains information about an established MQTT connection of the specified device, it indicates that the specified device has established an MQTT connection with a certain MQTT Broker instance (such as Broker1). The system then returns the network connection information and access token of Broker1 to the client. The client can then establish an MQTT connection with Broker1 based on Broker1's network connection information and access token, thereby enabling message communication with the specified device (such as device A) through Broker1. For example, device A can publish messages on different topics to Broker1, and client A can subscribe to messages on one or more topics published by device A from Broker1.

[0102] If the client and the specified device are not found to be bound together, or if they are found to be bound together but the stored connection information does not contain any MQTT connection information established by the specified device (i.e., the specified device has not established an MQTT connection with any MQTT Broker instance), then a request failure message is returned to the client, refusing to establish an MQTT connection.

[0103] It should be noted that, through the embodiments of this disclosure, message communication between devices and clients can be achieved via an MQTT Broker instance. Similarly, message communication between devices and between clients can be achieved via an MQTT Broker instance.

[0104] Furthermore, embodiments of this disclosure can cluster the scheduling service instances to achieve a scheduling service cluster. The scheduling service cluster includes at least one scheduling service instance, providing a unified scheduling service interface for devices or clients to call. Devices / clients can send a first scheduling request / second scheduling request through the scheduling service interface. The scheduling service cluster sends the first scheduling request / second scheduling request to a specific scheduling service instance within the cluster using a polling method.

[0105] Furthermore, the IoT system of this disclosure embodiment can also integrate other public service clusters. The public service clusters may include a service discovery management cluster and a database service cluster. The service discovery management cluster is used to provide service management functions, including service registration, discovery, configuration, and decommissioning. For example, the service discovery management cluster may include a Dynamic Naming and Configuration Service (Nacos) service cluster. The database service cluster is used to provide distributed data storage functions. For example, the database service cluster may include a Redis service cluster.

[0106] Referring to Figure 2, a schematic diagram of the structure of an Internet of Things (IoT) system according to an embodiment of the present disclosure is shown. As shown in Figure 2, the IoT system may include a device cluster 201, including at least one device 2011; a scheduling service cluster 202, including at least one scheduling service instance 2021; and an MQTT Broker cluster 203, including at least two MQTT Broker instances 2031. In some embodiments, the IoT system may further include a public service cluster, including a Nacos service cluster and a Redis service cluster. Communication between devices and scheduling service instances can be based on the HTTP protocol or any other known protocol, and communication between devices and MQTT Broker instances can be based on the MQTT protocol.

[0107] In some embodiments of this disclosure, the method may further include:

[0108] The scheduling service instance subscribes to the service discovery management cluster to receive notifications sent by the service discovery management cluster when an MQTT Broker instance registers or goes offline; each MQTT Broker instance in the MQTT Broker cluster registers with the service discovery management cluster after startup.

[0109] In this embodiment of the disclosure, each MQTT Broker instance first registers with the Nacos service cluster after startup. The Nacos service cluster can record the metadata of each registered MQTT Broker instance, including but not limited to the MQTT Broker instance's public IP address, port number, name, and online information.

[0110] The scheduling service instance can subscribe to services from the service discovery and management cluster (such as the Nacos service cluster). After a successful subscription, the Nacos service cluster will proactively send notifications to the scheduling service instance when a new MQTT Broker instance registers or an existing MQTT Broker instance goes offline. Thus, the scheduling service instance can dynamically detect the registration and offline status of MQTT Broker instances, and thereby know in real time which MQTT Broker instances are available in the MQTT Broker cluster.

[0111] Specifically, the Nacos service cluster provides relevant APIs (Application Programming Interfaces). MQTT Broker instances can register their own metadata with the Nacos service cluster through these APIs. Scheduling service instances can subscribe to the registered metadata of MQTT Broker instances through the Nacos service cluster's APIs. Furthermore, the scheduling service instance can cache the metadata of registered MQTT Broker instances locally, allowing it to quickly query available MQTT Broker instances when it receives a scheduling request. When an MQTT Broker instance registers or goes offline, the scheduling service instance receives a notification from the Nacos service cluster and can then synchronously update the metadata in its local cache.

[0112] After receiving the first scheduling request from the device and identifying the target MQTT Broker instance, the scheduling service instance can retrieve the network connection information of the target MQTT Broker instance from its locally cached metadata. The scheduling service instance generates an access token for the target MQTT Broker instance, which can be used to verify the legitimacy of the visitor's access. This access token can be a random value generated based on the target MQTT Broker instance's UUID (Universally Unique Identifier).

[0113] Furthermore, after generating the access token for the target MQTT Broker instance, the method may further include: setting the validity period of the access token, and deleting the access token from the preset database when the validity period expires.

[0114] After generating an access token corresponding to the device identifier for accessing the target MQTT Broker instance, the scheduling service instance can save the generated access token to a pre-configured database and set the validity period of the access token. In specific implementations, the validity period of the access token can be set according to the actual scenario. For example, for scenarios with high security requirements, the validity period can be set shorter to reduce the risk of the access token stored in the pre-configured database being stolen. For scenarios with high real-time requirements, the validity period can be set longer. In this way, when the device loses its connection with an MQTT Broker instance, the device can use the stored access token to quickly re-establish a connection with that MQTT Broker instance without having to re-access the scheduling service instance and regenerate a new access token. This reduces device interaction and improves system performance.

[0115] Furthermore, embodiments of this disclosure may also store the binding relationship between the device and the client in a pre-configured database (such as a Redis service cluster), as well as the MQTT connection information established between each MQTT Broker instance in the MQTT Broker cluster and the device or client.

[0116] After receiving the first scheduling request from the device, the MQTT Broker instance can query the stored binding relationships in the pre-configured database to determine if the device has a bound client. If so, it can query the stored connection information in the pre-configured database based on the bound client's user identifier to check if there is any MQTT connection information established by that bound client (user identifier). This determines whether the bound client has established an MQTT connection with an MQTT Broker instance. If the bound client has established an MQTT connection with an MQTT Broker instance, that MQTT Broker instance is selected as the target MQTT Broker instance. If no bound client has a binding relationship with the device, or if the stored connection information does not contain any MQTT connection information established by the bound client, the MQTT Broker instance that meets the pre-configured scheduling policy in the MQTT Broker cluster is selected as the target MQTT Broker instance. For example, in the MQTT Broker cluster, the MQTT Broker instance with the fewest established MQTT connections is selected as the target MQTT Broker instance.

[0117] Furthermore, the least-connection strategy adopted in this embodiment refers to identifying the MQTT Broker instance with the fewest established MQTT connections in the MQTT Broker cluster as the target MQTT Broker instance. In specific implementations, since devices are typically used for real-time data collection, they are mostly located in fixed positions and operate for extended periods. Therefore, the MQTT connections between the devices and the MQTT Broker instances are usually long-lived connections, maintaining the connection for a considerable time after establishment. Clients are typically mobile terminals used by users, and their MQTT connections with the MQTT Broker instances are usually short-lived connections, maintaining the connection for a short period after establishment, such as brief, multiple connections.

[0118] Based on the above practical scenario, when adopting the least-connection strategy, determining the number of MQTT connections established by each MQTT Broker instance can be done by simply counting the number of MQTT connections between the MQTT Broker instance and the device. Alternatively, it can be done by counting the total number of MQTT connections between the MQTT Broker instance and the device, as well as the client. This disclosure does not impose any limitations on this approach, and an appropriate strategy can be selected based on the actual scenario.

[0119] In some embodiments of this disclosure, the first scheduling request may also carry a timestamp and first authentication information, which is calculated by the device based on the timestamp and the device key (deviceSecret).

[0120] Typically, devices are pre-loaded with device information before leaving the factory, including product key, device name, and device secret. This device information is entered into the device database and burned into the device.

[0121] In this embodiment of the disclosure, the scheduling service instance can also add a device authentication function to perform device authentication before responding to the first scheduling request sent by the device, thereby improving system security. The device key is generated by the device manufacturer and burned into the device. The generation process is based on a complex encryption algorithm and random number generation technology to ensure the uniqueness and randomness of the device key.

[0122] When a device sends a first scheduling request, it calculates first authentication information based on the current timestamp and the device key, and includes its own device identifier, the current timestamp, and the first authentication information in the first scheduling request for the scheduling service instance to authenticate its identity. The device identifier carried in the first scheduling request may include the device name (deviceName) and the product identifier (productKey).

[0123] Further, as shown in Figure 11, after the receiving device sends the first scheduling request, the method may further include:

[0124] Step S41: Based on the device identifier, query the device key corresponding to the pre-stored device identifier;

[0125] Step S42: Calculate the second authentication information based on the timestamp carried in the first scheduling request and the queried device key;

[0126] Step S43: If the first authentication information and the second authentication information match, the device authentication is successful and the device responds to the first scheduling request; otherwise, the device authentication fails and the device refuses to respond to the first scheduling request.

[0127] In specific implementation, after receiving the first scheduling request sent by the device, the scheduling service instance queries the preset database for a device key corresponding to the device identifier carried in the first scheduling request. If the key exists, step S42 is executed; if not, the instance queries the device database for a device key corresponding to the device identifier carried in the first scheduling request. If the key exists, step S42 is executed, and the device key corresponding to the device identifier is saved in the preset database for quick retrieval next time. If the device database does not contain a device key corresponding to the device identifier, authentication fails, and the first scheduling request is refused.

[0128] If the device key corresponding to the device identifier is found in the preset database or device database, the second authentication information is calculated based on the timestamp carried in the first scheduling request and the found device key. The scheduling service instance compares the second authentication information it has calculated with the first authentication information carried in the first scheduling request. If the two match, the device authentication is successful, and the first scheduling request is responded to; otherwise, the device authentication fails, and the first scheduling request is refused.

[0129] Furthermore, the scheduling service instance can also add a blacklist service. Each scheduling service instance can have a pre-configured blacklist, which can be a list of device names. After the scheduling service instance receives the first scheduling request sent by a device, it first checks whether the device name exists in the blacklist. If the device name exists in the blacklist, it directly returns a request failure message, rejecting the request, without executing subsequent steps.

[0130] Referring to Figure 3, a flowchart illustrating the steps of a device accessing a scheduling service instance in an embodiment of this disclosure is shown. The scheduling service instance can provide a blacklist service, an authentication service, and a scheduling algorithm service. The blacklist service is used to filter devices in the blacklist. The authentication service is used to authenticate the device's identity, such as verifying the validity of the device key. The scheduling algorithm service is used to select a target MQTT Broker instance based on a pre-configured load balancing strategy. As shown in Figure 3, the specific steps may include:

[0131] Step A1: Initiate a scheduling request: The device sends a first scheduling request to the scheduling service instance in the scheduling service cluster. The first scheduling request carries a device identifier, which includes a product identification code, device name, timestamp, and first authentication information.

[0132] Step A2, Device Blacklist Filtering: Check if the device name carried in the first scheduling request exists in the blacklist. If it exists, return a request failure message directly; if it does not exist, proceed to step A3.

[0133] Step A3, Device Authentication: Based on the device identifier carried in the first scheduling request, query the device key corresponding to the pre-stored device identifier. Based on the timestamp carried in the first scheduling request and the queried device key, calculate the second authentication information. If the first authentication information and the second authentication information match, the device authentication is successful, and the first scheduling request is responded to, and step A4 is executed. Otherwise, the device authentication fails, a request failure message is returned, and the response to the first scheduling request is refused.

[0134] Step A4: Access the cache; if a match is found, directly return the target: Based on the device identifier, query the Redis service cluster for bound clients that are bound to the device; and query the connection information stored in the Redis service cluster to see if there is any MQTT connection information established by the bound client; if there is any MQTT connection information established by the bound client, then determine the MQTT Broker instance that has established an MQTT connection with the bound client as the target MQTT Broker instance; if there is no bound client that is bound to the device, or if there is no MQTT connection information established by the bound client, then proceed to step A5.

[0135] Step A5: Request the scheduling algorithm service to obtain the target MQTT Broker information: In the connection information stored in the Redis service cluster, query all MQTT connection information established between each MQTT Broker instance and the device in the MQTT Broker cluster; Based on all MQTT connection information established between each MQTT Broker instance and the device, determine the MQTT Broker instance that meets the preset load balancing strategy (e.g., the minimum number of connections established with the device) as the target MQTT Broker instance.

[0136] Step A6: Generate token: After determining the target MQTT Broker instance, obtain the network connection information of the target MQTT Broker instance and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance.

[0137] Step A7: Store target information in cache: Save the correspondence between the device identifier and the access token to the Redis service cluster, and return the network connection information of the target MQTT Broker instance and the access token to the device.

[0138] After receiving the network connection information and access token of the target MQTT Broker instance returned by the scheduling service instance, the device can establish an MQTT connection with the target MQTT Broker instance based on the network connection information and access token.

[0139] Referring to Figure 4, the token authentication process when a device establishes a connection with a target MQTT Broker instance in this embodiment of the present disclosure is illustrated. As shown in Figure 4, the device can send an MQTT connection request to the target MQTT Broker instance using the network connection information of the target MQTT Broker instance. This request carries the device identifier and the access token returned by the scheduling service instance. The target MQTT Broker instance verifies the validity of the access token sent by the device based on the access token corresponding to the device identifier stored in a pre-configured database. If the two match, the connection is considered valid, and the MQTT connection is established; if they do not match, the connection is considered invalid, and the MQTT connection is refused.

[0140] Referring to Figure 5, a schematic diagram of the processing flow after the device establishes an MQTT connection with the target MQTT Broker instance is shown, which may include the following steps:

[0141] Step B1: The device establishes an MQTT connection with the target MQTT Broker instance.

[0142] Step B2: Store the MQTT connection information between the target MQTT Broker instance and the device in the Redis service cluster, and set the time to live (TTL) of the MQTT connection information. The MQTT connection information can be a key-value pair between the device identifier of the device and the device identifier of the target MQTT Broker instance, and the TTL can represent the remaining time before the MQTT connection expires.

[0143] Step B3: The device sends a heartbeat to the target MQTT Broker instance.

[0144] Step B4: The target MQTT Broker instance refreshes the MQTT connection information stored in the Redis service cluster to prevent the MQTT connection information from timeout and to maintain its validity.

[0145] Step B5: If the device is detected to be offline actively or abnormally, proceed to step B6.

[0146] Step B6: Delete the MQTT connection information between the target MQTT Broker instance and the device from the Redis service cluster.

[0147] Step B7: If the target MQTT Broker instance detects a device idle timeout, proceed to step B8.

[0148] After the device establishes an MQTT connection with the target MQTT Broker instance, the device will send a heartbeat to the target MQTT Broker instance at fixed intervals. Each time a heartbeat is reported to the target MQTT Broker instance, the target MQTT Broker instance can refresh the MQTT connection information between the device and the target MQTT Broker instance stored in the Redis service cluster to maintain the validity of the MQTT connection information. If the target MQTT Broker instance detects that the device has timed out (i.e., has not received a heartbeat from the target MQTT Broker instance for more than a fixed period), it will proceed to step B8.

[0149] Step B8: Delete the MQTT connection information between the target MQTT Broker instance and the device from the Redis service cluster.

[0150] Referring to Figure 6, a flowchart of another embodiment of the connection method of this disclosure is shown, applied to an MQTT Broker instance, wherein the MQTT Broker instance is deployed in an MQTT Broker cluster, and the MQTT Broker cluster includes at least two MQTT Broker instances. The method may include the following steps:

[0151] Step 601: Receive an MQTT connection request sent by the requesting end, wherein the MQTT connection request carries the requesting end identifier and access token; the requesting end may be a device or a client;

[0152] Step 602: Based on the access token corresponding to the pre-stored requester identifier, verify the access token carried in the MQTT connection request to determine whether to establish an MQTT connection with the requester.

[0153] Step 603: If it is determined that an MQTT connection has been established with the requesting end, after the MQTT connection is successfully established, save the MQTT connection information established with the requesting end in the stored connection information.

[0154] This disclosure implements MQTT Broker instance clustering based on a custom scheduling service instance. The scheduling service instance is deployed independently of the MQTT Broker cluster and is used to schedule the MQTT Broker instances within the cluster. When a device needs to establish an MQTT connection with a specific MQTT Broker instance, it first accesses the scheduling service instance. The scheduling service instance allocates a connectable target MQTT Broker instance to the device and returns the network connection information and corresponding access token of the target MQTT Broker instance to the device. The device uses the received network connection information and access token to request the establishment of an MQTT connection with the target MQTT Broker instance. Similarly, for a client, when it needs to establish an MQTT connection with an MQTT Broker instance, it first accesses the scheduling service instance. The scheduling service instance queries the MQTT Broker instances already connected to the device bound to the client and returns the network connection information and access token of that MQTT Broker instance to the client. The client uses the received network connection information and access token to request the establishment of an MQTT connection with that MQTT Broker instance, thereby connecting its bound device to the same MQTT Broker instance.

[0155] In practice, an MQTT Broker instance can receive MQTT connection requests sent by a requesting end. These requests carry a requesting end identifier and an access token. When the requesting end is a device, the requesting end identifier may include a product identifier code and a device name. When the requesting end is a client, the requesting end identifier may include a user identifier.

[0156] The MQTT Broker instance allows the establishment of an MQTT connection with the requesting party if the access token carried in the MQTT connection request is valid; if the verification is invalid, it returns a request failure message and refuses to establish an MQTT connection.

[0157] When the requesting end is a device, after the MQTT Broker instance establishes a connection with the device, it can save the MQTT connection information between the device and itself in a pre-configured database (such as a Redis service cluster). When the requesting end is a client, after the MQTT Broker instance establishes a connection with the client, it can save the MQTT connection information between the client and itself in a pre-configured database (such as a Redis service cluster).

[0158] Furthermore, each MQTT Broker instance can collect real-time statistics on its MQTT connection count and resource consumption, storing this information in the Redis service cluster. This allows the scheduling service instance to retrieve this information from the Redis cluster when using a pre-defined load balancing strategy, thus identifying the target MQTT Broker instance that matches the strategy. The MQTT connection count for each Broker instance can include only the number of MQTT connections established between the Broker instance and the device, or it can include the total number of MQTT connections established between the Broker instance and the device and clients.

[0159] In some embodiments of this disclosure, the method may further include:

[0160] After startup, the instance registers with the service discovery management cluster so that the service discovery management cluster sends a notification of the MQTT Broker instance registration to the scheduling service instance that has subscribed to the service, or, when the MQTT Broker instance goes offline, the service discovery management cluster sends a notification of the MQTT Broker instance going offline to the scheduling service instance that has subscribed to the service.

[0161] After startup, each MQTT Broker instance in the MQTT Broker cluster first registers with the service discovery management cluster (such as the Nacos service cluster) so that the scheduling service instance can dynamically detect the registration and shutdown of MQTT Broker instances.

[0162] The other execution steps of the MQTT Broker instance have been described in detail in the foregoing embodiments and will not be repeated here.

[0163] In summary, this embodiment of the disclosure schedules each MQTT Broker instance in the MQTT Broker cluster through a custom scheduling service instance, achieving clustering of MQTT Broker instances and load balancing among them. The scheduling service instance is deployed independently and connects only to devices, which in turn connect to a specific MQTT Broker instance. Which MQTT Broker instance a device connects to depends on the scheduling of the scheduling service instance. There are no connections between the MQTT Broker instances in the MQTT Broker cluster, eliminating the need to establish complex pairwise internal communication links, thus reducing link complexity and resource consumption. Furthermore, through this embodiment, each MQTT Broker instance in the MQTT Broker cluster can achieve high cohesion and low coupling, focusing solely on message routing and forwarding without concern for complex logic such as device authentication and scheduling services. This reduces the problem of frequent MQTT Broker instance restarts and the need for devices to frequently re-establish MQTT connections due to iterations of non-core functions, enabling the system to operate more stably over the long term. Furthermore, compared to the relatively simple DNS scheduling algorithm, the embodiments of this disclosure use a custom scheduling service instance to integrate custom scheduling strategies and business services, making it applicable to a wider range of scenarios.

[0164] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of this disclosure are not limited to the described order of actions, because according to the embodiments of this disclosure, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of this disclosure.

[0165] Referring to Figure 7, a structural block diagram of a connection device embodiment of the present disclosure is shown, applied to a scheduling service instance. The scheduling service instance is deployed independently of the MQTT Broker cluster. The scheduling service instance is used to schedule MQTT Broker instances in the MQTT Broker cluster. The MQTT Broker cluster includes at least two MQTT Broker instances. The device may include:

[0166] The first request receiving module 701 is used to receive a first scheduling request sent by the device, wherein the first scheduling request carries the device identifier of the device.

[0167] The target broker determination module 702 is used to determine the target MQTT Broker instance in the MQTT Broker cluster according to the preset scheduling strategy;

[0168] The target information acquisition module 703 is used to acquire the network connection information of the target MQTT Broker instance and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance;

[0169] The target information return module 704 is used to return the network connection information and access token of the target MQTT Broker instance to the device, so that the device can establish an MQTT connection with the target MQTT Broker instance based on the network connection information and access token.

[0170] This disclosure implements load balancing by scheduling MQTT Broker instances in an MQTT Broker cluster using a custom scheduling service instance. An MQTT Broker instance can be a process running in a specific environment (such as a server or container). This disclosure does not limit the deployment method of the MQTT Broker instance. For example, the MQTT Broker instance can be deployed on a physical server, virtual machine, cloud server, or containerized environment with Linux installed.

[0171] This disclosure does not limit the deployment method of the scheduling service instance. Further, the scheduling service instance can be any one of the scheduling service instances in a scheduling service cluster, which may include at least one scheduling service instance providing a unified scheduling service interface. For example, the scheduling service instance can be implemented based on a microservice architecture; this disclosure allows deploying a microservice architecture scheduling service instance in a Kubernetes container.

[0172] In some embodiments, the target agent determination module includes:

[0173] The binding determination submodule is used to query the binding clients that have a binding relationship with the device based on the device identifier;

[0174] The query submodule is used to query the stored connection information to see if there is any MQTT connection information established by the bound client; the stored connection information includes MQTT connection information established between each MQTT Broker instance and device or client in the MQTT Broker cluster;

[0175] The first determining submodule is used to determine the MQTT Broker instance that has established an MQTT connection with the bound client as the target MQTT Broker instance if there is MQTT connection information that has been established by the bound client.

[0176] The second determination submodule is used to determine the target MQTT Broker instance in the MQTT Broker cluster according to a preset scheduling strategy if there is no bound client that has a binding relationship with the device, or if there is no MQTT connection information established by the bound client.

[0177] In this embodiment of the disclosure, before using the preset scheduling strategy, it can be determined whether the bound client has established an MQTT connection. If the bound client has established an MQTT connection, the MQTT Broker instance connected to the bound client is determined as the target MQTT Broker instance, so as to connect the bound device and the client to the same MQTT Broker instance. If the bound client has not established an MQTT connection, the preset scheduling strategy is then used to determine the target MQTT Broker instance.

[0178] In some embodiments, the second determining submodule is specifically used for:

[0179] In an MQTT Broker cluster, the MQTT Broker instance with the fewest established MQTT connections is identified as the target MQTT Broker instance.

[0180] In some embodiments, the stored connection information is stored in a preset database by the MQTT Broker instance after establishing an MQTT connection with the device or client.

[0181] In some embodiments, the first scheduling request further carries a timestamp and first authentication information, wherein the first authentication information is calculated by the device based on the timestamp and the device key of the device; the apparatus further includes:

[0182] The key query module is used to query the device key corresponding to the device identifier in a pre-stored manner based on the device identifier;

[0183] The authentication calculation module is used to calculate the second authentication information based on the timestamp carried in the first scheduling request and the queried device key;

[0184] The authentication matching module is configured to, if the first authentication information and the second authentication information match, then the device authentication is successful and the device responds to the first scheduling request; otherwise, the device authentication fails and the device refuses to respond to the first scheduling request.

[0185] In some embodiments, the apparatus further includes:

[0186] The service subscription module is used to subscribe to services from the service discovery and management cluster so as to receive notifications sent by the service discovery and management cluster when an MQTT Broker instance registers or goes offline; each MQTT Broker instance in the MQTT Broker cluster registers with the service discovery and management cluster after startup.

[0187] In some embodiments, the apparatus further includes:

[0188] The token storage module is used to store the access token in a preset database so that when the device requests to establish an MQTT connection with the target MQTT Broker instance based on the network connection information and the access token, the target MQTT Broker instance verifies whether the access token sent by the device is valid according to the access token stored in the preset database.

[0189] The expiration setting module is used to set the validity period of the access token, and delete the access token from the preset database when the validity period expires.

[0190] In some embodiments, the scheduling service instance is deployed in a scheduling service cluster, the scheduling service cluster including at least one scheduling service instance, providing a unified scheduling service interface to the outside world, and the apparatus further includes:

[0191] The service selection module is used to receive the first scheduling request sent by the device through the scheduling service interface, and then send the first scheduling request to a certain scheduling service instance in the scheduling service cluster through a round-robin method.

[0192] In some embodiments, the apparatus further includes:

[0193] The second receiving module is used to receive a second scheduling request sent by the client, the second scheduling request including the user identifier of the client and the device identifier of the specified device;

[0194] The binding query module is used to query whether the client and the specified device have a binding relationship based on the user identifier and the device identifier of the specified device;

[0195] The result return module is used to, if the client and the specified device have a binding relationship, query the stored connection information to see if there is an established MQTT connection information for the specified device; if there is an established MQTT connection information for the specified device, return the network connection information and access token of the MQTT Broker instance that established the MQTT connection with the specified device to the client; if there is no established MQTT connection information for the specified device, return a request failure message to the client.

[0196] Referring to Figure 8, a structural block diagram of another embodiment of the connection device of this disclosure is shown, applied to an MQTT Broker instance, the MQTT Broker instance being deployed in an MQTT Broker cluster, the MQTT Broker cluster including at least two MQTT Broker instances, the device may include:

[0197] The request receiving module 801 is used to receive an MQTT connection request sent by a requesting end, wherein the MQTT connection request carries a requesting end identifier and an access token; the requesting end may be a device or a client.

[0198] The token verification module 802 is used to verify the access token carried in the MQTT connection request based on the access token corresponding to the pre-stored requester identifier, and to determine whether to establish an MQTT connection with the requester.

[0199] The connection information storage module 803 is used to store the MQTT connection information established with the requesting end in the stored connection information after the MQTT connection is successfully established, when it is determined that an MQTT connection has been established with the requesting end.

[0200] In some embodiments, the apparatus further includes:

[0201] The registration module is used to register with the service discovery management cluster after startup, so that the service discovery management cluster sends a notification of the MQTT Broker instance registration to the scheduling service instance that has subscribed to the service, or, when the MQTT Broker instance goes offline, the service discovery management cluster sends a notification of the MQTT Broker instance going offline to the scheduling service instance that has subscribed to the service.

[0202] This disclosure also provides an Internet of Things (IoT) system. Referring to FIG2, a structural block diagram of an embodiment of an IoT system according to this disclosure is shown. The IoT system includes a device group 201, including at least one device 2011; a scheduling service cluster 202, including at least one scheduling service instance 2021; and an MQTT Broker cluster 203, including at least two MQTT Broker instances 2031. The scheduling service instance is deployed independently of the MQTT Broker cluster, and the scheduling service instance is used to schedule the MQTT Broker instances in the MQTT Broker cluster, wherein:

[0203] The device 2011 is used to send a first scheduling request to the scheduling service instance, wherein the first scheduling request carries the device identifier of the device.

[0204] The scheduling service instance 2021 is used to receive a first scheduling request sent by the device, determine a target MQTT Broker instance in the MQTT Broker cluster according to a preset scheduling policy, obtain the network connection information of the target MQTT Broker instance, and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance; and return the network connection information and access token of the target MQTT Broker instance to the device.

[0205] The device 2011 is also used to establish an MQTT connection with the target MQTT Broker instance 2031 based on the network connection information and access token.

[0206] Furthermore, the IoT system may also include a public service cluster, which may include a service discovery and management cluster (such as a Nacos service cluster) and a database service cluster (such as a Redis service cluster), etc.

[0207] This embodiment of the disclosure uses a custom scheduling service instance to schedule each MQTT Broker instance in an MQTT Broker cluster, achieving clustering of MQTT Broker instances and load balancing among them. The scheduling service instance is deployed independently and connects only to devices, with each device connecting to a specific MQTT Broker instance. Which MQTT Broker instance a device connects to depends on the scheduling service instance's scheduling. There are no connections between the MQTT Broker instances in the cluster, eliminating the need for complex pairwise internal communication links, reducing link complexity and resource consumption. Furthermore, through this embodiment, each MQTT Broker instance in the cluster can achieve high cohesion and low coupling, focusing solely on message routing and forwarding without concern for complex logic such as device authentication and scheduling services. This reduces the problem of frequent MQTT Broker instance restarts and device re-establishment of MQTT connections due to iterations of non-core functions, allowing for more stable long-term system operation. Moreover, compared to the relatively simple DNS scheduling algorithm, this embodiment uses a custom scheduling service instance that can integrate custom scheduling strategies and business services, making it applicable to a wider range of scenarios.

[0208] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0209] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0210] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0211] Referring to FIG9, which is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. As shown in FIG9, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform the steps of the connection method of the aforementioned embodiment.

[0212] This disclosure provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a program or processor of a terminal, enables the terminal to perform the steps of the connection method described in the foregoing embodiments.

[0213] This disclosure provides a connection method, apparatus, IoT system, and electronic device that can cluster MQTT Broker instances to meet the access needs of massive numbers of devices, and can reduce link complexity and resource consumption.

[0214] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0215] Furthermore, the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0216] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0217] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

[0218] The above description is only a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.

[0219] The foregoing has provided a detailed description of a connection method, apparatus, Internet of Things system, and electronic device provided by this disclosure. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this disclosure. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this disclosure. Therefore, the content of this specification should not be construed as a limitation of this disclosure.

Claims

1. A connection method applied to a scheduling service instance, wherein the scheduling service instance is deployed independently of an MQTT Broker cluster, the scheduling service instance is used to schedule MQTT Broker instances in the MQTT Broker cluster, the MQTT Broker cluster including at least two MQTT Broker instances, the method comprising: The receiving device sends a first scheduling request, the first scheduling request carrying the device identifier of the device; Based on the pre-defined scheduling strategy, determine the target MQTT Broker instance in the MQTT Broker cluster; Obtain the network connection information of the target MQTT Broker instance, and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance; The network connection information and access token of the target MQTT Broker instance are returned to the device so that the device can establish an MQTT connection with the target MQTT Broker instance based on the network connection information and access token.

2. The method according to claim 1, wherein, Before determining the target MQTT Broker instance in the MQTT Broker cluster according to the preset scheduling policy, the method further includes: Based on the device identifier, query the bound clients that have a binding relationship with the device; In the stored connection information, check if there is any MQTT connection information established by the bound client; the stored connection information includes MQTT connection information established between each MQTT Broker instance and device or client in the MQTT Broker cluster; If an MQTT connection has been established with the bound client, then the MQTT Broker instance that has established an MQTT connection with the bound client is identified as the target MQTT Broker instance.

3. The method according to claim 1, wherein, The step of determining the target MQTT Broker instance in the MQTT Broker cluster according to the preset scheduling strategy includes: If there is no bound client that has a binding relationship with the device, or if there is no MQTT connection information established by the bound client, then the target MQTT Broker instance is determined in the MQTT Broker cluster according to the preset scheduling policy.

4. The method according to any one of claims 1 to 3, wherein, The step of determining the target MQTT Broker instance in the MQTT Broker cluster according to the preset scheduling strategy includes: In an MQTT Broker cluster, the MQTT Broker instance with the fewest established MQTT connections is identified as the target MQTT Broker instance.

5. The method according to claim 2, wherein, The stored connection information is stored in a pre-configured database by the MQTT Broker instance after establishing an MQTT connection with the device or client.

6. The method according to claim 1, wherein, The first scheduling request also carries a timestamp and first authentication information, which is calculated by the device based on the timestamp and the device key of the device. After the receiving device sends the first scheduling request, the method further includes: Based on the device identifier, query the device key corresponding to the pre-stored device identifier; Calculate the second authentication information based on the timestamp carried in the first scheduling request and the queried device key; If the first authentication information and the second authentication information match, the device authentication is successful and it responds to the first scheduling request; otherwise, the device authentication fails and it refuses to respond to the first scheduling request.

7. The method according to claim 1, further comprising: Subscribe to the service discovery management cluster to receive notifications from the service discovery management cluster when an MQTT Broker instance registers or goes offline; each MQTT Broker instance in the MQTT Broker cluster registers with the service discovery management cluster after startup.

8. The method according to claim 1, wherein, After generating the access token corresponding to the device identifier for connecting to the target MQTT Broker instance, the method further includes: The access token is stored in a preset database so that when the device requests to establish an MQTT connection with the target MQTT Broker instance based on the network connection information and the access token, the target MQTT Broker instance verifies whether the access token sent by the device is valid according to the access token stored in the preset database. Set the validity period of the access token, and delete the access token from the preset database when the validity period expires.

9. The method according to claim 1, wherein, The scheduling service instance is deployed in a scheduling service cluster, which includes at least one scheduling service instance and provides a unified scheduling service interface to the outside world. The method further includes: After receiving the first scheduling request sent by the device through the scheduling service interface, the first scheduling request is sent to a scheduling service instance in the scheduling service cluster through a polling method.

10. The method according to claim 1, further comprising: Receive a second scheduling request sent by the client, the second scheduling request including the user identifier of the client and the device identifier of the specified device; Based on the user identifier and the device identifier of the specified device, query whether the client and the specified device have a binding relationship; If the client and the specified device have a binding relationship, then query the stored connection information to see if there is any MQTT connection information that the specified device has established; If an MQTT connection has been established with the specified device, the network connection information and access token of the MQTT Broker instance that has established an MQTT connection with the specified device are returned to the client. If no MQTT connection information has been established for the specified device, a request failure message is returned to the client.

11. A connection method applied to an MQTT Broker instance, the MQTT Broker instance being deployed in an MQTT Broker cluster, the MQTT Broker cluster comprising at least two MQTT Broker instances, the method comprising: Receive an MQTT connection request sent by the requesting end, the MQTT connection request carrying the requesting end identifier and access token; The requesting end includes a device or a client; Based on the access token corresponding to the pre-stored requester identifier, the access token carried in the MQTT connection request is verified to determine whether to establish an MQTT connection with the requester. If it is determined that an MQTT connection has been established with the requesting end, after the MQTT connection is successfully established, the MQTT connection information established with the requesting end is saved in the stored connection information.

12. The method of claim 11, further comprising: After startup, the instance registers with the service discovery management cluster so that the service discovery management cluster sends a notification of the MQTT Broker instance registration to the scheduling service instance that has subscribed to the service, or, when the MQTT Broker instance goes offline, the service discovery management cluster sends a notification of the MQTT Broker instance going offline to the scheduling service instance that has subscribed to the service.

13. A connection device applied to a scheduling service instance, the scheduling service instance being deployed independently of an MQTT Broker cluster, the scheduling service instance being used to schedule MQTT Broker instances in the MQTT Broker cluster, the MQTT Broker cluster including at least two MQTT Broker instances, the device comprising: The first request receiving module is used to receive a first scheduling request sent by the device, wherein the first scheduling request carries the device identifier of the device. The target broker determination module is used to determine the target MQTT Broker instance in the MQTT Broker cluster according to the preset scheduling strategy; The target information acquisition module is used to acquire the network connection information of the target MQTT Broker instance and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance; The target information return module is used to return the network connection information and access token of the target MQTT Broker instance to the device, so that the device can establish an MQTT connection with the target MQTT Broker instance based on the network connection information and access token.

14. A connection device applied to an MQTT Broker instance, the MQTT Broker instance being deployed in an MQTT Broker cluster, the MQTT Broker cluster comprising at least two MQTT Broker instances, the device comprising: The request receiving module is used to receive MQTT connection requests sent by the requesting end, wherein the MQTT connection request carries the requesting end identifier and access token; The requesting end includes a device or a client; The token verification module is used to verify the access token carried in the MQTT connection request based on the access token corresponding to the pre-stored requester identifier, and to determine whether to establish an MQTT connection with the requester. The connection information storage module is used to store the MQTT connection information established with the requesting end in the stored connection information after the MQTT connection is successfully established, when it is determined that an MQTT connection has been established with the requesting end.

15. An Internet of Things (IoT) system, comprising devices, a scheduling service instance, and an MQTT Broker cluster, wherein the scheduling service instance is deployed independently of the MQTT Broker cluster, the scheduling service instance is used to schedule MQTT Broker instances in the MQTT Broker cluster, and the MQTT Broker cluster includes at least two MQTT Broker instances, wherein: The device is configured to send a first scheduling request to the scheduling service instance, wherein the first scheduling request carries the device identifier of the device; The scheduling service instance is used to receive a first scheduling request sent by the device, determine a target MQTT Broker instance in the MQTT Broker cluster according to a preset scheduling policy, obtain the network connection information of the target MQTT Broker instance, and generate an access token corresponding to the device identifier for connecting to the target MQTT Broker instance; and return the network connection information and access token of the target MQTT Broker instance to the device. The device is also used to establish an MQTT connection with the target MQTT Broker instance based on the network connection information and the access token.

16. An electronic device comprising: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the steps of the linking method as described in any one of claims 1 to 12.

Images