微服务架构的城市照明控制系统服务平台设计

  • 来源:物联网技术
  • 关键字:微服务架构,城市照明
  • 发布时间:2019-02-25 16:53

  摘要:针对目前传统一体化服务架构的不足,为构建具有分布式、扩展性强以及容错性高等特点的城市照明控制系统,提出以微服务架构为基本框架搭建系统应用服务平台。通过分析系统应用服务平台的设计需求以及微服务架构的特点与优势,进而制定出完善的服务平台设计方案。在整个系统中,分别定义出产品、设备、从机、用户等四个概念,对终端设备和管理人员进行抽象描述,并阐述各个概念之间的相互层级关系以及所对应的系统原型,以达到服务平台便于对大量设备终端和操作用户统一管理的目的。该服务平台采用去中心化设计,具有易于扩展、易于访问、部署灵活等微服务特性,在提升服务平台性能的同时,从应用层面提出一种城市照明控制设备管理分散的解决方案。

  关键词:微服务;城市照明;服务平台;设备终端

  中图分类号:TP311.5文献标识码:A文章编号:2095-1302(2019)01-00-04

  0引言

  随着城市化规模的不断扩大和品质要求的不断提升,以及城市照明范围和灯具数量的逐渐增加,将城市照明进行有效控制、统一管理尤为重要[1]。目前,国内城市照明控制应用系统多以单体照明系统为主,城市级的各个照明系统管理分散,导致后期的管理与维护较为困难,若能将其接入同一服务平台统一管理,则问题即可得以解决。服务平台处于整个控制系统的核心部分,主要是对数据的存储与智能分析处理提供功能支撑[2]。但现有的服务平台存在诸多共性弊端。例如,采用整体架构模式设计,所有功能封装在一个应用系统中,导致系统扩展性差;系统耦合性高、集合度低,程序难以复用与维护,与低耦合高内聚的软件开发原则相悖[3]。针对上述问题,本文提出基于微服务架构(Micro-Service Architecture,MSA)的服务平台系统,有助于改善服务平台性能,创新其构建风格,发挥积极的作用。

  1微服务架构机制及其特点

  微服务是一种构建分布式系统的架构风格,将传统单体结构应用划分成一组小的服务,每个服务器根据其负责的具体业务职责提炼单一业务功能,由于其均有自己的处理和通信机制,因此可部署在单个以及多个服务器上,同时服务之间相互独立,采用轻量级通信机制,达到相互协作、互相配合的目的。微服务具有独立部署和扩展、功能解耦、独立开发和演化、团队自治等特点,能够有效降低应用复杂度、提升复用率、缩短应用开发周期,同时适应资源的弹性伸缩,进而实现提升整体系统稳定性与可用性的目标。

  2系统服务平台需求分析

  目前,现行城市照明通过计算机技术、通信技术、软件技术和自动化控制技术等实现对分散照明设备的统一管理和自动化控制,进而达到改进控制方式和降低能耗的目的。通常的照明控制系统体系结构如图1所示,主要分为四个不同的层级,由上到下依次为应用层、服务平台层、接入层和物理设备层。

  图1照明控制系统体系结构图

  应用层针对特定用户的自身需求,创建相应的实际应用,是整个系统中照明控制设备与用户交流的窗口。其中,通过应用开发、智能控制为不同用户提供对照明设备更为方便、直观的管理方式。

  服务平台层可以称为整个控制系统的核心层,承担着多设备终端数据汇聚、处理、融合和优化的核心功能,即为系统应用的功能提供技术支撑。具体地,通过服务平台提供的一系列接口,实现用户应用和照明设备终端的正常接入,实现上下层的数据传输,以达到用户对照明设备能够实时检测与控制的目标。同时,为应用层提供统一的设备终端与用户管理功能,并提供标准化的统一接口,使得数据传输更加简单直接。

  接入层是设备层和服务平台之间通信的桥梁,主要任务是将设备终端采集到的数据通过适当的协议进行转换,将数据以多种不同的网络通信方式发送至上层,实现设备终端的接入。

  物理设备层的主要功能是设备终端信息获取,包括不同的物理传感器和数据采集设备。各层之间互相配合,共同搭建物联网应用框架。

  为满足系统结构各层不同的功能,服务平台的需求主要有以下几点:

  (1)照明控制设备能够通过接入层的统一接入与管理;

  (2)可对物理设备层上传的数据进行合理分析,判断照明设备的运行状况,进而做出相应的处理,并能够对数据与处理结果进行存储,通过应用层供用户查询;

  (3)具备自动化控制功能,实现对照明设备的智能

  控制。

  基于上述分析,本文构建一种可实现对不同终端设备进行无缝接入和统一管理的开放式平台,并且该平台可对设备终端数据进行实时分析处理与存储,实现告警检测、智能控制的功能,以达到远程监控与节能的目的。

  3基于微服务架构设计系统服务平台

  微服务架构下城市照明控制服务平台设计的目标是将现有传统物联网服务平台的服务进行划分和复用,同时整合新服务,建设一个高内聚松耦合可扩展的服务平台。

  基于以上准则,采用的基本思想是:将整体功能分解至各个单一的服务中,以实现对解决方案的解耦,即将整体复杂的系统拆分为一系列小且功能专一的微服务,并通过各个服务之间的相互协作构建整体应用系统。

  3.1系统管理模型介绍

  实践中,为便于对照明控制系统中不同的终端设备进行管理,定义用户、产品、设备、从机四个概念,对终端设备进行抽象描述。

  (1)用户是指用户端的信息;

  (2)产品是一类设备的统称,亦可理解为“项目”或“系统”,是对同一类设备的集中化管理;

  (3)设备通常是对系统中网关的抽象描述,主要用于帮助照明控制设备通过各种联网方式接入服务平台,其属性信息包括设备名称、MAC、地址等;

  (4)从机是设备下属的某一类物理传感器集合或开关控制设备集合。

  用户与设备的关系:每个设备只能有唯一的最高操作权限的用户,可对设备信息进行增删改查等操作,称为设备的“管理员”,而其余用户可向该设备的管理员发送授权请求,授权成功后只能以“分享者”的角色对设备信息进行查看,不可修改、删除。

  产品与设备的关系:每个产品下可包含多个设备,单个设备只能属于一个产品。

  设备与从机的关系:为便于对设备数据进行管理,提出“从机”的概念,对设备数据进行适当分类,包括模拟量从机和开关量从机。从机位于设备之下,每个设备可包含多个从机,单个从机只能属于一个设备。

  用户和产品两者之间没有直接关系:产品是针对设备生产厂家为便于对设备进行分类管理而产生的概念,同一类设备属于同一产品,设备生产完成后需在服务平台中将设备注册于某一产品下;用户是针对设备的普通使用者而产生的概念,用户购买设备后需在平台中验证该设备注册与否,并添加相关设备信息与自身用户完成绑定。系统管理模型关系如图2所示。

  图2系统管理模型关系图

  3.2系统平台设计

  为方便上述管理模型的实际应用以及对照明设备的智能控制与检测,在系统服务平台中将整体服务拆分为多个微服务。其中,设备管理服务用于实现用户对设备信息的添加与修改等;消息队列遥测传输(Message Queuing Telemetry Transport,MQTT)服务用于为平台提供即时通信功能;智能控制服务用于根据用户提前设定好的时间计划,智能控制对应开关量的开关状态等功能。可见,每个服务的功能具体且专一,各自分别完成整个系统的部分功能。服务之间通过协作完成复杂的系列任务,如智能控制服务功能的实现需由设备管理服务查看当前所接入的设备,同时通过从机管理服务查看开关量从机的时间计划设置情况,智能控制相应设备的开关状态。根据系统平台的需求与功能和微服务架构特征,设计结构如图3所示。

  其中,基础服务层对具有共性业务特征的功能进一步抽取、内聚,形成服务中心,在系统内的多个微服务中共享使用。中间件层主要实现服务的统一管理,为服务间的相互协作运行提供技术支撑。监控层通过对应用、服务、服务调用链等进行监控,形成一种对整个微服务系统平稳运行的安全保障机制。业务服务层对系统整体的应用功能进行专业化分工,通过去中心化的服务方式,实现功能解耦。

  3.3服务平台工作流程

  从系统架构图中可以看出,系统中每个服务的功能与数据与其他服务均相互独立,服务之间采用RESTful HTTP协议的通信机制,下文通过添加设备信息过程中的具体业务说明微服务架构的工作流程。

  (1)应用端访问设备管理服务,携带用户验证信息(tokenId)和设备信息(包括MAC、设备名称、地址等),发起添加设备信息请求;

  (2)设备管理服务接收到请求后,根据用户验证信息(tokenId)访问用户管理服务,验证该用户信息的合法性;

  (3)根据应用端请求中的MAC信息访问产品管理服务,验证该MAC信息的合法性;

  (4)验证通过后,设备管理服务生成deviceId,并在数据库中添加设备信息;

  (5)将生成的deviceId告知MQTT服务,用于构成MQTT消息发送与接收的主题号,至此添加设备信息完成。

  上述过程中用到的RESTful API见表1所列。

  表1设备管理服务RESTful API

  请求类型 功能 URL示例

  POST 请求添加设备信息 http://... /m2mcloud/api/devices/create/

  PUT 验证用户信息 http://... /m2mcloud/api/users/inf/{id.tokenId}

  PUT 验证MAC信息 http://... /m2mcloud/api/products/inf/{mac.mac}

  PUT 添加deviceId信息 http://... /m2mcloud/api/mqtt /{id.deviceId}

  4系统原型实现

  目前,开源的微服务基础框架主要有Dropwizard和Spring Boot,两大框架在实现技术上存在一定的差异[5]。Dropwizard的突出特点是简单、轻量,但依赖注入不完整,需开发者自行选择,使得初期开发具有一定的难度。Spring Boot核心有依赖注入,解决大量的配置问题,提供模块化的依赖管理工作,使其具有自动化配置、快速开发、轻松部署等特性。因此本文选择Spring Boot作为构建微服务的基础框架。本文以设备管理服务中获取设备MAC信息为例,程序实现如下:

  @RestController

  @RequestMapping(“/api”)

  public class HolaRestControllerV1 {

  @RequestMapping(method=RequestMethod.GET,value = “/deviceV1”,produces = “text/plain”)

  public String deviceMac() throws UnknownHostException {

  String macInf= null;

  try {

  macInf =Device.geDevice ().getMacInf ();

  } catch (UnknownHostException e)

  {

  macInf = “unknown”;

  }

  Return macInf;

  }

  }

  其中,@RestController用于告知Spring该类是一个用于暴露HTTP端点的控制器(可以暴露GET,PUT和POST等基于HTTP协议的功能);@RequestMapping用于映射HTTP URI到对应的类或方法。

  在微服务架构中,为实现正常的服务运行管理功能,引入Spring Cloud组件。Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM 的云应用开发中的配置管理、服务发现、断路器、智能路由、分布式会话和集群状态管理等操作提供了一种简单的开发方式[5]。以Eureka为例,Eureka是Spring Cloud Netflix的一个子模块,也是核心模块之一,用于服务注册和服务发现。通过注解的方式使用Eureka,如通过注解@EnableEurekaServer启动一个服务注册中心提供给其他应用进行对话,代码如下所示:

  @EnableEurekaServer

  @SpringBootApplication

  public class Application {

  public static void main(String[] args) {

  SpringApplication.run(Application. class,args);

  }

  }

  5结语

  本文将微服务应用于城市照明控制系统服务平台,不仅能够从应用层面解决控制系统中的某些应用问题,而且适用于对开放性、可扩展性需求较高的城市照明控制系统。除此之外,分布式设计易于实现API跨服务通信,容易将多个照明控制系统整合到一个平台中,实现统一管理,进而从应用、管理、维护等多个角度对城市照明控制系统进行改进。

  参考文献

  [1]刘廷章,王健,杨晓.基于Web的城市景观照明远程监控技术研究[J].电气应用,2009,28(3):32-35.

  [2]程冬梅,王瑞聪,刘燕,等.基于REST架构风格的物联网服务平台研发[J].计算机工程与应用,2012,48(14):74-79.

  [3]吴昌雨,李云松,刘青,等.基于微服务架构的物联网应用基础框架设计[J].宿州学院学报,2015,30(7):88-92.

  [4]赵善龙,孙婉婷.基于微服务架构的互联网+农业平台设计[J].通信管理技术,2017,33(2):53-55.

  [5]张晶,黄小锋,李春阳.微服务框架的设计与实现[J].计算机系统应用,2017,26(6):259-262.

  [6]张向祺.基于微服务的企业移动办公平台规划设计[J].信息技术与标准化,2016,25(3):71-74.

  [7]王志勃,王麒森,毕艳茹.互联网环境下微服务框架分析与研究

  [J].信息与电脑,2017(22):23-25.

  [8]辛园园,钮俊,谢志军.微服务体系结构实现框架综述[J].计算机工程与应用,2018,54(19):10-17.

  张玉杰,王轩

  (陕西科技大学,陕西西安710021)

……
关注读览天下微信, 100万篇深度好文, 等你来看……
阅读完整内容请先登录:
帐户:
密码: