sitewhere 2.0

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/orchidofocean/article/details/79967512

        SiteWhere是一个具有工业强度的开源IoT应用程序支持平台,可以大规模地帮助获取,存储,处理和集成设备数据。该平台基于现代微服务体系结构,并且从可靠,高吞吐量,低延迟处理和动态可扩展性开始设计。SiteWhere充分利用Apache Kafka和Docker等经过验证的技术,以便有效扩展到大型IoT项目预期的负载。SiteWhere不采用单一体系结构,而是采用完全分布式的方法,使用微服务来允许在组件级别进行扩展,从而使系统可以根据客户使用情况进行量身定制。SiteWhere微服务通过使用明确定义的API的框架方法构建,因此随着物联网生态系统的发展,新技术可以轻松整合。本文档的其余部分涵盖了SiteWhere所使用的核心技术以及它们如何组合在一起来构建综合系统。



http://sitewhere.io/docs/en/2.0.EA3/platform/index.html

微服务

SiteWhere 2.0引入了与1.x平台中使用的完全不同的架构方法。虽然核心API大部分没有改变,但系统实现已经从单一的方法转变为基于微服务的方法。这种方法比以前的架构提供了许多优点。

关注点分离

每个微服务都是一个完全独立的实体,具有自己独特的配置模式,内部组件,数据持久性以及与事件处理管道的交互。SiteWhere微服务是建立在自定义微服务框架之上的,并作为单独的Spring Boot进程运行 ,每个进程都包含在它自己的Docker镜像中。

将系统逻辑分成微服务允许更清楚地定义系统各个区域之间的交互。这种转变已经导致了一个更易理解和可维护的系统,并且随着更多功能的增加,应该继续支付股息。

缩放你所需要的。抛开你没有的东西

微服务体系结构允许系统的各个功能区域单独调整或完全省略。在REST处理往往是瓶颈的使用情况下,可以同时运行多个REST微服务来处理负载。相反,可能不需要的服务(如存在管理)可以省略,以便将处理能力专用于系统的其他方面。

实例管理

2.0体系结构引入了SiteWhere 实例的概念,该实例允许分布式系统充当具有全球层面的一些方面的内聚单元。所有用于单个SiteWhere实例的微服务必须运行在同一个Docker基础架构上,尽管该系统可以使用诸如Docker SwarmKubernetes等技术分布在数十台或数百台机器上 

使用Apache ZooKeeper进行配置管理

SiteWhere 2.0将系统配置从文件系统移动到 Apache ZooKeeper中,以实现配置管理的集中协调方法。ZooKeeper包含一个分层结构,它表示SiteWhere实例的配置以及用于实现它的所有微服务。

每个微服务都直接连接到ZooKeeper,并使用层次结构来确定信息,例如它所属的实例以及它应该使用的配置。微服务监听配置数据的变化并动态响应更新。在微服务中本地不存储任何配置,这可以防止在系统配置更新时保持服务同步的问题。

使用Apache Kafka进行事件处理

SiteWhere 2.0中的事件处理管道已完全重新设计,并使用 Apache Kafka为逐步处理设备事件数据提供弹性的高性能机制。每个微服务都插入事件处理管道中的关键点,从众所周知的入站主题中读取数据,处理数据,然后将数据发送到众所周知的出站主题。对管道中任何点的数据感兴趣的外部实体可以充当SiteWhere主题的使用者,以便在数据在系统中移动时使用它们。

在SiteWhere 1.x体系结构中,用于出站处理的管道使用阻塞方法,这意味着任何单个出站处理器都可以阻塞出站管道。在SiteWhere 2.0中,每个出站连接器都是真正的Kafka用户,在事件流中有自己的偏移量标记。这种机制允许出站处理器按照自己的进度处理数据,而不会减慢其他处理器的速度。

使用卡夫卡还有其他优势,可以被SiteWhere利用。由于分布式日志的所有数据都存储在磁盘上,因此可以根据先前收集的数据“重放”事件流。这对调试处理逻辑或负载测试系统等方面非常有用。

与GRPC的微服务间通信

虽然设备事件数据通常在Kafka主题上从微服务到微服务的流水线中流动,但是有些操作需要直接在微服务之间进行。例如,设备管理和事件管理持久性分别包含在单独的微服务中,因此,当新事件进入系统时,入站处理微服务必须连接事件持久性微服务以存储事件。SiteWhere 2.0使用gRPC建立需要彼此通信的微服务之间的长期连接。由于gRPC使用持久的HTTP2连接,交互的开销大大降低,允许解耦而不会造成显着的性能损失。

整个SiteWhere数据模型都以Google Protocol Buffers格式捕获 ,因此可以在GRPC服务中使用它。所有SiteWhere API现在都直接作为gRPC服务公开,允许高性能,低延迟访问以前只能通过REST访问的内容。REST API仍然通过Web / REST微服务提供,但它们使用下面的gRPC API来提供一致的访问数据的方法。

由于服务扩大或缩小时,给定微服务的实例数可能会随时间而变化,因此SiteWhere会自动处理在微服务之间连接/断开gRPC管道的过程。每个出站gRPC客户端均可跨满足请求的服务池进行demulitplexed,从而允许并行处理请求。

分布式多租户

SiteWhere 1.x多租户方法是为每个租户使用单独的“租户引擎”。该引擎支持所有特定于租户的任务,例如数据持久性,事件处理等。由于SiteWhere 2.0已转移到微服务架构,因此多租户模型也已分发。SiteWhere支持两种类型的微服务:全局和多租户。

全球微服务

全球微服务不处理租户特定的任务。这些服务处理各个方面,如实例范围内的用户管理和租户管理,这些并非特定于个别系统租户。支持管理应用程序和REST服务的Web / REST微服务也是一项全球服务,因为为每个租户支持单独的Web容器将非常麻烦并且会破坏现有的SiteWhere 1.x应用程序。还有一个全局实例管理微服务,它监视整个实例的各个方面,并通过Kafka向各个微服务报告更新。

多租户微服务

大多数SiteWhere 2.0服务都是多租户微服务,它将流量委托给进行实际处理的租户引擎。例如,入站处理微服务实际上由许多入站处理租户引擎组成,每个入站处理租户引擎都是单独配置的,可以在不影响其他租户引擎的情况下启动/停止/重新配置。

对租户引擎的新方法改变了SiteWhere事件处理的动态性。现在可以停止单个租户引擎,而无需停止在其他微服务中运行的租户引擎。例如,租户的入站处理可以停止并重新配置,而租户流水线的其余部分则继续处理。由于可以允许新的事件在Kafka中堆积起来,租户引擎可以停止,重新配置并重新启动,然后在没有数据丢失的情况下恢复停止。

参考:https://github.com/sitewhere/sitewhere/blob/master/README.md

阅读更多

没有更多推荐了,返回首页