详情
架构物联网:一种新的解决方案
作者:本站采编
时间:2016-02-15 09:36:09
捷克的Linux大会“OpenAlt”上提出了这样的观点:物联网(IoT)是基于微服务的。我们打算覆盖所有实现层级,将难题放到一起。
关键词: 物联网

  本文将通过对几个项目的介绍,让读者完全了解并掌握如何架构物联网。几周前我们在捷克的Linux大会“OpenAlt”上提出了这样的观点:物联网(IoT)是基于微服务的。我们打算覆盖所有实现层级,将难题放到一起。也就是说,使用所有从边缘设备中所收集的数据,经过数据集成与分析之后,得出完整的物联网解决方案。

  物联网架构

  下面的架构图是对我们观点的高度概括。其中,很容易找到与物联网网关连接的所谓边缘设备。

  一般情况下,网关会将设备所传输的任何硬件与供应商特定协议转化为一致而更易集成的东西,方便在集成时使用,类似TCP和任何顶端的标准化信息协议之类的。

  一直只有一个网关吗?这个网关只使用硬件特定协议吗?两者的答案都是否定的。在不同位置上可能会有各种类型的多个网关,如果边缘设备足够智能的话,其中一些甚至使用的是TCP协议。更重要的是负责数据聚合的网关,其逻辑功能可能就是简单的路由器与消息转换器。

  再来看集成组件,也是核心业务逻辑所在之处。这个架构类似于优秀的经典SOA(服务导向架构)。这里可以/应该使用SOA原则。

  稍后,集成组件可以与复杂的系统(如JBoss业务流程管理系统)进行通讯,并进行决策与高等数据分析。

  那么网关与集成组件之间具体有什么不同呢?我们在其原理中提过这种区别。不过在具体的实现上,是否有什么不同呢?

  令人惊讶的是,并没有区别。使用我们的办法,通过Bulldog、Silverspoon和SilverWare所提供的微服务实现工具,两者实现的基础结构模块完全相同。

  想要区分特定微服务的含义,有多个维度的抽象。其中包括数据协议(低级硬件协议、简单的信息传递、TCP等),服务层(也就是来自优秀经典SOA架构)以及特定服务所需的计算能力。

  正是如此:微服务的目的及其规范是在系统创建时由开发者设定的。可以说微服务就像是干细胞。微服务与干细胞一样,是根据所使用的地方以及用法来发挥具体功用的。

  概念

  我们为什么会认为自己的解决方案“正确”呢?

  首先,我们希望覆盖所有级别的抽象。我们有物联网架构所有层面的组件与开发工具。将传感器与Arduino相连很有趣,但下一步是什么呢?如何整合才能存储大数据并执行分析呢?

  其次,我们是开放的,依靠现有标准,只是协助集成现有的解决方案。因此,无需学习全新的东西,只要理解单个结构模块,任何人都可以马上动手去开发复杂的系统。同时,我们尝试避免供应商的封锁。所有的相关组件、系统、设备等任何东西都可以很容易地替换。

  最后,我们希望达到最简,可以用简单、容易理解的服务来构建复杂的系统。这些服务可以在基于ARM的设备上与云端小型虚拟机上运行。启动更多服务实例可以让性能更强,因此扩展也很简单。

  实现

  我们的解决方案包括三个要素。

  使用Bulldog库来控制以及与边缘设备通讯。这个库提供了一定程度的抽象,允许开发者修改边缘设备与ARM board而无需重构代码。

  为了将代码转化成有意义的协议,我们使用了Silverspoon——这是一套Apache Camel组件。这些提供了设备特定协议与外部世界间的网关。我们认为,鉴于其具有路由功能、可扩展性、集成性及发送消息的能力,Apache Camel非常适合扮演物联网网关。因此我们在Apache Camel中加入了Bulldog组件。

  为了发展网关、集成与业务逻辑,我们创建了SilverWare——这是一个极简的微服务平台。微服务可以按照Apache Camel路由、CDI组件、信息队列/主题、Vert.x还有很多其他的(其中一些还没有实现)来进行创建。因此在你的公司里,这些结构模块的任何一个都可能已经存在了,而且能够很容易地转换或直接按照微服务部署。让我们受益的还有:简单的Maven项目依赖、一些容易理解的注释、小型可执行jar文件、部署以创建Docker镜像的能力。

  为了方便分析,我们推荐用NoSQL或时序数据库(比如InfluxDB)现代化分析工具(比如ElasticSearch、Grafana、Kibana)来进行集成。

  此外,一个完整的系统肯定应当包含以业务流程与规则的形式存在的高级业务逻辑。为此,用JBoss业务流程管理系统来集成也是可行的。

  应用架构如下图:

上一篇:消费级产品RFID标签编码的正确方式 下一篇:Nedap推出高端超高频RFID解决方案用于车辆识别