泊菲萊設備管理平台之技術選型

按照標準的項目開發和管理流程，我們首先分析項目需求並選擇合適的技術。

核心需求

從需求環境上看項目的特點：

碎片化

我們面臨的是一個硬體設備碎片化的環境。除了可以大致按照設備大致功能的分類外，其實從硬體的設計、設備的操作流程、參數是否確定、部件的選型、硬體是否模塊化、前期的整理和歸檔等都是不統一的。並且按照所處行業——科研實驗儀器的特殊性和設備開發流程看，最起碼短期內也很難有設備的標準化和技術統一。這就給編程時開發和設計設備模型的帶來了很多不確定性和難度！

平台化管理要求

這個需求領導認為是該項目最有價值的部分，而我也深以為然！

通俗的講我們不是僅僅做出一個解決通訊來查詢信息的工具，而是要大規模收集、存儲並理解行為信息最終像大腦一樣，可以用邏輯思維方式幫助解決客戶的問題。所謂平台化，就是要對信息資源進行深度開發利用。就像當今的專業諮詢策劃機構一樣，不僅接受諮詢，還提供解決方案，一站式完成。這就是平台化的價值。

應用場景多樣化

這裡的應用場景有兩層意思：

其一，設備的應用場景很複雜，這裡面就牽扯到一個很嚴重的問題：設備以何種方式接入平台並且能夠保證可控；

其二，用戶的使用場景考量，這裡包括了用戶與設備的管理許可權關係複雜，操作終端多樣化。舉兩個簡單的例子：

例1，我們的客戶老師領導了一個學生實驗團隊，老師自行管理學生的賬號。他可能會對其中的某幾個學生開放某一個環節的設備操作許可權，其他人都只有監控許可權，而對於某一個學生他可能有實驗室里某幾個環節的設備的操作權而其他設備他只能監控。這樣我們給老師提供了一部分團隊管理的功能但同時設備和賬戶就變成了複雜的多對多的關係。

例2，比方說小型的測試設備如光功率計，就為了監控測量值你不能指望實驗者還要屁顛屁顛去開電腦登陸平台去查看吧，這的多麻煩啊！因此手機等移動便攜設備也必須是操作終端的一部分，具體來說就是客戶可以用電腦也可以用手機端來使用平台，並且根據不同的設備操作的方式和複雜度也不相同。

需求不明確

平台需要適應未來設備的不確定性，同時會以服務客戶為核心來開發方便使用的新特性，最關鍵的考慮未來和行業上下游進行數據的對接。所以系統也是需要一個高的拓展性來不停地迭代。

開發團隊不健全

這個就不詳細說了，面對上述的這麼樣一個情況最基本也需要一個前端工程師搭一個後端工程師的配置。

可喜的是領導沒有對時間做硬性規定

雖然領導沒有做硬性時間規定，但快速開發、快速迭代是目前最好的選擇。

架構和技術選型

綜上我們的系統需要滿足以下要求：

高解耦（非常重要）

高可擴展性

高適應性和好的穩定性

模塊化（規範化）和對外介面

I/O的高並發（設備數據監控）

數據的高實時性

最好能夠快速開發

設計時，我們先將系統解耦為兩個獨立架構：物聯網部分和應用程序部分。

考慮到我們要做的是一個平台化的項目，應用程序必然基於互聯網來開發，因此應用程序和物聯網也必然是通過互聯網來通訊。開始我對物聯網的構思是硬體添加網卡模塊聯網，通過websocket來和應用程序通訊，後來發現這個對硬體端要求比較高，同時設備所處的網路環境也必須有保障，並且設備和設備之間的通訊也很難實現，所以最終放棄了這一方案，轉而考慮專業的物聯網協議。目前物聯網通信技術有兩大分支：互聯網技術系和移動蜂窩技術系(短距離通信不算，因為不符合我們的需求)。兩個陣營都有可靠的通信協議實現。考慮與互聯網的對接和高適應性和穩定性我們最終選擇了MQTT協議。

物聯網應用層協議介紹——MQTT

物聯網應用層協議介紹——CoAP

應用程序開始的設想是如下圖照搬阿里巴巴的模式

node.js作為大前端來使用，業務內核還是傳統的JAVA來實現，針對監控設備時產生的I/O高並發情況使用t-io庫來做性能提升。可是卻無法達到高可拓展和高實時性。

為了解決高實時性問題，考慮了很多解決方案，最後確定直接將瀏覽器作為一個MQTT的客戶端，使用了mqtt.js開源庫，該開源庫屬於node.js的技術棧。因此後端也為了統一數據格式更快的響應速度也放棄了JAVA內核，轉而全部用node.js實現。並且基於快速開發採用了阿里巴巴的node.js框架egg.js。

了解node.js看這一篇就可以了

技術選型完成。下面就開始應用程序架構的設計了。在充分模擬後，考慮到模塊化和可拓展性採用了前後端分離和RESTful設計風格。

至此泊菲萊設備平台的技術選型和架構設計基本完成。資料庫和模型設計因為不是難點所以在這裡略過。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！