HiveMQ Cloud Serverless 即將退役：阿明博士的 MQTT 替代方案與搬遷評估

收到 MQTT 雲端方案要退役的通知，第一個反應通常是：「換一個免費 Broker 不就好了？」阿明博士會先把清單攤開：有幾台設備連著、斷線多久可以接受、誰能更新韌體，以及搬完之後由誰照顧這套系統。這幾件事，往往比服務首頁上的「免費」更能決定下一步。

本文以 ESP32 感測專題、Home Assistant、小型遠端監測與客戶交付案為對象，依 2026 年 10 月 29 日查閱的原廠文件整理。方案試算與架構建議是本文的評估範例，尚未對各平台進行實際搬遷、壓力測試或可用性測量。

先確認影響範圍：退役的是 HiveMQ Cloud Serverless

HiveMQ 官方宣布，Serverless Free 與 Serverless Pay As You Go 於 2026/12/31 退役，目前已不能建立新的 Serverless 叢集或升級為 PAYG。期限後客戶端將無法連線，叢集與資料也會遭永久刪除；官方不會自動搬走客戶端、設定或資料。這則通知針對 Serverless 方案，不能解讀成所有 HiveMQ 產品都停止服務。HiveMQ 官方退役公告。

要盤點的資料包括 retained 訊息、持久工作階段、帳號與 Topic 權限。原廠目前公告寫的是停用後刪除，沒有提供可供本文確認的寬限時段；不要把其他網站轉述的刪除日期當成可延後搬遷的保證。以下建議提早完成切換，實際排程仍須配合設備可更新的時間。

選方案前，先替現有系統做一次體檢

不要只數感測器。Broker 的客戶端還可能包含 Node-RED、Home Assistant、資料庫接收程式、手機程式與測試工具；同一台設備若開多個 MQTT 連線，也會影響連線與工作階段的用量。請把下面這張表填完，再看價目表。

例如「100 台感測器，每分鐘各送一次」和「1 台閘道，每秒彙整上百筆」就是不同負載。另一個容易漏算的項目是訊息分發：一筆資料若同時送給多個後端，Broker 對外送出的流量也會增加。把實際收送路徑畫出來，比單憑設備數估價更可靠。

方案一：想繼續免管主機，先評估 EMQX Cloud Serverless

對原本使用雲端 Broker、沒有專人管理伺服器的小型專題，EMQX Cloud Serverless 是值得先測的候選。它提供每月免費額度：100 萬 session minutes、1 GB 公網流量及 100 萬次規則動作；超額並啟用付費後，對應單價為每百萬 session minutes 2 美元、每 GB 0.15 美元、每百萬次規則動作 0.25 美元。公網流量包含進站與出站，持久工作階段離線後仍可能納入 session 用量。EMQX 計費文件。

1,000 個連線的容量，不等於 1,000 台設備整月免費

以下是依公開費率自行計算的30 天估算。假設每個客戶端全天維持一個工作階段、規則動作仍在免費額度內，且沒有其他應計費項目。每個常連客戶端一個月就是 43,200 分鐘。

100 萬免費分鐘，換算約能涵蓋 23 個全天常連客戶端的 30 天 session 用量；流量與規則額度仍須分開確認。這只是找出量級的算法，實際金額會受月份天數、離線持久 session、短連線向上取整、每日結算與其他項目影響。不要為了壓低連線分鐘而讓設備不停重連；那可能增加握手負擔，且未必省下費用。

另一個要先選好的，是額度用完後的行為。Spend Limit 設為 0 時，免費額度耗盡會停止部署；大於 0 時，需依設定決定達限暫停，或提醒後繼續計費。教學測試可以接受停用保護，客戶的常態監測則要同時討論費用上限和停機後果。支出上限說明。

搬過去之前，先用真正的訂閱方式測一次

目前 Serverless 的限制包括最高 1,000 個同時連線、每個客戶端最多 10 個訂閱、每秒最多發布 10 次、最多 2,000 筆 retained 訊息，以及 MQTT 3.x session 的 2 小時到期限制。共用的接收閘道即使只有一個連線，也可能先撞到訂閱或發布頻率限制；有大量 discovery 與狀態 Topic 的系統，則要一起盤點 retained 數量。完整限額表。

權限設定也不能照抄。EMQX 文件說明預設 blacklist 行為會允許未被明確拒絕的操作；Serverless 可用「特定允許規則＋All Users 的 deny # 後備規則」建立白名單效果，並檢查規則優先順序。客戶端不能直接訂閱裸 #，但可以使用有前綴的 site-a/#；授權規則中的 # 與客戶端訂閱限制是不同用途。驗收時要真的嘗試越權操作，不能只測自己的帳號連得上。官方授權文件。

方案二：設備主要在同一現場，Mosquitto 自架很值得考慮

Eclipse Mosquitto 是支援 MQTT 5.0、3.1.1 與 3.1 的開源 Broker，定位輕量，可運行於單板電腦到伺服器。它適合把小型現場的資料交換放回自己掌握的環境，但主機、網路與管理工作仍由自己承擔。Mosquitto 專案介紹。

如果設備、控制邏輯和後端都在同一個家中、教室或機房，本地 Broker 可以減少對外部雲端的依賴。Home Assistant 官方也提供 Mosquitto Broker app 作為建議路徑；既有系統仍要核對 Home Assistant 版本、安裝型態、MQTT 協定與 discovery 使用方式。不要假設每一種 Home Assistant 安裝都有相同的 app 管理介面。Home Assistant MQTT 文件。

若設備分散在不同地點，將 Mosquitto 放到有公開可達端點的 VPS，也是一條路。不過這時你同時接手了 Linux 更新、憑證更新、連線告警、磁碟、備份與故障處理。阿明會把「月租主機＋維運工時＋備份＋中斷代價」一起算；若沒有明確管理者，省下的代管費可能換來更難處理的停機。

自架至少應完成三件實事：第一，使用適當的 TLS 與每類設備的驗證、Topic 存取控制；第二，確認持久資料寫到容器外的保存位置並做還原演練；第三，監看外部連線、磁碟和憑證到期。Mosquitto 的帳密驗證與授權是不同層，帳密加上去並不等於不同客戶的 Topic 已隔離。驗證與授權說明。

持久保存也不能只看「容器重啟後能啟動」。要核對使用版本的 persistence、資料位置與保存策略，實際確認重啟後 retained 和所需 session 是否仍可用。單台自架 Broker 仍有單點故障；啟動另一台、或加一條 bridge，不會自動得到可無縫接手的高可用叢集。Mosquitto 設定文件。

方案三：留在 HiveMQ 生態系，分清「代管」與「免費授權」

原廠的免費 Migration license 是自行部署的 HiveMQ Enterprise Broker 授權：符合資格的帳號可取得 12 個月、100 個同時連線與每秒 100 則訊息的額度，之後轉為目前 25 連線、每秒 25 則的免費 Lab 額度。它不是另一個免費雲端叢集；主機與管理要自己準備。領取資格與轉換條件應回到前述原廠公告及帳號頁核對。

一般 Lab 文件將用途定位在開發、測試與評估，並非正式生產用途；新發的一般 Lab 授權也有 30 天有效期與免費續期安排。不能把這些文字解讀成搬遷後可永久享有 100 個連線。若要把轉換後授權用在長期客戶案，應先確認該帳號實際有效期、續期方式及適用條件。Lab 與安裝文件、方案與續期說明。

希望仍由原廠代管，可以評估 HiveMQ Cloud Starter 或 Enterprise。查核時 Starter 起價為每小時 US$0.34，加每百萬則訊息 US$0.80。只算 30 天不停機的起始時間費，就是約 US$244.80，還沒加訊息等項目；這和低用量 Serverless 的支出結構差很多。它提供的容量、隔離與服務承諾也不同，不能只把兩個價格並列後就判定誰比較可靠。新建 Starter 仍會有新的叢集位址，需要更新客戶端。

方案四：需要現場繼續運作，考慮本地 Broker 加雲端同步

有些客戶真正需要的，是「外網斷了，現場仍能看資料、照既定規則運作」。這時可以讓設備先連本地 Broker，將控制程式與必要介面留在現場，再由閘道或受限 Topic 的 bridge 將需要的資料送到雲端。

這種設計的前提，是那些必要功能真的都在本地。只放一個本地 Broker，卻把判斷規則、DNS 相依或控制後端留在雲端，仍可能在斷網時失效。對外網中斷期間需要保存的資料，也要另外定義佇列容量、保存時間和恢復後補送方式；單靠「有 bridge」無法保證任意長度的斷線都不丟資料。

Bridge 需要限定 Topic、方向與身分，避免雙向轉送形成回圈，或讓舊 retained 控制指令重新進入現場。不要把整個 Topic 樹不加區分地同步。若選 VPN，先確認 VPN 由路由器或閘道終止，以及遠端網段可達性；不能假設每塊 ESP32 都能直接安裝桌面級 VPN 軟體。

把候選方案放回使用情境，比較才有意義

例如一套 12 台感測器、1 個後端接收程式的教學專題，若都全天常連，30 天約 561,600 session minutes，可先用免費額度量級評估，再核對流量與功能限制。換成 100 台常連設備，就不該繼續用「不用付費」當成設計假設。若是交付給店家長期運作的設備，還要把管理者、告警和恢復時間寫進服務範圍；本文不以任一品牌替你承諾現場可用性。

公開測試 Broker 不在正式替代清單內。test.mosquitto.org 官方就提醒不要依賴它承擔重要用途。能連線和能交付給客戶，是不同的驗收標準。

真正的搬遷難點：地址可以改，Broker 裡的狀態不會跟著走

MQTT 協定能讓我們繼續使用熟悉的客戶端，但它不會替兩個不同 Broker 搬家。即使保持相同 Client ID，新 Broker 也不會憑空擁有原來的持久 session、離線佇列或尚未完成的傳送狀態。這些需要依應用程式的恢復方式另行處理。EMQX 搬遷說明。

ESP32 的 TLS 測試不能只在筆電上做。要用正式韌體確認 CA 信任、主機名稱、裝置時間同步及記憶體是否足夠，再測斷線後重新握手。若驗證失敗，應修正原因，不用關閉憑證驗證來換取表面上的連線成功。

也不要急著把自有域名當成萬用解法。自架端點通常能自行配置相符憑證；代管服務則要先確認自訂域名、憑證與 SNI 支援。只加一筆 CNAME，不會讓服務商的憑證自動涵蓋你的新域名。若方案不支援，就把原廠 endpoint 做成可更新的設定，減少下次逐台改韌體的負擔。

在應用層，控制命令最好有命令 ID、有效期限與執行結果。MQTT 的 QoS 定義處理的是訊息傳遞，不能直接當成閥門、繼電器或其他設備已完成動作的證據；尤其 QoS 1 容許重複送達，切換時要測重複命令是否會被再次執行。MQTT 5.0 標準。

阿明建議的切換方式：先讓一組設備走完，再放大

最小試搬組合應包含一台代表性設備、一個後端訂閱者，以及用得到的控制程式。只用 MQTT 測試工具成功發布一次，還不足以代表現場可以切換。以下是可依專案調整的演練流程。

1. 凍結盤點表，定義成功與回退條件。記錄端點、Topic、權限、資料格式、狀態與相依程式；事先決定多久沒資料算失敗、誰決定回退，以及舊服務可維持到何時。
2. 先建新環境，讓權限與帳務行為可觀察。建立新帳號與必要整合，查看配額與預算設定；確認錯誤帳密與不該存取的 Topic 都被拒絕。
3. 讓一組真實設備與後端一起切換。檢查數值、時間戳、單位、重新訂閱及實際指令回應。若新舊環境並存，要安排資料去重和指令的單一發送來源，避免兩邊都在控制同一台設備。
4. 故意中斷一次。依需求測網路中斷、Broker 重啟、設備重啟和長時間離線；確認重連後收到的是需要的資料，而不是舊 retained 指令或無限重送的工作。
5. 分批切換並留下觀察時間。把後端、告警與遠端指令來源一併核對，追蹤未遷移及長期離線設備。資料成功寫進後端、越權操作被拒絕、用量符合預期後，才擴大批次。
6. 最後才關閉舊站並完成交接。確認沒有必要客戶端仍依賴舊端點，保存新設定、備份與還原方式；把管理者、憑證更新、費用與告警收件人交接清楚。

給正在使用免費方案的客戶，一個務實的安排

阿明會建議：現在先完成盤點與候選試連；把 11 月留給代表性設備、權限及中斷演練，再於 12 月中前完成主要切換，保留剩餘時間處理難以遠端更新或長期離線的設備。這是本文建議的工作節奏，不是原廠另給的保證時程。

少量測試設備，可以先從代管 Serverless 的免費額度試起；同一場域、已有人管理的系統，可以認真評估本地 Mosquitto；需要外部服務承諾或大量設備交付的案子，則應用實際負載向代管商估價。對斷網仍須運作的現場，把必要控制留在本地，通常比一味追求免費更接近真正需求。

這次退役提醒我們：MQTT 是可跨平台使用的協定，端點、憑證、權限和系統狀態仍需要設計。把它們做成可盤點、可更新、可驗證的項目，下次服務改版或設備增加時，就能用較少的現場工時完成調整。