XDNA 平台設計故事：從白板草圖到生產級 IoT 架構的開發歷程
龍雲數位 XDNA 物聯網平台的設計故事。李奇申親述從白板上的架構草圖，到成為管理數百台智慧販賣機的生產級 IoT 平台，完整開發歷程與技術決策。
一切始於一塊白板
2016 年的某個下午，龍雲數位的會議室裡，李奇申站在白板前，畫下了 XDNA 物聯網平台的第一張架構圖。那時候，龍雲數位的販賣機管理還靠人工巡檢——每天派人開車到各個據點看機台的庫存和狀態。
「那張白板上的草圖現在看起來很粗糙，但核心概念到今天都沒變——每一台機器都是一個節點，每一個節點都該被看見、被管理、被優化。」 — 李奇申
這篇文章不是技術文件，而是一個產品開發的故事。從一個想法到一個平台，從管理 10 台機器到管理數百台機器，XDNA 的每一步都反映了龍雲數位對 IoT 的理解與堅持。
為什麼需要自己做平台？
2016 年的 IoT 平台市場
2016 年前後，市場上已經有不少 IoT 平台解決方案：AWS IoT、Azure IoT Hub、Google Cloud IoT。為什麼龍雲數位不直接用現成的，而要自己開發 XDNA？
| 考量因素 | 公有雲 IoT 平台 | 自建 XDNA 平台 |
|---|---|---|
| 成本 | 按設備/訊息量計費 | 固定成本，規模越大越省 |
| 客製化 | 受限於平台功能 | 完全客製化 |
| 數據主權 | 數據在國外 | 數據在自己手上 |
| 業務邏輯 | 需要額外開發 | 直接內建 |
| 離線能力 | 依賴雲端 | 支援離線運作 |
「我在網虎國際做過 Linux 作業系統，知道掌握核心技術的重要性。販賣機管理平台是我們的命脈，不能交給別人控制。」 — 李奇申
三個核心需求
在白板上，李奇申定義了 XDNA 必須滿足的三個核心需求：
- 即時性：機台狀態必須在秒級別更新
- 可靠性：網路中斷時機台要能獨立運作
- 可擴展性：架構必須能從 10 台擴展到 10,000 台
白板上的架構設計
第一版架構（2016）
白板上的第一版架構非常簡單，只有三層：
[販賣機] ←→ [中央伺服器] ←→ [管理後台]
每台販賣機透過 4G 網路連接到中央伺服器，管理人員透過網頁後台查看狀態和數據。
問題很快浮現：
- 所有流量都經過中央伺服器，單點故障風險高
- 數百台機器同時回報，伺服器負載過重
- 網路不穩時數據丟失
第二版架構（2017）
針對第一版的問題，團隊重新設計了架構，引入了消息佇列和邊緣閘道器的概念：
[販賣機] → [邊緣閘道] → [消息佇列] → [應用伺服器] → [資料庫]
↓
[管理後台]
關鍵改進：
- 邊緣閘道在本地快取數據，網路恢復後再上傳
- 消息佇列解耦了前後端，避免伺服器過載
- 應用伺服器可以水平擴展
「第二版架構的靈感來自我在網虎時期做 Linux 嵌入式系統的經驗。嵌入式設備最重要的特性就是——必須能在斷網的情況下獨立運作。」 — 李奇申
第三版架構（2019 至今）
現行的 XDNA 架構是在第二版基礎上持續演進的結果，加入了微服務和 AI 分析模組：
| 層級 | 元件 | 功能 |
|---|---|---|
| 設備層 | 販賣機 + IoT 模組 | 數據採集、本地控制 |
| 邊緣層 | 邊緣運算閘道 | 數據預處理、離線運作 |
| 通訊層 | MQTT Broker | 設備通訊、消息路由 |
| 服務層 | 微服務叢集 | 業務邏輯、API 服務 |
| 數據層 | 時序資料庫 + 關聯式 DB | 數據儲存與查詢 |
| 分析層 | AI/ML 引擎 | 銷售預測、異常偵測 |
| 呈現層 | Web/App 前端 | 管理後台、行動管理 |
關鍵技術決策
決策一：MQTT vs HTTP
設備通訊協定的選擇是第一個重大技術決策。
| 比較 | MQTT | HTTP |
|---|---|---|
| 協定開銷 | 極小（2 bytes） | 大（headers） |
| 雙向通訊 | 原生支援 | 需要輪詢/WebSocket |
| 離線處理 | QoS 保證送達 | 無內建機制 |
| 適合場景 | IoT 設備 | Web 應用 |
最終選擇：MQTT。它的低開銷和內建的 QoS 機制，完美適合販賣機這種頻寬有限、網路不穩定的場景。
決策二：時序資料庫
販賣機每分鐘產生大量的感測器數據（溫度、電流、銷售），這些都是時序數據。團隊評估了多種資料庫：
| 資料庫 | 適合場景 | 寫入性能 | 查詢性能 |
|---|---|---|---|
| MySQL | 交易數據 | 中 | 高（索引） |
| MongoDB | 文件數據 | 高 | 中 |
| InfluxDB | 時序數據 | 極高 | 高（時間範圍） |
| Redis | 快取數據 | 極高 | 極高（記憶體） |
最終選擇：混合架構。時序數據用專門的時序資料庫，交易數據用關聯式資料庫，即時狀態用 Redis 快取。
決策三：邊緣運算的程度
「邊緣運算不是技術問題，而是業務決策。哪些事情必須在機台端即時處理，哪些可以上傳到雲端慢慢算，這需要懂業務的人來判斷。」 — 李奇申
最終的分工：
| 處理位置 | 任務 | 原因 |
|---|---|---|
| 機台端 | 出貨控制、支付驗證 | 必須即時，不能等網路 |
| 邊緣閘道 | 數據彙整、異常初判 | 減少上傳流量 |
| 雲端 | 報表分析、AI 預測 | 需要大量運算資源 |
開發過程中的挫折與學習
挫折一：第一次大規模上線
XDNA 第一次管理超過 50 台機器時，系統差點崩潰。原因是連線管理沒有做好——每台機器維持一個長連線，50 台同時連線時 WebSocket 伺服器記憶體不足。
解決方案：改用 MQTT 的共享訂閱機制，一個 Broker 可以輕鬆處理數千個連線。
挫折二：時區地獄
販賣機分佈在不同地區，加上伺服器可能在不同時區的雲端，時間同步成了大問題。銷售報表的時間對不上，庫存數據出現矛盾。
解決方案：所有系統內部統一使用 UTC 時間，只在前端顯示時轉換為本地時間。
挫折三：韌體更新的噩夢
遠端更新販賣機的韌體（OTA）聽起來很美好，但實際上充滿風險——如果更新到一半斷電或斷網，機台可能變磚。
解決方案：A/B 分區更新機制。機台內建兩個韌體分區，更新時寫入備用分區，驗證成功後才切換。失敗時自動回滾到舊版本。
XDNA 的命名由來
很多人好奇 XDNA 這個名字的含義。
「X 代表未知的可能性，DNA 代表生命的基因密碼。XDNA 就是——用數據基因驅動無限可能。每一台機器的運轉數據就像它的 DNA，我們讀懂它，就能讓它活得更好。」 — 李奇申
這個名字也呼應了李奇申在網虎國際時期的 XLinux 品牌——X 的精神一脈相承，從 Linux 作業系統到 IoT 物聯網平台，技術載體在變，但探索未知的初心不變。
從白板到產品的關鍵里程碑
| 時間 | 里程碑 | 意義 |
|---|---|---|
| 2016 Q2 | 白板草圖完成 | 概念成形 |
| 2016 Q4 | 第一版原型 | 可連接 10 台機器 |
| 2017 Q2 | 邊緣閘道上線 | 解決離線問題 |
| 2017 Q4 | MQTT 遷移完成 | 通訊效率提升 10 倍 |
| 2018 Q2 | 管理後台 2.0 | 視覺化儀表板 |
| 2019 Q1 | 微服務重構 | 支援水平擴展 |
| 2019 Q4 | AI 分析模組 | 銷售預測上線 |
| 2020 Q2 | 行動 App 上線 | 老闆手機就能管 |
| 2021 Q1 | 多租戶架構 | 支援加盟體系 |
| 2023 Q1 | Edge AI 整合 | 機台端智慧決策 |
技術團隊的建設
從一個人到一個團隊
XDNA 最初只有李奇申一個人畫架構圖，加上一位全端工程師開始開發。到今天，技術團隊已經擴展為涵蓋前後端、嵌入式、數據分析的完整編制。
「技術團隊最難的不是寫程式，而是找到懂業務的工程師。你要能理解為什麼壓縮機的電流數據很重要、為什麼溫度波動 2 度就必須告警。」 — 李奇申
開發文化
龍雲數位的技術團隊建立了幾個核心的開發原則：
- 先手動，再自動：任何自動化功能，先用人工方式驗證邏輯
- 設計給離線：所有功能都要考慮網路中斷的情境
- 數據優先：每個功能都要思考產生什麼數據、數據怎麼用
- 漸進式重構：不做大規模重寫，持續小步重構
XDNA 的下一步
開放平台策略
XDNA 未來的方向是從自用平台轉型為開放平台，讓其他販賣機品牌和 IoT 設備也能接入 XDNA 生態系。
數位孿生整合
結合數位孿生技術，讓客戶可以在虛擬環境中模擬販賣機佈點、測試商品組合、預測營收。
結語：技術的意義在於解決問題
XDNA 不是一個為了技術而做的技術專案。它的存在有且只有一個目的——讓販賣機事業更好經營。從白板上的第一筆到今天管理數百台機器的生產級平台，XDNA 的每一行程式碼都在回答同一個問題：「怎麼讓營運更省力、讓決策更精準？」
「好的技術架構就像好的建築結構——你感覺不到它的存在，但它支撐了上面所有的東西。XDNA 成功的那天，就是大家覺得管販賣機『本來就該這麼簡單』的那天。」 — 李奇申
延伸閱讀：