Mikroservis mimarisi: sorumluluk, iletişim ve veri
Mikroservisler, bir uygulamanın parçalarını ayrı geliştirmek ve ölçeklemek için kullanılabilir. Bunun karşılığında ağ iletişimi, veri tutarlılığı ve işletim yükü artar. Servisleri ayırmadan önce bağımsız ekip veya ölçekleme ihtiyacının bu yükü karşılayıp karşılamadığını değerlendirin.
Temel İlkeler
1. Tek Sorumluluk
Her servisin sorumluluğunu belirli bir iş alanıyla sınırlayın. Örneğin sipariş yönetimiyle ödeme işlemleri farklı kurallara ve değişim hızlarına sahip olabilir.
2. Gevşek Bağlantı
Servisler arasında açık API sözleşmeleri kullanın. Bir değişikliğin diğer servisleri nasıl etkilediğini kontrol edin; uyumsuz değişiklikler için geçiş planı hazırlayın.
3. Yüksek Uyum
Birlikte değişen işlevleri aynı serviste tutmak, sık ağ çağrılarını ve servisler arası koordinasyonu azaltabilir. Sınırları yalnızca kodun büyüklüğüne göre belirlemeyin.
İletişim Desenleri
Servislerin iletişim kurması gerektiğinde doğru deseni seçin:
- Senkron (REST/gRPC): Anında yanıt gerektiren gerçek zamanlı istekler için
- Asenkron (Mesaj Kuyrukları): Olay odaklı mimariler ve sonra işlenebilecek operasyonlar için
Veri Yönetimi
Her verinin hangi servis tarafından yönetildiği açık olmalıdır. Fiziksel olarak ayrı veritabanları kullanmak tek seçenek değildir; başka servislerin iç tablo yapısına bağımlı olmasını önlemek asıl amaçtır.
- Veriye yazma sorumluluğunu tek bir serviste tutun
- Diğer servislerin erişimi için API veya olay sözleşmeleri belirleyin
- Geciken veya tekrarlanan olaylarda veri tutarlılığını nasıl koruyacağınızı planlayın
Sonuç
Önce bir servis sınırını deneyin; bağımsız yayınlamanın faydasını ölçün. Hataları izlemek için günlükler, metrikler ve dağıtık izleme kurun. Bölmenin faydası işletim maliyetini karşılamıyorsa tek uygulama içinde modüler bir yapı daha uygun olabilir.
