Servisler arası iletişim tasarımı: senkron ve asenkron seçim rehberi

Senkron ve asenkron iletişim arasındaki temel fark

Mikroservisler arasında iletişim biçimi, sistemin dayanıklılığını, gecikmesini ve karmaşıklığını doğrudan belirler. Senkron iletişimde çağıran servis isteği gönderir ve yanıt gelene kadar bekler; tipik örnek bir HTTP üzerinden REST ya da gRPC çağrısıdır. Asenkron iletişimde gönderen servis mesajı ya da olayı bir aracıya bırakıp devam eder; alıcı mesajı kendi zamanında işler.

Senkron yaklaşım anlaşılması kolaydır ve yanıtı hemen verir. Ancak çağıran servis, çağrılan servisin ayakta ve hızlı olmasına bağımlıdır: biri yavaşlarsa diğeri de bekler, zincir uzadıkça toplam kullanılabilirlik düşer. Asenkron yaklaşımda servisler zamansal olarak ayrışır; alıcı geçici olarak kapalı olsa bile mesaj kuyrukta bekler. Karşılığında akışı izlemek, sıralama, tekrar ve tutarlılık sorunlarını yönetmek zorlaşır, sonuç kullanıcıya anında dönmez.

Bu seçim ikili bir tercih değildir: gerçek sistemler ikisini birlikte kullanır. Önemli olan, her etkileşim için doğru biçimi bilinçli seçmektir.

Karar ölçütleri: hangi etkileşim hangi biçime uygun?

Her servis çağrısı için şu sorulara bakın:

• Yanıta şimdi mi ihtiyaç var? Kullanıcı ekranda sonucu bekliyorsa (stok sorgusu, fiyat hesabı) senkron çağrı doğaldır. Sonuç sonra gösterilebilirse (e-posta gönderme, rapor üretme, bildirim) asenkron uygundur.
• Komut mu, olay mı? "Ödeme al" bir komuttur ve bir alıcıya yöneliktir. "Sipariş oluşturuldu" bir olaydır ve kimin dinleyeceğini yayımlayan bilmez. Olaylar gevşek bağlılık sağlar; komutlar açık hedef bağımlılığı yaratır.
• Hata toleransı: Alıcı kapalıyken gönderenin çalışmaya devam etmesi gerekiyor mu? Gerekiyorsa mesaj aracı üzerinden ayrıştırın.
• Tüketici sayısı: Aynı olayı birçok servis dinleyecekse, tek tek çağırmak yerine yayımlamak çok daha ölçeklenebilirdir.
• Sıralama ve tutarlılık: Olayların sırası önemliyse ve kayıpsız teslim gerekiyorsa, mesaj aracının sıralama ve teslimat davranışlarını inceleyin.
• Yük ve ani artış: Trafik dalgalıysa kuyruk, ani yükü yumuşatan bir tampon görevi görür.
• Gözlemlenebilirlik: Asenkron akışlarda tek bir isteğin izini sürmek için ilişki kimliği (correlation ID) ve dağıtık izleme gerekir.

Kural olarak sorgular senkron, durum değişikliği ve yan etkiler olay tabanlı tasarlanırsa dengeli bir yapı elde edilir. Ancak bu bir kural değil başlangıç noktasıdır; iş gereksinimi belirleyicidir.

Senkron iletişimi güvenli kurmak

Senkron çağrıların riski, zincirleme gecikme ve kaskad hatadır. Bunu azaltmak için temel önlemler vardır: her çağrıya makul bir zaman aşımı koyun; sınırlı sayıda ve gecikmeli yeniden deneme uygulayın (kontrolsüz deneme yük bindirir); devre kesici ile sağlıksız bağımlılığı geçici olarak devre dışı bırakın; yedek davranış tasarlayın.

Arayüz tarafında sözleşmeyi açık tutun. Sürümleme yapın ve geriye dönük uyumluluğu koruyun: alan eklemek genelde güvenlidir, alan silmek ya da anlamını değiştirmek tüketicileri kırar. REST ve gRPC arasındaki seçimde dış tüketim ve tarayıcı erişimi için REST, servisler arası yüksek performanslı ve güçlü tipli iletişim için gRPC sık tercih edilir; ancak ekibin araç bilgisi ve altyapısı da belirleyicidir.

Çağrı zincirlerini kısa tutun. Bir isteği karşılamak için birden fazla servisin art arda çağrıldığı yapı, sınır tasarımının yeniden değerlendirilmesi gerektiğini gösterebilir. Çağrı sayısını azaltmak için veriyi toplayan bir API geçidi ya da ayrı bir okuma modeli kullanılabilir.

Asenkron iletişimi güvenli kurmak

Asenkron iletişimde mesaj aracı (kuyruk ya da olay akışı platformu) merkezî bir bileşen olur. Tasarımda şu konular öne çıkar:

• Teslimat semantiği: Çoğu sistemde mesajlar en az bir kez teslim edilir; yani tekrar gelebilir. Alıcılar tekrar-güvenli (idempotent) olmalıdır.
• Atomik yayımlama: Veritabanını güncelleyip olay yayımlamak aynı işlemde olmalıdır. Outbox deseni bu sorunu çözmek için yaygın kullanılır.
• Olay sözleşmesi: Olayın içeriği ve şeması bir sözleşmedir; tüketicileri kırmadan evrilmesi için sürümleme ve geriye dönük uyum önemlidir.
• Hatalı mesajlar: İşlenemeyen mesajlar için yeniden deneme politikası ve ölü mektup kuyruğu (dead-letter queue) gerekir; sonsuz yeniden deneme hattı tıkar.
• Sıralama: Sıra önemli ise aynı varlığa ait mesajların aynı bölüme gitmesini sağlayın.
• Tutarlılık: İş akışı birden fazla servisten geçiyorsa saga gibi desenlerle tutarlılığı yönetin.

Asenkron akışı izlenebilir kılmak için her mesaja ilişki kimliği ekleyin, kuyruk gecikmesini ve birikmiş mesaj sayısını izleyin. Kullanıcıya sonuç gecikmeli döneceği için arayüzde "işleniyor" durumunu ve sonuç bildirimini planlayın.

Örnek: sipariş akışında yaklaşımların birlikte kullanımı

Bir e-ticaret siparişini düşünelim. Kullanıcı "Siparişi tamamla" düğmesine bastığında sipariş servisi, sepetteki ürünlerin stokta olduğunu ve fiyatın doğru olduğunu doğrulamak için katalog servisini senkron çağırır; çünkü kullanıcı sonucu hemen bekler ve hata durumunda ekranda uyarılmalıdır. Çağrıya zaman aşımı ve devre kesici konur.

Sipariş kaydedildikten sonra sipariş servisi "sipariş oluşturuldu" olayını yayımlar. Stok servisi stoğu düşürmek, e-posta servisi onay maili göndermek, analiz servisi satışı kaydetmek için bu olayı kendi hızında işler. Sipariş servisi bu servislerin kapalı olmasından etkilenmez ve yeni bir dinleyici eklemek siparişi değiştirmeyi gerektirmez.

Ödeme gibi sonucu hemen gereken ama dış servise bağlı adımda ise sıklıkla melez yaklaşım kullanılır: istek senkron alınır, ödeme asenkron işlenir, sonuç bildirimi ile siparişin durumu güncellenir. Akış çok adımlıysa orkestrasyon ya da saga yaklaşımı gerekir.

Sık yapılan hatalar

En sık hata, her şeyi senkron kurmaktır: servisler zincir halinde birbirini beklediğinde sistemin dayanıklılığı en zayıf halkaya düşer. Tersi de bir hatadır: her şeyi asenkron yapmak, basit bir sorgu için bile kuyruk ve gecikme eklemek, kullanıcıya anlaşılmaz durumlar yaşatır.

Diğer hatalar: zaman aşımı koymamak, kontrolsüz yeniden denemeyle yük bindirmek, olay sözleşmesini sürümlememek, tekrar gelen mesajları işleyememek, olay yerine veritabanı paylaşımıyla iletişim kurmak, ölü mektup kuyruğunu izlememek, izlenebilirlik için ilişki kimliği eklememek, olay ile komutu karıştırmak (olayı "şunu yap" emri gibi kullanmak).

Seçimi belgelemek için her servis çiftinin etkileşim türünü, nedenini ve hata davranışını kısa bir tabloya yazın. Bu, ekipler arası beklentiyi netleştirir ve tasarım değişikliğinde hızlı karar verdirir.

Bu beceriyi geliştirmek için eğitim bağlamı

İletişim biçimi seçimi; sınırlar, veri tutarlılığı, dayanıklılık ve gözlemlenebilirlik kararlarıyla iç içedir.

Mindset'in Mikroservis Mimarisi eğitimi, servisler arası iletişimi ayrı bir modül olarak işler; veri yönetimi ve tutarlılık, dayanıklılık desenleri ve API geçidi ve servis ağı modülleri bunu tamamlar. Java Mikroservisleri (Spring Cloud) eğitiminde servisler arası iletişim ve dayanıklılık ile veri yönetimi ve olay tabanlı entegrasyon modülleri yer alır. Bu içerikler arka uç geliştiricileri ve yazılım mimarları için uygundur; ekiplerde ortak bir iletişim standardı oluşturmak için kullanılabilir.