Source | elephant article | knife

1. Previously

Before reading this article, it is strongly recommended to read “Internet of Things Device Gateway System Architecture Design”, which introduces the system architecture of our company’s device gateway in detail from four levels.

In fact, architectural design is inseparable from three aspects: business architecture, system architecture, and technical architecture. They don’t have to follow one another in any particular order, but they have to start with the actual business so that the architecture has a foothold, otherwise it becomes a mere figment of paper. From this point of view, for profit-oriented organizations, it is more reliable to be business-driven and technology-driven, which can also play a big role in the B2B field.

In the architecture design of the device gateway, I did not write a separate article about the business architecture design, but integrated it into the system architecture design and made a certain introduction to it.

For the convenience of elaboration, I will post the system architecture design drawing first.

Figure 1 Device gateway system architecture

The following technical architecture design is nothing more than to analyze the four parts of the system architecture at the technical level.

In my opinion, the technical content of Device Group, Center Controller and Biz Processor is relatively high. Since the SCM equipment is not developed and produced by our company, we entrust this part of work to a third party company, so WE will not introduce it. Focus on Center Controller and Biz Processor.

2. Start with Netty

This section is part of a popular science section, because Netty plays an important role in the overall technical architecture. If you are familiar with it, you can skip it.

Here’s a look at the introduction from Netty’s official website:

Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server.

To put it bluntly: Netty is a set of easy-to-use APIS encapsulated in NIO that make it easy and fast to develop web applications.

Netty has many features, such as well-designed, non-blocking apis that support multiple protocols, high throughput, low latency, and low resource usage. In addition, Netty has an active community and a lot of documentation, which is one of the key reasons I chose Netty. Here is the Netty component diagram, you can feel:

Figure 2 Netty component diagram

Maybe people are concerned about what Netty can do. I don’t have the space to explain it in a slow way. I can only get a sense of Netty’s application domain.

  • High-performance RPC framework. This is a typical application scenario of Netty, the famous distributed service framework Dubbo remote call using the underlying communication framework is Netty, Dubbo is a time-tested excellent development framework, its default use of communication framework Netty is naturally very reliable. In addition to Dubbo, Taobao’s messaging middleware RocketMQ also uses Netty for high-performance, asynchronous communication between message producers and message consumers.

  • Big data processing. The RPC framework of Avro, a high-performance communication and serialization component of Hadoop, uses Netty for cross-node communication by default, and its Netty Service is implemented based on the secondary encapsulation of Netty framework.

  • Web container customization and development, this is a relatively advanced application. Web containers such as Tomcat and JBoss are based on THE HTTP protocol, while Netty is even more low-level than these running containers. After all, HTTP protocol is based on TCP/IP, and for HTTP requests, it still needs a communication framework such as Netty to handle the underlying protocol. Therefore, you can also develop a Web running container based on Netty if you wish.

In summary, after looking at my device gateway system architecture, it’s not hard to see why I chose Netty.

The following describes the technical architecture design of the device gateway.

3. Technical architecture of central control platform

The technical architecture of this part is closely related to Netty, which is the underlying communication framework of the central control platform.

The following figure can basically express my design ideas for the technical architecture of the central control platform:

Figure 3. Technical architecture of central control platform

As you can see, the entire architectural style is based on microservices constructed by Spring Cloud. Because the central control service instances can have multiple, to cope with the increase of equipment data brought about by the horizontal expansion.

The REST API component of the central control platform is mentioned in the system architecture, which can be corresponding to the REST Service of the central control server. This functionality is implemented using Feign, an easy-to-use HTTP request middleware with load balancing features that integrates the request component RestTemplate with the load balancer Ribbon. REST Service components can provide apis such as device information, connection channel status, device connection count, and instruction set maintenance for invocation at the business-relevant system layer.

MQ Service is an implementation of the message queue Service component in the system architecture. Theoretically, MQTT is the preferred messaging service protocol for the Internet of Things industry, which is designed for the communication of a large number of remote sensors and control devices with limited computing power and working on low-bandwidth, unreliable networks. However, it does not prevent you from choosing other protocols such as AMQP, STOMP, etc. Of course, each major manufacturer has the implementation of message queue service protocol, the most comprehensive protocol supported is Apache ActiveMQ, STOMP is a text-based message transfer protocol, forget about it, MQTT protocol is implemented by EMQ, AMQP protocol is implemented by RabbitMQ.

The rest of the Logger Service is nothing to explain, as it only logs, using a logging framework like LogBack or log4J.

The final Netty Service covers the implementation of many components, and its kernel is based on Netty services, so much of the design and implementation becomes obvious. Data transmission carrier of the whole control platform and equipment group depends on connection channel Tunnel (Connect), here with the help of a communications industry professional term “full-duplex”, it indicates that the command of the transceiver can occur in the Tunnel at the same time, so based on the connection channel this carrier, we can further realize the protocol parsing engine, command execution engine, Data collector and other components.

4. Technical architecture of business processor

Because I have adopted a microservices architectural style, the technical architecture of the business processor is tied to Spring Cloud. Let’s start with a technical architecture diagram:

Figure 4. Business processor technical architecture

The above section covers the various clients, including the Management System mentioned in the System architecture, which is not covered in this section.

The following part is the core technology architecture of the business processor. Considering the popularity of Spring Cloud is not very high in China, I will give a brief introduction to the five Spring Cloud components around the architecture diagram.

(1) Zuul Gateway, an API Gateway, forwards client requests to corresponding microservices for processing according to pre-configured routing rules;

② Config Server, which refers to Spring Cloud Config, is used to act as a unified configuration center, which stores almost all microservice-related configuration information;

③ Eureka Server, the service registration and discovery center, manages the metadata information of many micro-services;

(4) The Ribbon is a software-based load balancer. When multiple instances of a microservice are deployed, the Ribbon can be used for load balancing.

⑤ Hystrix, or microservice fuse, is designed to avoid the “avalanche effect” of distributed systems. When a microservice is unavailable for an extended period of time, fuses on that link are triggered, preventing a flood of invalid requests from dragging down the entire system.

The above introduction to Spring Cloud components may be too simple for beginners, but if you are interested, you can search for learning materials or follow my column, which I will share with you on microservices from time to time.

The next five core business modules are introduced.

① Log Analysis Mainly collect logs from the central control platform, as well as the relevant logs of the business layer itself, which can be used to analyze, troubleshoot and track problems, and then play a certain monitoring role. The ELK stack used in this section is a best practice for the log analysis function. Since the log analysis business has no other special business requirements, I did not consider other technologies.

② Data Analysis This topic is too big. I can only talk about it in the context of business. This part of the function is mainly reflected in data visualization, and monitoring services for early warning of equipment. Therefore, at present, the function of data analysis is to identify and integrate some business rules, so as to turn intangible data into tangible assets. At present, only offline analysis of data is considered. As for real-time analysis, it is not so urgent, so we only use related technologies in the Hadoop ecosystem.

③ Data Persistence This part of the function is to provide data for data analysis, as well as the client. There are two places for data persistence: MongoDB and MySQL. MySQL stores structured service data. Because such data is important, MySQL uses a master-slave structure to deploy the data, following the principle of primary write and secondary read. MongoDB stores other data except service data. Cluster deployment is not considered.

④ Monitor Dashboard is a monitoring platform. This part is the core function of equipment operation and maintenance, and this monitoring function should be understood in two aspects: the first is the business level, which aims to monitor the health status of equipment, central control and business, and display it through certain indicators; The second is the technical aspect, namely Turbine mentioned in the technical architecture diagram. In fact, Turbine combines Hystrix mentioned above to monitor the status of each micro-service.

⑤ Notification Service Manage the notification service of the whole device gateway. Mobile phone push uses a push platform. In addition, we can directly use a mail component of Spring Boot.

5, summary

Following on from the last system architecture design article, this article introduces the technical architecture design of the Internet of Things device gateway and the core communication framework Netty used in detail. However, for the implementation of each technology, this paper did not do too specific introduction, because it involves the detailed design of the code level, the subsequent implementation of the specific article.

-END-