1、前情概要

看这篇文章之前，强烈建议先阅读《物联网设备网关系统架构设计》，该篇文章从四个层次详细介绍了我司设备网关的系统架构。

其实做架构设计离不开三个方面：业务架构，系统架构，以及技术架构。它们彼此之间不需要遵循一定的顺序，但必须以实际业务作为出发点，这样做出来的架构才有落脚点，否则就沦为了一个纸上谈兵的花架子了。从这个角度考虑，对于以盈利为目的的组织来说，还是以业务驱动为导向会比较靠谱，技术驱动也未尝不可，在B2B的领域也可以大展拳脚。

在设备网关的架构设计中，对于业务架构的设计，我没有单独写一篇文章阐述之，而是融合在系统架构设计中，对其做了一定的介绍。

为了方便阐述，我将系统架构设计图先贴出来。

图1 设备网关系统架构

接下来的技术架构设计无非就是将系统架构的四个部分在技术层面进行剖析。

个人以为，Device Group，Center Controller，以及Biz Processor，这三个部分的技术含量较高，由于单片机设备并非我司开发和生产的，将这部分工作委托给了第三方公司，故对此不做介绍，重点剖析Center Controller和Biz Processor。

2、从Netty说起

这部分内容属于知识科普篇，因为Netty在整个技术架构中有着举足轻重的作用，如果读者对此比较熟悉，可以选择性跳过。

下面先看一段来自Netty官网的介绍：

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.

说得直接一点就是：Netty是一套基于NIO而封装的易用性较高的API，使用它可以简单快速地开发网络应用程序。

Netty拥有诸多特性，比如设计良好，支持多种协议的非阻塞式API，高吞吐量，低延迟，资源占用率低等。此外，Netty的社区较为活跃，文档资料较多也成为了我选择它的关键原因之一。以下是Netty组件图，大家可以感受一下：

图2 Netty组件图

可能大家比较关心Netty究竟能干些啥。限于篇幅，我不能慢条斯理地给大家解释，只能从感性上对Netty的应用领域进行认知。

• 高性能RPC框架。这是Netty的一个典型应用场景，著名的分布式服务框架 Dubbo 远程调用使用的底层通信框架就是Netty，Dubbo是久经考验的出色的开发框架，其默认使用的通信框架Netty自然是非常靠谱的。除了 Dubbo 之外，淘宝的消息中间件 RocketMQ 的消息生产者和消息消费者之间，也采用 Netty 进行高性能、异步通信。

• 大数据处理。分布式大数据处理框架 Hadoop 的高性能通信和序列化组件 Avro 的 RPC 框架，默认采用 Netty 进行跨节点通信，它的 Netty Service 基于 Netty 框架二次封装实现。

• Web容器定制和开发，这个算是比较高阶的应用。像Tomcat，JBoss这类Web容器是基于HTTP协议的，而Netty比这些运行容器还要更底层，毕竟HTTP协议是基于TCP/IP的，对于HTTP请求，还是需要像Netty这样的通信框架处理底层协议。因此，如果愿意的话，你也可以基于Netty开发一款Web运行容器。

综上所述，看过我的设备网关系统架构后，也不难想到我为什么会选择Netty了。

下面正式开始介绍设备网关的技术架构设计。

3、中控平台技术架构

这部分的技术架构与前面介绍的Netty是紧密相关的，中控平台的底层通信框架便是Netty。

如下这张图基本上可以表达我对中控平台技术架构的设计思想：

图3 中控平台技术架构

不难看出，整个架构风格采用的是以Spring Cloud构造的微服务。因为中控服务实例可以有多个，用以应对设备数据增加所带来的横向扩展。

系统架构中提到了中控平台的REST API组件，可以对应到中控服务器的REST Service。这部分功能用Feign进行实现，Feign可以认为是一个带有负载均衡特性的简单易用的HTTP请求中间件，其中集成了请求组件RestTemplate，以及负载均衡器Ribbon。REST Service组件可以提供诸如设备信息，连接通道状态，设备连接数，指令集维护之类的API，用于与业务相关的系统层进行调用。

MQ Service是系统架构中消息队列服务组件的实现。理论上来讲，物联网行业的消息服务协议首选MQTT，它是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议。但是也不阻止你选择其他协议，比如AMQP，STOMP等。当然，各大厂商都有对消息队列服务协议的实现，支持的协议最全面的就是Apache ActiveMQ，STOMP是基于纯文本的消息传输协议，不用考虑，MQTT协议实现的代表是出自国人之手的EMQ，AMQP协议实现的代表则是RabbitMQ。

接下来的Logger Service没什么好解释的了，因为只负责记录日志，使用logback，或者log4j之类的日志框架即可。

最后的Netty Service涵盖了很多组件的实现，其内核都是基于Netty的服务，很多设计和实现也就显而易见了。整个中控平台与设备组的数据传输载体就靠连接通道(Connect Tunnel)，这里借助一个通讯行业专业术语「全双工」，它表示命令的收发可以同时在通道里发生，所以基于连接通道这个载体，我们可以进一步实现协议解析引擎，命令执行引擎，数据收集器等组件。

4、业务处理器技术架构

因为我采用了微服务的架构风格，所以业务处理器的技术架构和Spring Cloud脱不了干系。先看一张技术架构图：

图4 业务处理器技术架构

上面一部分是各式各样的客户端，也包括了系统架构中提到的管理系统（Management System），这一部分不再展开叙述了。

下面一部分就是业务处理器的核心技术架构了，鉴于Spring Cloud在国内普及程度不是很高，我先对架构图周边的5个Spring Cloud组件进行简单介绍。

① Zuul Gateway，就是一个API网关的角色，根据事先配置好的路由规则，将客户端请求转发到相应的微服务中进行处理；

② Config Server，这里指代的是Spring Cloud Config，用于充当统一配置中心的角色，里面存放了几乎全部的微服务相关的配置信息；

③ Eureka Server，服务的注册与发现中心，管理着众多微服务的元数据信息；

④ Ribbon，是一个基于软件层面的负载均衡器，当一个微服务部署了多个实例的时候，可以通过Ribbon进行负载均衡；

⑤ Hystrix，即微服务熔断器，为了避免分布式系统产生“雪崩效应”。当一个微服务长时间无法到达时，就会触发该链路上的熔断器，防止大量的无效请求拖垮整个系统。

对于新手来说，上述的Spring Cloud组件介绍可能过于简单了，如果感兴趣，可以搜索相关学习资料，或者关注我的专栏，我会不定期的进行微服务领域的相关分享。

接下来介绍5个核心的业务模块。

① Log Analysis，日志分析。主要是收集来自中控平台的日志，以及业务层自身的相关日志，可以用来分析，排查和追踪问题，进而起到一定的监控作用。这部分使用的ELK技术栈，也算是日志分析功能的一个最佳实践，因为日志分析业务没有其他特殊的业务需求，所以其他的技术我也没有再去考虑了；

② Data Analysis，数据分析。这个话题太大了，我只能结合业务来谈。这部分功能主要体现在了数据可视化，以及结合监控服务对设备进行预警，所以，就目前而言，数据分析的功能就是对一些业务规则的识别和整合，让无形的数据变成有形的资产。目前只考虑数据的离线分析，至于实时分析的功能，现在还不是这么迫切，所以只用到了Hadoop生态里的相关技术；

③ Data Persistence，数据持久化。 这部分功能就是为数据分析，以及客户端提供相关数据。数据持久化有两个地方：MongoDB，MySQL。MySQL存储的是一些结构化的业务数据，因为这些数据比较重要，所以MySQL会使用主-从结构进行部署，遵循“主写，从读”的原则。MongoDB存储的是除业务数据的其他数据，暂不考虑集群部署；

④ Monitor Dashboard，监控平台。这个部分是设备运维的核心功能，而这个监控功能要分两个层面理解：第一个是业务层面，目的是监控设备，中控以及业务的健康状况，通过一定的指标展示出来；第二个是技术层面，也就是技术架构图中提到的Turbine，其实结合了上面提到的Hystrix，对各个微服务的状态进行监控；

⑤ Notification Service，通知服务。管理整个设备网关的通知业务，手机推送使用的是个推平台，此外还结合了邮件通知，我们可以直接使用Spring Boot自带的一个mail组件。

5、总结

承接上一篇的系统架构设计文章，这篇文章详细介绍了物联网设备网关的技术架构设计及其所用到的核心通信框架Netty。然而，对于各个技术的实现，本文没有做太具体的介绍，因为涉及到了代码层面的详细设计环节了，后续会出具体实现的文章。

-END-