事件驱动模式下物联网数据交换平台的研究_王威.pdf

第 39 卷 第 7 期 福 建 电 脑 Vol.39 No.7 2023 年 7 月 Journal of Fujian Computer Jul.2023 王威(通信作者)，男，1988年生，主要研究领域为云计算、分布式系统。E-mail:。事件驱动模式下物联网数据交换平台的研究 王威 (浙江金融职业学院信息技术系 杭州 310018)摘 要 目前物联网技术和市场发展迅速，但是物联网设备之间仍然存在信息孤岛的问题。为了实现物联网设备之间的联动，达到共享数据信息的目的，构建一个通用化的数据交换平台是十分必要的。本文提出了一套通用化数据交换平台的构建方案，对数据平台建设中存在的通信架构、数据模型、用户模块、应用架构、网络安全等问题进行了探讨并提出相应的解决方案。实践的结果表明，采用该方案构建的数据交换平台能够基本满足物联网厂商的接入需求并能够支撑其后续的更新迭代。关键词 物联网；信息化；事件驱动；数据中心；云计算 中图法分类号 TP302 DOI:10.16707/ki.fjpc.2023.07.009 Research on Data Exchange Platform of Internet of Things in Event-driven Mode WANG Wei(Department of Information Technology,Zhejiang Financial College,Hangzhou,China,310018)Abstract At present,the technology and market of the Internet of Things develop rapidly,but the problem of information island still exists among the Internet of Things devices.In order to realize the linkage between Internet of Things devices to achieve the purpose of sharing data information,it is very necessary to build a universal data exchange platform.In this paper,a set of construction scheme of universal data exchange platform is proposed,and the problems of communication architecture,data model,user module,application architecture and network security in the construction of data platform are discussed,and the corresponding solutions are put forward.The practical results show that the data exchange platform constructed by this scheme can basically meet the access requirements of Internet of Things vendors and support their subsequent updates and iterations.Keywords Internet of Things;Information;Event Driven;Data Center;Cloud Computing 1 引言 随着网络技术的发展，物联网正扮演着越来越重要的角色。国内设计生产的物联网设备越来越众多，从工业使用到家庭使用，大大提升了社会生活的智能化程度。但是目前的物联网设备都是各厂商自主研发，难以跨越各生产商的壁垒，形成一个统一的行业标准。目前，国内外有很多成熟的标准框架可供参考。这些标准和框架面向不同领域的问题提供不同的标准方案。本文以云计算技术为核心，首先将物联网架构划分为终端、云端、网络通路三个方面，并从用户模块、数据库设计、数据通信模型、安全模型、应用架构等方面，论述一个面向全行业的数据交换平台构建方案。2 通信模型 传统的物联网生态通常包括终端、网络通路、云端三个领域1。终端是指用户使用的硬件产品，云端则是指各厂商构建的(也可以向云端服务商进行租赁)面向自家产品的计算集群，主要提供计算和存储服务。终端和云端之间通过网络通路进行通信。这其中，终端主要是服务普通用户并发送设备48 王威：事件驱动模式下物联网数据交换平台的研究 第 7 期 数据到云端进行协同交互，云端负责接受并处理设备发送的数据。站在数据的角度，云端需要统筹报文的协议以及交换数据的格式，而终端需要按照指定的格式组建消息报文。整体网络架构如图 1 所示。首先由用户通过终端发起请求，请求报文经互联网传送到云端的网关服务器中。由网关服务器根据终端报文的业务标识，转发到两个异地的数据中心。请求报文经过集群的网关，根据子业务标识再转发到具体的业务集群里进行处理2。不同的业务集群共享一套身份认证。同时，不同的业务集群也共享一套基础软件服务，例如 kafka 消息订阅发布服务，redis 数据缓存服务、分布式数据库、应用服务监控系统等。各业务线可以共享基础服务。这样可以节省开发和维护的成本，也更容易把精力聚焦到各自的业务中。图 1 系统网络架构 从整体布局上看，上述的通信架构遵循前端-中台-后端这种经典的网络布局。其中前端部分负责接收终端的请求再进行转发；中台部分融合企业内部若干个公共服务组件，如身份验证、订阅消息服务、数据缓存服务等基础能力，由企业内部专门团队进行维护；后端部分则是基础的数据存储、业务计算，由各个业务线单独进行维护，可以提供微服务接口供其他业务方进行调用。从性能层面来看，由于承接各产业的海量请求，因此要求服务集群架构尽可能满足高可用、高可靠的要求。为了满足后续请求接入和升级的需要，要求服务架构满足可伸缩、可扩展等特性。通过组建大规模集群的方式，整个集群作为一个整体对外提供服务。平台监控系统的 agent 进程会自动检测各服务器状态。若单台服务器发生故障，监控系统会检测状态，转移发送给故障服务器的任务并尝试诊断并修复故障服务器。待故障服务器恢复上报正常状态后，该服务器重新加入集群中并对外提供服务。由此可见，大规模集群的组织方式，可以规避单台服务器出现故障产生的影响，也不影响集群对外的服务质量。同时，平台采用异地备份的方式，组建多套大规模集群。各大规模集群之间采用数据互为备份的策略。这样可以最大限度避免单个集群中心因发生不可抗力而造成数据丢失问题。3 用户模块 本平台主要面向两类用户，一类是终端企业用户，一类是普通用户3。终端企业用户作为企业的代表，需要在平台中注册企业的信息和设备标识，以及定义该设备所能执行的指令。普通用户需要先注册统一身份认证获得个人用户 id。在企业用户注册相关设备后，通过指定的注册接口提交本人的身份 id，和对应的设备 id 进行绑定。绑定后的设备可以进行数据的交换和联动。企业用户和普通用户的用例见图 2。图 2 平台功能用例图 企业用户的功能是录入企业信息并维护该企业下的设备列表。企业、企业用户和设备三者是一个闭环集合，设备必须从属于某个企业，而企业用户作为管理者，具备维护设备信息的权限。普通用户在平台注册身份信息后，会得到一个身份 id，然后就可以通过扫描二维码或者输入设备mac 地址的方式，和身份 id 一起，绑定该设备。绑定后的设备可以供普通用户进行调用。用户根据企业用户录入的设备指令，对指令进行重新编排，以此定义场景，实现场景内各设备之间的联动。这样设计的好处是把企业信息、企业设备和用户三者解耦。企业信息表中存有企业相关的信息，方便企业管理员更新数据，也允许后续企业的入驻登记。注册设备表记录的是平台内所有的设备类2023 年 福 建 电 脑 49 型，重点记录设备的标识 id、类型以及允许的操作。不同的设备对应不同的操作。例如电视设备对应的操作是打开、关闭；台灯设备对应的操作不仅仅是打开和关闭，还有设定色温和亮度等。部分设备的操作可能重合，部分设备可能有独有的操作。平台为每一类操作都定义了唯一的标识符，便于管理接入设备的操作种类。4 数据库设计 考虑到不同标准、不同类型的数据请求，要求平台的数据模型具备语义丰富、结构灵活、可扩展性以及向下兼容等特点。从数据库设计层面来看，各数据实体间要尽量解耦，便于后期的升级维护4。为了达成这些目标，数据库的设计首先要考虑系统中涉及的数据实体。由用户模块可知，最主要的数据实体可归结为两类：一类是用户，包括企业用户和普通用户，两者之间类型不同，被赋予的操作权限也不同。另一类是终端设备，由企业用户录入，由普通用户绑定后调用。具体数据实体关系见图 3。图 3 平台数据库 ER 图 围绕用户和设备两大实体，可以拓展出企业信息表、注册设备表、设备指令表、设备绑定表、用户注册表以及用户定义场景联动表。其中企业信息表用于企业的入驻，方便平台审查企业的资质。其主要字段包括平台分配给企业的唯一id、企业名称、企业联系方式、企业注册的管理员 id、企业注册地址、注册时间等。注册设备表示企业用户录入的本企业出品的设备信息，包括平台分配给每一个门类设备的唯一标识 id、设备类型、所属企业 id、支持的 action 操作、action 操作对应的接口、管理员 id以及更新时间。设备唯一标识 id 的作用是区别该企业的其他产品以及其他企业的产品。例如某家企业出品的一款智能台灯属于一个门类的设备，拥有全平台唯一的标识。其中 action 操作对应设备指定表中定义的指令集。设备类型主要用于区分设备所能支持的操作。通常一种类型的设备对于一系列的操作指令。例如普通台灯类型对应打开和关闭两类指令。而智能台灯类型对应打开、关闭、调节色温亮度等指令。一个设备，如果确定了一种类型，也就能知晓其所能承载的操作指令范围。Action 操作对应的接口字段是设备生厂商在设计制造设备时在设备内部预留的一个回调请求接口。平台或者服务运营商可以通过 HTTP 或其他协议的请求调用该接口，即可触发该设备的相关功能。这些接口需要设备厂家的运营管理人员预先录入平台。由于后续接口的拓展和服务的升级，需要跟踪设备信息的版本更新，因此注册设备表需要记录设备信息更新的时间和录入人员 ID。指令表是定义平台中设备能支持的指令集，包括常见的打开操作、关闭操作等。同时也规定了平台所能支持的所有指令范围，避免出现不合规、不合法的终端操作影响用户的使用体验和信息安全。指令表通常包括指令标识 id、指令的中文名称、指令类别和指令操作的中文说明。其中指令标识 id 是平台赋予的唯一标识。指定类别根据操作的效果可以分为用户主动发起的操作(如打开/关闭操作)和终端设备自发的操作(如定时/联动操作)。用户注册表记录的是用户统一身份验证的信息，包括用户 id、用户登录的密钥、昵称、联系方式等。其中用户登录的密钥 SK 是非对称加密的设计存储于数据库中。用户在登录验证过程遵循AK/SK 模型，具体在安全模型章节中阐述。设备绑定表记录的是用户绑定设备的信息。用户在正式使用设备联动功能之前，需要对设备信息进行绑定。设备绑定表中存储的字段有绑定后平台分配的唯一标识 id、所属用户 id、设备在企业目录中登记的标识码，该设备所能支持的指令码以及用户绑定设备的时间。用户绑定的操作，其实质就是在云端数据库中存入记录，以确定该设备的归属和权限。最后场景联动表记录的是用户在绑定设备后自定义的设备之间联动的逻辑关系。例如回家场景中，用户可以通过平台提供的 APP 定义一个逻辑表达式，50 王威：事件驱动模式下物联网数据交换平台的研究 第 7 期 晚上 18 时到次日 6 时，家中智能门锁打开后后自动开启智能台灯。这个表达式有两个主体。一个是门锁设备，前置操作是打开；另一个主体是台灯，后置操作是打开台灯。而场景执行的时间前提是晚上 18 时到次日 6 日。app 会自动将这条描述语句翻译为设备联动的表达式，并采用 JSON 格式存储于场景联动表中。等到事件触发，门锁设备上报打开的操作记录，则平台会根据用户定义的表达式，首先判断触发的时间是否在场景定义的范围中。如果满足触发的时间范围，则平台会自动调用台灯设备预留的接口，向台灯设备下发打开执行，完成两个终端设备之间的联动。从技术实现层面来看，数据的存储可以采用面向列的 HBase 分布式数据库。一方面，HBase 数据库的目标是存储并处理大型的数据，可以在廉价的服务器上构建超大规模的存储集群并支持大规模的访问请求。另一方面，平台的数据并不广泛涉及数据的事务，因此只在诸如用户信息、设备信息等访问修改不频繁且要求事务性的场景应用关系型数据库。其他诸如场景联动表等需要实时读写实时触发的数据均可以采用 HBase 搭配 Redis 缓存服务的方式，提升整个联动平台的响应速率。5 数据传输模型 如前面所述，终端设备是通过发送请求报文的方式和云端处理集群进行交互。而请求报文中最重要的部分就是承载业务逻辑的数据模型，即报文正文。在业务前期，由于业务和接入设备数量的限制，数据模型往往设计得比较单一，就足以应付业务的需求。但是随着后期业务的拓展和设备类型的增加，单一结构的数据模型逐渐承载不了业务需要的数据字段。这时，一个灵活可扩展并且向前兼容的数据模型就显得至关重要。例如智能台灯支持的操作指令有打开、关闭、设置色温。这其中的指令可以分为两大类。一类指令是不需要用户上报其他参数的，如台灯的打开和关闭，只要用户上报用户 id和设备 id 就能完成操作。另外一类指令是需要用户的终端设备上报额外参数，如设置台灯的色温这个指令，上报的请求除了要携带用户的身份 id、设备标识符、设备 id 外，还要包含色温。这就要求请求报文的数据模型尽可能做到可扩展和向下兼容。可扩展具体体现在可以很方便地扩充字段、删减字段或更改字段。因为后续设备固件的升级，终端设备所能承载的业务也会升级，接口中原有的字段可能满足不了最新业务的需求，所以需要报文承载的数据结构具备可扩展能力。而向前兼容性主要体现在接口升级后，互联网中会有多套接口的数据模型上报。这其中升级后的设备会上报新版本的数据模型，而没有升级过固件的旧设备会上报旧的数据模型。服务的提供商不能因为接口的升级就强制用户升级固件才能使用，所以服务提供商需要兼容两套乃至多套版本的数据模型。这需要服务商的后端处理模型足够灵活，能自动识别接口中的版本标识并进行相应处理。综上所述，平台采用 JSON（JavaScript Object Notation，JS 对象简谱）格式作为数据模型的载体。JSON 是一种轻量级的数据交换格式。它是基于 ECMAScript（European Computer Manufacturers Association，欧洲计算机协会制定的javascript 规范）的一个子集，采用与具体编程语言无关的文本格式来存储和表示数据。JSON 格式的特点是简洁和清晰的层次结构，便于用户阅读，也易于编写。可以说 JSON 是一个序列化的对象或数组，由于其简洁清晰的层次结构，易于字段扩展和解析，适合作为复杂结构数据的一种格式载体应用到数据传输网络中。目前主流的互联网应用，大部分都基于 JSON 格式的数据格式来开发。6 安全模型 作为一款数据为主动的互联网应用，本平台与外部设备的数据交互均通过互联网传输。而互联网作为一种新型的传播介质，数据安全一直是人们关心的话题。平台作为数据的保存者和监管方，对数据安全负有完全的责任。为保障接入厂商的数据安全以及用户消费者的信息安全，平台需要验证每次用户或设备的数据请求的合法性和正确性5。传统的身份认证是采用 Token Auth 的方法，即客户端输入用户名和密码，传输到云端的认证服务器进行验证，同时返回授权的 token 给客户端。客户端保存 token 作为认证令牌，后续和云端服务器的交互都需要携带 token，云端服务器会根据 token来判断请求是否合法。但是这种认证方式具有天然的缺陷，如密码泄露、伪造 token 等，并不满足平台级的安全需求。本平台采用的认证模型是 AK/SK 模型。由于AK/SK 授权方式的基础原理是基于对称加密，因此能弥补 token 认证方式的权限。AK/SK 认证由2023 年 福 建 电 脑 51 AK(Access Key，终端接入标识符)和 SK(Secret Access Key，密钥接入键)组成。其认证的一般过程是：客户端在注册后得到由云端服务器生成的一对AK和SK并保存在本地。AK用于标识唯一的设备，SK 用于对称加密通信的密钥。客户端在构建 HTTP请求时，使用 SK 加密运算请求报文的 request body得到签名 signature，然后将 AK 和签名 signature 一同发送给云端服务器。云端服务器根据请求中的AK，对比本地数据库找到对应的 SK，然后用同样的算法将请求中的request body和SK一起计算得到signature。最后对比客户端发送的 signature 和本地计算得到的signature是否一致。如果两个签名一致，证明该请求合法，随后转发到内部服务器进行处理。如果签名不一致，则对该请求进行拦截并加入黑名单。7 应用模型 为构建一个功能齐全、性能稳定的数据交换服务，按照软件开发的单一职责原则，本平台对不同的业务进行了划分。在内部网络中为每个单一功能搭建独立服务器或服务器集群，采用微服务的方式独立开发和部署6。由各个微服务组成一个业务整体，统一向外部提供服务。应用部署架构参见图 4。图 4 应用架构图 用户首先通过 APP 发送管理请求进行注册和绑定设备。用户管理的请求会发送到 RuleAdmin 服务集群中进行集中处理。场景策略的数据由RuleAdmin 转发给 RuleManager，由 RuleManager对用户发送的场景策略数据进行验证和解析，并生成 JSON 格式的触发策略存储于数据库中。用户也可以通过 APP 查看设备列表和自定义的场景。用户注册信息并绑定设备后，就可以开启设备联动服务。设备联动服务可分为两类，一类是定时触发服务，如用户定义每晚 8 点开启空调。对于定时服务，在用户通过 APP 提交场景策略数据时，由RuleAdmin 调用 CronTrigger 的接口创建定时任务。CronTrigger 服务内部设置有定时机制，每天每时每分会扫描策略库中符合时间条件需要触发的定时任务，然后调用 RuleManager 获得详细的触发策略，按照要求触发。另外一类联动服务是设备发送数据请求触发，如“打开家门就开灯”这个场景。门锁设备在打开后会发送一个数据请求到平台的数据网关，由网关把数据请求路由转发到 EventTrigger服务器。EventTrigger 负责解析设备数据，提取设备关键信息，并调用 RuleManager 接口获取当前设备需要触发的场景，按照要求依次调用 EventDriver接口触发消息。EventDriver 是专门用于对接设备接口的服务。它的职责是接收触发信号，并向设备发送请求触发对应操作。8 结束语 物联网海量数据对平台的自动化、处理性能和稳定性提出了更高的要求。为了构建高效快速的数据平台，本文研究了数据平台中可能遇到的基础问题，包括通信架构中的性能瓶颈和数据备份问题、数据接口的兼容性问题、用户模块设计中的角色划分问题、数据传输中的安全问题以及业务划分和应用部署问题等，并提出相应的解决方案。但是也要关注到，随着业务的扩大以及用户量的攀升，平台需要向自动化、智能化的方向继续发展，还需要扩充一系列自动化相关的能力，如应用的持续集成和自动化部署、平台资源监控和自主调配，业务日志的分布式追踪等。参 考 文 献 1 朱锐,王宏志,崔双双,张恺欣,燕钰.面向元宇宙的云边端协同大数据管理.大数据,2023,9(01):63-77 2 王海涛,周天启,邹云.某系统基于云环境的网络架构设计与实现.数字技术与应用,2023,41(02):168-170 3 张军,黄毅松.面向云服务的用户体验设计研究及实践.包装工程,2017,38(10):31-36 4 徐 立 艳.计 算 机 软 件 数 据 库 设 计 的 原 则 及 问 题 研 究.软 件,2023,44(01):141-143 5 阮浩德,马力.面向云平台下构建计算机网络安全和防范机制.网络安全技术与应用,2020(02):70-71 6 罗欢,陈仁泽,刘明伟,徐律冠.基于 DevOps 的云平台微服务架构可靠性研究.环境技术,2020,38(04):106-111