在這片文章中，主要討論在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服務管理的。
配置文件數據被用於將端點放到端點組中 - 由配置文件適配器定義的獨立的管理實體。配置文件符合配置文件適配器的端點被自動變成這個組的成員。一個端點可以同時位於無限個組中。
端點也與擁有者相關。基於應用，應有着可以是人，組或者是組織。