我一直覺得物聯(lián)網(wǎng)這行有個特別有意思的現(xiàn)象講方案的人喜歡把“云、管、端”掛在嘴邊可真要自己動手做項目很多人連第一步的設(shè)備接入都卡半天。這篇是我整理“物聯(lián)網(wǎng)技術(shù)架構(gòu)”這一章時的完整筆記不繞彎子直接從“口紅說物聯(lián)網(wǎng)”這個梗講起把感知層、網(wǎng)絡(luò)層、平臺層、應(yīng)用層一層層掰開揉碎配合ESP32-S3環(huán)境監(jiān)測、ULN2003A擴展IO、Spring Boot 3.x Netty MQTT智能充電樁這些真實能落地的項目經(jīng)驗幫你把物聯(lián)網(wǎng)技術(shù)架構(gòu)從概念變成能動手的東西。不管是做畢業(yè)設(shè)計、準備物聯(lián)網(wǎng)安裝調(diào)試員競賽還是想轉(zhuǎn)行進物聯(lián)網(wǎng)工程方向這篇都值得收藏。1. 物聯(lián)網(wǎng)技術(shù)架構(gòu)的全景認知三層到四層是怎么來的1.1 從“口紅說”看物聯(lián)網(wǎng)的本質(zhì)網(wǎng)上有個很火的“口紅說物聯(lián)網(wǎng)”我當時看完覺得特別貼切。一根口紅拆開看其實就是三樣東西外殼、旋轉(zhuǎn)底座、膏體。外殼負責貼合使用場景旋轉(zhuǎn)底座負責把膏體一點點推出來膏體才是最后涂在嘴唇上的顏色本體。物聯(lián)網(wǎng)也一樣。傳感器和執(zhí)行器就是“外殼”負責貼合物理世界數(shù)據(jù)傳輸就是“旋轉(zhuǎn)底座”負責把采集到的信號從端側(cè)推出去而云平臺和應(yīng)用系統(tǒng)就是“膏體”數(shù)據(jù)經(jīng)過處理之后變成對人類有價值的信息。這個比喻雖然生活化但把物聯(lián)網(wǎng)技術(shù)架構(gòu)的核心邏輯說透了任何一朵“物聯(lián)網(wǎng)”的花都跑不出“采集—傳輸—處理—應(yīng)用”這條主線。所以你在看任何一份物聯(lián)網(wǎng)技術(shù)架構(gòu)圖的時候不要被那些花哨的方框嚇到。先問三個問題數(shù)據(jù)從哪來數(shù)據(jù)怎么傳數(shù)據(jù)到哪去、怎么用把這三條主線串起來整個架構(gòu)就立住了。1.2 分層架構(gòu)為什么實用一次環(huán)境監(jiān)測項目的拆解分層不是學術(shù)派硬造出來的概念是為了讓你改代碼的時候少掉頭發(fā)。我見過不少學生項目采集、上傳、顯示全部寫在一個文件里設(shè)備多了之后想加一個傳感器都得翻半天邏輯。我自己做一個ESP32-S3環(huán)境監(jiān)測節(jié)點的時候是嚴格按四層來拆的感知層DHT22溫濕度傳感器、SGP30空氣質(zhì)量傳感器負責采集原始數(shù)據(jù)。網(wǎng)絡(luò)層設(shè)備通過Wi-Fi連接路由器用MQTT協(xié)議把JSON數(shù)據(jù)包發(fā)布到主題topic/sensor/env。平臺層本地部署的EMQX Broker負責消息轉(zhuǎn)發(fā)后端服務(wù)訂閱該主題把數(shù)據(jù)解析后寫入時序數(shù)據(jù)庫。應(yīng)用層Web端和手機小程序從后端API讀取數(shù)據(jù)繪制溫濕度趨勢曲線超出閾值時觸發(fā)告警。這樣拆完以后每一層的職責非常清晰。傳感器壞了只需要換感知層MQTT斷連了只需要查網(wǎng)絡(luò)層數(shù)據(jù)庫寫不進去了直接定位平臺層。不同層之間通過標準接口協(xié)議和數(shù)據(jù)結(jié)構(gòu)通信調(diào)試的時候可以單獨測每一層。1.3 別忽略架構(gòu)里的“橫切面”安全、設(shè)備管理與生命周期除了上面四個縱向?qū)哟挝锫?lián)網(wǎng)技術(shù)架構(gòu)里還有幾個“橫切面”。安全是最容易被新手忽視的。我見過有人為了讓設(shè)備快速上線把Wi-Fi密碼和服務(wù)器地址直接明文寫死在固件里這其實等于把家門鑰匙掛在門口。設(shè)備管理也很重要。幾十個設(shè)備在線的時候你要知道哪些設(shè)備離線了、固件版本是多少、電池電量還剩多少。平臺層的設(shè)備影子功能就是干這個的。生命周期管理則是指設(shè)備從注冊、激活、在線、離線到注銷的全過程尤其是量產(chǎn)之后的設(shè)備批量注冊數(shù)據(jù)模型設(shè)計得不好會非常痛苦。這四個橫切面建議在項目一開始就規(guī)劃而不是等出了問題再補。2. 感知層數(shù)據(jù)從哪來節(jié)點怎么選2.1 傳感器選型心法不是越貴越好感知層是整個物聯(lián)網(wǎng)技術(shù)架構(gòu)的起點傳感器的選型直接決定項目成敗。很多初學者挑傳感器只看兩樣價格和例程數(shù)量。實際上應(yīng)該按下面這個順序來第一確定量程和精度。測大棚溫度溫度范圍0到50攝氏度就夠非要買工業(yè)級的-40到125攝氏度探頭性能和成本都是浪費。第二確定輸出接口。數(shù)字接口I2C、SPI、單總線抗干擾能力強模擬接口ADC在長線傳輸時容易受噪聲影響。第三確定功耗水平。電池供電的項目傳感器待機電流和采樣周期是核心指標我之前用過一款激光粉塵傳感器霧化功耗能到100mA左右用電池根本撐不住后來換成紅外式的才解決問題。另外新手容易忽略傳感器的一致性。同一型號的傳感器個體差異可能會讓測量結(jié)果偏差較大尤其是模擬輸出的氣體傳感器。批量部署前最好做一次標定把校準系數(shù)寫進設(shè)備配置里。2.2 ESP32-S3項目實測環(huán)境監(jiān)測節(jié)點怎么搭ESP32-S3是我目前最推薦的入門級物聯(lián)網(wǎng)主控雙核240MHz、支持Wi-Fi和藍牙、GPIO數(shù)量充足而且有原生USB接口調(diào)試方便。做一個典型的環(huán)境監(jiān)測節(jié)點接線大概是這樣DHT22數(shù)據(jù)腳接GPIO4VCC接3.3VGND接GND。SGP30用I2C接口SDA接GPIO8SCL接GPIO9VCC接3.3V。板載LED接GPIO2用于狀態(tài)指示。數(shù)據(jù)采集和上報的核心邏輯很簡單每次采樣后組織成JSON然后通過MQTT發(fā)布到Broker。一個最小可運行的ESP-IDF或Arduino代碼骨架如下#include WiFi.h #include PubSubClient.h #include DHT.h const char* ssid your_wifi; const char* password your_password; const char* mqtt_server 192.168.1.100; const char* topic sensor/env; WiFiClient espClient; PubSubClient client(espClient); DHT dht(4, DHT22); void setup() { Serial.begin(115200); WiFi.begin(ssid, password); while (WiFi.status() ! WL_CONNECTED) { delay(500); Serial.print(.); } client.setServer(mqtt_server, 1883); dht.begin(); } void loop() { if (!client.connected()) { reconnect(); } client.loop(); float h dht.readHumidity(); float t dht.readTemperature(); if (isnan(h) || isnan(t)) { Serial.println(Failed to read from DHT sensor!); delay(2000); return; } String payload {\humidity\: String(h) , \temperature\: String(t) }; client.publish(topic, payload.c_str()); delay(5000); }這里有幾個容易被坑的點DHT22剛上電的時候讀取容易失敗要等兩秒以上MQTT的client.loop()必須頻繁調(diào)用否則會收不到心跳響應(yīng)Wi-Fi連接過程中阻塞時間太長會拖垮整個采樣周期。另外如果傳感器和主控之間有較長的杜邦線建議加一個0.1uF的去耦電容在傳感器電源腳附近。2.3 IO不夠ULN2003A救急方案從原理到實戰(zhàn)做物聯(lián)網(wǎng)項目最尷尬的事情就是功能想好了代碼寫完了一看主控IO不夠了。ESP32-S3的GPIO雖然多但有些引腳被Flash、PSRAM、USB占用了實際可用的并不多。這時候ULN2003A就是我常用的救急方案。ULN2003A本質(zhì)上是一個達林頓晶體管陣列內(nèi)部集成了7路獨立的達林頓對每一路可以承受最大500mA的灌電流非常適合驅(qū)動繼電器、LED燈帶、步進電機這些外圍設(shè)備。核心思路是用主控的小電流GPIO去控制ULN2003A的輸入端ULN2003A輸出端直接驅(qū)動大電流負載輸入輸出之間還有內(nèi)部續(xù)流二極管接感性負載的時候尤其好用。接線方式也很直觀GPIO輸出高電平時ULN2003A內(nèi)部達林頓管導通輸出端對地導通負載接在VCC和輸出端之間就會通電。注意它的輸出是集電極開路結(jié)構(gòu)實際是“灌電流”驅(qū)動千萬別接反成推挽輸出。實際項目中我用它擴展了8路繼電器控制一個微型溫室的風扇、加熱片、補光燈和霧化器。代碼上幾乎不用改把原來直接控制GPIO的邏輯換成控制ULN2003A對應(yīng)的輸入引腳就行。不過有一點要提醒ULN2003A導通時會有大概1V左右的壓降如果負載對供電電壓敏感得把這個壓降算進去。2.4 無源物聯(lián)網(wǎng)感知層正在發(fā)生的變革這兩年“無源物聯(lián)網(wǎng)”的熱度越來越高它不是簡單地省電而是完全不要電池。核心原理是反向散射通信設(shè)備端從環(huán)境中的射頻信號里獲取能量同時通過調(diào)制反射信號來傳數(shù)據(jù)。遠距離RFID就是最典型的例子。無源物聯(lián)網(wǎng)對技術(shù)架構(gòu)最大的影響在感知層的部署密度。沒有電池、沒有維護成本傳感器節(jié)點就可以像墻紙一樣鋪到任何地方。目前在物流盤點、冷鏈監(jiān)測、智能倉儲這些場景已經(jīng)有落地應(yīng)用。做項目的時候如果節(jié)點數(shù)量極多、布線困難可以考慮這類方案。但它也有明顯的限制通信距離短、數(shù)據(jù)量小、實時性差。所以選型的時候不要拿它去對標LoRa和NB-IoT它們解決的問題不在一個維度。3. 網(wǎng)絡(luò)層數(shù)據(jù)怎么傳協(xié)議怎么選3.1 一張表看懂主流通信方案怎么選網(wǎng)絡(luò)層是整個物聯(lián)網(wǎng)技術(shù)架構(gòu)里“花樣”最多的一層因為可選的通信方式實在太多。我直接把自己常用的選型參考表放出來通信方式頻段/特點速率功耗成本適用場景Wi-Fi2.4GHz/5GHz適合室內(nèi)高Mbps級較高低智能家居、室內(nèi)環(huán)境監(jiān)測藍牙BLE2.4GHz短距中Kbps級極低低穿戴設(shè)備、手機互聯(lián)ZigBee2.4GHz自組網(wǎng)低Kbps級低低樓宇自動化、傳感器網(wǎng)絡(luò)LoRa470/868/915MHz遠距穿透強低Kbps級低中農(nóng)業(yè)、城市、野外長距離傳輸NB-IoT運營商蜂窩網(wǎng)絡(luò)中低低中智能表計、市政設(shè)施4G/5G蜂窩網(wǎng)絡(luò)覆蓋廣高高較高車聯(lián)網(wǎng)、視頻監(jiān)控、移動設(shè)備選型有三個原則先看距離再看速率最后看功耗。室內(nèi)幾十米范圍選Wi-Fi或藍牙室外幾公里且數(shù)據(jù)量小LoRa比NB-IoT更靈活因為不依賴運營商信號覆蓋如果要傳輸視頻流或大量圖片只能在Wi-Fi和4G/5G里選。千萬不要一上來就堆參數(shù)架構(gòu)設(shè)計最怕的就是為了“炫技”選一個根本不匹配的方案。3.2 MQTT為什么是物聯(lián)網(wǎng)的事實標準網(wǎng)絡(luò)層的協(xié)議選擇上MQTT是目前繞不開的一個。它是基于發(fā)布/訂閱模式的輕量級消息協(xié)議專為低帶寬、高延遲、網(wǎng)絡(luò)不穩(wěn)定的環(huán)境設(shè)計。我選它有三個理由第一異步解耦。設(shè)備不需要知道平臺端有哪些消費者直接把數(shù)據(jù)發(fā)布到主題上就行。平臺、數(shù)據(jù)庫、告警服務(wù)各自訂閱自己關(guān)心的主題互不干擾。第二 QoS機制。MQTT支持QoS 0、1、2三檔在弱網(wǎng)環(huán)境下可以保證消息不丟。做實際項目的時候我一般用QoS 1兼顧可靠性和開銷。QoS 2雖然最可靠但握手流程復(fù)雜非關(guān)鍵數(shù)據(jù)沒必要。第三特殊消息設(shè)計。遺囑消息LWT可以在設(shè)備異常斷線時自動發(fā)布“設(shè)備離線”通知保留消息Retained Message可以讓新訂閱的設(shè)備立刻拿到最新狀態(tài)這兩個特性在設(shè)備狀態(tài)管理里非常有用。Broker選型方面小規(guī)模測試用Mosquitto就夠了單機幾萬個連接的話上EMQX它對弱網(wǎng)和大量客戶端連接的優(yōu)化做得更好。MQTT的Topic命名也要提前規(guī)劃我習慣用層級結(jié)構(gòu)比如projectid/location/devicetype/deviceid/data這樣在Broker端做權(quán)限控制和數(shù)據(jù)分流都方便。3.3 網(wǎng)絡(luò)層最容易踩的坑弱網(wǎng)、并發(fā)與斷線重連網(wǎng)絡(luò)層有很多問題是寫代碼時發(fā)現(xiàn)不了的一定要到真機上跑才能暴露。弱網(wǎng)環(huán)境下Wi-Fi信號可能只有一格TCP連接頻繁超時MQTT的心跳包發(fā)不出去。這時設(shè)備端要設(shè)置合理的心跳間隔我常用的值是30到60秒太短會增加功耗和服務(wù)器壓力太長會導致斷線發(fā)現(xiàn)延遲。另外重連一定要加退避策略不能設(shè)備一斷線就瘋狂重連否則幾百臺設(shè)備同時重連會把Broker打掛。高并發(fā)連接是另一個大坑。我調(diào)試過一個接入500臺設(shè)備的小系統(tǒng)最初用的是默認配置的Mosquitto結(jié)果單機連接數(shù)一上去內(nèi)存直接飆滿。后來把文件描述符上限調(diào)高分區(qū)大小調(diào)整好并且換成了EMQX才穩(wěn)定住。無論如何做架構(gòu)設(shè)計時就得想清楚設(shè)備的規(guī)模從幾百臺到幾萬臺Broker的部署方案完全不同。NAT環(huán)境下還有一個問題設(shè)備在局域網(wǎng)里平臺端無法主動訪問設(shè)備。解決辦法是讓設(shè)備主動維持一條到平臺的長連接MQTT本身就是長連接平臺通過下行消息反向控制。不要指望直接ping通設(shè)備那是TCP/IP的思維方式不是物聯(lián)網(wǎng)的思維方式。4. 平臺層與應(yīng)用層數(shù)據(jù)怎么管、怎么用4.1 公有云IoT平臺與開源自建怎么取舍平臺層是整個物聯(lián)網(wǎng)技術(shù)架構(gòu)的中樞。新手做項目最容易糾結(jié)的就是用公有云物聯(lián)網(wǎng)平臺還是自己搭。公有云物聯(lián)網(wǎng)平臺比如阿里云物聯(lián)網(wǎng)平臺這一類成熟服務(wù)確實省事設(shè)備接入、物模型、規(guī)則引擎、告警、OTA都是現(xiàn)成的。但它有兩個問題一是商業(yè)化產(chǎn)品的規(guī)則和限制比較多二是如果遇到“新購受限”或者平臺調(diào)整產(chǎn)品策略你的存量設(shè)備會非常被動。我在幫朋友處理一個公有云物聯(lián)網(wǎng)設(shè)備遷移項目時就因為某公有云物聯(lián)網(wǎng)平臺突然不再支持新購實例不得不整體遷移到自建平臺。如果你的項目需要長期維護、設(shè)備量可控我更推薦自建方案。技術(shù)?？梢赃@樣組合EMQX做設(shè)備接入層TDengine或InfluxDB做時序數(shù)據(jù)存儲后端用Spring Boot或Node.js做業(yè)務(wù)邏輯前端用Vue或小程序做展示。這套組合的好處是每一層都能自己掌控不受制于人。自建平臺的核心源碼網(wǎng)上也有不少開源項目可以學習重點看設(shè)備接入、物模型、規(guī)則引擎這三塊的實現(xiàn)思路。4.2 繪制物聯(lián)網(wǎng)應(yīng)用系統(tǒng)的工作過程先畫數(shù)據(jù)流再畫架構(gòu)很多人畫圖時喜歡先畫一堆設(shè)備和云平臺結(jié)果圖畫得挺好看評審一問“數(shù)據(jù)是怎么流轉(zhuǎn)的”就卡殼。我的經(jīng)驗是畫物聯(lián)網(wǎng)應(yīng)用系統(tǒng)的工作過程核心是畫“數(shù)據(jù)流”不是畫“設(shè)備拓撲”。我自己的建模套路是六步列出所有物理對象傳感器、執(zhí)行器、網(wǎng)關(guān)、攝像頭等。列出每個對象產(chǎn)生的數(shù)據(jù)項溫度、濕度、開關(guān)狀態(tài)、坐標等。標明數(shù)據(jù)的流向從哪個設(shè)備出來經(jīng)過什么協(xié)議到哪個服務(wù)。標明數(shù)據(jù)在哪里被存儲采用什么數(shù)據(jù)庫保留多久。標明數(shù)據(jù)在哪里被消費Web頁面、大屏、告警還是手機App。標明數(shù)據(jù)閉環(huán)比如溫度超過某個值之后系統(tǒng)如何下發(fā)指令給執(zhí)行器。拿一個很常見的校園宿舍環(huán)境監(jiān)測系統(tǒng)來舉例宿舍里的ESP32節(jié)點采集溫濕度和PM2.5通過Wi-Fi和MQTT上傳到校園網(wǎng)的EMQX Broker后端服務(wù)訂閱數(shù)據(jù)并寫入時序數(shù)據(jù)庫Web管理端和宿舍大屏實時展示數(shù)據(jù)超過閾值時后端自動發(fā)布指令到執(zhí)行器節(jié)點打開排氣扇。把這條數(shù)據(jù)通路畫完整哪怕一幅圖里一個圖標都沒有評審也能看懂你的系統(tǒng)是怎么工作的。4.3 Spring Boot 3.x Netty MQTT實戰(zhàn)智能充電樁怎么拆智能充電樁是這兩年畢業(yè)設(shè)計和競賽里出現(xiàn)頻率很高的物聯(lián)網(wǎng)項目。它本質(zhì)上是“設(shè)備端采集電流電壓 → 上報狀態(tài) → 平臺計費控制 → 下發(fā)通斷指令”的一個完整閉環(huán)非常適合用來理解物聯(lián)網(wǎng)技術(shù)架構(gòu)的應(yīng)用層。我拆一個基于Spring Boot 3.x Netty MQTT的充電樁后端架構(gòu)充電樁設(shè)備內(nèi)部一般是一塊STM32或ESP32主板負責采集電壓電流、檢測插槍狀態(tài)通過4G或Wi-Fi連接云端。設(shè)備端和云端之間的協(xié)議既可以用MQTT承載JSON數(shù)據(jù)也可以用Netty自研TCP私有協(xié)議。如果走MQTT平臺側(cè)直接用Spring Boot集成MQTT客戶端訂閱充電樁主題比如charging/pile1/report和charging/pile1/status。如果需要走自研TCP協(xié)議就用Netty做網(wǎng)關(guān)處理粘包拆包、心跳維持和指令下發(fā)。Spring Boot 3.x里配置MQTT客戶端的核心邏輯大概是這樣的spring: mqtt: url: tcp://localhost:1883 username: emqx password: public client-id: backend-service default-topic: charging/# timeout: 30 keepalive: 60后端收到數(shù)據(jù)之后先做協(xié)議解析把電壓電流、電量和充電狀態(tài)落到業(yè)務(wù)表里然后通過規(guī)則判斷是否觸發(fā)告警。比如充電樁溫度超過85度后端自動下發(fā)斷開指令。指令下發(fā)走的是同一個MQTT連接只是Topic方向反過來charging/pile1/command。如果你用Netty做TCP網(wǎng)關(guān)最核心的就是編解碼器。自定義協(xié)議一定要設(shè)計好幀格式我用的是“幀頭長度消息體CRC校驗”的結(jié)構(gòu)。解析時要注意TCP粘包和拆包問題Netty里用LengthFieldBasedFrameDecoder就能解決不需要自己造輪子。這里的經(jīng)驗是協(xié)議字段長度盡量不要用變長定長字段解析起來既簡單又不容易出錯。5. 常見問題與排查技巧實錄5.1 畢業(yè)設(shè)計和競賽中的高頻翻車點這幾年我斷斷續(xù)續(xù)看過不少畢業(yè)設(shè)計和物聯(lián)網(wǎng)競賽作品翻車的地方其實高度集中。最大的問題是“只做表面”。很多人把精力花在繪制精美的H5頁面上結(jié)果設(shè)備端只有一套模擬數(shù)據(jù)在輪播。評審老師隨便一問他“真實傳感器采集的值和模擬值差異在哪兒”項目就露餡了。物聯(lián)網(wǎng)項目最核心的競爭力永遠是“真實閉環(huán)”真實設(shè)備、真實采集、真實鏈路哪怕展示簡陋一點也比純模擬強一百倍。第二個問題是“項目范圍失控”。物聯(lián)網(wǎng)項目天然是橫跨硬件、嵌入式、網(wǎng)絡(luò)、后端、前端的全棧工程。一個人不可能每個環(huán)節(jié)都做到極致。我的建議是畢設(shè)或者競賽項目選擇一條最短的真實鏈路做完做透。比如做一個單節(jié)點環(huán)境監(jiān)測MQTT上傳Web展示閾值告警這已經(jīng)是完整項目了不要貪多。第三個問題是設(shè)備端異常處理做得太粗。我給競賽評審的時候看過一個溫室大棚項目插頭一松整個系統(tǒng)直接白屏。設(shè)備端沒有重連機制、沒有看門狗、沒有離線緩存基本都是扣分重災(zāi)區(qū)。至少要做到斷網(wǎng)自動重連、斷電重啟后能恢復(fù)到上次狀態(tài)、采集失敗有日志。物聯(lián)網(wǎng)安裝調(diào)試員競賽這類賽項里重點考察的是現(xiàn)場接線、組網(wǎng)配置、云平臺接入和設(shè)備調(diào)試的規(guī)范流程。平時訓練一定要熟記各種傳感器的引腳定義和通信協(xié)議比賽現(xiàn)場沒有時間讓你翻數(shù)據(jù)手冊。5.2 學習物聯(lián)網(wǎng)需要什么軟件我的工具清單這個問題被問過太多次我直接列一份我現(xiàn)在還在用的工具清單硬件開發(fā)Arduino IDE入門友好、ESP-IDF專業(yè)開發(fā)、STM32CubeMXKeil工業(yè)級MCU。電路設(shè)計/仿真立創(chuàng)EDA國產(chǎn)上手快、Fritzing面包板接線圖。網(wǎng)絡(luò)調(diào)試MQTTXMQTT調(diào)試神器、Wireshark抓包分析、Xshell遠程終端。平臺服務(wù)EMQXMQTT Broker、Docker一鍵部署各種中間件、TDengine/InfluxDB時序數(shù)據(jù)庫。后端開發(fā)IntelliJ IDEA、VS Code、Postman。畫圖工具draw.io、ProcessOn畫架構(gòu)圖和數(shù)據(jù)流圖足夠。初學者最容易犯的錯誤是“把時間花在裝環(huán)境上”。其實不用一開始就把所有工具配齊先用Arduino IDE點亮一塊ESP32板子配合MQTTX收發(fā)幾條消息把最基礎(chǔ)的數(shù)據(jù)鏈路跑通再一層層往外擴展。工具永遠是服務(wù)于鏈路的鏈路通了工具自己就會了。5.3 物聯(lián)網(wǎng)工程就業(yè)方向的一點觀察最后聊一下就業(yè)這也是很多人學物聯(lián)網(wǎng)技術(shù)架構(gòu)最關(guān)心的落點。物聯(lián)網(wǎng)工程專業(yè)看起來什么都學但就業(yè)方向上大致可以分四條線嵌入式開發(fā)方向主要做單片機、RTOS、外設(shè)驅(qū)動核心技能是C/C和電路基礎(chǔ)崗位多門檻相對低適合喜歡跟硬件打交道的人。IoT平臺開發(fā)方向主要做設(shè)備接入服務(wù)、消息處理、數(shù)據(jù)存儲和系統(tǒng)架構(gòu)核心技能是Java/Python、MQTT、數(shù)據(jù)庫和分布式對系統(tǒng)設(shè)計能力要求更高。測試與運維方向做的是設(shè)備兼容性測試、平臺穩(wěn)定性壓測、物聯(lián)網(wǎng)系統(tǒng)的部署運維懂協(xié)議、懂網(wǎng)絡(luò)、懂日志分析就能干。解決方案方向主要面向客戶把業(yè)務(wù)需求翻譯成技術(shù)方案對溝通和全局視野要求最高但是越老越吃香。我的個人建議是物聯(lián)網(wǎng)這個領(lǐng)域最稀缺的不是單項技術(shù)專家而是能把“端、管、云、用”串起來的人。學架構(gòu)的時候不要只盯著某一個層次可以試著把每一層都自己動手跑一遍。哪怕只是用ESP32發(fā)一條消息到本地Broker再用Python腳本訂閱下來打印出來這個經(jīng)歷也會讓你對物聯(lián)網(wǎng)技術(shù)架構(gòu)的理解遠超只畫圖不落地的人。最后再分享一個我自己的習慣拿到任何一個物聯(lián)網(wǎng)項目需求不要立刻去選型硬件或者寫代碼先在一張紙上把數(shù)據(jù)流畫出來。從傳感器到平臺再從平臺到執(zhí)行器一條條標注清楚。這張數(shù)據(jù)流圖既是項目的骨架也是后面跟隊友、導師、客戶溝通的共同語言。畫圖的過程其實就是用“口紅說”的方式把一朵飄在空中的物聯(lián)網(wǎng)拉回到地面上。