This article was edited by the founder of drawon.cn (desk case) .
What are the difficulties and fatal points in the development of IoT products?
Now is the era of the Internet of Everything, and the difficulty of IoT products varies from industry to industry. However, cloud communication interaction on IoT devices has become a problem that various industries need to solve first. IoT communication problems start from product design. If they cannot be solved well or there are problems in the design scheme, even if the products in this industry are successful in the market, with the increase of business, the number of devices connected to the network will increase. Doomed to be unable to get rid of the fate of being dragged to death or being strangled to death by entangled problems .
communication model
To understand the difficulties and fatal points of IoT products, we must first understand the essential difference between the model of IoT products and the model of traditional stateless Internet products.
Traditional Stateless Internet Interaction Model
As we all know, traditional web applications use HTTP for communication. HTTP is stateless, the client sends a request to the backend, and the backend returns the result to the frontend according to the meaning of the request. The backend does not save the state of the frontend. The backend cannot actively send messages to the frontend. The backend processes messages passively.
The stateless back-end communication model, using k8s for load balancing is non-invasive to the development code, and can complete elastic expansion and load balancing without code modification .
The so-called elastic expansion capability: It is the ability of the system to automatically start or stop running instances according to the business concurrency, so as to meet the increasing or decreasing concurrency of customers.
The so-called load balancing capability: when there are multiple instances processing the same business concurrently, the system dynamically maintains the processing balance between multiple instances according to the preset rule algorithm. Instead of squeezing all requests to a certain node, the ability to cause the node to crash.
The HTTP-based request-responsemodel is easy to achieve elastic expansion and dynamic expansion. In other words, when the back-end nodes cannot satisfy the existing concurrent requests, dynamic expansion can be completed with a little modification. Technically there is no difficulty.
The following figure is a model based on http communication
Communication Models for the Internet of Things
The communication model of the Internet of Things is much more complex than the traditional Web communication model. The IoT communication model is a stateful model. Device and user, device and backend, backend and user are full-duplex communication . In other words, any party can actively send data to the other party.
In addition, IoT products are often in a one-to-many relationship, and a user must manage multiple devices of the same type or different types at the same time. And communicate with them, or post a message.
Based on the above, the communication design of IoT systems is much more difficult than that of traditional Web products. This is the fundamental reason why many teams working on Internet products, even with a lot of successful experience, are still unable to develop IoT products.
The following figure shows the ideal IoT communication system model:
As shown in the figure above, we have drawn the ideal model of the Internet of Things system. If all users can make the system model as above, basically the communication of the system and the unlimited expansion of future equipment will not be a problem. System communication is rock solid. But such a structure belongs to infrastructure. For a company of Xiaomi's size, there is no doubt that the system is also designed in this way. Because they have a strong team and financial support. For small and micro enterprises, or general enterprises, they seldom consider investing in infrastructure. From the very beginning, it was for business. Not any team has the ability to make the system into such a model. Most start-up companies have business support from the beginning, financial indicators and market customers force them to deliver in a short time. And no time to take into account the stability of the system. The problems with the products that ended up being sold abounded. With the increase of new businesses, the system is not competent, which leads to the death of start-up companies.
The above model focuses on solving three problems.
- The cluster of MQTT-Broker proxy forwarders is basically impossible for small companies to develop a cluster of MQTT-Broker. High-tech talents are needed, and there are some companies at home and abroad that specialize in this field. It can still be solved by spending money on purchases and secondary development.
- The security of the device networking mainly depends on the design of the MQTT-broker and the design of the protocol model. Yunjing IoT Communication puts the security of the device on the cloud in the first place and also considers the problem to be solved
- Business cluster (backend), business cluster is also a difficult point. There are at least four communication models here , and the business cluster service itself is stateful. When a node hangs up, the customer must not perceive it. It is still a test of the architect's skills. The previous version of the MQTT3.1-based protocol could not complete the design of load balancing at all, resulting in the inability to design a business cluster model, so it was impossible to design a system that satisfied elastic expansion and load balancing . **If a system that meets the requirements of these two conditions cannot be designed, the development of the enterprise will not go very far.
The above question 3 is not without a breakthrough, that is the birth of the MQTT5.0 protocol. MQTT5.0 added a feature "shared subscription" which is the back-end load balancing problem. It only provides the customer's business system with the ability to support load balancing. As for how to design the client system, dynamic expansion and load balancing can be achieved. This requires the architects of each company to use their talents to design the system. For this reason, Yunjing has designed a communication protocol that meets the above requirements based on its many years of experience, that is, the jiot-mqtts protocol.
Among the above three difficulties, difficulty 1 is not the primary problem to be solved in the process of enterprise development. For mqtt-broker, it is only a forwarder, forwarding data, and not undertaking heavyweight business processing. Single node, master-slave backup, it is no problem to carry the connection of less than 100,000 devices, (or purchase mqtt-broker from cloud service vendors) can be satisfied. And if the business cluster of the system (as shown in the yellow part in the figure above) is not designed as a cluster mode. Then the processing power of the monolithic architecture quickly reaches the bottleneck. It will cause the system to hang up frequently, business data to be lost, or the processing delay to be large and slow.