物联网燃气表云服务架构设计

物联网燃气表云服务架构设计浅析

1  业务特点分析

    1-1 基于TCP、UDP协议通讯

          目前物理网燃气表有以下几种类型：GPRS物联网表（2G/4G）、集中器物联网表、NB-IoT物联网表

          GPRS物联网表-2G，目前只有少量的工业表是该类型的表，基于三大运营商提供的2G制式的手机卡与云服务端进行通讯，通讯协议：TCP

          GPRS物联网表-4G，主要是工业表较多，基于三大运营商提供的4G制式的手机卡与云服务端进行通讯，通讯协议：TCP

          集中器物理网表，通过集中器接入运营商基站再与云服务端进行通讯，通讯协议：TCP/UDP

         NB-IoT物联网表，目前最火的一种类型，基于NB模组与云服务端通讯，支持的通讯协议：TCP/UDP

    1-2 终端消息协议版本多样、升级频繁

          由于燃气表的行业特性，各燃气表厂商制定的消息协议版本各不相同，国内暂时还没有一个统一的标准，各个燃气公司采购的燃气表往往

          来自于不同的燃气表厂商，这就导致了云服务平台所接入的燃气表类型、消息协议的版本多样化。另外，因为物联网燃气表是一个新兴的

          产物，一开始指定的协议都有很多问题，这就导致了后期对协议的升级相对比较频繁，云服务平台必须能够满足这种多协议版本燃气表的

          接入，能够准确的解析各种协议版本的消息，并且还能实现协议版本的在线升级。

    1-3 云服务消息接入层（数据网关）特定时间段高并发、大流量

          物联网燃气表一般每天都会同服务端通讯一次，完成抄表数据上报，业务指令下发。一般燃气表跟服务端的通讯都会被设置在0点以后，

          燃气使用较少的时间段，在这段时间内，所有的燃气表都会跟服务端进行通讯，这就导致了在这段时间内，服务端会承受较高的并发及

          较大的流量。

         燃气表每次通讯的数据大小一般不会超过1k，按照最大1k的流量计算，如果并发数在1W的情况下，对于带宽的需求为10M。所以数据

         网关所在服务器对于带宽的要求不能低于10M，最大句柄设置不低于1W（阿里云ECS的最大句柄数默认为65535）。

2  架构设计

      首先云服务平台需要有以下几大块功能：1 数据网关； 2 解析服务； 3 指令缓存池

      1 数据网关

         基于数据网关高并发、大流量的业务特点，同时数据网关需要处理多种协议的通讯消息，且表端在线时间短。就需要数据网关的逻辑

         尽量简单，尽量跟业务逻辑解耦， 不做数据库访问，协议头的解析通过调用解析服务提供的RPC服务实现。

       2 解析服务

         解析服务主要实现以下功能：对表端上传的数据进行解析、封装下发到表端的指令、解析操作及指令封装操作所依赖的 协议包要满

         动态调用、协议包要能够热加载、对上传消息及下发指令做数据持久化操作

       3 指令缓存池

         指令缓存池，主要功能是对下发指令进行生命周期管理。

      ===>>>基于以上功能模块的特点，本云服务系统架构设计如下：

       

         数据网关的基础框架采用netty4.x，支持UDP、TCP消息的上传及下发，且并发量也完全能够满足2W+的并发请求。

        所有上传消息的解析及后续业务逻辑处理都通过RabbitMQ进行解耦，由解析服务端进行异步处理。

        技术架构如下图所示：

        

        数据网关需要满足无状态化，UDP、TCP服务由外部应用动态启停。因为燃气表需要发往不同的燃气公司，而各燃气公司分布在全国各个不同的区域

        就需要有一个专门的管理系统对该云服务平台进行部署管理、燃气表接入管理等，由此又衍生出来了以下架构设计：