基于微服务架构的分布式测距系统的研究与设计

向彬彬 马明星 童茂林 彭 瑾 苏文秀 高秀敏

(杭州电子科技大学电子信息学院 浙江 杭州 310018)

0 引 言

近年来，随着科学技术的不断进步，诸多领域都取得了飞速发展。在距离测量方面，国内外也先后出现了红外线测距[1]、微波测距[2]、超声波测距[3]与激光测距[4]等技术。而随着这些理论的不断发展，适用于各种环境的测距系统也相继出现。其中，激光测距技术由于激光高亮度、单色性和相干性好、方向性强的特点而被广泛应用于卫星[5]、雷达[6]、汽车防撞[7]、移动机器人[8]等高精度的测距系统中。虽然测距系统在许多应用中都取得了飞速发展，测距技术也呈现出多样化，但传统的测距系统依然受到了测量范围、扩展性等方面的限制。

基于微服务架构的分布式测距系统首先利用无限WIFI通信原理与Ad Hoc网络技术[9]，实现了可以自组网的测距传感网络，使得系统很好地克服了测量范围的限制。然后利用Hadoop对海量测量数据进行分析与处理，并利用负载均衡原理[10]实现了测量网络与数据分析模块的流量控制，平衡了网络负载，提高了系统的计算能力。最后，根据微服务架构原理[11]将系统根据功能的不同拆分为独立的服务，在实现了根据功能对系统进行横向扩展的同时也简化了服务的开发与维护。

1 系统架构

基于微服务架构的分布式测距系统作为分布式的测距传感系统，通过对待测系统添加多个测距探针采集数据，然后通过数据分析模块对采集的数据进行分析，最后将分析结果通过前端展示。系统架构如图1所示。

图1 系统架构

该系统底层是由多个测距探针组成的测距系统。测距探针是一个包含测距传感器模块、通信模块与控制模块的嵌入式系统，主要通过测距传感器采集数据，并使用控制模块对数据进行预处理，然后利用WIFI通信模块将数据发送到数据分析模块进行具体任务处理与持久化操作。

该系统底层所有测距探针采集到的数据首先都会发送到数据分析模块进行处理和数据持久化操作。数据分析模块主要使用Hadoop大数据进行数据处理，使用HBase和HDFS(Hadoop分布式文件系统)进行数据持久化。数据分析模块可以有一个或多个，如果使用多个则需要使用负载均衡器选取最优的数据分析模块进行数据处理。

该系统基于微服务架构将应用拆分为不同的服务，这些服务主要包括：基础服务，为系统提供基本操作，包括用户管理、日志服务等；任务分发服务，结合具体测距项目将数据处理封装为一个或多个子任务，并将这些子任务分发到对应的数据分析模块中进行数据处理；项目管理服务，可以获取项目的拓扑结构，也可以对每一个单独的探针进行创建、删除、修改等管理操作；设备监控服务，对探针进行全面的监控，包括提供探针心跳检测和温湿度监控等功能。另外，系统根据微服务架构原理在服务层实现了服务自发现与服务注册等功能。

该系统最上层为显示层，用户可以利用浏览器或手机客户端通过域名访问和使用测距系统平台。Web Portal显示层使用Spring框架通过调用REST API接口实现显示层的功能[12]。显示层并非直接调用服务层各服务API，而是统一通过API网关进行身份认证，然后利用API网关将请求转发到对应的服务中进行处理。

2 测距探针的设计

2.1 测距探针结构

测距探针是该分布式测距系统的数据采集核心组件，该模块实现了数据采集、数据预处理、WIFI通信与心跳检测等功能。图2显示了测距探针的内部结构。

图2 测距探针内部结构

测距探针的主体结构由一个STM32控制系统、数据采集模块和WIFI通信模块组成。其中，数据采集模块主要用于采集测距数据。在一个测距系统中可能使用不同类型的传感器，如激光传感器、红外传感器、超声波传感器等，为了控制系统更好地适配各类型传感器，需要添加转换电路将不同传感器的信号转换为统一的模拟电压信号量传入STM32内部ADC转换器中处理。基于STM32的控制系统则主要用于将采集到的数据进行预处理，转化为Json格式，并通过WIFI通信模块将数据发送到数据分析模块进行进一步分析、处理和存储。

2.2 测距传感网络

该系统主要针对大规模测距系统应用而设计，因此需要使用大量测距探针组成测距传感网络。该系统使用AODV实现Ad Hoc自组网。AODV协议[13]是一种基于DSDV(目的节点序列距离矢量协议)的按需路由协议。在AODV协议中，当节点收到一个路由请求分组后，该节点可以反向学习到请求发送节点的路由信息。最终，目的节点收到路由请求分组后，可以根据学习到的路由回复路由请求。这样，源节点和目的节点之间便建立了一条全双工路径。

在AODV协议的实现中，路由查找算法是传感网络实现的核心，该系统中路由查找算法的实现流程如图3所示。在进行路由查找时，首先需要确定路由表中是否包含到该节点的路由，如果有且路由可用，则释放空间直接结束处理。然后判断是否到达RREQ路由请求报文发送时间，发送RREQ，如果没到则直接结束处理。在查找过程中，如果查询该节点的次数用尽，则说明没有找到可以到达该节点的路由，此时删除缓存中发送到该节点的数据包，然后结束处理。如果是第一次发送RREQ路由请求报文，则设置相应的初始值，如果不是第一次发送，便扩大转发范围，然后组装数据包转发到下一个节点。

图3 路由算法流程图

3 数据分析模块的设计

3.1 分布式数据分析与存储的实现

Hadoop是一个开源的分布式计算架构，它实现了一个高容错性的分布式文件系统HDFS和一套海量数据计算框架MapReduce，另外还衍生了整套基于Hadoop的分布式计算生态圈[14]。该系统便是使用Hadoop实现对海量测距探针检测数据的分析处理和持久化存储。

测距探针采集到的数据通过WIFI通信模块发送到Hadoop HDFS文件系统中创建临时文件保存。然后，系统通过调用定时任务定时对临时文件中的数据进行MapReduce任务处理，过滤异常数据和错误数据；进而将处理后的数据保存到HBase数据库中。服务层的任务分发服务发送任务请求到数据分析模块时，数据分析模块根据请求内容调用指定的MapReduce任务分析和处理数据。另外，用户还可以通过任务分发服务自定义MapReduce任务处理自定义分析过程。数据分析模块的处理过程如图4所示。

图4 数据分析模块处理过程

3.2 负载均衡的实现

在实际应用中，测距系统一般使用大量测距探针协同工作，为了更加准确快速地分析和处理海量测量数据，系统采用集群部署模式部署Hadoop数据分析模块，因此一个高效的负载均衡器是必不可少的。

该系统的负载均衡器主要对数据分析模块接收测距探针数据和接收任务分发服务的任务处理请求选择最优节点。图5描述了该系统负载均衡的均衡策略。测距探针和任务分发的处理请求首先都暂存到阻塞队列中等待策略模块过滤转发。对于测距探针的数据接收请求，负载均衡器主要利用项目ID、区域和网络流量等对数据分析模块进行过滤选择；而对于任务分发服务的数据处理请求，负载均衡器主要利用项目ID、任务数以及CPU利用率等进行过滤选择。当选择到最优的数据分析节点则将请求发送到对应的节点进行处理，而如果有多个符合条件的节点，则负载均衡器将随机选择其中一个转发处理请求。

图5 负载均衡策略图

4 服务层的设计

4.1 服务层结构

该系统基于微服务架构将系统各功能拆分为独立的服务。拆分出来的服务通过RPC(远程过程调用)实现相互通信，为前端提供业务服务。服务层的具体结构如图6所示。

图6 服务层结构

服务层底层包含基础服务和任务分发服务，其中基础服务提供面向系统的基础性服务，如用户管理、授权管理、日志管理等；任务分发服务主要用于将项目和设备管理中的业务转换为计算任务发送到数据分析模块。服务层上层主要包含项目管理服务和设备监控服务，其中项目管理服务针对具体的项目提供管理服务，可以提供项目的详细拓扑，还可以对测距探针进行增、删、改、查等管理操作。另外，服务层还包含一个服务注册中心，用于管理所有服务和监控服务健康状况。各服务之间的交互通过RPC实现，如各服务模块记录操作日志都需要调用RPC的cast()方法发送消息到RabbitMQ消息队列[15]中，对应的基础服务日志管理模块则监听消费名为operation-log的队列中的消息。

4.2 服务发现

该系统采用服务端发现方式实现服务自发现，客户端通过API网关转发请求到具体的服务处理请求。因此，该系统在服务层实现了一个服务注册中心管理各个服务的注册信息。

该系统利用将所有服务的IP和端口号以key-value(键值对)形式保存到etcd中；服务注册中心则提供两类API管理etcd中的配置信息。一类API为管理服务API，主要实现服务的注册和注销功能；另一类API为查询服务API，API网关通过该API查询相关服务的IP和端口号。

4.3 服务注册

每个服务在启动时都需要主动将服务注册到服务注册中心中。完成服务注册首先需要在该服务中添加一个配置文件service-sdk.conf，该配置文件配置了服务相关信息。

ranging.service.sdk {

service:{

name:″task-allocation″,

description:″Task Allocation Service″,

module:″Task-Allocation″,

platform:″Ranging System″,

endpoint:{

target:″ranging/taskallocation″,

apis:[{

version:″1.0″,

state:″STABLE″

}]

}

}

}

上述配置文件描述了任务分发服务的配置信息。其中，service中配置了服务的所有配置：name表示服务的名称，description表示服务的描述，module则用来在平台范围内唯一标识服务，platform表示平台名；endpoint描述了该服务的endpoint信息，其中包含target表示服务API的基础注册点，apis则表示了所有API服务，每一个API对象都定义了API的版本状态state以及API版本version。每个服务在完成注册的同时也需要将对应的endpoint信息注入API网关中，这样Web Portal层在访问时便可以通过endpoint找到对应的服务。

添加配置文件之后，则需要为服务添加一个注册方法register()来完成服务注册。该方法接收一个InputService类型的参数，InputService类封装了配置文件中服务的配置信息。register()方法调用服务注册中心的管理API将服务的配置信息主动发送到服务注册中心中注册服务。

5 API网关的设计

该系统中，API网关有两个作用：一是用于前端用户身份认证和鉴权；二则用来将前端HTTP请求转发的对应服务中进行处理。

API网关的处理流程如图7所示。API网关接收到前端发送的HTTP请求时，首先会判断该请求是否为登录用户验证请求，如果是，则直接解析请求URL，并转发请求到服务层验证；如果验证通过，则生成token令牌，并保存到Redis缓存中，然后将token添加到响应头部返回；如果验证未通过，则直接返回403错误。如果API网关判断该请求不是登录用户验证请求，则对请求头部携带的token进行验证。如果验证不通过，则直接返回401错误；如果验证通过，则解析请求的URL地址。前端通过Web Portal层发送HTTP请求的URL主要由三部分组成：前缀、版本和服务层URL，其中前缀和版本就是4.3节中服务注册时配置的endpoint中的target和API的版本信息version。API网关通过解析的前缀和版本号在服务注册中心中查找相应服务的IP和端口号。如果找到相应的服务信息，则使用查找到的IP和端口号以及服务层URL将请求转发到服务层对应服务中进行处理；否则，直接返回404错误。

6 实验结果与分析

6.1 测距探针测试

实验中，采用激光测距传感器(测量距离12 m，误差±5 mm)，结合图2所示的结构设计了测距探针的电路，并制作了测距探针实物。本文设置了56组测距模型，分别使用测距探针和人工方式测量了所有模型的距离。根据测量数据，绘制了如图8所示的折线图。

图8 56组测量数据折线图

由图8可知，测距探针测量与人工测量的测量结果基本一致。当测量距离不超过10 m范围，测距探针的测量误差不超过±2 mm；而测量距离在10～12 m之间，测距探针误差相对较大，但也不超过±5 mm。由此可知，测距探针的测量结果稳定、误差较小、可靠性高。另外，由于测距探针利用转换电路可以适配不同类型的测距传感器，因此在大型项目中如果需要使用不同传感器测量只需将不同的传感器接入对应的转换电路接口即可，简化了电路的设计与开发。

6.2 数据分析模块与服务层性能测试

本文使用Linux虚拟机搭建基于Hadoop集群的数据分析模块测试环境。其中，包含一个namenode节点和4个datanode节点，所有节点的规格都为2核4 GB内存、50 GB硬盘、Ubuntu14.04操作系统。实验中，使用Yarn(Hadoop2.0新MapReduce框架)分析多个测距探针采集的数据日志文件，从中提取出测距数据以及温度、心跳等监控数据。该实验分别使用2、3、4个节点处理同一量级的测距数据；然后将多组数据的处理时间绘制成如图9的折线图进行分析。

图9 2、3、4个节点数据处理性能对比折现图

由图9可知，当数据量小于100 MB时，2个节点处理同一量级数据的速度比3个、4个节点的处理速度更快，这主要是由于此时2个节点map、reduce操作的数量较少，且可以满足处理数据量的要求；而3个、4个节点还需要考虑到节点的调度与数据交互等多个因素。当数据量大于100 MB，3个、4个节点的处理速度明显提高，这是由于此时两个节点已经无法很好地满足计算数据量的需求，需要通过扩展多个datanode节点达到更好的处理效果。

随着项目的不断增加，处理的数据也将不断增长。为了提高数据分析模块的处理速度，降低节点的流量，系统可以继续增加一个或多个datanode节点，并通过3.2节中提出的负载均衡器实现各节点的负载均衡。需要注意的是，集群节点并不是越多越好，而是应该根据需要选择合适的节点数。使用多节点存储和处理数据，避免了系统的单点故障，也可以实现系统的横向扩展。

实验中，服务层的所有应用都部署在Docker容器中，然后通过Kubernetes管理所有容器。如果需要添加服务，只需要根据4.3节所提出的方法在对应服务中实现服务注册功能，然后将其制作成Docker镜像并以Docker容器的方式启动即可。这样，各服务都只需要通过服务注册中心进行管理，并利用API网关对外提供统一接口，实现松耦合，简化了各服务的开发，降低了系统的复杂度。

6.3 前端显示

系统Web Portal层为用户提供界面友好的测距系统界面，方便用户通过手机和浏览器访问和管理系统。图10展示了测距探针的测量数据的监控界面。

图10 测距探针监控界面

7 结 语

测距系统广泛应用于环境、电力、铁路、军事等领域，对于一些精度要求高、测量范围广的场景，测距系统的可靠性、精确性和扩展性显得尤为重要。本文首先提出了一种基于微服务的分布式测距系统架构。然后分别深入阐述了测距探针、数据分析模块、服务层以及API网关的设计与实现。本文提出的测距系统通过WIFI接入网络，方便快捷，使用户只需通过PC机或手机便可以远程监控测距探针的状态和测量数据。系统采用了Ad Hoc自组网技术，使得测距探针可以自动匹配路由信息，降低了组网难度，从而使得添加或删除测距探针更加容易。本文设计的分布式测距系统利用分布式和负载均衡的思想，避免了由于单一计算节点导致的单点故障和测量数据不准确等问题，大大提高了测距系统的可靠性。另外，系统基于微服务架构实现服务自发现和服务注册功能，不仅简化了开发和降低了系统复杂度，还提高了测距系统的横向扩展性。

参考文献

[1] Garcia M A, Solanas A. Automatic Distance Measurement and Material Characterization with Infrared Sensors[C]//RoboCup 2004:Robot Soccer World Cup VIII. DBLP, 2004:451-458.

[2] Zhang F, Ge X, Gao B, et al. Phase-coded microwave signal generation based on a single electro-optical modulator and its application in accurate distance measurement[J]. Optics Express, 2015, 23(17):21867-21874.

[3] Kelemen M, Virgala I, Kelemenova T, et al. Distance Measurement via Using of Ultrasonic Sensor[J]. Microelectronics Journal, 2015, 33(5):479-486.

[4] 孟文东, 汤凯, 邓华荣,等. 1064nm波长卫星激光测距技术和实验研究[J]. 光学学报, 2015, 35:(a01):197-202.

[5] 卫志斌, 瞿锋, 项清革,等. SESAM锁模激光器在卫星激光测距领域应用研究[J]. 测绘科学, 2009, 34(6):5-6.

[6] 侯建刚，陶然，单涛，等. m系列在激光测距雷达中的应用[J]. 兵工学报, 2005, 26(1):37-41.

[7] 贺大松，门延会. 激光测距技术在汽车主动安全装置中的应用研究[J]. 应用激光, 2011, 31(2):160-163.

[8] 隋金雪，杨莉，贺永强. 激光测距在移动机器人自主导航中的应用[J]. 传感器与微系统, 2007, 26(7):114-117.

[9] 李勇，黄均才，王凤碧，等. Ad Hoc网络体系结构研究[J]. 计算机应用, 2005, 25(1):163-164.

[10] 张松，杜庆伟，孙静，等. Hadoop异构集群中数据负载均衡的研究[J]. 计算机应用与软件, 2016, 33(5):31-34.

[11] 李春阳，刘迪，崔蔚，等. 基于微服务架构的统一应用平台[J]. 计算机系统应用, 2017, 26(4):43-48.

[12] 宋涛，徐庆增，吕思思. 浅谈基于Spring MVC的REST功能[J]. 电脑知识与技术：学术交流, 2016, 12(12):86-87.

[13] Perkins C, Belding-Royer E, Das S. Request for Comments:Ad hoc on-demand distance vector (AODV) routing[J]. Experimental Internet Society, 2003, 6(7):90.

[14] 曹旭，张云华. Hadoop平台下计算模型中调度策略的研究[J]. 计算机应用与软件, 2013, 30(9):208-214.