Internet of Things (IoT) Architecture ：IoT Tutorial for Beginners
1、前情概要
看這篇文章之前，強烈建議先閱讀上週分享的《物聯網設備網關係統架構設計》，該篇文章從四個層次，詳細介紹了我司設備 Gateway 的系統架構。
其實做架構設計離不開三個方面：業務架構，系統架構，以及技術架構。它們彼此之間不需要遵循一定的順序，但必須以實際業務作為出發點，這樣做出來的架構才有落腳點，否則就淪為了一個紙上談兵的花架子了。從這個角度考慮，對於以盈利為目的的組織來說，還是以業務驅動為導向會比較可靠，技術驅動也未嘗不可，在 B2B 的領域也可以大展拳腳。
在設備 Gateway 的架構設計中，對於業務架構的設計，我沒有單獨寫一篇文章闡述之，而是融合在系統架構設計中，對其做了一定的介紹。
為了方便闡述，我將系統架構設計圖先貼出來。
接下來的技術架構設計，無非就是將系統架構的四個部分，在技術層面進行剖析。
個人以為，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 運行容器。
綜上所述，看過我的設備 Gateway 系統架構後，也不難想到我為什麼會選擇 Netty 了。
下面正式開始介紹設備 Gateway 的技術架構設計。
3、中控平台技術架構
這部分的技術架構，與前面介紹的 Netty 是緊密相關的，中控平台的底層通信框架便是 Netty。
如下這張圖基本上可以表達，我對中控平台技術架構的設計思想：
不難看出，整個架構風格採用的是以 Spring Cloud 構造的微服務。因為中控服務實例可以有多個，用以應對設備數據增加，所帶來的橫向擴展。
系統架構中提到了中控平台的 REST API 組件，可以對應到中控服務器的 REST Service。這部分功能用 Feign 進行實現， Feign 可以認為是一個，帶有負載均衡特性的，簡單易用的 HTTP 請求中間件，其中整合了請求組件 Rest Template，以及負載均衡器 Ribbon。REST Service 組件可以提供諸如設備資訊，連接通道狀態，設備連接數，指令集維護之類的 API，用於與業務相關的系統層進行調用。
MQ Service 是系統架構中，消息隊列服務組件的實現。理論上來講，物聯網行業的消息服務協議首選 MQTT，它是為大量計算能力有限，且工作在低頻寬、不可靠的網路的遠端感測器，和控制設備通訊而設計的協議。但是也不阻止你選擇其他協議，比如 AMQP，STOMP 等。
當然，各大廠商都有對消息隊列服務協議的實現，支持的協議最全面的就是 Apache ActiveMQ，STOMP 是基於純文本的消息傳輸協議，不用考慮，MQTT 協議實現的，代表是出自EMQ，AMQP 協議實現的代表則是 RabbitMQ。
當然，各大廠商都有對消息隊列服務協議的實現，支持的協議最全面的就是 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 Gateway 的角色，根據事先配置好的路由規則，將客戶端請求轉發到相應的微服務中進行處理；
② 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，通知服務。管理整個設備 Gateway 的通知業務，手機推送使用的是個推平台，此外還結合了郵件通知，我們可以直接使用 Spring Boot 自帶的一個 mail 組件。
5、總結
承接上一篇的系統架構設計文章，這篇文章詳細介紹了物聯網設備 Gateway 的技術架構設計，及其所用到的核心通信框架 Netty。然而，對於各個技術的實現，本文沒有做太具體的介紹，因為涉及到了代碼層面的詳細設計環節了，後續有機會會出具體實現的文章。
康橋科技 —— 白光攝影機專業廠商！
 |
| 康橋科技 —— 白光攝影機專業廠商！ |
0 comments:
張貼留言