sitewhere 2.0

    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 Swarm或Kubernetes等技术分布在数十台或数百台机器上 。

使用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

原文链接：https://blog.csdn.net/orchidofocean/article/details/79967512