一种基于Dubbo的车联网命令发送方法的设计
来源:用户上传
作者:
摘要：该文介绍了一种基于Dubbo框架实现的车联网命令发送方法。该方法通过服务的注册机制，扩展了Dubbo的Cluster接口的方式，实现了命令管理服务自动感知车辆接入服务扩容和缩容，并可以对多个实例进行透明的访问。另外采用先询问，确定车辆接入的服务后再下发命令到车上的方式解决了控制命令的私密性，提高了系统的安全性。
關键词：车联网;命令系统;分布式访问
中图分类号：TP393 文献标识码：A
文章编号：1009-3044（2020）21-0050-02
开放科学（资源服务）标识码（OSID）：
1 背景
随着物联网优势不断显现，汽车接人互联网也慢慢成为标配。尤其是新能源汽车更是以国家规范的方式，要求必须接人到车联网，以满足车企和政府的安全监管需求。
车联网系统平台应支持数万、数十万甚至是数百万的车辆接人。由于单服务器的资源受限，无法支持巨量车辆的网络接人，需要多台接人服务器，形成一个服务集群来为车辆提供互联服务。
车辆在接人车联网时，由于网络环境的差异导致链接可能随时中断。也会发生的接人服务器可能无法提供服务，在设计上，车辆会维持一个主机列表，车辆会根据实际情况随机选择连接的主机。这样车辆接人点是动态的变化的。
当用户需要控制车辆下发控制命令，如开关车窗、门锁等。由于车辆的动态接人原因，命令管理服务难以知道其所需要控制的车辆所在的接人点。传统上，有两个方法解决这个问题，一种是采取广播的方式，命令管理服务将命令广播到每个接人服务中。另一个方法是在命令管理服务中维持每个车辆接人服务名称和其位置信息（ip和端口）的对应关系，并根据车辆上报数据时所在接人服务的名称，查找到接人服务的位置信息，将命令发送到接人访问。
第一种方法命令内容的安全性不强，第三方实现的车辆接人服务可以轻易获取车辆控制命令。第二种方法不支持车辆接人服务的动态扩容和缩容，如果增加一台车辆接人服务器，那么需要将此服务器的ip地址和端口手动添加至命令管理系统，导致需要频繁增加或删除配置，甚至需要重启命令管理系统。实时性不强，且设计复杂。
2 设计方案
命令管理服务系统的设计目的是当存在多个车辆接人服务实例运行，车辆可随机选择连接其中一个接人服务时，命令管理服务能够准确地透明地将命令下发至指定车辆。另外，系统应支持车辆接人服务能够动态扩容和缩容。
2.1总体架构
由上图，整个系统方案由三个服务组件组成。分别为车辆接人服务、命令管理服务以及注册组件。车辆接人服务可以启动多个实例，并向注册组件注册本服务;注册组件保存车辆接人服务各实例的配置和接口信息;命令管理服务可以读取注册组件中车辆接人服务的注册信息，并可以调用车辆服务实例中的下发命令的接口。
2.1.1方案组成部分说明
2.1.1.1车辆接入服务
车辆接人服务主要负责车辆的网络接人的服务，为车辆提供数据交互和链接维持功能。
2.1.1.2命令管理服务
命令管理服务主要负责接收用户的命令下发，并准确地向指定车辆发送命令的功能。主要包含选择器和筛选器两个策略器。
2.1.1.3注册组件
注册服务主要负责保存各服务的注册信息，记录各服务的位置以及调用接口等元数据信息。支持存储节点的动态更改通知。
2.1.2接入服务注册和删除流程
车辆接人服务实例在启动的时候向注册组件注册自己的位置及接口的相关信息。当有命令下发，命令管理服务从注册组件中获取车辆接人服务列表信息，采用远程过程调用RPCⅢ的方式直接访问车辆接人服务的接口。另外，命令管理服务缓存了车辆接人列表实例信息，如果有新的车辆接人服务实例上线或者原有的服务下线，注册组件中的数据均会改变。注册组件会立即将改变推送至命令管理服务，命令管理服务可以实时维护最新的车辆接人服务的列表，从而支持了车辆接人服务自动透明的扩容和缩容。
2.2 命令下发流程
命令管理服务在接收到用户的车辆控制命令后，获取指定车辆的标识符，向车辆接入服务广播，询问指定车辆所在接入服务的位置。如果车辆在线，将会收到一个接人服务在线的应答，表明车辆在此接人服务中上线。然后命令管理服务调用命令下发接口将命令发送到此接人服务中，进而通过TCP链接转发至车辆的接收设备，实现了命令下发的过程。
2.2.1 在线链接询问
在线链接询问是命令管理服务向各个接入服务询问指定终端在线情况的过程。管理服务采取广播的方式询问接人服务，接人服务将车当前在线或者离线状态返回给命令管理服务。采取先询问后发送命令的好处在于，保证命令内容的安全性。由于接人服务器可能由第三方维护，为了避免将某些敏感的命令信息暴露给第三方的接人服务，造成不必要的信息泄露。所以在发送命令之前，先询问待接收命令的车辆所在服务的确切位置，后将命令发送给接人服务中。
2.2.2 接入服务选择器
车辆的TCP链接存在假死的情况，当车辆在A接人服务链接意外失效，但服务并没有感知，直到超时之后A才发现车辆长时间没有发送数据到服务端1上。从而将链接断开，此时A车才在服务器端处于离线状态。但可能出现A在超时期间，又重新链接到了接人服务2上。那么如果此时用户要发送命令到A车，命令管理服务器询问A车所在链接的位置，服务1和服务2均返回A车在线，命令管理服务无法确认车辆真实所在位置。
解决这个问题的办法是，实现一个接人服务选择器。此选择器为策略器的具体实现。在命令管理服务询问时，接人服务将返回车辆在线状态和最后接收到车辆数据的时间。选择器确定最近收到数据的链接为车辆的真实在线链接，以此接人服务为选择出来的服务。 2.2.3 命令协议
车辆的控制命令根据实际需要更新较为频繁，经常出现增加某个控制命令或者更改某个控制协议。如果协议转换模块在车辆接人服务中实现，势必导致车辆接人服务软件更替较快，影响到车辆的接人服务。我们将命令协议放人到命令管理服务中，车辆接人服务只接收二进制命令数据，可直接发送。这样使双方的接口定义更加的简单，命令下发更加灵活，同时也降低了车辆接人服务的实现复杂度。命令管理服务在接收到用户发送的命令之后，转换成车辆的通信协议的二进制数据后，直接通过车辆接人服务发送至车辆。
2.3 具体实现
2.3.1 Dubbo介绍
Apache Dubbo[2]是一款阿里巴巴公司开源的高性能JavaRPC框架。其为用户封装了远程过程调用的实现细节，具有智能纠错，负载均衡和自动注册发现等功能。是一款应用极为广泛的RPC框架。
2.3.2 接口定义
接口即为契约，使服务双方共同达成的访问协议。在命令下发程序中涉及两个服务。一个是车辆接人服务，另一个是命令管理服务。命令管理服务调用车辆接人服务的接口，完成命令下发过程。
ITsService为接口，定义了isOnline和fireBvtesData两个成员函数。isOnline就是询问车辆否在此接入服务中在线，参数为车辆标识符;fireCommand即为下发命令接口，参数车辆标识符和命令的二进制数据。
VehicleService为车辆接人服务类，维持车辆与平台的网络链接，实现了ITsService的接口。
CommandMgrService为命令管理服务类，接收用户的命令并通过Dubbo框架远程调用VehicleService的接口方法，實现了车辆状态的查询和命令的下发功能。
2.3.3 筛选器实现
筛选器是在命令管理服务中实现的询问车辆所在接人服务的位置并将命令下发到车辆的模块。因为车辆接人服务器时是按照预先保存的服务器列表和当时的网络环境随机选择主机。系统平台一开始并不确定某台车在哪个接入实例中上线。在发送车辆命令时需要知道当前车辆所在的接人实例，这样可以利用其维持的网络链接，向车辆发送命令信息。车辆在随机接人服务器后，系统通过筛选器获取其所在的接人实例。筛选器主要起到向上屏蔽查查找车辆链接位置的逻辑，并完成向车辆发送命令的功能。我们利用Dubbo集群的Cluster的SPI接口实现了自定义筛选器功能。
在具体实现上，按照Dubbo的提供的JAVA SPI规范在ME-TA-INF中的dubbo文件夹中建立说明文件com.alibaba.dubbo.rpc.cluster.Cluster，定义Cluster接口的实现并命名为evts。在引用ITsService实例时在@Reference注解中指定cluster成员变量为evts。这样在CommandMgrService可以直接透明访问已经注册的车辆接人服务ITsService接口列表，从而实现车辆在线状态询问和命令发送过程。
3 结束语
本文介绍了一种基于Dubbo框架的车联网命令下发方法。此方法支持车辆接人服务的自动扩容和缩容，屏蔽了查找在线车辆所在接人服务逻辑，对于单机接人实例和集群接人实例形成了统一一致的访问方式。有效地降低了系统的复杂度，对命令管理等上层应用提供了无感的访问方式。并且采取询问发送的方式，避免了敏感的命令内容的泄露，进一步提高了系统的安全性。
参考文献：
[1] Srinivasan R.RPC： remote procedure call protocol specification[Ml.United States：RFC Editor，1988.
[2] The Apache Software Foundation. Apache Dubbo[EB/OL].[2019- 12-20].http：//dubbo.apache.org/.
【通联编辑：谢媛媛】
作者简介：胡晨光（1981-），男，安徽宿州人，高级工程师，硕士，研究方向为车联网、大数据。
转载注明来源:https://www.xzbu.com/8/view-15296322.htm
