Mikro Hizmet Mimarisi ile Olay Güdümlü Mimari: Bölme Kararı ve İletişim Kararı

Kısa cevap: Aynı sorunun iki farklı ekseni

Bu iki kavram çoğu zaman birbirinin alternatifi gibi konuşulur, oysa farklı soruları yanıtlarlar. Mikro hizmet mimarisi, uygulamanın nasıl parçalara bölüneceğini anlatır: her hizmet tek bir iş yeteneğini üstlenir, kendi verisine sahiptir, ayrı bir kod tabanında tutulur ve diğerlerinden bağımsız olarak dağıtılır. Microsoft'un Azure mimari rehberi bunu sınırlı bağlam (bounded context) içinde tek bir iş yeteneği uygulayan küçük, özerk hizmetler topluluğu olarak tanımlar.

Olay güdümlü mimari ise bileşenlerin birbiriyle nasıl haberleşeceğini anlatır. Olay üreticileri bir durum değişikliğini (sipariş oluşturuldu, ödeme alındı) olay olarak yayımlar, olay kanalı bunu taşır, olay tüketicileri dinler ve tepki verir. Üretici, kimin dinlediğini bilmez.

Bu yüzden asıl seçim çoğunlukla "mikro hizmet mi, olay güdümlü mü" değil, "mikro hizmetlerim birbirine doğrudan istek mi atsın, olay mı yayımlasın" sorusudur. Bir sistem mikro hizmetlerden oluşup tamamen senkron API çağrılarıyla çalışabilir; tek parça (monolit) bir uygulama da dış sistemlerle olay üzerinden konuşabilir.

Ortak zemin: Gevşek bağlılık ve dağıtık sistem gerçekleri

İki yaklaşım da bileşenler arasındaki bağımlılığı azaltmayı hedefler ve ikisi de dağıtık sistemin zorluklarını beraberinde getirir. Ortak noktaları şunlardır: • Bağımsız ölçekleme: Yükü artan parça, sistemin geri kalanı büyütülmeden ölçeklenebilir. • Hata yalıtımı: Bir bileşenin çökmesi, doğru tasarlandığında tüm sistemi durdurmaz. • Nihai tutarlılık: Veri birden fazla hizmete dağıldığında tek bir veritabanı işleminin (ACID) sağladığı anlık tutarlılık kaybolur; sistem bir süre farklı parçalarda farklı durum gösterebilir. • Gözlemlenebilirlik ihtiyacı: Tek bir kullanıcı işlemi birçok bileşenden geçer; ilişkilendirme kimliği (correlation ID), merkezi günlük ve dağıtık izleme olmadan hata bulmak zorlaşır. • Olgun DevOps kültürü: Otomatik test, bağımsız dağıtım hattı ve izleme altyapısı her ikisinde de ön koşuldur.

Bu ortaklık nedeniyle iki yaklaşım sıkça aynı projede buluşur. Microsoft'un rehberi de olay güdümlü mimarinin mikro hizmetler, olay kaynaklama (event sourcing) ve borular-filtreler gibi stillerle birleştirilerek hibrit yapı kurulabileceğini belirtir.

Ölçüt ölçüt temel farklar

• Yanıtladığı soru: Mikro hizmet / sistem hangi sınırlardan bölünür, kim neyin sahibidir. Olay güdümlü / bileşenler birbirine nasıl haber verir.
• Temel birim: Mikro hizmet / iş yeteneği etrafında kurulmuş, kendi verisine sahip hizmet. Olay güdümlü / geçmişte olmuş bir şeyi bildiren olay ve onu taşıyan kanal.
• Varsayılan iletişim: Mikro hizmet / iyi tanımlanmış API'ler; senkron istek-yanıt da asenkron mesajlaşma da olabilir. Olay güdümlü / asenkron yayın; üretici yanıt beklemez.
• Bağımlılık yönü: Mikro hizmet / çağıran hizmet, çağrılan hizmeti ve adresini bilir. Olay güdümlü / üretici tüketicileri tanımaz; yeni tüketici eklemek üreticiyi değiştirmez.
• Altyapı: Mikro hizmet / API geçidi, konteyner orkestrasyonu, hizmet keşfi. Olay güdümlü / mesaj aracısı (broker), olay akışı platformu, şema yönetimi.
• Tipik risk: Mikro hizmet / uzun senkron çağrı zincirlerinde gecikme ve zincirleme hata. Olay güdümlü / olay sırası, aynı olayın iki kez işlenmesi, kaybolan mesaj, akışın izlenememesi.
• Tasarım odağı: Mikro hizmet / alan analizi ve hizmet sınırları. Olay güdümlü / olay tasarımı, şema sürümleme, idempotent tüketici.
• Test zorluğu: Mikro hizmet / bağımlı hizmetlerin taklit edilmesi, sözleşme testleri. Olay güdümlü / uçtan uca asenkron akışın doğrulanması, gecikmeli tutarlılığın testi.

Olay güdümlü iletişim hangi durumda öne çıkar?

Azure mimari rehberi olay güdümlü yaklaşımın şu koşullarda uygun olduğunu söyler: • Aynı olayı birden fazla alt sistemin işlemesi gerekiyorsa (sipariş oluşunca stok, faturalama ve bildirim hizmetlerinin ayrı ayrı tepki vermesi gibi). • Gecikmesi düşük, gerçek zamanlıya yakın işleme gerekiyorsa. • Zaman penceresi içinde örüntü yakalama ya da toplama gibi karmaşık olay işleme gerekiyorsa. • Nesnelerin interneti gibi yüksek hacimli, yüksek hızlı veri akışı varsa. • Üretici ile tüketicinin birbirinden bağımsız ölçeklenmesi isteniyorsa.

Örneğin bir e-ticaret sisteminde sipariş hizmeti "Sipariş Oluşturuldu" olayını yayımladığında depo, muhasebe ve sadakat puanı hizmetleri bunu kendi hızlarında işler. Daha sonra eklenen bir kampanya analiz hizmeti de aynı olayı dinlemeye başlar; sipariş hizmetinin kodunda değişiklik gerekmez. Olay akışı (event streaming) modelinde olaylar kalıcı bir günlüğe yazıldığı için yeni tüketici geçmiş olayları da baştan okuyabilir.

Senkron istek-yanıt hangi durumda daha doğrudur?

Aynı rehber, olay güdümlü yaklaşımın uygun olmayabileceği durumları da açıkça sayar: basit istek-yanıt akışlarında senkron çağrı gecikme ve hacim ihtiyacını karşılıyorsa, iş işlemi hizmetler arasında güçlü tutarlılık gerektiriyorsa ve ekip dağıtık asenkron sistem işletme deneyimine sahip değilse.

Pratikte bu şu anlama gelir: Kullanıcının ekranda anında yanıt beklediği sorgularda (müşterinin kredi limitini sorgulamak, stokta ürün olup olmadığını göstermek) doğrudan API çağrısı daha anlaşılır ve izlenebilirdir. Banka hesapları arası para aktarımı gibi "ya hep ya hiç" işlemlerde nihai tutarlılık kabul edilemiyorsa, işlemi tek bir hizmetin sınırı içinde tutmak çoğu zaman daha sağlıklı bir yoldur. Olay tabanlı bir akış kurulacaksa telafi edici işlem ve Saga deseniyle geri alma mantığının baştan tasarlanması gerekir.

Birlikte kullanım: Olay güdümlü mikro hizmetler

Olgun sistemlerde iki yaklaşım sıkça bir arada bulunur: hizmet sınırları mikro hizmet ilkeleriyle çizilir, hizmetler arasındaki iletişimin bir kısmı senkron API, bir kısmı olay olur. Bu karışımı sağlıklı kurmak için izlenen tipik adımlar şunlardır: • Önce alan analiziyle hizmet sınırlarını belirleyin; olay tasarımı ancak sınırlar netleştikten sonra anlam kazanır. • Hizmetin kendi verisini değiştirdiği anı yayımlamak için outbox (giden kutusu) desenini kullanın; böylece veritabanı güncellemesi ile olay yayını arasında kayıp oluşmaz. • Tüketicileri idempotent yazın; aynı olay ikinci kez geldiğinde sonuç değişmemelidir. • Olay şeması için baştan bir sürümleme stratejisi belirleyin; üretici ve tüketiciler aynı anda güncellenemez. • İşlenemeyen olaylar için hata işleyici ve ölü mektup kuyruğu (dead-letter queue) tanımlayın. • Her olaya ilişkilendirme kimliği koyun ve dağıtık izlemeyi ilk günden kurun.

Sık yapılan hatalar da bu adımların tersidir: veritabanı tablosunu olduğu gibi olay olarak yayımlamak, "veri değişti" gibi genel olaylar üretmek, hizmetler arasında ortak kütüphane ve şema paylaşmak, tüm akışı olaya çevirip kullanıcıya anında dönmesi gereken sorguları da kuyruğa sokmak.

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

Mikroservis Mimarisi eğitimi, servis sınırlarını çizme, servisler arası iletişim, veri yönetimi ve tutarlılık, dayanıklılık desenleri ile API geçidi konularını ele alır; monolitten bölünmeye hazırlanan ya da mevcut hizmetlerinin sınırlarını tartışan yazılım mimarları ve kıdemli geliştiriciler için uygundur.

Olay güdümlü tarafta Olay Güdümlü Mimari (Event-Driven Architecture) Tasarımı programı olay fırtınası ile alan modelleme, olay şeması ve sürüm yönetimi, üretici ve tüketici desenleri ile dağıtık iş akışları ve nihai tutarlılık modüllerini içerir. İki dünyanın kesişimine odaklanan Mikroservislerde Olay Tabanlı Entegrasyon Desenleri eğitimi ise outbox, idempotency ve dağıtık iş akışı başlıklarıyla, hizmetleri zaten ayrılmış ve aralarındaki entegrasyonu güvenilir hale getirmek isteyen platform ve backend ekiplerine hitap eder. Kurumsal ekipler bu başlıkları kendi sistemleri üzerinden ortak bir tasarım çalışması olarak işleyebilir.