Sürümleme ve rollout

Dispatch anahtarı fiziksel queue adı, positive schema version ve exact content kind üçlüsüdür. Sürüm framework sürümü değil, uygulamanın mesaj sözleşmesidir. Tek fiziksel queue aynı binary içindeki V1 ve V2 handler’larına yönlenebilir; bunun için ikinci subscription tanımlanmaz.

Eski ve yeni handler’ı birlikte ekleyin#

Aşağıdaki modül aynı queue için iki JSON sözleşmesini kaydeder. Ayrı dosyadaysa uygulamanın modül ağacına mod orders; ile dahil edin; TOML’de tek orders.created entry’si kalır.

use lilyrs::consumer::{Injectable, ServiceTrait};
use lilyrs::queue::{Json, QueueHandlerError, queue, queue_service};
use serde::Deserialize;

#[derive(Deserialize)]
struct OrderV1 { order_id: String }
#[derive(Deserialize)]
struct OrderV2 { order_id: String, source: String }

#[derive(Injectable)]
#[service(lifetime = "Singleton")]
struct OrderWorker;
impl ServiceTrait for OrderWorker {}

#[queue_service]
impl OrderWorker {
    #[queue("orders.created", version = 1, content = "json")]
    async fn v1(&self, Json(event): Json<OrderV1>) -> Result<(), QueueHandlerError> {
        apply_order(event.order_id, "legacy".into()).await
    }

    #[queue("orders.created", version = 2, content = "json")]
    async fn v2(&self, Json(event): Json<OrderV2>) -> Result<(), QueueHandlerError> {
        apply_order(event.order_id, event.source).await
    }
}

async fn apply_order(id: String, source: String) -> Result<(), QueueHandlerError> {
    if id.is_empty() || source.is_empty() {
        return Err(QueueHandlerError::permanent("ORDER_INVALID"));
    }
    Ok(())
}

Burada V1’den ortak uygulama modeline dönüşümü uygulama yapar. Lily otomatik upcast, JSON shape tahmini veya “en yakın sürüm” seçimi yapmaz. version 1–65535 aralığında literal olmalı; content zorunludur ve son makro argümanından sonra virgül kabul edilmez.

Bilinmeyen sözleşme ne olur?#

Bilinmeyen version/content scope açılmadan ve middleware’e girilmeden reddedilir. Bu yüzden her poison mesajı application middleware ile gözlemek mümkün değildir. Linked duplicate kontrolü ilgili queue o configuration’da pasif olsa da yapılır.

Replica geçişini sıraya koyun#

1. V1 ve V2 kabul eden binary’yi hazırlayın ve bütün Consumer replica’larına dağıtın.
2. V1-only replica kalmadığını ve queue readiness durumunu doğrulayın.
3. Publisher’ları V2 üretmeye geçirin.
4. Broker backlog, retry/DLQ replay ve üretici geçişini değerlendirdikten sonra V1 desteğini kaldırın.

RabbitMQ competing consumer seçiminde Lily version header’ına göre uygun binary’yi seçmez. Aynı queue üzerinde V1-only ve V2-only replica’ları karıştırmak yanlış replica’nın kalıcı ret üretmesine yol açabilir. Kasıtlı uyumsuz süreçler için ayrı fiziksel queue/binding tasarlayın.

Kimlik ve durable kayıtlar#

Aynı event yeniden gönderiliyorsa saklanmış event ID korunur; her gönderimde yeni kimlik üretmek deduplication davranışını değiştirir. Transactional inbox kullanırken handler kimliği/ismi ve retention horizon’ı da rollout kararının parçasıdır. Migration ve kayıt saklama rehberini birlikte uygulayın.