Bir gıda çarşısında yemek yediğinizi düşünün. Her yiyecek tezgahı belirli bir mutfak türünde uzmanlaşmıştır: Birinden döner, diğerinden bir dürüm, ve içecek reyonundan bir soğuk içecek alırsınız. Her tezgah bağımsız çalışsa da, genellikle bir merkezi ödeme noktası ve sipariş toplama merkezi gibi ortak bileşenler vardır.

Örneğin, ödeme işlemleri bir merkezi ödeme noktasında yapılır. Bu ödeme noktası, her tezgaha ödemenin yapıldığına dair bir sinyal gönderir. Bu sayede, dürüm tezgahı ödemenizin gerçekleştiğini anlar ve siparişinizi hazırlar.

Aynı şekilde, sipariş toplama merkezi, farklı tezgahlardan gelen siparişleri toplar ve onları tek bir yerden müşterilere dağıtır. Bu merkez, her bir tezgahın sipariş durumunu takip ederek, tüm süreci koordine eder.

Bu örnek, yazılım dünyasının “Mikroservis” mimarisine oldukça benzer. Her mikroservis bağımsız olarak çalışır, fakat etkili bir şekilde koordine olabilmeleri için bir merkezi ödeme servisi veya sipariş yönetimi gibi bileşenlere ihtiyaç vardır.

Mesela, bir servis ödeme işlemleri için sorumludur ve ödeme başarılı olduğunda, diğer servislere bu durumu bildirir. Bu, örneğimizdeki dürüm tezgahının ödeme alındı sinyalini alması gibi çalışır.

Bir başka servis, kullanıcı taleplerini yönetir ve bu taleplerin hangi servis tarafından işleneceğini belirler. Bu da, yemek çarşısındaki sipariş toplama merkezinin işlevine benzer. Bu yazıda, mikroservis mimarisinde iletişiminin getirdiği doğal zorlukları ve modern uygulamalarda bu zorlukların nasıl aşılacağını anlatacağım.

Monolit ve Mikroservis Mimarisinde İletişim Zorluğu

• Mikroservis mimarisiyle uygulama geliştirme ve dağıtımı köklü bir şekilde değişti. Fakat bu değişiklik, özellikle servisler arası iletişim konusunda kendi zorluklarını da beraberinde getirdi. Örneğin:
  • Monolitik bir mimaride, tüm işlemler bir merkezden kontrol edilir. Bir hata, tüm sistem için probleme yol açabilir.
  • Monolitik mimaride, tüm uygulama tek bir blok olarak ölçeklenir. Bu, belirli bir bileşenin (örneğin, veritabanı erişimi) aşırı yüklenmesi durumunda, tüm sistemi etkileyebilir.
  • Bileşenler arası yüksek bağımlılık, bir bileşenin değişiklik veya güncellemesinin diğer bileşenleri de etkileme riskini artırır.
  • Tek bir kod tabanı üzerinde çalışıldığı için, farklı teknolojileri veya dilleri entegre etmek genellikle daha zor olabilir.
• Buradaki zorluğu kendi örneğimizle açıklamamız gerekirse; tek bir mutfak olduğunu düşünelim ve bu mutfaktan tüm işlemlerin gerçekleştirildiğini varsayalım:
  • Mutfakta yaşanabilecek bir arıza, tüm sistemin aksamasına neden olabilir. Bu, mutfakla olan yüksek bağımlılığımızı gösterir. (Dependency)
  • Birden fazla müşterinin geldiğini varsayalım. Eğer müşteriler sadece dürüm istiyorsa, sadece dürüm için mutfak genişletilmek zorunda kalınır. Bu, tüm sistemin sadece bir öğe için ölçeklendirilmesi anlamına gelir. (Scalability)
  • Yeni bir yemek eklenirken, mevcut tüm yemeklerin düzeni değiştirilmek zorunda kalabilir. (Deployment)
  • Yiyecek tezgahları belirli kurallar ve standartlar etrafında döner. Bu, tüm sistem için belirli bir standart ve uyumluluk sağlasa da, bireysel bileşenlerin ihtiyacına göre hızlı bir şekilde değişiklik yapabilmelerini veya farklı yöntemler denemelerini engeller. (Low flexibility)
• Buna göre Mikroservis mimarisi bize şu avantajları sunar:
  • Her bir yemek türü ayrı bir mutfak olarak sunulur. (Decentralized)
  • Eğer bir yemek türü yapılması kesildiğinde diğer yemek türleri bundan etkilenmez. (Isolation of Failure)
  • Sadece dürüm’e olan talep arttığında onun kendi mutfağının genişletilmesi diğer mutfakların sabit kalmasını sağlar ve ekstra maliyetten kurtarır. (Scalability)
  • Yeni bir yemek türü tanıtıldığından diğer mutfakları etkilemez. (Deployment)
• Burada her şey en iyi durum varsayılarak düşünüldü. Ya bu mikroservis mimarisi iyi bir şekilde koordine edilmezse;
  • Aşırı Ağ Trafik Yükü
    • Tezgahlar arasında sürekli bilgi alışverişi yapılması, siparişleri koordine etme sürecini yavaşlatabilir. Örneğin, içecek tezgahı dürüm tezgahından sürekli olarak sipariş bilgisi alıyorsa, bu durum siparişin tamamlanma süresini uzatabilir. (Network Traffic Overload)
  • Veri Tutarsızlığı
    • Dürüm tezgahı bir siparişi tamamladığını belirtirse ancak ödeme bankosu bu bilgiyi güncellemezse, müşteri siparişini almakta zorluk yaşayabilir. (Data Inconsistency)
  • Zaman Aşımı Sorunları
    • İçecek tezgahı, bir dürüm siparişinin ne zaman hazır olacağını öğrenmek için dürüm tezgahına sıkça sormak zorunda kalırsa, bu durum siparişin tamamlanmasını geciktirebilir. (Network Latency)
  • Karmaşıklık
    • Eğer tezgahlar birbirleriyle sürekli iletişimde olmaları gerekiyorsa, bu durum koordinasyon sürecini karmaşıklaştırabilir. (Complexity)
  • İşlem Bütünlüğü
    • Eğer bir müşteri birden fazla tezgahdan sipariş verdiyse ve bir tezgah siparişi tamamlamazsa, bu durum müşteri memnuniyetsizliğine yol açabilir.

  Bu problemleri çözmek için genellikle iki tür iletişim modeli kullanılır: Eş Zamanlı(Senkron) ve Eş zamansız(Asenkron) iletişim:

  İletişim Stillerinin Hızlıca Gözden Geçirilmesi: Senkron ve Asenkron İletişim

  Senkron ve asenkron iletişim, mikroservis mimarilerinde kritik öneme sahiptir:

• Mikroservislerde Eş Zamanlı İletişim:
  • Mikroservisler mimarisinde senkron iletişim, tipik olarak bir istek/yanıt paradigmalarını içerir. Bir servis, diğerine bir istekte bulunur ve çağrı yapan servis bir yanıt bekler. Bu, örneğin REST API çağrıları üzerinden uygulanabilir.
  • Bir tezgahın diğer tezgaha spesifik bir talepte bulunması ve bir yanıt beklemesi şeklinde çalışır. Örneğin, içecek tezgahı dürümün hazır olduğu bilgisini dürüm tezgahından bekler. Sadece bu bilgi alındığında, içeceği hazırlar.
  • Bunun bize avantajı basit ve doğrudan bir iş akışı sağlar fakat dezavantajı ise; içecek tezgahı, dürüm tezgahından bilgi gelene kadar beklemek zorundadır. Bu, toplam sipariş zamanını uzatabilir. Ayrıca, bir tezgahın diğerine bağımlılığını artırrır.
  • Sonuç olarak, eş zamanlı iletişim basit ve doğrudandır, ancak servisler arasında bağımlılığa yol açabilir ve çağrı yapan servisin yanıtı beklemesi gerektiği için gecikmeyi artırabilir.
• Mikroservislerde Eş Zamansız İletişim:
  • Burada bir servis, diğerine bir mesaj gönderir ve yanıt beklemez. Mesaj kuyrukları ve event-driven mimariler, asenkron iletişimin sağlanmasında kullanılır.
  • Pizza tezgahı bir sipariş aldığında hemen bir mesaj gönderir salata tezgahına, fakat bir yanıt beklemez ve kendi işlemine devam eder. Salata tezgahı mesajı aldığında, kendi iş akışına göre salatayı hazırlar.
  • Bu yöntem, tezgahların birbirlerinden bağımsız çalışmasına olanak sağlar, bu da genellikle daha hızlı ve ölçeklenebilir bir sistem anlamına gelir.
  • Asenkron iletişim, özellikle çok sayıda bağımsız tezgah varsa, daha karmaşık hale gelebilir. Eğer bir tezgahın gönderdiği mesaj kaybolur veya gecikirse, bu durum siparişin tamamlanmasını zorlaştırabilir.

Sonuç

Bu ilk yazıda mikroservis mimarisinin iletişim dinamiklerini çözmeye çalıştık. Ancak daha yolun başındayız. İkinci yazımda, ‘Mikroservis Mimarisi: Eş Zamanlı İletişimin Detaylı İncelemesi’ ile daha derinlere dalacağız.

Kaynakça

• https://microservices.io/index.html
• ChatGPT