Mikroservislerde Gevşek Bağlılık

Gevşek bağlılık (loose coupling), servislerin birbiri hakkında olabildiğince az şey bilmesi ve birbirine olabildiğince az bağımlı olmasıdır. Ölçüsü şudur: bir servisi değiştirdiğinde ya da yayınladığında diğerlerine dokunman gerekmiyorsa ve bir servis çöktüğünde diğerleri çalışmaya devam edebiliyorsa bağlılık gevşektir.

Basit bir örnek: sipariş oluşunca müşteriye e-posta gidecek. Sipariş servisi bildirim servisini doğrudan çağırırsa ona bağımlı olur; bildirim servisi çökünce sipariş de alınamaz. Bunun yerine sipariş servisi "sipariş oluşturuldu" olayını yayınlar, bildirim servisi bu olayı dinler. Sipariş servisi bildirim servisinin varlığından bile haberdar değildir; yarın aynı olayı dinleyen bir sadakat puanı servisi eklersen sipariş servisinde tek satır değişmez.

Bunu sağlamanın başlıca yolları:

1. Her servisin kendi veritabanı olsun. En sık yapılan hata ortak veritabanıdır. İki servis aynı tabloyu okuyorsa, tablodaki bir değişiklik ikisini birden bozar. Başka servisin verisine yalnızca onun API'si ya da olayları üzerinden ulaşılır.

2. Servisler yalnızca sözleşme üzerinden konuşsun. Dışarıya açılan API ya da olay yapısı kararlı ve sürümlü olmalı; servisin iç yapısı ve veritabanı modeli dışarı sızmamalı. Değişiklikler geriye uyumlu yapılır (alan eklenir, silinmez).

3. Mümkün olan yerde asenkron iletişim kullan. Olaylar ve mesaj kuyrukları (Kafka, RabbitMQ) servisleri zaman açısından da ayırır: alıcı o an ayakta olmasa bile mesaj bekler.

4. İhtiyaç duyduğun verinin yerel kopyasını tut. Sipariş servisi her istekte müşteri adını kullanıcı servisinden sormak yerine, "kullanıcı güncellendi" olaylarını dinleyip ihtiyacı olan alanları kendi veritabanında saklayabilir.

5. Kaçınılmaz senkron çağrıları koru. Zaman aşımı, devre kesici ve yedek yanıt kullanarak karşı servisin sorununun sana yayılmasını engelle.

6. İş mantığı içeren ortak kütüphanelerden kaçın. Tüm servislerin kullandığı ortak bir "model" kütüphanesi, onları gizlice birbirine bağlar; kütüphane değişince hepsini yeniden yayınlaman gerekir. Yalnızca loglama gibi teknik yardımcılar paylaşılabilir.

7. Sınırları doğru çiz. İki servis hep birlikte değişiyorsa ya da birbirini sürekli çağırıyorsa sorun teknikte değil sınırdadır; büyük olasılıkla tek servis olmaları gerekir.

Bu yapılmadığında ortaya çıkan şeye dağıtık monolit denir: servisler ayrı ayrı çalışır ama birlikte yayınlanmak zorundadır ve biri çökünce hepsi durur. Mikroservislerin karmaşıklığını alıp faydasını alamamış olursun.

Tek sorumlulukla ilişkisi şöyle: tek sorumluluk bir servisin içindeki parçaların birbiriyle ilgili olmasını (yüksek uyum), gevşek bağlılık ise servislerin birbirinden bağımsız olmasını sağlar. İkisi birlikte hedeflenir.