Mikroservis Mimarisi ile Ölçeklenebilirlik

Monolit kötü değildir

Yazılım dünyasında mikroservis mimarisi uzun süredir modern olmanın simgesi gibi anılıyor. Bu yüzden birçok ekip, henüz ihtiyacı yokken uygulamasını onlarca küçük servise bölmeye kalkışıyor. Oysa bütün özelliklerin tek bir uygulama içinde yaşadığı monolitik yapı, pek çok proje için hâlâ en doğru başlangıç.

Monolit tek bir yerde geliştirilir, tek seferde test edilir, tek seferde yayına alınır. Küçük ve orta ölçekli ekipler için bu sadelik büyük bir avantaj. Sorun, uygulama ve ekip büyüdükçe ortaya çıkıyor; bu yazıda o noktanın nasıl anlaşılacağını ve geçişin nasıl güvenle yapılacağını anlatıyoruz.

Mikroservis nedir, kısaca

Mikroservis mimarisinde uygulama, her biri belirli bir iş alanından sorumlu, bağımsız olarak geliştirilip yayına alınabilen küçük servislere bölünür. Örneğin bir e-ticaret sisteminde sipariş, ödeme, stok, kargo ve bildirim ayrı servisler olabilir. Her servisin kendi verisi, kendi yayın takvimi ve gerektiğinde kendi ölçeklenme ayarı vardır.

Bu bağımsızlığın bedeli ise karmaşıklık: tek bir uygulama yerine birbirleriyle ağ üzerinden konuşan çok sayıda parça yönetilir. Doğru zamanda yapılan geçiş bu bedeli fazlasıyla karşılar; yanlış zamanda yapılan geçiş ise ekibi yavaşlatır.

Ne zaman mantıklı?

Aşağıdaki işaretlerden birkaçını birlikte görüyorsanız, parçalı bir mimariyi değerlendirme zamanı gelmiş olabilir:

• Farklı ekipler aynı kod tabanında çalışıyor ve birinin değişikliği sık sık diğerinin işini bozuyor.
• Küçük bir değişikliği yayına almak bile uzun bir test ve onay sürecine takılıyor.
• Sistemin belirli bir bölümü (örneğin kampanya dönemlerinde sipariş alma) diğerlerinden çok daha fazla yük alıyor ve bütün uygulamayı büyütmek pahalıya patlıyor.
• Bir bölümdeki hata bütün sistemi durdurabiliyor.
• Bazı bölümlerin farklı bir teknolojiyle geliştirilmesi gerçekten avantaj sağlayacak.

Ne zaman mantıklı değil?

• Ekip küçükse ve herkes uygulamanın tamamını rahatça tanıyorsa.
• Ürün henüz şekilleniyorsa; iş alanlarının sınırları belirsizken çizilen servis sınırları da yanlış olur.
• Otomatik test, otomatik yayın ve merkezi izleme altyapısı henüz yoksa.
• Asıl sorun performans değil de kod kalitesiyse; dağınık bir monolit, dağınık mikroservislere dönüşür.

Sınırları iş alanına göre çizin

Başarılı bir geçişin en kritik kararı, servislerin sınırlarını nereden çizeceğiniz. Teknik katmanlara göre bölmek (veritabanı servisi, arayüz servisi gibi) genellikle hayal kırıklığıyla sonuçlanıyor. Doğru yaklaşım, işin kendi doğal parçalarına göre bölmek: sipariş, faturalama, stok, müşteri.

İyi çizilmiş bir sınırın işareti, bir iş değişikliğinin çoğu zaman tek bir servisi etkilemesi. Bir kampanya kuralı değiştiğinde yalnızca fiyatlandırma servisine dokunuluyorsa sınır doğru; her değişiklik üç dört servisi birlikte güncellemeyi gerektiriyorsa, sınırlar yeniden düşünülmeli.

Veri sahipliği

Mikroservislerde en sık yapılan hata, servisleri ayırıp veritabanını ortak bırakmak. Bu durumda servisler kâğıt üzerinde bağımsızdır, ama bir tablodaki değişiklik hepsini etkiler. Her servis kendi verisinin sahibi olmalı; başka bir servis o veriye ihtiyaç duyduğunda, tabloya doğrudan erişmek yerine sahibine sormalı.

Bu yaklaşım, raporlama gibi birden çok servisin verisini birleştiren ihtiyaçlar için ayrı bir çözüm gerektirir. Genellikle servislerin yayınladığı olaylardan beslenen, yalnızca okuma amaçlı bir raporlama katmanı kurulur.

Servisler nasıl konuşur?

Servisler arası iletişimde iki temel yol var. Senkron iletişimde bir servis ötekine istek gönderir ve cevabı bekler; anlaşılması kolaydır, ama karşı taraf yavaşladığında ya da çöktüğünde bekleyen servis de etkilenir. Asenkron iletişimde ise servis bir olay yayınlar ("sipariş oluşturuldu") ve ilgilenen servisler bu olayı kendi hızlarında işler; bir servisin geçici olarak çalışmaması diğerlerini durdurmaz.

Çoğu sistemde ikisi birlikte kullanılır: anında cevap gereken işlemler için senkron çağrılar, birden çok servisi ilgilendiren gelişmeler için mesaj kuyrukları. Asenkron yapıda aynı mesajın iki kez işlenmesi ya da sırasının karışması gibi durumlara karşı önlem almak da tasarımın parçası olmalı.

Gözlemlenebilirlik: log, metrik, iz

Monolitte bir hata olduğunda tek bir log dosyasına bakmak çoğu zaman yeterlidir. Mikroservislerde ise tek bir kullanıcı isteği beş farklı servisten geçebilir; sorunun nerede çıktığını anlamak için üç şey gerekir. Merkezi log toplama: bütün servislerin kayıtları tek yerde aranabilmeli. Metrikler: her servisin yanıt süresi, hata oranı ve yükü izlenmeli. Dağıtık iz: bir isteğin servisler arasındaki yolculuğu baştan sona takip edilebilmeli.

Bu altyapı geçişten önce kurulmalı. Gözlemlenebilirliği sonraya bırakan ekipler, ilk ciddi hatada sorunun hangi serviste olduğunu saatlerce aramak zorunda kalıyor.

Güvenli yayın: test, kademeli yayın, geri alma

Servis sayısı arttıkça yayın sayısı da artar; her yayının riskini düşürmek bu yüzden şart. Otomatik testler, bir servisin değişikliğinin diğerleriyle olan sözleşmesini bozmadığını doğrulamalı. Yeni sürümler önce kullanıcıların küçük bir kısmına açılıp sorun yoksa kademeli olarak yaygınlaştırılmalı. Bir sorun çıktığında da önceki sürüme dakikalar içinde dönülebilmeli.

Servislerin sürümlenmesi de önemli: bir servisin arayüzü değiştiğinde, onu kullanan diğer servislerin aynı anda güncellenmesini beklemek yerine, eski ve yeni sürümün bir süre birlikte çalışması sağlanmalı.

Kademeli geçiş: hepsini birden yeniden yazmayın

Çalışan bir monoliti baştan sona yeniden yazıp bir gecede mikroservislere geçmek, yazılım projelerinin en riskli girişimlerinden biri. Daha güvenli yol, monolitin bir parçasını seçip onu ayrı bir servis olarak çıkarmak, trafiği yavaş yavaş yeni servise yönlendirmek ve eski kodu ancak yeni servis güvenle çalıştıktan sonra kaldırmak.

İlk ayrılacak parça genellikle, en sık değişen ya da en çok yük alan, ama diğer bölümlerle bağı görece az olan bölüm oluyor. Her başarılı ayrıştırma, ekibe hem deneyim hem de bir sonraki adım için güven kazandırıyor.

Maliyet tarafı

Mikroservisler, doğru kullanıldığında altyapı maliyetini düşürebilir: yalnızca yük alan servisi büyütmek, bütün uygulamayı büyütmekten ucuzdur. Ama yeni maliyetler de getirir: daha fazla sunucu bileşeni, izleme araçları, otomasyon altyapısı ve bunları yönetecek uzmanlık. Geçiş kararını verirken bu iki tarafı birlikte hesaplamak, sürprizleri önlüyor.

Özet

Ölçeklenebilirlik yalnızca daha fazla sunucu açmak değil; doğru sınırlar, net veri sahipliği, güvenilir iletişim, gözlemlenebilirlik ve güvenli yayın pratiklerinin birlikte kurulması. Mikroservis mimarisi bu ihtiyaçları karşılayan güçlü bir araç; ama ancak doğru zamanda, kademeli olarak ve sağlam bir altyapının üzerine kurulduğunda.

Büyüyen yazılımınız için doğru mimariyi birlikte değerlendirmek isterseniz yazılım çözümlerimize göz atabilirsiniz. Sistemler arasındaki veri trafiğini düzenlemek üzerine kurumsal veri akışı yazımız da ilginizi çekebilir.