Mikroservis mimarisi nasıl tasarlanır: sınırlar, iletişim ve veri

Mikroservis mimarisi neyi çözmeyi hedefler?

Mikroservis mimarisi, bir uygulamayı tek bir büyük blok yerine küçük, birbirinden bağımsız dağıtılabilen servislere bölme yaklaşımıdır. Her servis bir iş yeteneğini üstlenir, kendi verisini yönetir ve diğerleriyle iyi tanımlanmış arayüzler üzerinden konuşur. Amaç, ekiplerin birbirini beklemeden değişiklik yapabilmesi, yoğun çalışan parçaların ayrı ölçeklenebilmesi ve bir parçadaki arızanın tüm sisteme yayılmamasıdır.

Bunun bedeli karmaşıklıktır: ağ üzerinden iletişim, dağıtık veri, çoklu dağıtım hatları ve izleme ihtiyacı. Bu yüzden tasarım becerisi, hangi parçayı ayıracağınıza olduğu kadar neyi ayırmayacağınıza da karar vermeyi içerir.

Tasarım adımları: servis sınırlarından başlayın

Sağlıklı bir tasarım genellikle şu sırayı izler:

• İş alanını anlayın: Süreçleri ve kavramları iş tarafıyla birlikte çıkarın. Sınırlı bağlam (bounded context) düşüncesi, hangi kavramın hangi parçaya ait olduğunu bulmanıza yardım eder.
• Sınırları çizin: Birlikte değişen şeyleri aynı serviste, bağımsız değişenleri ayrı servislerde tutun. Sınır, teknik katmana göre değil iş yeteneğine göre çizilir.
• Her servisin verisini ayırın: Servisler birbirinin veritabanına doğrudan erişmemelidir.
• İletişim biçimini seçin: Anlık yanıt gereken yerde eşzamanlı çağrı, iş akışlarını gevşek bağlamak için olay tabanlı iletişim kullanın.
• Dayanıklılığı ve işletmeyi tasarlayın: Zaman aşımı, yeniden deneme, devre kesici, günlük ve izleme baştan düşünülür.

Tasarımı kâğıt üzerinde bitirip sonra küçük bir parçayla doğrulamak, büyük bir tasarımı toptan uygulamaktan çok daha güvenlidir.

Servisler arası iletişim ve veri tutarlılığı

Eşzamanlı iletişimde (genellikle HTTP tabanlı API çağrıları) bir servisin yavaşlaması zincirleme etkiye yol açabilir; bu yüzden zaman aşımı ve devre kesici gibi dayanıklılık desenleri gerekir. Asenkron iletişimde ise servisler bir mesaj aracısı üzerinden olay yayınlar; gönderen, alıcının o anda ayakta olmasına ihtiyaç duymaz. Olay tabanlı mimari bu nedenle mikroservislerle sık birlikte anılır.

Veri tarafında asıl zorluk, tek bir işlemin birden fazla servise yayıldığı durumlardır. Klasik veritabanı işlemi servisler arasında geçmez; yerine ardışık adımlar ve telafi eylemleri içeren saga yaklaşımı gibi yöntemlerle nihai tutarlılık sağlanır. Bu, geliştiricinin düşünme biçimini değiştirir: anlık tutarlılığı her yerde beklemek yerine hangi verinin ne kadar gecikmeyle tutarlı olabileceğine iş tarafıyla birlikte karar verilir.

Örnek senaryo: sipariş akışını servislere ayırmak

Örneğin bir e-ticaret uygulamasında sipariş, stok, ödeme ve bildirim ayrı servisler olsun. Müşteri siparişi verdiğinde sipariş servisi bir olay yayınlar; stok servisi ürünü rezerve eder, ödeme servisi tahsilatı yapar, bildirim servisi müşteriye mesaj gönderir. Ödeme başarısız olursa sipariş servisi bir telafi adımıyla rezervasyonu geri aldırır.

Burada dikkat edilecek nokta, istemcinin tek bir giriş noktasıyla konuşması için bir API geçidi kullanılabilmesi, her servisin kendi veritabanını yönetmesi ve olayların şemasının sürümlenmesidir. Aynı sistemi tek bir uygulamada tutmak, ekip küçükse ve trafik düşükse daha doğru olabilir; mikroservis her proje için varsayılan cevap değildir.

Sık yapılan hatalar

• Çok erken bölmek: İş alanı henüz oturmadan açılan onlarca servis, bakımı zor bir dağıtık monolite dönüşür.
• Ortak veritabanı kullanmak: Servisleri veri düzeyinde birbirine bağlar ve bağımsız dağıtımı imkânsız kılar.
• Gözlemlenebilirliği sona bırakmak: Merkezî günlük, metrik ve izleme olmadan bir isteğin hangi serviste yavaşladığı bulunamaz.
• Her yerde eşzamanlı çağrı zinciri kurmak: Bir servisin arızası bütün zinciri düşürür.
• Güvenliği ve uyumu atlamak: Servisler arası kimlik doğrulama ve yetkilendirme tasarımın parçasıdır.

Sağlam bir yaklaşım, monolitten kademeli ayrıştırmaktır: önce en bağımsız ve en çok değişen parçayı ayırın, işletme alışkanlıklarını oturtun, sonra devam edin.

Başlangıçtan ileri düzeye öğrenme yolu

Başlangıçta mikroservisin neden ortaya çıktığını, monolitle farklarını ve temel iletişim biçimlerini öğrenin; bir web API'si yazıp ikinci bir servisle konuşturmak iyi bir ilk alıştırmadır. Orta düzeyde servis sınırı çizme, API geçidi ve servis ağı, merkezî yapılandırma ve konteyner tabanlı dağıtım konuları gelir. İleri düzeyde dağıtık veri yönetimi, olay kaynaklaması, CQRS, dayanıklılık desenleri, gözlemlenebilirlik ve güvenlik ele alınır.

Hangi dil ya da çerçeveyle çalışırsanız çalışın ilkeler aynıdır; Java dünyasında Spring Cloud ekosistemi bu ilkelerin hazır karşılıklarını sunan yaygın bir örnektir.

Monolit mi mikroservis mi? Ne zaman geçmemelisiniz?

Mikroservis, her sorunun çözümü değildir. Ürün henüz keşif aşamasındaysa ve iş alanı sık değişiyorsa servis sınırlarını doğru çizmek zordur; yanlış sınırlar sonradan pahalı bir yeniden yapılandırmaya yol açar. Küçük ekiplerde ise çok sayıda servisin dağıtımı, izlenmesi ve güvenliği ekibin enerjisini ürün geliştirmeden alıp altyapıya kaydırabilir.

Karar teknik modadan değil ihtiyaçtan gelmelidir. Küçük ekip, belirsiz iş alanı ve düşük trafik varsa iyi yapılandırılmış bir monolit genellikle daha hızlı ve ucuz işletilir. Ekipler birbirini bekleyerek yavaşlıyorsa, parçalar farklı ölçek istiyorsa ya da bağımsız dağıtım kritikse mikroservis anlam kazanır.

Bu durumlarda modüler bir monolit, yani tek dağıtım birimi içinde net modül sınırları olan yapı, mantıklı bir başlangıçtır. Sınırlar oturup ekip büyüdüğünde en bağımsız modül servis olarak ayrılabilir. Mimari karar, bir inanç meselesi değil; ekip yapısı, değişim hızı ve işletme olgunluğuna bakan bir mühendislik değerlendirmesidir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Mikroservis Mimarisi programı servis sınırlarını çizme, servisler arası iletişim, veri yönetimi ve tutarlılık, dayanıklılık desenleri, API geçidi ve servis ağı, gözlemlenebilirlik ve işletme ile güvenlik ve uyumluluk modüllerini içerir.

Java ile çalışanlar için Java Mikroservisleri (Spring Cloud) programı mikroservis tasarımı ve ayrıştırma, servis keşfi ve ağ geçidi, merkezî yapılandırma, dayanıklılık ve olay tabanlı entegrasyon başlıklarına odaklanır. Event-Driven Mimari programı ise olay tasarımı ve şema, mesaj aracısı seçimi, olay kaynaklaması ve CQRS ile entegrasyon konularını ayrıntılandırır.