物聯網設備網關係統架構設計

0、寫在前面的話

坦白來講，我對物聯網行業沉澱較少。

做軟體出身的我，之前也學過一些單片機的知識，還有射頻，ZigBee諸如此類的無線傳輸協議，因為那段時間「智能家居」火了，年少無知的我也跟著瘋了，然後就沒有然後了……

回想自己以前對技術的狂熱，還是值得肯定的，但是那種近乎盲目的追求，就有點過猶不及了。

總之，學到的新技術或者新概念，需要及時去實踐，去落地，長時間的擱置會導致最終一場空，這種到頭來一無所有的感受，對自己的積極性也是一種打擊。

1、背景介紹

如今，隨著公司業務的不斷擴大，有一批設備需要對接到我們的平台里，所以我嘗試著去設計一下我司的設備網關係統架構。

目前接入的均為無線設備，設備與載體可隨時移動，使用普通SIM卡流量，所以沒有固定ip地址。至於設備網關1.0的核心功能，說來也簡單，攏共分為三大部分：

① 設備安裝/綁定。

② 設備數據實時上報

③ 設備運維

2、四層結構

讓我們從另一個視角來看待設備網關：層次結構。

我梳理了一下整個業務過程，追蹤了一遍整個數據流向，於是乎很容易就得出了如下的四層結構圖：

整個層次結構自底向上依次為數據層、控制層、應用層、表現層，該層次結構也成為了我之後設計系統架構的指導思想。

現在對每個層次做一個簡單的介紹：

• 數據層。處於底層，整個系統的數據源頭，很明顯是一個最基礎的層次。
• 控制層。這是一個承上啟下的關鍵層次，最主要的功能是指令的解析，以及指令的收發。
• 應用層。亦可稱之為業務層，這個層次與系統的業務邏輯是緊密相關的，一些業務的實現都將在這裡得以發揮。對上承接的是表現層，進而可以通過控制層對設備進行指令的收發，對下接入的是控制層，可以獲取設備相關數據提交給表現層。
• 表現層。亦可稱之為交互層，是人機交互，數據可視化的切入點。不難看出，這個層次是直接與人打交道的，所以在滿足業務需求的同時，需要設計得足夠人性化才行。

通過上述的介紹，結合層次結構圖，不難得出：數據層和控制層是業務無關的，我們可以統稱為「協議層」，而應用層和表現層是業務相關的，我們可以統稱為「系統層」。整個層次結構相互獨立而又彼此相連，達到了弱耦合的目的。

3、架構演進(level-1)

做出整個架構也是一個很痛苦的過程，唯恐有考慮不周的地方，導致今後會不斷踩坑。也非常感謝在這個過程中給我提供幫助和建議的業內人士，在他們的指點下，我才有了更多的靈感。

至於所謂的IoT體系結構，也並沒有完全遵循。整個業務場景也不像是一個非常標準的物聯網，所以給自己的要求不是很高，設計出來的架構堪用就行。

首先，我們從一個較高的視角去看待，整個架構是這樣子的：

從圖中不難看出，整個設備網關存在4個關鍵角色。

• 設備以及設備組成的群組(Device Group)，是最基礎的角色，屬於數據層。考慮到今後可能會對設備做精細化管理，所以會按一定的規則（比如地域，組織）對設備進行分組，這部分設計在前期體現得不是很明顯。
• 中控平台(Center Controller)，對應的是控制層。這個角色的主要工作有數據採集，設備指令的收發等，值得注意的是，接入到系統裡面的設備廠商可能不止一家，設備種類也是形形色色，報文協議也不盡相同，因此中控平台應該被設計成「對設備類型不敏感」的，以便提升中控平台的兼容性，可擴展性，以及可用性。
• 業務處理器(Biz Processor)，對應的是應用層（業務層）。這個角色集中體現了系統的業務需求，包括設備運維監控，數據分析以及持久化，日誌分析，當然，這也是建立在中控平台的基礎之上。
• 設備管理系統(Management System)，對應的是表現層。這個角色是直接面向終端用戶的，是一個可操作的人機交互平台，該平台可以通過業務處理器控制整個數據鏈條。因為是整個架構的最高層級，通過對底層數據的有效整合，想像空間還是很大的。

以上就是設備網關架構的Level-1，緊接著我們再更深入的剖析整個架構，進入Level-2。

4、架構演進(level-2)

這部分內容，我們深入到四個角色的內部，窺探其中的結構組成。

1) 設備以及設備群組。這裡我們將引入一個叫作「子設備」的概念，即一個設備對象下會再附屬若干個設備，我們稱之為「子設備」。當然，一個設備也可能沒有子設備，依實際情況而定。

舉個例子： 以一扇門作為一個設備，那麼密碼鎖，鎖舌，紅外探頭都可以是子設備; 再比如地震監測的探針，就是一個獨立的設備，下屬沒有子設備。

這樣設計的目的是為了能夠更精細化地對接入的設備進行控制，進可控制單個子設備，退可控制整個大設備。此外，對於平台內的所有大小設備，都不會直接相互進行通信，都是直接與中控平台打交道的。

2) 中控平台。我把這個角色定位為一種中間件，如下是中控平台的組件圖:

整個中控平台由八大組件構成，下面做一個簡單的介紹。

• 連接器（Connector）。這個組件是控制層與數據層的數據傳輸渠道，維護著中控平台和各個設備的數據連接，數據傳輸連接都是基於TCP/IP協議。
• REST API。中控平台作為協議層與系統層的樞紐，對下層提供了連接器，對上層則提供了RESTful介面。因為設備網關將會使用微服務架構風格，所以使用的是REST API，暫不考慮其他的遠程調用方式。
• 消息隊列（Message Queue）服務。主要是解決應用耦合，非同步消息，流量削鋒等問題，最終實現高性能，高可用，可伸縮和最終一致性架構，有利於實現協議層與系統層准實時通信。
• 協議解析引擎（Protocol Parser）。這個組件很好理解，因為要適配不同的源設備，不同的設備廠商，協議規範是不一樣的，需要通過協議解析引擎進行轉換並在系統內形成規範。這部分工作對上層系統完全透明，只需要根據系統內的規範進行數據交互即可。所以，協議的解析是雙向的，由內向外，以及由外而內。
• 指令執行引擎（Command Executor）。在這個組件中會維護一份最新的「指令集」，每條指令都有特定的功能，依靠協議解析引擎，對應到不同的設備上的不同功能。
• 數據採集器（Data Collector）。顧名思義，這個組件的主要任務是收集來自設備的所有數據，配合日誌服務進行記錄。數據採集器大致可以分為兩類：實時性和非實時性，根據業務需求響應不同時效性的採集器。
• 日誌服務（Logger Service）。這部分記錄的日誌有兩種類型：數據型，設備型。日誌的存儲形態不在本篇範疇，這裡著重闡述一下這兩類數據。
  - 數據型日誌記錄的是流經控制層的數據，分為三種：
  ① 源數據，亦可稱之為「裸數據」，這一部分數據沒有經過任何的加工，從各個設備直出；
  ② 結構化數據，這部分數據是最接近業務數據的，對源數據進行了粗加工形成的；
  ③ 業務數據，根據系統的業務需求，對結構化數據做了進一步整合和加工形成的。

  - 設備型日誌記錄的是接入平台里的設備相關的數據，分為兩種：

  ① 設備狀態，記錄的是設備狀態流數據；
  ② 指令收發，記錄的是中控平台對設備指令的收發數據。
• 管理工具套件（Management Toolkit）。這部分可以認為是中控平台的增值服務，優先順序最低，不過想像的空間也是很大的。我打算將其設計成一個可響應Terminal命令的服務，比如獲取當前連接數，最大連接數是多少，指令集配置，發送指令給設備等等。

3) 業務處理器，這個是與業務相關的角色，可以根據實際業務需求去設計。我在設計業務處理器的時候，是以設備為中心的，再去擴充其他功能。如下是一張業務處理器的拓撲圖，具體的業務需求就不再展開敘述了。

4) 設備管理系統(Management System)，這部分我認為要做到兩個「可視化」：數據可視化，設備可視化。「數據可視化」比較好理解，就是數據的整合及其圖形化表示，當然，數據的來源可以是實時的，也可以是離線加工過的，這個業界都有成熟的解決方案。還有一個就是「設備可視化」，這個主要是給普通用戶一個比較友好的操作體驗，將設備具象化，點擊不同的按鈕可以觸發其對應的功能。當然，對於專家用戶，也可以提供站內Terminal，直接使用命令與設備進行交互。

5、總結

整篇文章闡述了設備網關的四層結構，並分兩個層面深入分析設備網關的系統架構。通篇沒有涉及具體技術細節，因為這是技術架構層面的內容了，定當另起新篇闡述之。

希望能對你有所幫助！

THANKS！

推薦閱讀：