What is an IoT Gateway?
 |
|
任何顏色車牌——都拍攝的清清楚楚！
|
1、背景介紹
隨著業務的不斷擴大，有一批設備需要對接到我們的平台裡，所以我嘗試著去設計一下，我們公司的設備 Gateway 系統架構。
目前接入的均為無線設備，設備與載體可隨時移動，使用普通 SIM 卡流量，所以沒有固定 IP 地址。至於設備網關1.0 的核心功能，說來也簡單，攏共分為三大部分：
① 設備安裝/綁定。
② 設備數據即時上報
③ 設備運維
2、四層結構
讓我們從另一個視角來看待設備 Gateway ：層次結構。
我整理了一下整個業務過程，追蹤了一遍整個數據流向，於是乎很容易就得出了，如下的四層結構圖：
整個層次結構自底向上依次為數據層、控制層、應用層、表現（顯示）層，該層次結構也成為了我之後設計系統架構的指導思想。
現在對每個層次做一個簡單的介紹：
數據層。處於底層，整個系統的數據源頭，很明顯是一個最基礎的層次。
控制層。這是一個承上啓下的關鍵層次，最主要的功能是指令的解析，以及指令的收發。
應用層。亦可稱之為業務層，這個層次與系統的業務邏輯是緊密相關的，一些業務的實現都將在這裡得以發揮。對上承接的是顯示層，進而可以透過控制層，對設備進行指令的收發，對下接入的是控制層，可以獲取設備相關數據提交給顯示層。
顯示層。亦可稱之為交互層，是人機交互，數據可視化的切入點。不難看出，這個層次是直接與人打交道的，所以在滿足業務需求的同時，需要設計得足夠人性化才行。
透過上述的介紹，結合層次結構圖，不難得出：數據層和控制層是業務無關的，我們可以統稱為「協議層」，而應用層和顯示層是業務相關的，我們可以統稱為「系統層」。整個層次結構相互獨立，而又彼此相連，達到了弱耦合的目的。
3、架構演進(level-1)
做出整個架構也是一個很痛苦的過程，唯恐有考慮不周的地方，導致今後會不斷踩坑。也非常感謝在這個過程中，給我提供幫助和建議的業內人士，在他們的指點下，我才有了更多的靈感。
至於所謂的 IoT 體系結構，也並沒有完全遵循。整個業務場景，也不像是一個非常標準的物聯網，所以給自己的要求不是很高，設計出來的架構堪用就行。
首先，我們從一個較高的視角去看待，整個架構是這樣子的：
從圖中不難看出，整個設備 Gateway 存在四個關鍵角色。
設備以及設備組成的群組(Device Group)，是最基礎的角色，屬於數據層。考慮到今後可能會對設備做精細化管理，所以會按一定的規則（比如地域，組織）對設備進行分組，這部分設計在前期體現得不是很明顯。
中控平台(Center Controller)，對應的是控制層。這個角色的主要工作有數據採集，設備指令的收發等，值得注意的是，接入到系統裡面的設備廠商可能不止一家，設備種類也是形形色色，報文協議也不盡相同，因此中控平台應該被設計成「對設備類型不敏感」的，以便提升中控平台的相容性，可擴展性，以及可用性。（如是以資安角度考量，相容性與可拓展性是要有所取捨的！）
業務處理器(Biz Processor)，對應的是應用層（業務層）。這個角色集中體現了系統的業務需求，包括設備維運監控，數據分析以及持久化，日誌分析，當然，這也是建立在中控平台的基礎之上。
設備管理系統(Management System)，對應的是顯示層。這個角色是直接針對終端用戶的，是一個可操作的人機交互平台，該平台可以透過業務處理器，控制整個數據鏈條。因為是整個架構的最高層級，透過對底層數據的有效整合，想相空間還是很大的。
以上就是設備 Gateway 架構的 Level-1，緊接著我們再更深入的剖析整個架構，進入 Level-2。
4、架構演進(level-2)
這部分內容，我們深入到四個角色的內部，窺探其中的結構組成。
1) 設備以及設備群組。這裡我們將引入一個叫作「子設備」的概念，即一個設備對象下，會再附屬若干個設備，我們稱之為「子設備」。當然，一個設備也可能沒有子設備，依實際情況而定。
舉個例子： 以一扇門作為一個設備，那麼密碼鎖，鎖舌，紅外探頭都可以是子設備；再比如地震監測的探針，就是一個獨立的設備，下屬沒有子設備。
這樣設計的目的，是為了能夠更精細化地對接入的設備進行控制，進可控制單個子設備，退可控制整個大設備。此外，對於平台內的所有大小設備，都不會直接相互進行通信，都是直接與中控平台打交道的。
2) 中控平台。我把這個角色定位為一種中間件，如下是中控平台的組件圖:
整個中控平台由八大組件構成，下面做一個簡單的介紹。
連接器（Connector）。這個組件是控制層與數據層的數據傳輸管道，維護著中控平台和各個設備的數據連接，數據傳輸連接都是基於 TCP/IP 協議。
REST API。中控平台作為協議層與系統層的樞紐，對下層提供了連接器，對上層則提供了 RESTful 接口。因為設備 Gateway 將會使用微服務架構風格，所以使用的是 REST API，暫不考慮其他的遠端調用方式。
訊息佇列（或稱消息隊列，Message Queue）服務。主要是解決應用耦合，異步消息，流量削鋒等問題，最終實現高性能，高可用，可伸縮和最終一致性架構，有利於實現協議層與系統層準即時通信。
協議解析引擎（Protocol Parser）。這個組件很好理解，因為要適配不同的源設備，不同的設備廠商，協議規範是不一樣的，需要透過協議解析引擎進行轉換，並在系統內形成規範。這部分工作對上層系統完全透明，只需要根據系統內的規範進行數據交互即可。所以，協議的解析是雙向的，由內向外，以及由外而內。
指令執行引擎（Command Executor）。在這個組件中會維護一份最新的「指令集」，每條指令都有特定的功能，依靠協議解析引擎，對應到不同的設備上的不同功能。
數據採集器（Data Collector）。顧名思義，這個組件的主要任務，是收集來自設備的所有數據，配合日誌服務進行記錄。數據採集器大致可以分為兩類：即時性和非即時性，根據業務需求響應不同時效性的採集器。
日誌服務（Logger Service）。這部分記錄的日誌有兩種類型：數據型，設備型。日誌的儲存形態不在本篇範疇，這裡著重闡述一下這兩類數據。
- 數據型日誌記錄的是流經控制層的數據，分為三種：
- 源數據，亦可稱之為「裸數據」，這一部分數據沒有經過任何的加工，從各個設備直出；
② 結構化數據，這部分數據是最接近業務數據的，對源數據進行了粗加工形成的；
③ 業務數據，根據系統的業務需求，對結構化數據做了進一步整合和加工形成的。
- 設備型日誌記錄的，是接入平台裡的設備相關的數據，分為兩種：
- 設備狀態，記錄的是設備狀態流數據；
② 指令收發，記錄的是中控平台對設備指令的收發數據。
管理工具套件（Management Toolkit）。這部分可以認為是中控平台的增值服務，優先級最低，不過想像的空間也是很大的。我打算將其設計成一個可響應Terminal命令的服務，比如獲取當前連接數，最大連接數是多少，指令集配置，發送指令給設備等等。
3) 業務處理器，這個是與業務相關的角色，可以根據實際業務需求去設計。我在設計業務處理器的時候，是以設備為中心的，再去擴充其他功能。如下是一張業務處理器的拓撲圖，具體的業務需求就不再展開敘述了。
4) 設備管理系統(Management System)，這部分，我認為要做到兩個「可視化」：數據可視化，設備可視化。「數據可視化」比較好理解，就是數據的整合及其圖形化表示，當然，數據的來源可以是即時的，也可以是離線加工過的，這個業界都有成熟的解決方案。
還有一個就是「設備可視化」，這個主要是給普通使用者，一個比較友好的操作體驗，將設備具象化，點擊不同的按鈕，可以觸發其對應的功能。當然，對於專家使用者，也可以提供站內 Terminal，直接使用命令與設備進行交互。
沒有留言:
張貼留言