之前經常聽到國內的物聯網廠商提到賦能倆字，但是一直沒搞明白到底賦了啥能，給誰賦的。最近同袍君正好看了點德州的ClearBlade的資料，好像稍微明白了一點。好東西不敢獨樂樂，這篇文章就給大家介紹物聯網應用項目賦能平臺——ClearBlade物聯網邊緣計算平臺。
1.引子
通常，物聯網網關提供商和物聯網平臺提供商都存在這樣的矛盾：網關和平臺固定的功能無法滿足眾多物聯網應用客戶的多變的需求。例如：
- 客戶A今天買了1000個網關，但是客戶A考慮到傳感器成本和可靠性，要求後期對已經部署到現場的網關能夠支持其他型號的傳感器接入。
- 客戶B他為了降低風險，要求兩家物聯網網關產品都要能接入到客戶B指定的某廠家物聯網平臺上。
- 客戶C規模比較大，集團總部要求所有物聯網項目數據都要接入到集團總部的IT部門的數據倉庫中。
- 客戶D要監控的設備是高價值的非標生產線設備，要採集的數據點、告警規則、監控界面等每個設備有部分是相同的，剩下的一部分是不同的。
- 客戶E是做智慧園區監控的，需要把上傳的數據發送給指定的第三方平臺。一會是MySQL，一會是mongodb，一會又要求是socket，kakfa。
上面這些需求都是普遍、真實存在的。通常每個物聯網客戶都會提出些這樣那樣的定製需求。如果每個客戶都給他們去定製，物聯網網關和物聯網平臺就變成了物聯網項目開發——表面上賣的是硬件產品和平臺軟件，實際上賣的是軟件定製服務。這樣子就很難做大做專做強。用高大上的語言來描述的話，就是物聯網平臺沒有給物聯網應用軟件開發賦能。
這是目前行業內普遍存在的困境。
為什麼會出現這樣的困境呢？——本質上，是因為網關和平臺的控制權在網關和平臺開發商手裡。他們沒有把控制權開( fu)放( neng)給用戶。控制權在網關和平臺開發商手裡，那有需求，用戶沒法改。現場邊緣計算層面的物聯網網關設備的程序都是固定的，無法在雲端隨時修改更新現場網關設備的業務邏輯代碼、數據、配置文件、訪問權限、網關與雲端傳輸的消息格式等。不找你找誰？
例如現場的物聯網網關接的某型號的振動傳感器成本太高，而且快停產了，需要更換傳感器廠商。那就需要更新現場物聯網網關內的傳感器採集程序和配置。傳統方式就是派人去現場更新，這樣成本很高。高級點的，支持遠程升級物聯網網關內的一些程序和配置文件，或者整體來遠程OTA升級整個固件系統。
但是這樣做還是存在問題，為什麼？因為業務邏輯開發過程和這個升級部署過程是分離的。對邊緣計算物聯網網關內的業務邏輯代碼、數據、配置文件、訪問權限、雲端傳輸消息格式，一般網關廠商和雲平臺廠商都是定死的，不允許最終使用者去修改。要改個傳感器協議採集程序，或者改下MQTT傳輸的格式，物聯網應用程序開發者沒法改。
這樣，物聯網應用程序開發者，只能找物聯網網關廠商和物聯網平臺廠商去提需求，讓他們去配合修改。這樣物聯網應用程序開發者有力使不上，物聯網網關廠商和物聯網平臺廠商也不勝其煩，因為會有很多客戶要求他們改這改那。要是不給客戶改，那他們就不會用你的東西；要是改吧，整天跟在後面改也來不及。
那為什麼不把對網關和平臺的控制權放開，把用戶關心的東西都開放出來，對用戶賦能，讓他們可以自己去修改、去配置、去部署呢？為什麼不直接在物聯網平臺上讓最終用戶在Web界面上，把修改現場網關的程序、數據、配置之類的都暴露給用戶呢？
理想情況下，對邊緣計算物聯網網關內的業務邏輯代碼、數據、配置、權限、雲端傳輸等的配置應該都是靈活的。讓物聯網平臺的二次開發人員可以隨時修改，隨時部署到已經在現場運行的網關。
這樣子一來，網關和平臺廠商的定製壓力就會小很多。客戶可以自己去做想做的事情。
皆大歡喜。
2.ClearBlade平臺總體介紹
上面說了這麼多，其實就是ClearBlade要解決的問題。
ClearBlade是2018年的Application Enablement Platform（AEP，應用程序賦能平臺）評分卡上榜的廠商之一。為什麼能上榜？因為它確實給物聯網應用程序開發商賦能了。
下圖是ClearBlade物聯網平臺的總體結構圖。
整體上分為兩大部分：
- IoT Platform（物聯網平臺）：是一個可以根據不同行業定製要求二次開發的物聯網雲平臺。部署在雲端，支持多租戶。每個租戶可以創建多個系統。在每個系統下開發人員可以根據業務需求，創建、配置和管理數據、消息傳輸、自定義代碼、觸發器和可視化界面。然後將這些資產下發到邊緣平臺上執行。同時向上也提供了與其他企業信息系統集成。
- IoT Edge Platform（物聯網邊緣平臺）：部署在邊緣計算設備上，向下與物聯網設備交互，向上與物聯網平臺連接。通過適配器Adapter來接入各種協議的設備。
用戶在ClearBlade物聯網平臺上首先創建一個系統。系統相當於當前租戶下創建的一個物聯網監控系統。
在系統內，開發人員可以創建業務邏輯代碼、物聯網設備協議適配器、自定義可視化監控界面、數據集合、定時器、觸發器、界面插件、邊緣設備等。
創建系統有四種方式：
- 基於已有的系統模板
- 從GitHub項目導入
- 從系統文件導入
- 創建空的系統
我們選擇創建空的系統。然後填寫系統名稱PlcRemote，就創建好了一個系統：
我們可以看到出現了12個功能模塊。這些功能模塊都是可以讓用戶自己創建和定義的。
下面我們來一一介紹這12個功能模塊。
3.12個功能模塊的介紹
3.1服務Services
為了便於開發人員根據業務邏輯需要，擴展平臺功能，ClearBlade提供了Code功能模塊。
Code功能模塊可以讓開發人員實現自定義業務邏輯的代碼，然後Web端、移動端等就可以通過ClearBlade的API調用這些代碼。
Code分為兩種：服務和庫。
ClearBlade的服務其實就是生命週期最長30秒的JavaScript微服務。在沙箱中運行，一旦完成調用，就銷燬。
服務可以用三種方式調用
- RESTful API請求
- 觸發器Trigger觸發
- 定時器Timer觸發
每個服務有一個名稱，這個名稱與自動生成的服務函數名相同。
例如創建了一個名稱為analyze的服務，系統就會自動生成如下函數：
function analyze(req, resp){}
這個函數有兩個參數，與NodeJS 的Express框架類似。
服務可以使用Requires指令導入一個或多個庫Library。以便使用ClearBlade提供的或自定義開發的庫。
定時器Timer提供了讓服務可以定時調用的機制。創建服務時，可以指定一個定時器來告訴系統定時執行這個服務。定時器的調度機制與UNIX的cron job類似。
例如：
- 從現在開始每隔5分鐘運行一次服務
- 從2019年1月1日的每兩週的週五開始，運行26次服務
- 每天凌晨運行一次服務
除了定時器，還可以在服務上定義觸發器Trigger。一旦觸發器的觸發源Trigger Source對應的事件發生，就會調用該服務。
觸發源Trigger Source的分類
- 消息：Publish、Upon Subscribe、Upon Unsubscribe、User Connected、User Disconnected、Device Connected、Device Disconnected
- 數據：表Created、表Updated、表Deleted、item Created、item Updated、item Deleted
- 用戶：Created、Updated、Deleted
- 設備：Created、Updated、Deleted
3.2庫Libraries
庫Library也是Code的一種。它是可重用的代碼。服務用Requires指令就可以導入使用庫。
庫分為兩種：
- Native庫
- 自定義庫
本地Library是ClearBlade自帶的JavaScript庫，包含了常用的功能。底層是用Go語言實現的，並且每個庫都進行了性能優化。
Native庫包括：
- Clearblade：與集合、消息、用戶、邊緣、設備等進行交互
- Log：日誌輸出
- http：http/https請求
- geo：地理信息處理庫
- crypto：hash算法庫
- file_writer：文件寫入
- jsutil：js輔助函數類庫
- mailer：郵件發送
- net_cb：網絡庫
- oauth2_lib：OAuth輔助類庫
開發人員也可以創建自定義庫，封裝常用的業務邏輯，用於重用。
3.3集合Collections
在開發物聯網系統時，不同開發人員會選擇不同的後臺數據庫用來存儲從物聯網設備傳輸上來的設備實時數據和歷史數據。
ClearBlade平臺考慮到了這個普遍性的需求，封裝了集合這個抽象概念。一個Collection相當於一個數據庫。
開發人員通過Collections來存儲不同類型的數據到不同的數據庫中。
每個Collection可以通過Console、Portals、API和SDK來訪問。
Collection分為兩種：
- Cloud
- Connection
Cloud
ClearBlade提供一個默認的基於Postgresql的cloud Collection。
Connection
Connection類型允許開發人員，集成已有的數據庫。目前支持如下幾種：
- MySQL
- PostgreSQL
- MongoDB
- Oracle
- DB2_Linux
- DB2_zOS
- DB2_System_i
- Microsoft_SQL_Server
- Cassandra
- CouchDB
3.4適配器Adapters
適配器是一個開發人員自定義的軟件組件，部署在物聯網網關設備上運行。它實際上就是相當於邊緣計算設備上與設備打交道的協議驅動程序。
每個適配器都有一個名稱，若干個管理命令，和一些可執行的程序文件。
這些文件包括可執行的程序和依賴庫，以及用來管理適配器的shell腳本。
一旦適配器已經成功部署到邊緣設備，就可以在平臺的開發人員終端web界面上啟動、停止或者重啟適配器。
適配器的狀態有運行和停止。
如果適配器沒有部署到邊緣設備，那麼這個邊緣設備會放在未連接邊緣設備界面中。
適配器支持的命令類型有：
- 部署命令Deploy Command – 在邊緣設備上安裝完適配器後運行的命令或shell腳本。可選命令。
- 啟動命令Start-up Command – 啟動適配器的命令或shell腳本。
- 停止命令Stop Command –停止適配器的命令或shell腳本。
- 狀態命令Status Command – 查看適配器當前運行狀態的命令或shell腳本。
- 取消部署命令Undeploy Command – 在邊緣設備上卸載部署好的適配器。
- 日誌命令Logs Command – 從邊緣設備上獲取適配器的日誌文件。
3.5門戶Portals
作為一個物聯網監控系統，肯定要有可視化監控界面。ClearBlade通過Portal來讓開發人員定製和二次開發可視化界面。
Portal門戶是一個Web應用的實例。它是響應式的、移動端友好和可定製的。
Portal可以包括：
- 多個Page頁面
- 多個數據源
- 一個Header Pane
- 一個Flyout Pane
Portal包含的組件有：
Portal界面上可以訪問的數據源包括：
- Collections
- MQTT消息主題
- Code Service
Page
用戶每次可以看一個頁面。默認頁面是’Home’頁面。
一個頁面可以包含多個面板Pane。
Pane
一個面板是一個或多個widget的容器。面板的寬高是根據Bootstrap Grid網格佈局。
Widget
Widget控件與一個或多個數據源關聯，根據數據源的數據進行可視化渲染或者交互。
Parser
Parser解析器是數據源輸出的數據在給widge渲染前進行的處理。轉成widget所需的數據格式。
Flyout Pane
這個面板是可定製的面板，位於左側。
Header Pane
這個面板在Portal中每個頁面都會顯示，用作header。
External Resource
外部資源代表了一個外部網站的一個js或css文件。
Theme Editor
主題編輯器用於自定義portal的主題顏色樣式。
Screen Size Editor
屏幕大小編輯器用於根據不同屏幕大小，調整面板和widget的佈局。
3.6插件Plugins
插件是Portal加載的JavaScript文件。它的用途是用於擴展支持當前不支持的數據源和widget控件。
3.7部署Deployments
部署用於指示哪些資源要部署或同步到哪些Edge邊緣計算節點。
部署到Edge邊緣計算節點的資源，可以是系統中創建的如下內容：
- Code:包括Service和Library
- Collections
- Adapters
- Portals
- Roles
- Users
- Devices
- Edges
- Messages
Edge邊緣計算節點上的資源或者物聯網平臺上的資源可能會發生變更。因此要部署的資源需要配置相應的動作。
動作有兩種：
- 部署Deploy：當邊緣設備啟動時，資源會被從雲端部署到邊緣設備。
- 同步Sync：資源已經部署過了，當邊緣設備或物聯網平臺的資源變更了，邊緣設備和物聯網平臺之間就會自動進行同步更新。
最常見的部署應用場景是：開發人員首先在物聯網平臺上創建好業務相關的code service和collections，然後Snyc部署到多個Edge邊緣計算節點上。這樣當Edge邊緣計算節點上的collections發生變化，物聯網平臺的collections也會同步變化。
3.8角色Roles
角色是物聯網平臺上的用戶的訪問權限的類別分類。默認分為系統管理員、匿名用戶和認證用戶三類角色。系統管理員權限最高。
每個角色都有對應的權限。下圖是系統管理員的部分權限：
3.9用戶Users
能夠訪問這個系統的用戶的管理。
用戶創建完成後，會讓管理員設置該用戶的角色。
3.10設備Devices
設備是指物聯網傳感器和物聯網設備。這些設備不一定是通過TCP/IP網絡連接的，也可能是通過低功耗藍牙或ZigBee等方式通訊的。邊緣計算網關可以連接一個或多個設備。
3.11邊緣設備Edges
Edge就是一個邊緣計算設備，例如對應現場的一個網關。
創建完成後，可以設置edge。選擇target目標宿主機環境，然後就可以複製Edge程序的安裝腳本，執行該腳本就可以在目標邊緣計算設備上安裝好Edge。
Edge的安裝命令
curl -fsSL https://get.clearblade.com -o get-clearblade.sh; sh get-clearblade.sh edge linux-amd64 5.0.5
Edge的啟動命令
edge -platform-ip='platform.clearblade.com' -parent-system='a8953ecc0bc8c7b27gcr' -edge-ip='localhost' -edge-id='edge1' -edge-cookie='t6W19QRwG8xK726X9b08C7n9'
3.12消息Messages
邊緣計算平臺和雲平臺支持MQTT協議。可以通過觸發器觸發調用自定義的Service服務，以實現複雜的消息處理流程。
消息發送流程
流程1: 在 publish這個觸發源上綁定一個觸發器，來用service處理消息，然後再publish
每當有mqtt消息發佈到物聯網平臺，那麼觸發器就調用相應的Service服務進行處理，然後再發布為另外一個消息。
流程2: 在publish這個觸發源上綁定一個觸發器，通過Service將這個消息存儲到Collections中保存。
ClearBlade平臺完整實現了MQTT 3.1.1版本的協議。
4.API接口和SDK
ClearBlade提供RESTful API，可以對系統的各種資源進行管理。
比如通過Code接口，可以直接調用相應的Service服務。
SDK是對上述API的封裝，支持有多種語言，如Python、Java、Go、C、C#、NodeJS等。
5.平臺的優缺點
缺點：
角色和權限較弱。權限好像更多針對的是開發人員，對最終使用者權限關注不夠。
擴展性不夠，只是在資源上允許進行簡單的字段擴展。
開發起來還是有點繁瑣，對開發人員技術要求有一定門檻。
Collections的界面不好用。
資源部署的歷史版本沒有。
適配器的實現對開發人員約束太少，封裝不夠。
Portal功能不如開源的Grafana之類的可視化dashboard軟件。
缺乏對自身的監控指標的監控。
優點：
抽象的比較細膩。把平臺二次開發所需要的功能全部暴露給開發人員，便於開發人員根據行業業務邏輯要求擴展。
可以遠程下發適配器之類的到邊緣計算節點上。
提供了多種語言的SDK。
資源自動同步。
每個類型的資源都可以擴展自定義字段。
閱讀更多 物聯網前沿技術觀察 的文章
