Bir sistemi mikro hizmetlere ayırmak her zaman doğru değildir.
Bir hizmeti ayırma için geçerli nedenlerin yanı sıra, hizmetleri bir arada tutma veya ilk başta ayırmama konusunda da güçlü nedenler vardır.
Bu nedenler Granularity Integrators olarak bilinir.
Hizmeti ayırmadan önce duraksamanızı veya büyük tutmanın gerekçesini sağlayan faktörlerdir.
Doğru hizmet boyutunu seçme becerisi, dekompozisyon sürücüleri ile entegrasyon sürücüleri arasında dengeyi sağlamaktan geçer, körü körüne bir yönde gitmekten değil.
Aşağıda, hizmetleri entegre etmek veya ayırmaktan kaçınmak için en önemli dört neden bulunmaktadır.
1. Veritabanı İşlemleri (ACID)
Bir işlem, sistemin birden fazla parçasında güçlü bir ACID işlemi gerektiriyorsa, bu parçalar genellikle ayrı hizmetler olmamalıdır.
Örnek (Laravel)
Bir Sipariş oluşturmak ve Stok güncellemek birlikte gerçekleşmelidir.
Birinin başarısız olması durumunda, her ikisi de geri alınmalıdır.
Eğer bu işlemler ayrı hizmetlerde ise, şunlara ihtiyacınız olacaktır:
- Dağıtılmış işlemler
- Karmaşık telafi mantığı
- Daha yüksek hata senaryoları
Bu durumda, entegrasyon veya monolit mantıklı ve daha basit bir seçimdir.
2. İş Akışı & Koreografi Karmaşıklığı
Şunu kendinize sorun:
Hizmetlerin, tek bir iş operasyonunu tamamlamak için yoğun iletişime ihtiyacı var mı?
Örnek:
- Sipariş Servisi
- Ödeme Servisi
- Gönderim Servisi
Eğer her sipariş bu hizmetler arasında sürekli bir gidiş-geliş iletişimi gerektiriyorsa, ayırmak:
- Gecikmeyi artırabilir
- Operasyonel karmaşıklığı artırabilir
- Hata ayıklamayı çok daha zor hale getirebilir
Yüksek iletişim yükü, genellikle ayırmanın daha fazla zarar verebileceğinin bir işaretidir.
3. Ortak Kod
Birden fazla hizmet aynı karmaşık mantığa bağımlı mı?
Örnek (Laravel)
Birden fazla hizmette tekrar kullanılan karmaşık doğrulama mantığı olduğunu düşünün.
Eğer:
- Aynı kodu her yerde kopyalıyorsanız
- Veya sıkça çağrılan paylaşılan hizmetler oluşturuyorsanız
O zaman hizmet ayrımı gürültülü ve kırılgan hale gelir.
Bu durumda, mantığı bir arada tutmak daha temiz ve sürdürülebilir olabilir.
4. Veritabanı İlişkileri
Kodu ayırabiliyor olsanız bile — veriyi ayırabilir misiniz?
Örnek
Şunlar gibi varlıklar:
Sıklıkla güçlü ilişkisel bağımlılıklara sahiptir.
Eğer hizmetler:
- Sık sık birleştirme gerektiriyorsa
- Güçlü tutarlılık garantilerine ihtiyaç duyuyorsa
- Veri seviyesinde sıkı bağlantı gerektiriyorsa
O zaman ayırmak, şu sorunları ortaya çıkarır:
- Karmaşık senkronizasyon
- Tutarlılık sorunları
- Sonsuz kenar durumları
Bazen, veritabanı modeli mikro hizmetlere karşı çıkar.
Son Düşünceler
Mikro hizmetler bir hedef değildir — bunlar bir mimari tercihtir.
- Aşırı ayırma karmaşıklığı artırır
- Aşırı entegrasyon esnekliği azaltır
İyi bir mimari dengedir.
Ayırmayı veya entegre etmeyi gerçek kısıtlamalar ve alan ihtiyaçları temelinde yapmalısınız, trendler veya hype değil.
Gerçeklik için tasarlayın — moda için değil.
Kaynak: Orijinal Makale
