Technical Tutorials

Nesnelerin İnterneti (IoT) sistemleri doğası gereği kırılgandır. Tek bir kararsız sensör, anlık bir ağ kesintisi veya aşağı akış API zaman aşımı, sistem genelinde arızalara yol açabilir. Geleneksel programlama dilleri bu istisnaları `try-catch` bloklarıyla ele alırken, Node-RED gibi görsel iş akışı araçları hata toleransı için farklı bir yaklaşım gerektirir. Üretim düzeyi altyapı için mesajların sessizce başarısız olmasına izin vermek bir seçenek değildir. Gerçekten kendini onaran bir sistem oluşturmak için, kademeli arızaları önlemek üzere Devre Kesicileri (Circuit Breakers) ve teslim edilemeyen mesajları yakalayıp denetlemek için Ölü Mektup Kuyruklarını (DLQ'leri) uygulamalıyız.

Görsel İş Akışları Neden Açık Hata İşleme Gerektirir

Node-RED akışında, bir düğüm başarısız olursa (örneğin, bir HTTP isteği zaman aşımına uğrarsa), mesaj genellikle düşürülür veya bir hata düğümüne gönderilir. Bir strateji olmadan, başarısız olan aşağı akış hizmeti (bulut veritabanı gibi), tüm akışın yığılmasına, bellek tüketimine ve sağlıklı cihazlar için kritik uyarıların gecikmesine neden olur. Kendini onaran bir sistemin amacı, bu arızaları otomatik olarak tespit etmek, bozuk bileşene trafik göndermeyi durdurmak (devre kesici) ve boru hattının geri kalanını durdurmadan başarısız olan verileri sonraki kurtarma için güvenli bir şekilde depolamaktır (DLQ).

Devre Kesici Deseninin Uygulanması

Bir Devre Kesici, bağımlı bir servise yapılan çağrıların başarı oranını izler. Hata oranı bir eşiği aşıyorsa, devreyi "açar" ve servise toparlanma süresi tanımak için belirli bir süre boyunca sonraki istekleri anında başarısız kılar.

Node-RED yerleşik hata işleme özelliklerine sahip olsa da, bu mantığı switch, function ve change düğümlerinin bir kombinasyonunu kullanarak uygulayabiliriz. İşte bağlam depolamada hata sayılarını takip eden bir function düğümü kullanılarak kavramsal bir uygulama:

// Function Node: Devre Kesici Mantığı
// Bu düğüm, kararsız HTTP Request düğümünün önüne yerleştirilmelidir.

let failures = context.get('failures') || 0;
let circuitState = context.get('circuitState') || 'CLOSED'; // CLOSED, OPEN, HALF_OPEN
const FAILURE_THRESHOLD = 3;
const RESET_TIMEOUT = 30000; // 30 saniye

// Devre OPEN ise, tekrar deneme zamanı olup olmadığını kontrol et (HALF_OPEN)
if (circuitState === 'OPEN') {
    const now = new Date().getTime();
    const lastOpenTime = context.get('lastOpenTime') || 0;
    
    if (now - lastOpenTime > RESET_TIMEOUT) {
        circuitState = 'HALF_OPEN';
        context.set('circuitState', circuitState);
        // Servisi test etmek için bir isteğin geçmesine izin ver
        return msg;
    } else {
        // Devre hâlâ açık, mesajı düşür ve uyarıyı tetikle
        msg.payload = { error: "Servis kullanılamıyor", circuit: "OPEN" };
        msg.topic = "circuit_breaker_trip";
        return [msg, null]; // DLQ/Hata Uyarısına yönlendir
    }
}

// Mesajı servis düğümüne ilet
msg._circuitContext = { failures: failures };
return msg;

// **ÖNEMLİ:** Yanıtı işlemelisiniz.
// Servis çağrısından sonra bir "Devre Kesici İşleyici" düğümü ekleyin.
// Servis çağrısı başarısız olursa (hata düğümü), hataları artırın.
// Başarılı olursa, hataları sıfırlayın.

Yanıtı İşleme: Hem başarı hem de hata yollarını yakalamalısınız. Servis düğümünüzün out çıkışını, başarıda hata sayısını sıfırlayan bir function düğümüne bağlayın. Servis düğümünün error çıkışını, hata sayısını artıran ve eşik karşılanırsa circuitState'i OPEN olarak güncelleyen ayrı bir function düğümüne bağlayın.

Ölü Mektup Kuyruğunun (DLQ) Uygulanması

Bir devre kesici tetiklendiğinde veya bir mesaj doğrulamada başarısız olduğunda, verileri atmayız. Onları bir Ölü Mektup Kuyruğuna göndeririz. Node-RED'de bir DLQ, genellikle kalıcı bir depolama olarak uygulanır; örneğin bir file düğümü, dlq/alerts adlı bir mqtt konusu veya bir database koleksiyonu.

Veri bütünlüğünü sağlamak için DLQ düğümünü nasıl yapılandıracağınız aşağıda gösterilmektedir:

// Function Node: Mesajı DLQ İçin Hazırla
// Bu düğüm, Devre Kesicinin hata çıkışına veya
// akışın ana hata düğümüne yerleştirilir.

const dlqMessage = {
    originalPayload: msg.payload,
    originalTopic: msg.topic,
    deviceId: msg.deviceId,
    timestamp: new Date().toISOString(),
    errorReason: msg.error.message || "Bilinmeyen Hata",
    retryCount: context.get('retryCount') || 0
};

// İsteğe bağlı olarak, planlanan yeniden işleme için bir yeniden deneme sayacı artırın
const currentRetries = dlqMessage.retryCount + 1;
dlqMessage.retryCount = currentRetries;

return {
    payload: dlqMessage,
    topic: "iot/dlq/alerts" // Ayrı bir MQTT konusu kullanın
};

Otomatik Kurtarma ve Yeniden Deneme

Gerçek bir kendini onaran sistem, başarısız olan mesajları sadece depolamakla kalmaz; onları kurtarmaya çalışır. Her 5 dakikada bir tetiklenen bir inject düğümü ekleyin. Bu düğüm, DLQ depolamanızdan okumalıdır (örneğin, bir saklama politikasına sahip iot/dlq/alerts/# için bir MQTT aboneliği veya bir veritabanı sorgusu).

DLQ'den alınan her mesaj için circuitState'i kontrol edin. Devre CLOSED veya HALF_OPEN ise, orijinal yükü ana işleme akışına yeniden yayınlayın. Devre OPEN ise, bir sonraki döngü için DLQ'de bırakın. Bu, başarısız mesajların yalnızca aşağı akış servisi sağlıklı olduğunda yeniden denendiği doğal bir geri basınç mekanizması oluşturur.

Sonuç

Node-RED iş akışlarınıza Devre Kesicileri ve Ölü Mektup Kuyruklarını entegre ederek, kırılgan bir IoT sistemini dayanıklı, kendini onaran bir mimariye dönüştürürsünüz. Devre Kesici aşırı yüklenmeyi önler ve servislerin toparlanmasına izin verirken, DLQ hiçbir verinin kaybolmadığından emin olur. Bu desen, veri bütünlüğü ve çalışma süresinin en önemli olduğu herhangi bir üretim IoT dağıtımı için kritiktir. Küçük başlayın: en kararsız aşağı akış hizmetiniz için kesici mantığını uygulayın ve sistem kararlılığı üzerindeki etkiyi gözlemleyin.