HiveMQ Geçiş Kontrol Listesi: İş Yükünüzü Ölçün, Kimlik Bilgilerini Planlayın ve Özel Bir Broker'ı Test Edin

HiveMQ Cloud Serverless'tan ayrılmak, herhangi bir cihaza dokunmadan önce üç şey yapıldığında sorunsuz ilerler: iş yükünüzü bilirsiniz, yeni kimlik bilgilerinizi planlamışsınızdır ve özel bir broker'ı gerçek trafiğinizle test etmişsinizdir. Bu kontrol listesi bu üç adımı işaretleyebileceğiniz somut maddelere dönüştürüyor. Her hedef broker ile çalışır; yararlı olduğu yerlerde her maddenin ConnectMQ'ya nasıl karşılık geldiğini gösteriyoruz.

HiveMQ, Serverless'ı 31 Aralık 2026'da sonlandırıyor. Arka plan için HiveMQ Cloud Serverless kapanıyor yazısını okuyun.

1. Bölüm: İş Yükünüzü Kontrol Edin

İş yükünüz hangi plana ihtiyacınız olduğunu ve geçişin ne kadar süreceğini belirler.

Bağlantılar

• HiveMQ kümesindeki en yüksek eşzamanlı bağlantı sayısı (en yoğun saatinizde konsolu kontrol edin).
• Önümüzdeki 12 ila 18 ay için beklenen büyüme.
• Cihaz değil, uygulama veya dashboard olan bağlantıların sayısı.
• Birden fazla bağlantı açan istemciler (örneğin saha başına bir gateway veya worker'ları olan bir backend).

Mesajlar

• Ortalama ve en yüksek mesaj hızı.
• Sparkplug B gibi ikili formatlar dahil en büyük payload boyutu.
• Kullanılan QoS seviyeleri; QoS 2 akışlarını not edin.
• Retain bayrağını kullanan topic'ler ve retained durumun başlangıç için önemli olup olmadığı.
• Kalıcı oturum kullanan ve çevrimdışıyken kuyruğa alınan mesajları bekleyen istemciler.

Topoloji

• Topic öneklerinin tam listesi ve her birine kimin yayın yaptığı veya abone olduğu.
• Backend'lerin kullandığı wildcard abonelikleri.
• Yük dengeleme için kullanılan shared subscription'lar.
• Kümenize bağlanan iş ortakları veya müşteriler.

Yeni Plan Nasıl Boyutlandırılır?

Her zaman en yüksek değere ek pay bırakarak boyutlandırın. Ortalamaya uyan bir plan, bir ağ kesintisinden sonraki yeniden bağlanma fırtınası sırasında bağlantıları reddeder.

2. Bölüm: Yeni Kimlik Bilgilerinizi Planlayın

HiveMQ küme URL'niz ve kimlik bilgileriniz taşınamaz; bu yüzden her istemci yenilerini alır. Şemayı cihaz başına doğaçlama yapmak yerine bir kez planlayın.

• Her HiveMQ kimlik bilgisini ve onu neyin kullandığını listeleyin.
• Kimlik bilgilerini broker'larla eşleyin. ConnectMQ'da her broker bir kullanıcı adı, parola ve client ID üretir. Aynı güven sınırına ait istemcileri tek bir broker altında gruplayın.
• Client ID'leri tasarlayın. ConnectMQ client ID'yi kimlik bilgilerine bağlar; istemciler verilen ID'yi kullanabilir veya YOUR_CLIENT_ID_line1-plc gibi bir son ek ekleyebilir. İki cihazın asla çakışmaması için son ekleri benzersiz bir donanım tanımlayıcısından türetin. MQTT client ID en iyi uygulamaları yazısına bakın.
• Güven sınırlarını ayırın. Müşterileri veya iş ortaklarını birbirinden izole etmek için HiveMQ topic izinlerini kullandıysanız, tek bir paylaşımlı kimlik bilgisi yerine her birine kendi broker'ını verin.
• Secret'ları doğru saklayın. Kimlik bilgilerini bir secrets manager'da, cihazlarda ise korumalı depolamada tutun; asla kaynak kod deposunda değil. Cihazlarda MQTT kimlik bilgilerini güvenceye alma yazısına bakın.
• Rotasyonu planlayın. Kimlik bilgilerini ileride yeni bir geçiş yapmadan nasıl yenileyeceğinize karar verin. MQTT kimlik bilgisi rotasyonu yazısına bakın.
• Uç noktaları yapılandırılabilir yapın. Hostname, port, kimlik bilgileri ve client ID uzaktan değiştirilebilir olmalı; böylece bir broker değişikliği için son kez firmware değişikliğine ihtiyaç duyarsınız.

3. Bölüm: Özel Bir Yönetilen Broker'ı Test Edin

İlk üretim cihazının ilk test olmasına asla izin vermeyin. Özel bir broker oluşturun, örneğin app.connectmq.com adresinde ücretsiz bir tane, ve şu testleri tamamlayın.

Bağlantı

• Cihazlarınızın kullandığı her ağ türünden port 8883 üzerinde TLS ile bağlanın.
• Web dashboard'unuzdan port 8084 (path /mqtt) üzerinde secure WebSocket ile bağlanın.
• Cihazların broker sertifikasına güvendiğini doğrulayın. ConnectMQ Let's Encrypt kullanır; ISRG Root X1 kök sertifikası güven deposunda olmalıdır. MQTT TLS yapılandırması yazısına bakın.

Davranış

• Gerçek topic yapınız ve payload'larınızla yayın yapın ve abone olun.
• Kullandığınız her QoS seviyesini test edin.
• Bir retained mesaj yayınlayın ve yeni bir abonenin onu aldığını doğrulayın.
• Bir Last Will mesajı ayarlayın ve iletildiğini doğrulamak için istemciyi aniden sonlandırın.
• Kalıcı bir oturumla yeniden bağlanın ve kuyruktaki mesajların geldiğini doğrulayın.
• En büyük payload'unuzu gönderin.

Performans ve Limitler

• Gidiş-dönüş gecikmesini yalnızca ofisten değil, cihazların bulunduğu konumlardan ölçün.
• Bir kesintiden sonraki toparlanmayı simüle etmek için bir grup test istemcisini aynı anda yeniden bağlayın.
• Bir limite ulaşıldığında istemcilerinizin nasıl davrandığını doğrulayın; MQTT 5 istemcileri kota aşımı için 0x97 reason code'unu alır.
• Testi canlı topic gezgininde ve dashboard'da izleyin.

MQTT.js ile hızlı bir gecikme testi:

// npm install mqtt
const mqtt = require("mqtt");
const topic = "migration-test/rtt";
const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  username: process.env.MQTT_USERNAME,
  password: process.env.MQTT_PASSWORD,
  clientId: `${process.env.MQTT_CLIENT_ID}_rtt`,
  protocolVersion: 5,
});

let sentAt = 0, n = 0;
client.on("connect", () => client.subscribe(topic, { qos: 1 }, send));
function send() { sentAt = Date.now(); client.publish(topic, String(n), { qos: 1 }); }
client.on("message", () => {
  console.log(`round trip ${n}: ${Date.now() - sentAt} ms`);
  if (++n < 20) setTimeout(send, 250); else client.end();
});

4. Bölüm: İlk Dalgadan Önce Başla / Başlama Kararı

• Envanter tamamlandı ve her istemci türü için sorumlular belirlendi.
• Plan seçildi ve en yüksek değere ek pay bırakılarak boyutlandırıldı.
• Kimlik bilgileri ve client ID şeması belgelendi.
• 3. Bölüm'deki tüm testler başarılı oldu.
• Retained durum dışa aktarıldı veya istemciler tarafından bağlanırken yeniden yayınlanıyor. HiveMQ Serverless veri silme yazısına bakın.
• Paralel çalıştırma için relay test edildi. Kesintisiz HiveMQ geçişi yazısına bakın.
• Geri dönüş planı: eski küme hâlâ çalışırken bir şey ters giderse bir dalganın HiveMQ'ya nasıl döneceği.
• Son dalga için 31 Aralık 2026'dan birkaç hafta önceye bir hedef tarih.

Her kutu işaretlendiğinde asıl taşıma için HiveMQ Serverless geçiş rehberini izleyin.

Sık Sorulan Sorular

HiveMQ Serverless'taki en yüksek bağlantı sayımı nasıl bulurum?

En yoğun döneminizde HiveMQ Cloud konsolundaki bağlantı bilgilerini kontrol edin ve kendi cihaz envanterinizle karşılaştırın. Emin değilseniz yeni planı cömert boyutlandırın.

Her cihaz için ayrı bir kimlik bilgisine ihtiyacım var mı?

Her zaman değil. ConnectMQ'da birçok cihaz benzersiz client ID son ekleri kullanarak tek bir kimlik bilgisi setini paylaşabilir. Cihazların veya kullanıcıların farklı güven sınırlarına ait olduğu durumlarda ayrı broker'lar veya kimlik bilgileri kullanın.

ConnectMQ'yu ödeme yapmadan önce test edebilir miyim?

Evet. Serverless (Free) planı kredi kartı gerektirmez ve 25 bağlantıya kadar destekler; bu, bu kontrol listesindeki tüm testleri çalıştırmak için yeterlidir.

Bir test başarısız olursa ne olur?

Üretim istemcilerini taşımadan önce sorunu giderin. Hataların çoğu TLS güven depoları, client ID kuralları veya plan limitlerinden kaynaklanır ve üçü de eski küme hâlâ çalışırken daha kolay düzeltilir.