物聯網設備網關技術架構設計

1、前情概要

看這篇文章之前，強烈建議先閱讀《物聯網設備網關係統架構設計》，該篇文章從四個層次詳細介紹了我司設備網關的系統架構。

其實做架構設計離不開三個方面：業務架構，系統架構，以及技術架構。它們彼此之間不需要遵循一定的順序，但必須以實際業務作為出發點，這樣做出來的架構才有落腳點，否則就淪為了一個紙上談兵的花架子了。從這個角度考慮，對於以盈利為目的的組織來說，還是以業務驅動為導向會比較靠譜，技術驅動也未嘗不可，在B2B的領域也可以大展拳腳。

在設備網關的架構設計中，對於業務架構的設計，我沒有單獨寫一篇文章闡述之，而是融合在系統架構設計中，對其做了一定的介紹。

為了方便闡述，我將系統架構設計圖先貼出來。

接下來的技術架構設計無非就是將系統架構的四個部分在技術層面進行剖析。

個人以為，Device Group，Center Controller，以及Biz Processor，這三個部分的技術含量較高，由於單片機設備並非我司開發和生產的，將這部分工作委託給了第三方公司，故對此不做介紹，重點剖析Center Controller和Biz Processor。

2、從Netty說起

這部分內容屬於知識科普篇，因為Netty在整個技術架構中有著舉足輕重的作用，如果讀者對此比較熟悉，可以選擇性跳過。

下面先看一段來自Netty官網的介紹：

Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server.

說得直接一點就是：Netty是一套基於NIO而封裝的易用性較高的API，使用它可以簡單快速地開發網路應用程序。

Netty擁有諸多特性，比如設計良好，支持多種協議的非阻塞式API，高吞吐量，低延遲，資源佔用率低等。此外，Netty的社區較為活躍，文檔資料較多也成為了我選擇它的關鍵原因之一。以下是Netty組件圖，大家可以感受一下：

可能大家比較關心Netty究竟能幹些啥。限於篇幅，我不能慢條斯理地給大家解釋，只能從感性上對Netty的應用領域進行認知。

• 高性能RPC框架。這是Netty的一個典型應用場景，著名的分散式服務框架 Dubbo 遠程調用使用的底層通信框架就是Netty，Dubbo是久經考驗的出色的開發框架，其默認使用的通信框架Netty自然是非常靠譜的。除了 Dubbo 之外，淘寶的消息中間件 RocketMQ 的消息生產者和消息消費者之間，也採用 Netty 進行高性能、非同步通信。
• 大數據處理。分散式大數據處理框架 Hadoop 的高性能通信和序列化組件 Avro 的 RPC 框架，默認採用 Netty 進行跨節點通信，它的 Netty Service 基於 Netty 框架二次封裝實現。
• Web容器定製和開發，這個算是比較高階的應用。像Tomcat，JBoss這類Web容器是基於HTTP協議的，而Netty比這些運行容器還要更底層，畢竟HTTP協議是基於TCP/IP的，對於HTTP請求，還是需要像Netty這樣的通信框架處理底層協議。因此，如果願意的話，你也可以基於Netty開發一款Web運行容器。

綜上所述，看過我的設備網關係統架構後，也不難想到我為什麼會選擇Netty了。

下面正式開始介紹設備網關的技術架構設計。

3、中控平台技術架構

這部分的技術架構與前面介紹的Netty是緊密相關的，中控平台的底層通信框架便是Netty。

如下這張圖基本上可以表達我對中控平台技術架構的設計思想：

不難看出，整個架構風格採用的是以Spring Cloud構造的微服務。因為中控服務實例可以有多個，用以應對設備數據增加所帶來的橫向擴展。

系統架構中提到了中控平台的REST API組件，可以對應到中控伺服器的REST Service。這部分功能用Feign進行實現，Feign可以認為是一個帶有負載均衡特性的簡單易用的HTTP請求中間件，其中集成了請求組件RestTemplate，以及負載均衡器Ribbon。REST Service組件可以提供諸如設備信息，連接通道狀態，設備連接數，指令集維護之類的API，用於與業務相關的系統層進行調用。

MQ Service是系統架構中消息隊列服務組件的實現。理論上來講，物聯網行業的消息服務協議首選MQTT，它是為大量計算能力有限，且工作在低帶寬、不可靠的網路的遠程感測器和控制設備通訊而設計的協議。但是也不阻止你選擇其他協議，比如AMQP，STOMP等。當然，各大廠商都有對消息隊列服務協議的實現，支持的協議最全面的就是Apache ActiveMQ，STOMP是基於純文本的消息傳輸協議，不用考慮，MQTT協議實現的代表是出自國人之手的EMQ，AMQP協議實現的代表則是RabbitMQ。

接下來的Logger Service沒什麼好解釋的了，因為只負責記錄日誌，使用logback，或者log4j之類的日誌框架即可。

最後的Netty Service涵蓋了很多組件的實現，其內核都是基於Netty的服務，很多設計和實現也就顯而易見了。整個中控平台與設備組的數據傳輸載體就靠連接通道(Connect Tunnel)，這裡藉助一個通訊行業專業術語「全雙工」，它表示命令的收發可以同時在通道里發生，所以基於連接通道這個載體，我們可以進一步實現協議解析引擎，命令執行引擎，數據收集器等組件。

4、業務處理器技術架構

因為我採用了微服務的架構風格，所以業務處理器的技術架構和Spring Cloud脫不了干係。先看一張技術架構圖：

上面一部分是各式各樣的客戶端，也包括了系統架構中提到的管理系統（Management System），這一部分不再展開敘述了。

下面一部分就是業務處理器的核心技術架構了，鑒於Spring Cloud在國內普及程度不是很高，我先對架構圖周邊的5個Spring Cloud組件進行簡單介紹。

① Zuul Gateway，就是一個API網關的角色，根據事先配置好的路由規則，將客戶端請求轉發到相應的微服務中進行處理；

② Config Server，這裡指代的是Spring Cloud Config，用於充當統一配置中心的角色，裡面存放了幾乎全部的微服務相關的配置信息；

③ Eureka Server，服務的註冊與發現中心，管理著眾多微服務的元數據信息；

④ Ribbon，是一個基於軟體層面的負載均衡器，當一個微服務部署了多個實例的時候，可以通過Ribbon進行負載均衡；

⑤ Hystrix，即微服務熔斷器，為了避免分散式系統產生「雪崩效應」。當一個微服務長時間無法到達時，就會觸發該鏈路上的熔斷器，防止大量的無效請求拖垮整個系統。

對於新手來說，上述的Spring Cloud組件介紹可能過於簡單了，如果感興趣，可以搜索相關學習資料，或者關注我的專欄，我會不定期的進行微服務領域的相關分享。

接下來介紹5個核心的業務模塊。

① Log Analysis，日誌分析。主要是收集來自中控平台的日誌，以及業務層自身的相關日誌，可以用來分析，排查和追蹤問題，進而起到一定的監控作用。這部分使用的ELK技術棧，也算是日誌分析功能的一個最佳實踐，因為日誌分析業務沒有其他特殊的業務需求，所以其他的技術我也沒有再去考慮了；

② Data Analysis，數據分析。這個話題太大了，我只能結合業務來談。這部分功能主要體現在了數據可視化，以及結合監控服務對設備進行預警，所以，就目前而言，數據分析的功能就是對一些業務規則的識別和整合，讓無形的數據變成有形的資產。目前只考慮數據的離線分析，至於實時分析的功能，現在還不是這麼迫切，所以只用到了Hadoop生態里的相關技術；

③ Data Persistence，數據持久化。 這部分功能就是為數據分析，以及客戶端提供相關數據。數據持久化有兩個地方：MongoDB，MySQL。MySQL存儲的是一些結構化的業務數據，因為這些數據比較重要，所以MySQL會使用主-從結構進行部署，遵循「主寫，從讀」的原則。MongoDB存儲的是除業務數據的其他數據，暫不考慮集群部署；

④ Monitor Dashboard，監控平台。這個部分是設備運維的核心功能，而這個監控功能要分兩個層面理解：第一個是業務層面，目的是監控設備，中控以及業務的健康狀況，通過一定的指標展示出來；第二個是技術層面，也就是技術架構圖中提到的Turbine，其實結合了上面提到的Hystrix，對各個微服務的狀態進行監控；

⑤ Notification Service，通知服務。管理整個設備網關的通知業務，手機推送使用的是個推平台，此外還結合了郵件通知，我們可以直接使用Spring Boot自帶的一個mail組件。

5、總結

承接上一篇的系統架構設計文章，這篇文章詳細介紹了物聯網設備網關的技術架構設計及其所用到的核心通信框架Netty。然而，對於各個技術的實現，本文沒有做太具體的介紹，因為涉及到了代碼層面的詳細設計環節了，後續會出具體實現的文章。

我的個人公眾號：技術匯。ID：jishuhui_2015

推薦閱讀：