SiteWhere是一个工业级的物联网开源应用支持平台

SiteWhere是一个工业级的、开源的物联网应用支持平台，它促进了大规模物联网设备数据的摄取、存储、处理和集成。该平台利用了运行在cutting-edge技术（如Kubernetes、Istio和Kafka）之上的微服务架构，以便有效地扩展到大型物联网项目的预期负载。

SiteWhere采用了运行在Kubernetes上的分布式架构，并提供了highly-available数据库和MQTT代理等基础设施以及微服务，以促进物联网项目开发的各个方面。该平台采用框架方法构建，使用明确定义的API，以便随着物联网生态系统的发展，新技术可以轻松集成。

部署和协调

SiteWhere由Java-based微服务组成，这些服务被构建为Docker映像并部署到Kubernetes进行编排。为了简化安装和配置，Helm用于为各种部署场景提供标准模板。Helm图表提供了运行完整站点部署所需的微服务和依赖关系。基础设施组件包括Apache Zookeeper和Kafka等技术，高可用性数据库，如MongoDB、InfluxDB和Cassandra，以及其他支持技术，如MQTT代理。

Microservices

SiteWhere不是使用单一方法，而是基于许多作为分布式系统运行的微服务。每个微服务都是一个完全self-contained实体，它有自己的配置模式、内部组件、数据持久性以及与事件处理管道的交互。微服务构建在一个定制的微服务框架之上，并作为独立的Spring引导进程运行，每个进程都包含在自己的Docker映像中。

关注点分离

将系统逻辑分离为微服务，可以更清楚地定义系统各个区域之间的交互。它还允许管道的某些部分正常关闭或出现故障，而不会阻止系统的其他部分正常工作。跨越许多微服务的事件处理管道由Kafka缓冲，因此数据处理在保持高吞吐量的同时具有强大的交付保证。

Scale What You Need. Leave Out What You Don't

微服务体系结构允许系统的各个功能区域独立缩放或完全忽略。在REST处理往往成为瓶颈的用例中，可以并发运行多个REST微服务来处理负载。相反，可以省略诸如可能不需要的存在管理之类的服务，以便可以将处理能力专用于系统的其他方面。

Instance Management

SiteWhere支持实例的概念，它允许分布式系统作为一个内聚单元，在全局级别处理某些方面。一个站点的所有微服务实例必须运行在同一个Kubernetes基础架构上，尽管系统可能分布在数十台或数百台机器上以分配处理负载。

Istio服务网

SiteWhere利用Istio为系统微服务提供服务网格，允许动态扩展平台，同时还提供了对数据路由的大量控制。Istio允许使用诸如金丝雀测试和故障注入等现代方法来提供一个更健壮的fault-tolerant系统。它还允许详细监视和跟踪流经组件的数据。

使用Apache ZooKeeper进行集中配置管理

配置存储在Apache ZooKeeper中的站点，以允许对配置管理采用可扩展的外部化方法。ZooKeeper包含一个层次结构，它表示一个或多个站点的配置，其中实例和用于实现它们的所有微服务。复制配置以获得高可用性。

每个微服务都与ZooKeeper直接连接，并在运行时使用层次结构确定其配置。微服务监听配置数据的更改，并对更新做出动态响应。microservice中没有本地存储配置，这可以防止在系统配置更新时保持服务同步的问题。

使用Rook.io的分布式存储

由于许多系统组件（如Zookeeper、Kafka和各种数据库）都需要访问持久性存储，因此SiteWhere在Kubernetes中使用Rook.io来提供分布式、复制的块存储，该存储在硬件故障时仍然具有良好的性能特性。随着存储和吞吐量需求的增加，新的存储设备可以动态地使用。Rook.io使用的底层Ceph架构可以处理数据的外字节，同时允许数据在节点、机架甚至数据中心级别恢复故障。

High Performance Data Processing Pipeline

SiteWhere中的事件处理管道使用Apache Kafka提供一个弹性的high-performance机制，用于逐步处理设备事件数据。微服务可以插入事件处理管道中的关键点，从well-known入站主题读取数据，处理数据，然后将数据发送到well-known出站主题。对管道中任何一点的数据感兴趣的外部实体可以充当站点的使用者，在该站点中，当数据在系统中移动时，主题将使用这些数据。

Fully Asynchronous Pipeline Processing

SiteWhere事件处理管道利用Kafka的消息传递结构来允许设备事件数据异步处理。如果微服务关闭，并且没有其他副本可用于处理负载。数据将排队，直到副本开始并再次开始处理。这是防止数据丢失的保证，因为数据总是由Kafka的high-performance存储支持。microservices利用Kafka的消费者群体概念在多个消费者之间分配负载，并相应地扩展处理。

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

API Connectivity Between Microservices

虽然在Kafka主题上，设备事件数据通常以管道形式从微服务流向微服务，但也有一些API操作需要在微服务之间实时发生。例如，设备管理和事件管理功能包含在它们自己的微服务中，但系统的许多其他组件都需要这些功能。许多微服务提供api，其他微服务可以访问这些api来支持存储持久数据或启动microservice-specific服务等方面。

使用gRPC提高性能

SiteWhere并不是仅仅使用基于http1.x的REST服务，后者往往会有很大的连接开销，而是使用gRPC在需要相互通信的微服务之间建立long-lived连接。由于gRPC使用持久的HTTP2连接，交互的开销大大减少，允许在不显著降低性能的情况下进行解耦。Istio还允许gRPC连接在微服务的多个副本之间多路复用，以扩展处理并提供冗余。

数据模型以Google Protocol Buffers格式捕获的整个站点，以便可以在GRPC服务中使用。所有API也直接作为gRPC服务公开的站点，允许high-performance，low-latency访问所有API函数。restapi仍然可以通过Web/REST微服务（充当API网关）提供，但是它们使用下面的grpcapi来提供访问数据的一致方法。

Multitenancy

SiteWhere是为large-scale物联网项目而设计的，它可能涉及多个共享单个SiteWhere实例的系统租户。与大多数物联网平台相比，站点的一个关键区别在于，每个租户独立于其他租户运行。默认情况下，租户不共享数据库资源或管道处理，并且具有完全独立的配置生命周期。通过这种方法，每个租户可以使用自己的数据库技术、外部集成和其他配置选项。租户的部分处理管道可以重新配置/重新启动，而不会对其他租户造成中断。

Data Privacy

SiteWhere处理多租户的方式的一个重要后果是，每个租户的数据与其他租户的数据分离。大多数提供多租户的平台将所有租户的数据存储在共享表中，仅通过租户id进行区分。共享方法可能导致一个租户的数据损坏另一个租户，这在许多物联网部署中是不可接受的风险。此外，每个租户都有自己的处理管道，因此in-flight数据也永远不是co-mingled。

在内存和处理资源方面，为租户提供专用资源可能会非常昂贵，因此SiteWhere还提供了每个租户内部的客户概念。客户允许在租户内区分数据，但不需要单独的专用数据库和管道。在可以接受共置数据的情况下，租户可以拥有任意数量的客户，这些客户共享同一个数据库和处理管道。在安全性和可伸缩性方面，这两个方面都是好的。

来源 https://www.5axxw.com/wiki/content/2uu25o