IoT Kaa平臺學習（二）

在這片文章中，主要討論在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服務管理的。

配置文件數據被用於將端點放到端點組中 - 由配置文件適配器定義的獨立的管理實體。配置文件符合配置文件適配器的端點被自動變成這個組的成員。一個端點能夠同時位於無限個組中。

端點也與擁有者相關。基於應用，應有着能夠是人，組或者是組織。