Mikroservis nedir, monolit ne zaman servislere ayrılmalı?
Mikroservis, belirli bir iş yeteneğini kendi dağıtımı ve açık arayüzüyle sunan küçük hizmettir. Monolitik mimaride uygulamanın ana parçaları aynı dağıtım biriminde çalışır. Monolitin büyük olması tek başına ayrılma gerekçesi değildir: küçük ekip, açık modüller ve güvenilir sürüm hattıyla uzun süre tek uygulamayı rahatça yönetebilir. Ayrım, belirli bir parçanın farklı hızda değişmesi, ayrı ölçeklenmesi veya arızasının diğer işlevleri etkilememesi gerektiğinde anlam kazanır. Yeni sınırın kaldırdığı sürtünme, ağ ve işletim maliyetinden fazla olmalıdır.
Önce teslimatı neyin engellediğini sorun. Yavaş derleme, kırılgan dağıtım, çakışan ekip değişiklikleri ve kararsız dış bağımlılık aynı çözümü gerektirmez. Eksik testleri ve elle sürüm çıkarmayı ayrı sunuculara taşımak bu sorunları gidermez. Modüler monolitik mimari, paketler arasında zorlanan bağımlılık kuralları ve açık sahiplikle aynı dağıtım içinde sınır kurar. Bu sınırın işe yaradığını görmeden onu ağa taşımak, belirsizliği büyütebilir.
Kararı teknik moda yerine ölçülen kısıtla verin. Bir bileşeni hızlandırmak için bütün uygulamayı ölçeklemek zorundaysanız kaynak kullanımını inceleyin. Ekipler birbirinin sürümünü bekliyorsa bekleme nedenlerini kaydedin. Her yavaşlığı mikroservis gereksinimi saymak yerine sorunu, bugünkü değerini ve kabul edilecek sonucu tek cümlede ifade edin.
Servis sınırı seçme alıştırması
İlk adım, aday sınırları karşılaştırmaktır. Bir iş akışını çizin; kararların, veri kümelerinin ve dış sözleşmelerin sahiplerini işaretleyin. AWS'nin iş yeteneğine göre ayırma rehberi, satış veya müşteri hizmetleri gibi işin değer üreten yeteneklerini başlangıç noktası olarak kullanır. Bu çalışma için kodu bilen geliştiriciyle birlikte iş kurallarını bilen bir kişi de gerekir.
| Gözlenen durum | İlk seçenek | Ayrım için kanıt |
|---|---|---|
| Testler eksik, sürümler kırılgan | Sürüm hattını iyileştir | Sorun sınır değişince azalmalı |
| Aynı veriye ortak yazım | Monolitte sahiplik kur | Tek yetkili yazar bulunmalı |
| Farklı hızda değişen iş yeteneği | Bağımsız sınırı dene | Eşgüdümsüz sürüm mümkün olmalı |
| Tek bileşende yoğun yük | Ölçekleme adayını ölç | Ek işletim maliyeti karşılanmalı |
| Dış bağımlılık bütün akışı bozuyor | Hata sınırını ayır | Arıza diğer akışlara yayılmamalı |
Üç aday seçip her biri için bir sayfalık karar kaydı oluşturun: iş amacı, veri sahibi, tüketiciler, eşzamanlı çağrılar, ortak işlemler, beklenen yarar ve yeni maliyet. Fiyat hesabı güçlü aday olabilir; bütün özelliklerin kullandığı genel veritabanı erişim katmanı genellikle iş yeteneği değildir. En az bağımlı ve ölçülebilir yararı olan tek adayı deneyin. Toplam puan yüksek olsa bile, hâlâ ortak işlem (transaction) gerektiren bir para kuralı gibi bir engel gözden kaçmamalıdır.
Monoliti ayırmadan önce neyi hazırlamalı?
İlk aşamada yeni sınırı monolitin içinde kurun. Diğer modüller fiyat tablosuna doğrudan erişmek yerine tanımlı arayüzü kullansın. İstek ve yanıt alanlarını, zorunlu bilgileri, hata davranışını ve sürüm uyumluluğunu yazın. Örneğin fiyat isteğinde ürün, müşteri grubu, para birimi ve hesaplama zamanı; yanıtta toplam, vergi ve kural sürümü bulunabilir. Eski davranışı örneklerle kaydeden testler, sınır değişirken beklenmedik sonuçları gösterir.
Veri sahipliği kod sahipliğiyle birlikte çözülmelidir. Microsoft'un mikroservislerde veri yönetimi rehberi, başka servislerin aynı tabloları doğrudan okuyup yazmasının şema üzerinden bağımlılık yarattığını açıklar. Ayrı fiziksel veritabanı sunucusu zorunlu değildir; asıl konu veri ve şema sınırıdır. Bir servisin şema değişikliği bütün ekiplerin aynı anda sürüm çıkarmasını gerektiriyorsa ayrımın özerklik hedefi gerçekleşmemiştir.
Her veri kümesi için yetkili yazarı, okuma yolunu ve güncellik beklentisini kaydedin. Sipariş, fiyat ve stok aynı işlemde değişiyorsa hangi iş kuralının birlikte kesinleşmesi gerektiğini sorun. Gecikmeli güncellemeyi kabul eden rapor ile ödeme tutarının doğruluğunu aynı sınıfa koymayın. İki uygulamaya açıklamasız çift yazım eklemek yerine hata, tekrar ve uzlaştırma davranışını tasarlayın. İş kuralı bölünemiyorsa daha geniş bir sınır veya modüler monolit daha uygun olabilir.
Servis sahibi yalnızca geliştirmeyi değil dağıtımı, izlemeyi, güvenlik güncellemelerini ve olay müdahalesini de üstlenmelidir. Dağıtım hattı, yetkili hizmet kimliği, gizli bilgi yönetimi, istek kimliği ve bağımlılık gecikmesi kaydı hazırlayın. Zaman aşımı ve tekrar deneme sınırlarını uçtan uca gecikme bütçesine göre belirleyin. Dış hizmet yanıt vermezse kullanılacak davranış iş kuralına bağlıdır; ödeme gibi işlemlerde sessizce başarılı görünmek güvenli bir seçenek değildir.
Tek ayrımı geri alınabilir biçimde deneyin
Önce gölge okuma veya yan etkisiz hesaplama yapın: asıl yanıt eski uygulamadan gelsin, yeni sonuç yalnızca karşılaştırma için hesaplansın. Microsoft'un Strangler Fig deseni, işlevleri ortak giriş noktasının arkasında aşamalı değiştirmeyi anlatır. Bu yaklaşım bütün monoliti bir günde yeniden kurmadan tek sınırı sınamanızı sağlar. Rota değişikliğinin önüne bir anahtar koyun ve eski yolun kapasitesini deneme boyunca koruyun.
Karşılaştırmada aynı girdiyi ve aynı kural sürümünü kullanın; değişmiş fiyat verisiyle üretilen iki sonucu hata diye saymayın. Farkları sınıflandırın, beklenen farklılıkları onaylayın, açıklanamayanları düzeltin. Sonra küçük bir kullanıcı grubuyla başlayın. Salt hesaplama için rota geri dönüşü yeterli olabilir; yeni serviste kayıt oluşuyorsa eski sistemin bu kayıtları okuyup işleyebilmesi ayrıca kanıtlanmalıdır. Geri alma planını veri taşınmadan önce yazın.
Varsayımsal örnek: sipariş uygulamasında fiyatlandırma
Örneğin altı kişilik bir ekibin sipariş uygulaması ayda dört ana sürüm çıkarsın; fiyat kuralları ise haftada iki kez değişsin. Son altı haftada 12 fiyat değişikliğinin 8'i ana sürümü beklemiş, ortanca bekleme üç gün olmuş olsun. Günlük 20.000 teklifin fiyat hesabı ayrı bir iş yeteneğidir. İlk hedef, servis sayısını artırmak değil fiyat değişikliklerini bağımsız teslim etmek ve sipariş gecikmesini korumaktır. Bütün rakamlar varsayımsaldır; bir Hatson müşteri sonucu değildir.
Ekip önce monolit içinde fiyat arayüzü ve kural sahipliği oluşturur. 2.000 geçmiş teklif aynı girdilerle karşılaştırılır; kuruş ve vergi farkları ayrı kaydedilir. Ardından trafiğin %5'i yeni servise gider. Bu örnekte kabul hedefi fiyat farkının sıfır olması, uçtan uca p95 gecikmesinin 800 milisaniyeyi aşmaması ve fiyat değişikliği beklemesinin bir günün altına inmesidir. Bunlar evrensel eşik değil, bu örneğe özgü iş hedefleridir.
İki sürümden sonra bekleme azalır fakat yeni nöbet ve altyapı yükü haftada dört saat ekliyorsa kazanç bu maliyetle birlikte değerlendirilir. Hâlâ her fiyat değişiminde sipariş ekibinden eşzamanlı sürüm gerekiyorsa daha çok servis açılmaz. Veri sınırı yeniden ele alınır; gerekirse fiyat modülü tek uygulamada tutulur. Bağımsız geri alma ve ekip sahipliği görülmeden pilot başarılı sayılmaz.
Mikroservis geçişinin test ve ölçüm planı
- Başlangıç değerini kaydedin: Bekleyen dağıtım, değişiklik teslim süresi, hata oranı ve bakım saatini aynı zaman aralığında ölçün. Sonuçları aday sınır bazında ayırın.
- Sözleşmeyi sınayın: Boş değer, eski istemci, yanlış para birimi, yetkisiz çağrı ve sürüm uyumsuzluğu için beklenen yanıtı tanımlayın.
- Arızayı üretin: Servisi durdurun, yanıtı geciktirin ve ağ bağlantısını kesin. Zaman aşımı, tekrar sınırı ve diğer akışların çalışması gözlenebilir olmalı.
- Veriyi uzlaştırın: Tekrar eden istek, eşzamanlı güncelleme ve iptal sonrasında tutarları ve kayıt sayılarını karşılaştırın; farkın sahibini belirleyin.
- Geri dönüşü deneyin: Trafiği eski yola alın, eski kapasiteyi ve yeni kayıtların okunmasını doğrulayın. İşlem sırasındaki kullanıcıları ayrıca kontrol edin.
- Durdurma kuralını uygulayın: İki sürüm sonunda beklenen yarar görülmüyorsa yeni ayrımları durdurun; sınırı veya ilk sorunun tanımını değiştirin.
Sık yapılan hatalar
- Kod satırı veya ekip sayısını tek ayrılma eşiği kabul etmek; iş darboğazını ölçmemek.
- İş yeteneği yerine teknik katmanları ayırıp her isteğe uzun çağrı zinciri eklemek.
- Ortak veritabanı yazımlarını koruyarak yalnızca dağıtım dosyalarını çoğaltmak ve bağımsızlık beklemek.
- İzleme, nöbet, güvenlik bakımı ve veri uzlaştırmasını proje maliyetinden çıkarmak.
- Geri alma anahtarını yeterli sayıp yeni yazılmış verinin eski yolda davranışını sınamamak.
Hatson Tech bunu nasıl kuruyor?
Özel yazılım geliştirme çalışmalarında önce iş akışını, değişiklik beklemelerini ve veri sahipliğini çıkarıyoruz; aday sınırı sözleşme ve kabul testleriyle tanımlıyoruz. Daha geniş seçenekler için uygulama modernizasyonu karar rehberine, seçilen parçanın nasıl taşınacağı için kademeli eski sistem geçiş planına bakabilirsiniz. İlk pilotun çıktısı yeni bir servis olmak zorunda değildir; ölçümle desteklenen bir karar da değerli bir sonuçtur. Mevcut darboğazı ve bir aday iş yeteneğini paylaşmanız, keşif çalışmasının sınırını somutlaştırır.