Teslim ve ürün
Senkron çağrı zincirini kırın
Yavaş tek bir servis bütün bir istek yolunu durdurabiliyorsa, sistem en zayıf halkası kadar güvenilirdir. Doğru akışları olaylara taşırız; şemalar, teslim garantileri ve yeniden oynatma baştan kurulur.
- Süre
- 6 ila 16 hafta
- Model
- Tasarım ve kurulum
- Çıktı
- Olay omurgası ve taşınan akışlar
Çağrı zincirinin riske dönüştüğünü gösteren işaretler
Senkron çağrılar zincir uzayana kadar basittir. Sonra her bağımlılığın kötü günü sizin de kötü gününüz olur.
- Aşağı akıştaki bir servisteki zaman aşımı; ödeme, giriş ya da ana ekranda hataya dönüşüyor.
- Bir olay sırasında tekrar denemeler yükü katlıyor; küçük bir yavaşlama kesintiye dönüşüyor.
- Sipariş ya da ödeme verisinin yeni bir tüketicisini eklemek, veriyi üreten servisi değiştirmeyi gerektiriyor.
- Arka plan işleri neyin değiştiğini anlamak için veritabanını birkaç saniyede bir sorguluyor.
- Olaylar zaten yayımlanıyor ama tüketiciler bazılarını iki kez işliyor, bazılarını kaçırıyor.
- Bir projeksiyonu yeniden kurmak ya da bir tüketicideki hatayı düzeltmek için dün olanları kimse yeniden oynatamıyor.
- Kafka çalışıyor ama topic’ler, anahtarlar ve saklama süreleri gelişigüzel seçilmiş; şemaların sahibi yok.
Olaylar işe yaradığı yerde, çağrılar gerektiği yerde
Her şeyi olaylara taşımak, her şeyi senkron tutmak kadar risklidir. Bazı etkileşimler anında cevap ister; bazılarının yalnızca bir şeyin olduğunu bilmesi yeterlidir. İş, akışları ayırmakla başlar: hangi çağrılar olaya dönüşebilir, hangileri istek olarak kalmalı, hangileri birden fazla adımı koordine eden bir saga gerektirir.
Taşınan akışlar için kurallar açık hale getirilir: olay şemaları ve bunların nasıl evrileceği, anahtarlar ve sıralama, teslim garantileri, idempotent tüketiciler ve bir veritabanı değişikliği ile olayının hiçbir zaman çelişmemesi için outbox deseni.
İşletilebilirlik ilk topic’ten itibaren kurulur. Dead-letter yönetimi, yeniden oynatma, tüketici gecikmesi izleme ve asenkron adımlar boyunca izleme sayesinde ekibiniz bir mesajın nereye gittiğini tahmin etmeden akışı görüp düzeltebilir.
Kapsam
Dahildir
- Akış envanteri: hangi çağrılar olaya dönüşür, hangileri senkron kalır
- Olay şemaları, sürümleme ve şema kayıt sistemi
- Topic, anahtar, bölüm ve saklama tasarımı
- Güvenilir yayın için outbox deseni
- Idempotent tüketiciler ve tekilleştirme kuralları
- Çok adımlı süreçler için saga koordinasyonu
- Dead-letter yönetimi ve yeniden oynatma prosedürleri
- Asenkron akışlarda izleme ve gecikme takibi
Dahil değildir
- Her akışın olaylara taşınması
- Akış analitiği ve gerçek zamanlı panolar
- Devirden sonra mesajlaşma kümesinin günlük işletimi
- Taşınan akışlarla ilgisi olmayan servislerin yeniden yazılması
İş nasıl ilerler
- Hafta 1 ila 3Akışları ayırın. İstek yolları, hata geçmişi ve veri bağımlılıkları haritalanır. Her akış olay, istek ya da saga olarak işaretlenir; gerekçesi yazılır.
- Hafta 4 ila 6Omurgayı kurun. Topic’ler, şemalar, kayıt sistemi, outbox ve tüketici kuralları kurulur ve gerçek bir akış üzerinde uçtan uca kanıtlanır.
- Hafta 7 ve sonrasıAkışları sırayla taşıyın. Akışlar tek tek taşınır; sonuçları eşleşene kadar eski yolla paralel çalışır.
- Son haftalarİşletin ve devredin. Yeniden oynatma, dead-letter yönetimi ve izleme, devirden önce ekibinizle birlikte bir tatbikatta denenir.
Elinize geçenler
Omurga sizin altyapınızda çalışır; kurallar sizin depolarınızda durur.
Bu hizmet kimin için değil
- Birkaç servisi ve kısa çağrı zincirleri olan sistemler. Olaylar, ancak bağımlılık can yakmaya başladığında karşılığını veren hareketli parçalar ekler.
- Yalnızca Kafka kurulumu arayan ekipler. Değer kümede değil, akış tasarımında ve kurallardadır.
- Her etkileşimin olaya dönüştürülmesini isteyen projeler. Anında cevap gereken yerlerde istekleri koruruz.
Sık sorulanlar
Kafka kullanmak zorunda mıyız?
Hayır. Kafka yüksek hacimli, yeniden oynatılabilir akışlara çok uyar; ama AWS, Azure ve Google Cloud’un yönetilen kuyrukları ve broker’ları çoğu zaman yeterlidir. Seçim hacminize, sıralama ihtiyacınıza ve ekibinize göre yapılır.
Mükerrer işlemeyi nasıl önlüyorsunuz?
Tüketiciler idempotent yapılır: her olay bir kimlik taşır ve işleme, neyin zaten işlendiğini kaydeder. Üretici tarafındaki outbox deseniyle birlikte mükerrer mesajlar yanlış sonuç üretmez.
Veri tutarlılığına ne oluyor?
Olaylara taşınan akışlar nihai tutarlı hale gelir ve bunun nerede kabul edilebilir olduğunu biz tasarlarız. Kabul edilemediği yerde akış senkron kalır ya da açık telafi adımları olan bir saga ile koordine edilir.
Bu hizmetin Dağıtık Sistem Tasarımı’ndan farkı ne?
Dağıtık Sistem Tasarımı tutarlılık modelini belirler ve referans kodla kanıtlar. Bu hizmet olay omurgasını kurar ve üretimdeki akışlarınızı onun üzerine taşır.
Bir mesajın her an nerede olduğunu görebilir miyiz?
Evet. Asenkron adımlar boyunca izleme ve tüketici gecikmesi takibi devrin parçasıdır; takılan bir akış log aramadan görünür.
Önce kısa bir teknik sohbetle başlayalım
Otuz dakika. Sizi en çok endişelendiren çağrı zincirini anlatırsınız, biz hangi parçalarının olaya dönüşmesi gerektiğini söyleriz.