关注点分离

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

扩展你所需要的。留下你不做的

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

实例管理

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

服务网格与 Istio

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

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

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

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

使用 Rook.io 的分布式存储

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

高性能数据处理管道

SiteWhere 中的事件处理管道使用Apache Kafka 提供一种弹性、高性能的机制来逐步处理设备事件数据。微服务可以插入事件处理管道中的关键点，从知名的入站主题读取数据，处理数据，然后将数据发送到知名的出站主题。对管道中任何一点的数据感兴趣的外部实体都可以充当 SiteWhere 主题的消费者，以便在数据通过系统时使用数据。

全异步流水线处理

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

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

微服务之间的 API 连接

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

使用 gRPC 提升性能

SiteWhere 并没有单独使用基于 HTTP 1.x 的 REST 服务，后者往往具有显着的连接开销，而是使用gRPC在需要相互通信的微服务之间建立长期连接。由于 gRPC 使用持久的 HTTP2 连接，交互的开销大大减少，允许解耦而不会显着降低性能。Istio 还允许 gRPC 连接在微服务的多个副本之间进行多路复用，以扩展处理并提供冗余。

整个 SiteWhere 数据模型已以 Google Protocol Buffers格式捕获，因此可以在 GRPC 服务中使用。所有 SiteWhere API 也直接公开为 gRPC 服务，允许对所有 API 功能进行高性能、低延迟访问。REST API 仍然可以通过 Web/REST 微服务（充当 API 网关）使用，但它们使用下面的 gRPC API 来提供一致的数据访问方法。

多租户

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

数据隐私

SiteWhere 处理多租户的方式的一个重要结果是每个租户的数据都与其他租户的数据分开。大多数为共享表中的所有租户提供多租户存储数据的平台，仅通过租户 ID 进行区分。共享方法开启了一个租户的数据破坏另一个租户的可能性，这在许多物联网部署中是不可接受的风险。此外，每个租户都有自己的处理管道，因此飞行中的数据也永远不会混合在一起。

为租户提供专用资源在内存和处理资源方面可能会很昂贵，因此 SiteWhere 还提供了每个租户内客户的概念。客户允许在租户内区分数据，但没有单独的专用数据库和管道。在可以接受共置数据的情况下，租户可以拥有任意数量的客户，这些客户共享相同的数据库和处理管道。这在安全性和可扩展性方面实现了两全其美。