Mikroservisleri bağımsız değişim ihtiyacına göre seçmek
İş sınırları, veri sorumluluğu ve bağımsız yayımlama ihtiyacı örtüşüyorsa ayrı servis seçeneğini değerlendirin.
Hangi değişiklik bağımsız yapılabilmeli?
Uygulamayı birden fazla servise dağıtmak bağımsız geliştirmeyi kendiliğinden sağlamaz. Aynı kişiler her fiyat kuralında bütün servisleri birlikte değiştirip yayımlamak zorundaysa koordinasyon ihtiyacı sürer. Buna ağ üzerinden çağrılar ve ek işletim işleri eklenir.
Microsoft bağımsız dağıtımı ve verinin kendi sorumlusunun olmasını temel özellikler arasında açıklar. Bu yüzden karara somut bir değişiklikten başlamayı öneriyoruz: Hangi iş alanı, başka alanları aynı anda uyarlamadan bu değişikliği taşıyabilmeli?
Örnek: teklif ve sipariş şimdilik birlikte kalıyor
Bu ürün ve çalışma biçimi kurgusaldır. Tek ekip teklifleri, siparişleri ve raporları yönetir. Fiyat kuralları teklif ile siparişte birlikte değişir. Rapor biçimlerinin değişim ihtiyacı farklıdır.
Örnekte gözlenen sınır | Geçici karar | Kararı desteklemesi gereken koşul |
|---|---|---|
Teklif ve sipariş aynı fiyat kuralı değişikliğini paylaşır. | İçeride açık modüllerle birlikte yayımlamak. | Sorumluluk ve modüller arası erişim açıkça tanımlanır. |
Rapor biçimleri bağımsız değişebilir. | Ayrı modül; somut ihtiyaç varsa ayrı servisi değerlendirmek. | Kararlı veri arayüzü, işletim sorumlusu ve gereken veri güncelliği netleşir. |
Bu planda uygulama önce modüler monolit olarak kalır: iç sınırlar, ortak yayımlama. Spring Modulith, modülün dışa açtığı arayüz ile iç uygulamasının ayrımına örnek verir. Bu ayrımı tanımlamak, o belirli aracı seçmeden de yararlıdır.
İşletimi de karara dahil edin
Ayrı rapor servisi veri kaynağının arızasını ele alabilmelidir. Dağıtım, izleme ve hata incelemesinin sorumlusu gerekir. Ekip, geçişte eski ve yeni arayüz sürümlerinin nasıl birlikte çalışacağını da belirlemelidir. Ayrı süreç olması tek başına bu koşulları sağlamaz.
İleride ayırma gerekçesini kaydedin: Örneğin gerçekten gereken bağımsız yayımlama veya farklı ele alınması gereken yük. Bağımlılığı, veri erişimini ve işletim emeğini yeniden değerlendirin. Birlikte yayımlanan modüller de açık yapılandırılabilir. Diğer yandan iyi sınırlandırılmış bir servis, uygulamanın kalanı bölünmeden de gerekçeli olabilir. Servis sayısı bu kararın kalite ölçüsü değildir.
Kaynaklar
Devamını okuyun
Tüm yazılar
ASES ile Yazılım geliştirme
Özel yazılım, web ve mobil uygulamalar