在这片文章中，主要讨论在Kaa架构和逻辑设计下的功能性概念。

Kaa IoT平台由Kaa server，Kaa扩展和端点SDKs组成。

• kaa服务器是平台的后端部分。他被用于去管理租户，应用，用户和设备。Kaa服务器暴露了集成接口并且提供了管理能力。
• kaa扩展是独立的软件模块，他提升了平台的功能性。
• 端点SDK是为多种多样的Kaa平台特征提供客户端的API并且处理通信，数据编集，持久性等的一个库。Kaa SDK被设计区促进客户端应用的创造性来运行在各种各样连接的设备上。然而，不使用Kaa端点SDK的客户端应用也是有可能的。以不同的编程语言有多种不同的端点SDK。

Kaa集群

Kaa服务器节点使用Apache的ZooKeeper来与服务合作。互相连接的节点和特别的Kaa实例组成了一个Kaa集群。Kaa集群需要Nosql和SQL数据库实例来保存端点数据和原语。

位于集群中的Kaa节点运行了Control,Operation和Bootstrap服务的组合。

Control服务

Kaa控制服务管理所有的系统数据，处理来自Web UI和外部集成系统的API请求，并且向Operaion服务发送通知。控制服务通过持续的接收来自ZooKeeper的信息来维持一个最新的可操作服务列表。除此之外，控制服务运行嵌入的使用控制服务API的管理web UI组件，来想用户提供方便的基于web的接口来管理租户，用户账户，应用数据等。

为了支持高可用性，一个Kaa集群至少有两个节点是使能控制服务的。在高可用性模式中，其中的一个控制服务是活动的，另外一个是待机模式。一旦活动的控制服务失效了，ZooKeeper会唤醒其中一个待机控制服务并且将它升级成为活动控制服务。

操作服务

操作服务最基础的角色就是与当前多个端点进行通信。操作服务处理端点请求并且把数据发送给他们。

为了横向扩展，你可以设置一个Kaa集群的每一个几点都是操作服务使能的。在这个情况下，所有的操作服务的实例当前都是在运行的。如果一个操作服务意外终止了，之前连接端点自动转换到其他可用的操作服务中去。Kaa服务器在运行时可以重新负载均衡，所以在集群中路由端点到低负载的节点中的效率是非常高的。

引导程序服务

Kaa Bootstrap服务发送关于操作服务连接参数的信息到端点中。取决于配置的协议栈，连接参数可能包括IP地址，TCP端口，安全证书等。Kaa SDK包含一个在集群中预生成的Bootstrao可用列表，他被用于生成SDK库。在这个列表中的端点查询Bootstrap服务为当前可用操作服务取回连接。Bootstrap服务通过和ZooKeeper服务合作来维持他们的可用操作服务的列表。

第三方组件

Zookeeper

Apache ZooKeeper使能在Kaa集群节点之间高可靠性分布式合作。每一个Kaa节点持续的推送关于连接参数，使能的服务和回应的服务负载的信息，其他Kaa节点使用这个信息去获取他们兄弟的列表并且与他们进行通信。活动的控制服务在SDK生成期间使用关于可用Bootstrap服务和他们连接参数的信息。

SQL database

SQL数据库实例被用于存储租户，应用，端点组合其他原语，他们不随着端点的增加而增长。

一个Kaa集群的高可用性通过在HA模式下部署SQL数据库被实现了。Kaa现在官方支持MariaDB和PostgreSQL最为嵌入的SQL数据库。

NoSQL database

NoSql数据库实例被用于存储端点关系数据，这些数据随着端点的增加成线性增长。

NoSQL数据库节点可以和Kaa节点一样放在相同的为或虚拟机上，并且为了这个系统的高可用性，他应该在HA模式下被部署。Kaa官方支持Apache Cassandra和MongoDB作为嵌入的NoSQL数据库。

Internode communications

Kaa服务使用Apache Thirft来进行进程和节点之间的通信。每一个服务使用ZooKeeper包含关于他的兄弟的元数据。这个元数据包含关于Thrift主机和端口的信息。

高可用性和伸缩性

Kaa集群可以横向和线性扩展；在Kaa集群架构中没有单一故障点。Kaa操作和Bootstrap服务是独一无二的并且工作在主动-主动的HA模式下。其中一个集群节点包含一个活动的控制服务。一旦节点发生故障，位于另外一个节点的待机控制服务被提升变成活动的。Kaa集群的高可用性也依赖于SQL和NoSQL数据库的HA。

主动负载均衡

Kaa SDK在初始化期间伪随机选择Bootstrap和操作服务实例。依赖于对Kaa集群的请求发起者两个负载均衡的方法被使用：Kaa端点SDK或者是REST API。

端点SDK请求

Kaa SDK在初始化过程中伪随机选择Bootstrap和操作服务。然而，如果集群负载太重，端点的随机分发可能是效率不高的。当一个新的节点加入集群的时候，他在更新拓扑的时候，为了更好的性能，被要求重新均衡负载。

Kaa服务使用主动负载均衡方法来构建一些端点来重新连接一个不同的操作服务，因此平衡了节点之间的负载。使用算法来使服务器加载数据（连接的端点的数量，加载平均值等），该算法被kaa节点公布作为输入，并且定期的重新计算每一个节点的权重值。然后，超负荷的节点被要求重定向到一个不同的节点，一些端点被要求连接。

一个相似的方法可以被采用，通过预定服务的方式来加载进一个节点中，或者是在物理或虚拟机上逐渐的移植集群。为了实现，你需要通过实现重新均衡负载借口来设置一个自定义的负载均衡策略。

REST API请求

对于REST API负载均衡，你可以使用现成的HTTP负载均衡解决方案，例如Nginx，AWS Elastic负载均衡，Google Cloud LB。

Kaa实例

Kaa实例是Kaa平台一个特殊的安装，特也可以是单节点的，也可以是集群部署。

在Kaa中的一个应用定义了一系列数据模型，端点和Kaa服务之间的通信的类型和运行规则。Kaa应用对特定的平台，操作系统或客户端软件实现是不具体的。例如，针对一个压力传感器的两个固件实现在Arduino和STM32平台上是不一样的，但是在kaa中可以被看做是相同的应用，只要他们报告相同结构的遥测数据。

Kaa平台是多租户的。一个单一的Kaa实例可以支持多个独立的商务实体。应用属于租户，但是端点注册在应用中。（看下图）

一个端点（EP）是一个抽象，他代表着在一个Kaa部署中一个分离的管理实体。通俗的将，一个端点是在一个Kaa实例中的特别注册的Kaa客户端。基于用户实例，不同层的物理实例被认为是端点。在一个个人设置中，一个位于船队追踪应用中的单一的空气质量传感器，一个火车（尽管写到这多个报告数据的传感器）可能只是一个实体被认为是一个端点。

为了通过不同的属性区分端点，而不是使用一个ID，Kaa使用端点配置文件。

端点配置文件是一个自定义的结构化的数据集合，他描述了位于一个应用中的一个特定端点的特征。每一个端点配置文件包括客户端，服务端和系统部分。客户端部分的初始化值是被客户端开发者使用数据模式指定的。接着，客户端端点配置文件在一个新的端点被注册的时候生成。端点配置文件的服务器和系统部分数据是由Kaa服务管理的。

配置文件数据被用于将端点放到端点组中 - 由配置文件适配器定义的独立的管理实体。配置文件符合配置文件适配器的端点被自动变成这个组的成员。一个端点可以同时位于无限个组中。

端点也与拥有者相关。基于应用，应有着可以是人，组或者是组织。