MQTT vs NATS: IoT İçin Mesajlaşma Sistemi Seçimi

MQTT vs NATS karşılaştırması, mikroservisler için NATS'in sadeliğini seven bir ekip onun cihazlara da hizmet edip edemeyeceğini merak ettiğinde gündeme gelir. Her ikisi de wildcard subscription'lara ve düşük gecikmeye sahip hafif publish/subscribe sistemleridir; yine de çok farklı istemcilerin ihtiyaçlarıyla şekillenmişlerdir. Bu rehber cihaz desteğini, teslim garantilerini, kalıcılığı ve ekosistemi karşılaştırıyor ve yönetilen bir MQTT broker'ın NATS'in yanında nereye oturduğunu açıklıyor.

İki Hafif Pub/Sub Sistemi

MQTT açık bir OASIS standardı protokoldür. Uyumlu her istemci uyumlu her broker'la konuşabilir ve her ikisinin de çok sayıda uygulaması vardır. Güvenilmez ağlar üzerinden kısıtlı cihazlardan telemetri toplamak için geliştirilmiştir; Last Will, retained message'lar ve kalıcı oturumlar gibi özelliklere sahip olmasının nedeni de budur.

NATS, CNCF ekosisteminden çıkmış açık kaynaklı bir mesajlaşma sistemi ve protokolüdür ve tek bir birincil sunucu uygulaması vardır. Cloud-native servisler arası iletişim için geliştirilmiştir: veri merkezleri içinde ve arasında hızlı request/reply, fan-out ve yük dengeli iş dağıtımı. Core NATS bilinçli olarak gönder-ve-unut mantığıyla çalışır; NATS sunucusuna yerleşik olan JetStream ise kalıcılık, yeniden oynatma ve daha güçlü teslim garantileri ekler.

Her ikisi de tasarlandıkları işte iyidir. Asıl soru hangi istemcileri bağladığınızdır.

Bir Bakışta MQTT vs NATS

Belirleyici Etken: Cihaz Desteği

IoT için en pratik fark istemci bulunabilirliğidir. Bir cihaz mühendisinin dokunduğu neredeyse her platform için MQTT istemcileri vardır: PubSubClient gibi ESP32 ve Arduino kütüphaneleri, RTOS hedefleri için gömülü C kütüphaneleri, modem firmware'inde MQTT bulunan hücresel modüller, MQTT'yi yerleşik olarak sunan PLC'ler ve endüstriyel gateway'ler ile Sparkplug B konuşan SCADA ve historian yazılımları. Hazır sensörler ve gateway'ler de genellikle MQTT'yi bir yapılandırma seçeneği olarak sunar.

NATS istemcileri ise Linux sınıfı donanımlarda Go, Rust, Java, .NET, JavaScript, Python ve C için mükemmeldir. Bir Raspberry Pi veya endüstriyel bir PC bunları rahatça çalıştırabilir. Mikrodenetleyicilerde ve üretici firmware'lerinde NATS desteği nadirdir. Firmware yazmadan veri göndermesi gereken ticari bir cihazınız varsa, neredeyse kesinlikle NATS değil MQTT konuşacaktır.

Teslim Garantileri ve Kalıcılık

MQTT teslim garantilerini her mesajın içine yerleştirir. Bir cihaz aynı bağlantı üzerinden bir alarmı QoS 1 ile, yüksek frekanslı bir titreşim ölçümünü ise QoS 0 ile publish edebilir. Kalıcı oturumlar, bağlantısı kopan bir subscriber için QoS 1 ve 2 mesajlarını tutar; retained message'lar ise topic başına son değeri saklar, böylece sonradan açılan bir dashboard güncel durumu hemen görür. Ayrıntılar için MQTT QoS seviyeleri ve MQTT retained message'lar yazılarına bakın.

Core NATS, mesajı yalnızca o anda bağlı olanlara iletir, daha fazlasını değil. Bu hızlı ve basittir ve birçok servis çağrısı için doğru modeldir. Kalıcılığa ihtiyaç duyduğunuzda JetStream mesajları saklama politikalarıyla stream'lerde depolar, consumer'ların onay vermesini ve yeniden oynatmasını sağlar ve mesaj ID'sine göre tekrarları ayıklayabilir. JetStream, geçmiş ve yeniden oynatma konusunda MQTT oturumlarından daha yeteneklidir; ancak birinin tasarlaması ve işletmesi gereken ayrı bir kavramlar kümesidir (stream'ler, consumer'lar, onay politikaları).

Varlık Bilgisi ve Cihaz Durumu

IoT sistemleri sürekli olarak "bu cihaz çevrimiçi mi ve son ölçümü neydi?" sorusunu yanıtlamak zorundadır. MQTT ikisini de yerleşik olarak yanıtlar. Bir cihaz site1/pump7/status topic'inde retain bayrağıyla offline gibi bir Last Will ayarlar, bağlandıktan sonra online publish eder ve bağlantı beklenmedik şekilde koparsa broker will mesajını publish eder. Desenin tamamı için MQTT Last Will and Testament rehberine bakın.

NATS'te ise varlık bilgisini genellikle her cihazdan gelen heartbeat'lerle ya da sunucunun system account'undaki bağlantı olaylarını izleyerek oluşturur, son değerleri de bir JetStream key-value bucket'ında saklarsınız. Çalışır, ancak bunu yapılandırmak yerine parça parça kurarsınız.

Subject'ler vs Topic'ler

İsimlendirme modelleri birbirine çevrilebilecek kadar benzerdir. factory1/line2/cnc1/temperature şeklindeki bir MQTT topic'i doğal olarak factory1.line2.cnc1.temperature şeklindeki bir NATS subject'ine karşılık gelir. MQTT'deki +, NATS'teki * gibi tek bir seviyeyle eşleşir; MQTT'deki # ise NATS'teki > gibi kalan kısmın tamamıyla eşleşir. NATS sunucusu topic'leri bu şekilde subject'lere eşleyen ve MQTT 3.1.1 istemcilerini kabul edebilen bir MQTT arayüzü bile sunar; bu, NATS zaten omurga olduğunda işe yarar. MQTT 5 özelliklerini desteklemez; bu nedenle NATS belgelerini cihazlarınızın dayandığı özelliklerle karşılaştırarak kontrol edin.

Pratik Bir Hibrit Mimari

Birçok ekip ikisini de, her birini uygun olduğu katmanda kullanır:

1. Cihazlar, PLC gateway'leri ve HMI'lar TLS üzerinden bir MQTT broker'a bağlanır.
2. Bir köprü servisi cihaz topic'lerine subscribe olur ve backend mikroservisleri için bunları NATS subject'lerine yeniden publish eder.
3. Servisler kendi aralarında NATS request/reply ve queue group'ları, kalıcı stream'lere ihtiyaç duyduklarında ise JetStream kullanır.
4. Komutlar köprü üzerinden geri döner ve cihazın MQTT komut topic'ine publish edilir.

Eclipse Paho Go istemcisini ve resmi NATS istemcisini kullanan minimal, tek yönlü bir Go köprüsü şöyle görünür.

package main

import (
	"crypto/tls"
	"log"
	"strings"

	mqtt "github.com/eclipse/paho.mqtt.golang"
	"github.com/nats-io/nats.go"
)

func main() {
	nc, err := nats.Connect(nats.DefaultURL)
	if err != nil {
		log.Fatal(err)
	}
	defer nc.Drain()

	opts := mqtt.NewClientOptions().
		AddBroker("tls://broker.connectmq.com:8883").
		SetClientID("YOUR_CLIENT_ID").
		SetUsername("YOUR_USERNAME").
		SetPassword("YOUR_PASSWORD").
		SetTLSConfig(&tls.Config{MinVersion: tls.VersionTLS12}).
		SetAutoReconnect(true)

	opts.SetOnConnectHandler(func(c mqtt.Client) {
		// Yeniden bağlanmalardan sonra geri yüklenmesi için connect handler içinde subscribe ol
		c.Subscribe("factory1/+/+/telemetry", 1, func(_ mqtt.Client, m mqtt.Message) {
			subject := strings.ReplaceAll(m.Topic(), "/", ".")
			if err := nc.Publish(subject, m.Payload()); err != nil {
				log.Printf("nats publish failed: %v", err)
			}
		})
	})

	client := mqtt.NewClient(opts)
	if token := client.Connect(); token.Wait() && token.Error() != nil {
		log.Fatal(token.Error())
	}
	log.Println("bridging MQTT to NATS")
	select {}
}

Paho Go istemcisi MQTT 3.1.1 kullanır; ConnectMQ bunu MQTT 5'in yanında kabul eder. Kimlik bilgileri olmadan denemek için herkese açık MQTT test broker'ında tcp://broker.connectmq.com:1883 adresini, benzersiz herhangi bir client ID'yi ve connectmq/demo/<random-id>/ gibi bir topic önekini kullanın. MQTT topic'lerinde geçerli olan ancak NATS subject'lerinde özel anlam taşıyan . veya boşluk gibi karakterlere dikkat edin ve bunları köprüde temizleyin.

Hangisi Ne Zaman Seçilmeli?

İstemcileriniz cihazlar, gateway'ler, PLC'ler veya üçüncü taraf donanımlarsa, bağlantı güvenilmezse ya da varlık bilgisine, retained duruma ve Sparkplug B ile Unified Namespace gibi endüstriyel konvansiyonlara ihtiyacınız varsa MQTT seçin.

İstemcileriniz güvenilir ağlarda çalışan ve sizin yazdığınız servislerse ve minimum altyapıyla hızlı request/reply, queue group'lar ve isteğe bağlı JetStream kalıcılığı istiyorsanız NATS seçin.

Bir cihaz filonuz ve zaten NATS üzerinde standartlaşmış bir mikroservis backend'iniz varsa ikisini birlikte seçin.

Cihaz katmanı için yönetilen bir MQTT broker, internete açık bir servisi işletme ve güvence altına alma yükünü ortadan kaldırır. ConnectMQ; MQTT 3.1.1 ve 5.0, TLS, ücretli Serverless planda shared subscription'lar, plan bazlı kotalar ve çok kiracılı izolasyon sunar. Yerleşik bir NATS köprüsü içermez; bu nedenle köprü, gösterildiği gibi sizin küçük servisiniz olarak kalır. Başka backend'leri de karşılaştırıyorsanız MQTT vs Kafka yazısına, temel bilgiler için ise MQTT eğitimine bakın.

ConnectMQ ile Başlayın

Cihazlarınıza standart ve iyi desteklenen bir MQTT uç noktası verin, NATS'i ise servisleriniz için saklayın. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun, bir cihazı ve köprünüzü bağlayın ve her iki tarafı da canlı topic gezgininde izleyin.

Sık Sorulan Sorular

NATS, MQTT'den daha mı hızlı?

Her ikisi de düşük gecikmelidir ve gerçek dünyadaki hız, protokolden çok sunucuya, ağa ve teslimat ayarlarına bağlıdır. Seçiminizi ham hıza değil, istemcilere ve özelliklere göre yapın.

IoT cihazları doğrudan NATS'e bağlanabilir mi?

Linux sınıfı cihazlar NATS istemcilerini kullanabilir. Mikrodenetleyiciler ve ticari sensörler ise NATS'i nadiren destekler; cihaz katmanında MQTT'nin baskın olmasının nedeni de budur.

NATS, MQTT istemcilerini destekliyor mu?

NATS sunucusu, JetStream tarafından desteklenen bir MQTT 3.1.1 arayüzü sunar. MQTT 5 özelliklerini kapsamaz; bu nedenle büyük ve karma filolar için genellikle özel bir MQTT broker daha uygundur.

MQTT retained message'ın NATS'teki karşılığı nedir?

En yakın karşılıkları, subject başına son mesajı tutacak şekilde yapılandırılmış bir JetStream stream'i ya da bir JetStream key-value bucket'ıdır. Her ikisinin de açıkça kurulması gerekir.