Mikroservis Mimarisi: Eş Zamanlı İletişim

Serinin ilk blog yazısında giriş seviyesinde örneklerle başladık. Şimdiki kısımda monolitik bir yapının mikroservis mimarisinden farkını işledikten sonra mikroservis mimarisinde eş zamanlı iletişimi teknik derinlikte inceleyeceğiz.

Eş Zamanlı İletişim

Eş zamanlı (senkron) iletişim, bir işlemin bir diğerini beklediği bir iletişim tarzıdır. Pratikte, bu “sor ve yanıt bekle” modeline benzer. Yani bir işlem (ya da bir ‘servis’ ya da ‘modül’ gibi düşünebiliriz) başka bir işlemden bir şey yapmasını istediğinde, yanıt alana kadar bekler. Yanıt geldiğinde, işlem tamamlanır ve ilk işlem devam eder.

Bu yazıda, mikroservis mimarisinde eş zamanlı iletişim ile monolit sistemdeki iletişim farkını ve bu sistemde eş zamanlı iletişimi neden, ne zaman ve nasıl kullanılacağı üzerinde duracağız. Ancak, bu tür iletişimin sadece avantajlarını değil, aynı zamanda hangi durumlarda kullanmaktan kaçınmamız gerektiğini de ele alacağız.

Monolit İletişim Yaklaşımı ve Mikroservis Eş Zamanlı İletişim Yaklaşımı:

Monolitik bir yapıda, tüm modüller veya bileşenler aynı işlem içinde çalıştığından, iletişim doğrudan aynı işlem içinde gerçekleşir. Bu, hızlı veri paylaşımı sağlasa da, genellikle bağlılık ve ölçeklenebilirlik gibi kısıtlamaları beraberinde getirir. Mikroservis mimarisinde ise, eş zamanlı iletişimi belirli senaryolar için kullanırken, bu iletişimin avantajlarından da yararlanır. Özellikle, bağımsız olarak ölçeklendirilebilen, hata toleransı yüksek ve geliştirme süreçlerini basitleştiren bir yapı sunar. Bu sayede, her bir servisi optimize etmek ve özel gereksinimlere yanıt vermek daha kolay hale gelir.

Monolit yapılardaki iletişim yaklaşımını ele aldık ve mikroservis mimarisinde nasıl bir dönüşüm yaşandığını gördük. Peki, bu dönüşümün altında yatan temel sebep neydi? Şimdi, mikroservis mimarisinde neden eş zamanlı iletişime bu kadar ihtiyaç duyduğumuza odaklanalım.

Neden Eş Zamanlı İletişime İhtiyaç Duyarız?

Mikroservis mimarisinde eş zamanlı iletişime tamamen bağlı kalmak istemesek de, bu yaklaşımın sunduğu çeşitli avantajlar bazen kaçınılmaz kılıyor. Hızlı ve anlık geri bildirim sağlama, sıralı iş akışlarını kolaylaştırma, programlama karmaşıklığını azaltma, güvenilir hata raporlama ve veri tutarlılığı gibi unsurlar, eş zamanlı iletişimin uygulamamız için oldukça değerli olmasını sağlıyor. Bu avantajlar, bu iletişimin bazı senaryolarda vazgeçilmez bir araç olmasına yol açıyor. Bu senaryoları inceleyelim:

• Hızlı Geri Bildirim
  • Bir servis diğer bir servise bir talepte bulunur ve hemen bir yanıt bekler. Bu, kullanıcı deneyimini iyileştirebilir; çünkü son kullanıcı bir işlemi gerçekleştirdiğinde, sistem hemen bir yanıt vererek işlemin başarılı olup olmadığını bildirir.
  • Telefonla karşı tarafa soru sorduğunuzda, hemen bir yanıt beklersiniz. Bu anlık geri bildirim, konuşmanın akıcı ve etkili olmasını sağlar.
• Sıralı İş Akışları
  • Bir servisin diğerinin tamamlanmasını ve beklemesini sağlar.
  • Telefon görüşmesinde bir konuyu kapattıktan sonra diğerine geçersiniz. Örneğin, bir restoranda masa rezervasyonu yaptırırken önce müsaitlik durumunu sorar, sonra rezervasyon yaparsınız. Her adımın tamamlanması bir sonraki adım için temel oluşturur.
• Programlama Karmaşıklığını Azaltma
  • Servisler arası etkileşimi basit ve anlaşılır hale getirir. Bir servis talep yaptığında, ne zaman bir yanıt alacağını ve bu yanıtın ne olacağını önceden bilmek daha kolaydır.
  • Telefon görüşmesi sırasında, konuşulanları ve cevapları sırayla takip etmek, karmaşık bir konuşma yerine konuyu daha basit ve anlaşılır hale getirir.
• Güvenilir Hata Raporlama
  • Bir servis hata verdiğinde bu hemen tespit edilir. Bu, hataların daha hızlı çözülmesini ve kullanıcıya daha hızlı geri bildirim sağlanmasını mümkün kılar.
  • Eğer telefonunuz kesilirse veya karşı taraf cevap vermezse, bu hemen anlaşılır ve problemin ne olduğunu hızlıca tespit etmek mümkündür.
• Veri Tutarlılığı
  • Verinin hızlı bir şekilde güncellenmesini ve tüm servisler tarafından görülmesini sağlar.
  • Telefon görüşmesinde, bir konu veya soru hakkında aldığınız yanıt, genellikle o an için geçerli ve tutarlıdır. Örneğin, bir havayolu şirketini arayıp uçak bileti fiyatını sorduğunuzda, aldığınız yanıt o an için geçerli bir bilgidir ve diğer planlarınızı buna göre yapabilirsiniz.

Eş zamanlı iletişimin neden bu kadar önemli olduğunu ele aldık ve altında yatan sebepleri inceledik. Ancak her durumda eş zamanlı iletişimi tercih etmek doğru olmayabilir. Peki, hangi durumlarda bu iletişim şeklini tercih etmeliyiz? Şimdi bu konuya daha yakından bakalım.

Ne Zaman Eş Zamanlı İletişimi Tercih Etmeliyiz?

Mikroservis mimarisi içerisinde, iletişim yönteminin eş zamanlı olup olmadığı özel ihtiyaçlara ve iş gereksinimlerine bağlıdır. Bu ihtiyaçlar nelerdir, hangi durumlarda eş zamanlı iletişimin tercih edileceği ve bu yaklaşımın bize ne gibi avantajlar sağlayabileceği, aşağıda maddeler şekilde ele alınmıştır.

• Hızlı Geri Bildirim Gerekliyse
  • Eğer kullanıcının veya bir başka servisin, işlemin başarılı olup olmadığını hemen öğrenmesi gerekiyorsa.
  • Bir e-ticaret sitesine giriş yaptığınızda, sepetinizdeki ürünü satın almak için ödeme bilgilerinizi girersiniz. Bu durumda, uygulama sunucusu eş zamanlı olarak bir istekte bulunur ve size ödemenizin onaylandığı ya da reddedildiği konusunda hızlı bir geri bildirim sağlar. Kullanıcılar, bu tür işlemlerde hızlı ve kesin bir geri bildirim almayı tercih ederler ve sistem bu ihtiyacı etkin bir şekilde karşılar. Bu senaryoda, eş zamanlı iletişim sayesinde:
    • Kullanıcılar anında geri bildirim alır, bu da güven ve memnuniyet oluşturur.
    • Ödeme işlemi hızlı bir şekilde tamamlanır, bu da kullanıcı deneyimini olumlu etkiler.
    • İşlemlerin hızlı bir şekilde tamamlanması, kullanıcının platformu daha etkin bir şekilde kullanabilmesine olanak tanır.

Eş zamanlı iletişimin sağladığı hızlı ve etkin cevap mekanizması, özellikle ödeme gibi kritik işlemlerde kullanıcı memnuniyetini artırır.

• Sıralı İşlemler Var İse
  • Bir işlem diğerini tetikliyorsa ve her birinin başarıyla tamamlanması bir sonraki için önemliyse.
  • Bir otomobil kiralama şirketinde, müşteriler online olarak araç rezervasyonu yapabilirler. Müşteri, uygun bir aracı seçtikten ve rezervasyon için gerekli bilgileri ( kiralanacak gün sayısı, alış ve dönüş noktası vb.) girdikten sonra, bir ödeme işlemi gerçekleştirilir. Bu sırada, sistemin eş zamanlı olarak birkaç işlemi yürütmesi gerekir:
    1. Müşterinin seçtiği tarihler için aracın müsait olup olmadığını kontrol etmek.
    2. Eğer araç müsaitse, ödeme işlemleri için müşteri bilgilerini almak.
    3. Ödemenin onaylanması durumunda, rezervasyonu kesinleştirmek ve aracı müsait olmayanlar listesine eklemek.
    4. Müşteriye hızlı bir şekilde rezervasyonun onaylandığına veya reddedildiğine dair bilgi göndermek.
    Avantajları

    • Hızlı Geri Bildirim: Müşteri, ödeme işlemi ve araç müsaitliği hakkında hızlı bir geri bildirim alır. Bu, müşterinin diğer planlarını yapabilmesi için çok önemlidir.
    • Kullanıcı Deneyimi: Ödeme ve araç müsaitliği hemen onaylanırsa, müşteri için bu sürecin ne kadar hızlı ve sorunsuz olduğuna dair pozitif bir izlenim oluşturur.
    • Veri Tutarsızlığını Önleme: Bir aracın aynı tarihler için birden fazla kişiye kiralanması gibi olası veri tutarsızlıkları önlenir.
    • İş Etkinliği: Birçok işlemi hızlı ve etkin bir şekilde tamamlamak için gereklidir, bu da genel iş etkinliğini artırır.

  Bu örnekte, otomobil kiralama şirketlerinde sıralı işlemlerin hızlı ve etkin bir şekilde gerçekleştirilmesine imkan tanır. Bu yaklaşım, müşterilere hızlı geri bildirim sağlar, kullanıcı deneyimini iyileştirir ve olası veri tutarsızlığını engeller.

• Veri Tutarlılığı Önemliyse
  • Çok sayıda servisin birbiriyle veri paylaştığı senaryolarda, tutarlı ve güncel veriye ihtiyaç duyuluyorsa.
  • E-ticaret sitesinde bir kullanıcı, sınırlı sayıda bulunan bir ürünü satın almak istiyor.
  Bu durumda avantajları:

  • Hızlı Geri Bildirim: Kullanıcı, ödeme işlemi sırasında hızlı bir şekilde stok durumu hakkında bilgi alır. Bu, kullanıcı deneyimini pozitif yönde etkiler.
  • Veri Tutarsızlığını Önleme: Eş zamanlı iletişim, aynı ürünün birden fazla kullanıcıya satılmamasını garantiler. Bu, veri tutarlılığı açısından çok önemlidir.
  • İş Etkinliği: Eş zamanlı iletişim, stok ve ödeme işlemlerinin hızlı ve etkin bir şekilde yürütülmesini sağlar, bu da genel iş etkinliğini ve müşteri memnuniyetini artırır.

  Bu örnekte, stok takip gibi kritik işlemlerde veri tutarlılığını sağlamak, iş etkinliğini artırmak ve kullanıcı deneyimini iyileştirmek için kritik bir rol oynar.

• Hata Yönetimi
  • Bir işlem sırasında bir hata oluştuğunda, bu hatanın hemen tespit edilmesi ve gerekli düzeltmelerin yapılmasını sağlar.
  • Bir şehirde akıllı elektrik şebekesi kurulmuştur ve bu şebeke, enerji üretiminden tüketime kadar tüm süreçleri izlemektedir. Sistem, enerji üretimi, enerji dağıtımı, enerji depolama ve tüketici tarafındaki enerji kullanımını koordine eden farklı servislerden oluşur. Burada da eş zamanlı iletişim ve hata yönetimi kritik öneme sahiptir.
  İş Akışı

  1. Elektrik tüketimi aniden artar (örneğin, bir etkinlik ya da acil bir durum nedeniyle).
  2. Tüketici servisi, bu durumu enerji üretim ve dağıtım servislerine eş zamanlı olarak bildirir.
  3. Üretim servisi, yetersiz enerji durumunu tespit eder ve enerji depolama servisine bir istekte bulunur.
  4. Enerji depolama servisi, ek enerji sağlayabilirse işlemi onaylar.
  5. Herhangi bir hata durumunda (örneğin, depolanan enerjinin yetersiz olması), tüm işlemler durdurulur ve yetkililere hata mesajı gönderilir.
  Bu durumda avantajları:

  • Hızlı Geri Bildirim: Enerji talebinin karşılanamayacağı hızlı bir şekilde tespit edilir.
  • Veri Tutarlığı: Enerji üretimi ve tüketimi arasında tutarsızlıkların anında fark edilmesini sağlar.
  • Operasyonel Etkinlik: Hata durumlarında hızlı tepki vermek, olası enerji kesintilerini veya enerji israfını önlemeye yardımcı olur.
  • Kullanıcı Deneyimi: Elektrik kesintileri veya dalgalanmalar anında tespit edilip düzeltilebildiğinden, tüketicilerin genel deneyimi olumlu etkilenir.

  Bu senaryoda, akıllı elektrik şebekesinin farklı bileşenleri arasında eş zamanlı iletişim sayesinde hata yönetimi etkin bir şekilde yürütülmektedir. Bu yaklaşım, enerji taleplerinin hızlı ve güvenilir bir şekilde karşılanmasını, veri tutarlılığını ve operasyonel etkinliği sağlar.

• Düşük Gecikme Süresi
  • Gecikme süresi, bir işlemin başlatılması ve tamamlanması arasında geçen zamanı ifade eder.
  • Bir oyun firmasının çok oyunculu bir oyun yapmaktadır. Bu oyunlarda genellikle yüksek eş zamanlı işlem kapasitesine ve düşük gecikme sürelerine ihtiyaç vardır. Örneğin, bir savaş oyunu düşünün. Oyuncuların hareketleri, saldırıları ve diğer etkileşimleri son derece eş zamanlı ve gerçek zamanlı olmalıdır. Bu tür bir sistem için mikroservis mimarisi kullanılabilir:
    1. Oyuncu Konum Servisi: Oyuncuların anlık konumlarını izler.
    2. Envanter Servisi: Oyuncunun envanterini (silahlar, eşyalar vs.) yönetir.
    3. Oyun Durumu Servisi: Oyunun genel durumunu, kimin kazandığını, kimin kaybettiğini vs. yönetir.
    4. Sohbet Servisi: Oyuncular arası sohbeti yönetir.

    Bu servislerin her biri ayrı ayrı ölçeklenebilir ve geliştirilebilir. Ancak, bu servisler arası iletişimin son derece hızlı ve etkili olması gerekmektedir. Örneğin, bir oyuncu bir saldırı yaparsa, bu bilgi hem Oyuncu Konum Servisi’ne hem de Oyun Durumu Servisi’ne anında iletilmelidir. Ayrıca, Envanter Servisi’nin de güncellenmesi gerekebilir.

Eş zamanlı iletişimin ne zaman tercih edilmesi gerektiğini derinlemesine inceledikten sonra, şimdi teknik yönüyle daha detaylı bir bakış sunacağız. Mikroservis mimarisinde eş zamanlı iletişim için kullanılan temel yaklaşımlar olan REST, GraphQL ve gRPC’yi mercek altına alalım.

Eş Zamanlı İletişim için Mikroservis Mimarisinde Kullanılan Yaklaşımlar: REST, GraphQL ve gRPC

Servislerin birbiriyle verimli ve hızlı bir şekilde konuşabilmesi için kritik bir öneme sahiptir. Bu yaklaşımda genellikle belirli bir işlevi yerine getirmek üzere tasarlanmış, bağımsız çalışabilen küçük servislerdir. Ancak, bu servislerin kendi başlarına çok fazla bir anlamı yoktur; güçlerini, birbirleriyle ve dış dünya ile etkileşime girebildiklerinde gösterirler.

Bu etkileşim, çeşitli yaklaşım ve teknolojiler kullanarak gerçekleştirilebilir. Her bir yaklaşım, farklı avantajlar ve dezavantajlar sunar, bu yüzden ihtiyaca uygun olanı seçmek önemlidir. Bu bölümde, eş zamanlı iletişim için sıkça kullanılan üç popüler yaklaşımı kısaca ele alacağız: REST (Representational State Transfer), GraphQL ve gRPC (gRPC Remote Procedure Calls). Her bir yaklaşımın nasıl çalıştığı, hangi tür projeler için uygun olduğu ve avantajları ile dezavantajları üzerinde duracağız.

REST

REST (Representational State Transfer), web servisleri için bir mimari yaklaşımıdır. Web kaynaklarının URL’ler aracılığıyla temsil edilmesine dayanır ve bu kaynaklara standart HTTP metodları (GET, POST, PUT, DELETE vb.) ile erişilir. Ayrıca, REST’in web dünyasında bu kadar popüler olmasının arkasında yatan sebepler sorusunun cevabı nedir?

İşte REST’in sunduğu başlıca avantajlar:

• Basit ve Anlaşılır: Standart HTTP metodları kullanarak, servislerin nasıl çalıştığını anlamak daha kolaydır.
• Ölçeklenebilir: Durumsuz yapısı sayesinde, RESTful servisler kolayca ölçeklenebilir ve büyük sistemlere uyum sağlar.
• Platform Bağımsız: REST, farklı teknolojilerle ve platformlarla kolaylıkla entegrasyon yapabilme avantajına sahiptir.
• Durumsuz: Her istekte gerekli tüm bilgilerin gönderilmesi, bir isteğin diğer isteklerden bağımsız olmasını sağlar.
• Önbellekleme: REST, HTTP’nin sunduğu önbellekleme mekanizmalarını kullanarak, sunucu yükünü azaltabilir ve cevap sürelerini hızlandırabilir.
• Esneklik: REST, standartlaşmış HTTP yöntemleri kullanarak geniş cihaz ve istemci setleriyle esnek entegrasyonlar sağlar.
• Test Edilebilirlik: Kolayca HTTP API kısmını tarayıcı, Postman plugin, ve curl gibi komutlarla test edilebilir.

REST’in avantajlarını kavradıktan sonra, hangi durumlarda bu yaklaşımın tercih edilmesi gerektiği sorusu akıllara gelmektedir. İşte REST’ı düşünmeniz için bazı kritik senaryolar:

• Web tabanlı uygulamaların arkasında basit ve etkili bir API oluşturma ihtiyacı duyduğunuzda,
• Büyük ve ölçeklenebilir sistemler geliştiriyor olmanız,
• Farklı platformlar veya cihazlar arasında sorunsuz entegrasyon yapma ihtiyacınızın bulunması.

Bu maddeler, REST’in en verimli şekilde ne zaman kullanılacağını göstermektedir. Fakat REST bize çoğu konuda büyük bir avantaj sağlamasına rağmen bazı durumlarda REST bizim için uygun bir yaklaşım olmaktan çıkar bu durumlar:

• İnternet Bağımlılığı: REST, çalışması için sürekli bir internet bağlantısına ihtiyaç duyar. Bu, çevrimdışı çalışma ihtiyacı olan uygulamalar için bir engel teşkil edebilir.
• Sürüm Kontrolü Zorluğu: REST API’lerde yapısal bir değişiklik olduğunda, genellikle yeni bir sürüm oluşturmak gerekebilir. Bu, API’nin sürdürülebilirliği ve yönetimi açısından zorluklara neden olabilir.
• Aşırı İstek: Bazı durumlarda, bir istemcinin tüm gerekli bilgilere erişebilmesi için birden fazla istekte bulunması gerekebilir. Bu, performansı etkileyebilir ve aşırı istek yapısına neden olabilir.
• Çoklu İstek Karmaşıklığı: Birden fazla istek gerektiğinde HTTP metodlarının karmaşıklaşması.
• Çoklu Kaynak Talebi: Tek bir istekte birden fazla kaynağa erişim ihtiyacının zorlukları.

Özetlemek gerekirse, REST, web servislerinin ve uygulamalarının ihtiyaç duyduğu ölçeklenebilirlik, basitlik ve platform bağımsızlığı sağlar ve bu nedenle birçok modern web uygulamasında ve servisinde tercih edilen bir mimari yaklaşımdır. Ancak, internet bağımlılığı, belirli sorgulama esnekliğinin eksikliği ve standartlaşmamış hata mesajları gibi dezavantajları da bulunmaktadır. Bu nedenle, bir mimari yaklaşım seçerken projenizin ihtiyaçlarına ve kısıtlamalarına dikkatlice bakmalısınız.

gRPC

gRPC, Google tarafından açık kaynaklı olarak geliştirilen bir uzaktan prosedür çağrısı (RPC) framework’üdür. Temel hedefi, servisler arası iletişimi hızlı, verimli ve kolay bir şekilde sağlamaktır. Bu amaçla, Protocol Buffers (çoğunlukla “protobuf” olarak bilinir) adlı seri hale getirme formatını kullanmaktadır. Peki, gRPC’nin teknoloji dünyasında bu kadar öne çıkmasının nedenleri nelerdir? İşte bu soruya ışık tutan bazı avantajları:

• Hızlı ve Etkili: Protobuf, oldukça hafif ve hızlı bir seri hale getirme yöntemidir. Bu, daha az bant genişliği tüketimi ve hızlı veri transferi anlamına gelir.
• Çok Dilli: Hangi dilde çalışırsanız çalışın, gRPC’nin otomatik kod üretimi sayesinde farklı teknolojilerle yazılmış servisler arasında iletişim kurabilirsiniz.
• Gerçek Zamanlı(Real-Time) Uygulamalar İçin Hazır: Tek ve çift yönlü streaming desteğiyle gerçek zamanlı veri transferi mümkündür.
• Optimize Edilmiş Bağlantı: HTTP/2 üzerinden çalışma, bağlantıların daha etkili yönetilmesini sağlar.

Avantajlarını gözden geçirdikten sonra, gRPC’nin hangi durumlarda tercih edilmesi gerektiğini belirlemek de büyük önem taşımaktadır. Özellikle şu senaryolarda gRPC’yi düşünmelisiniz:

• Mikroservis mimarisiyle çalışıyor olmanız,
• Düşük gecikmeyle yüksek performanslı uygulamaların peşinde koşmanız,
• Farklı platformlar ve diller arasında entegrasyon ihtiyacınızın olması.

Bu maddeler, gRPC’nin ideal olarak ne zaman kullanılması gerektiğine dair bazı ipuçları sunmaktadır.

gRPC’nin dezavantajları ise:

• Öğrenme Eğrisi: gRPC ve Protocol Buffers’ı tam olarak anlamak ve etkili bir şekilde kullanmak için biraz zaman harcamanız gerekebilir. Özellikle REST ve JSON’a aşina olan geliştiriciler için bu yeni yapı biraz karmaşık gelebilir.
• Tarayıcı Desteği: gRPC, doğrudan tarayıcılar tarafından tam olarak desteklenmemektedir. Bu, özellikle web uygulamaları için bir sorun olabilir.
• Altyapı Uyumluluğu: Bazı altyapı araçları ve ara katman teknolojileri gRPC’yi tam olarak desteklemeyebilir. Bu da entegrasyon ve dağıtım süreçlerinde bazı zorluklara yol açabilir.
• Veri Boyutu: Protobuf, seri hale getirme için oldukça verimlidir; fakat, kullanılan şema veya yapı karmaşıklaştığında, üretilen veri boyutu büyüyebilir.
• Hata Yönetimi: gRPC, hataların standartlaşmış bir şekilde döndürülmesini sağlamak için kendi mekanizmasına sahip olmasına rağmen, bu mekanizma her zaman yeterince açıklayıcı olmayabilir.
• Sınırlı Test Araçları: gRPC için test yapma süreci, diğer API yaklaşımlarına göre biraz daha zorlayıcı olabilir. Özellikle, postman gibi yaygın kullanılan API test araçları gRPC’yi doğrudan desteklememektedir. Bunun yerine, geliştiriciler genellikle .proto dosyalarına dayalı olarak çalışan özel eklentileri (örn. grpcurl, BloomRPC gibi araçlar) kullanarak gRPC servislerini test ederler. Bu, öğrenme eğrisini artırabilir ve test sürecini daha karmaşık hale getirebilir.

Sonuç olarak, gRPC, modern uygulamaların iletişim ihtiyaçları için oldukça uygundur. Özellikle mikroservis mimarileri, gerçek zamanlı uygulamalar ve çok dilli projelerde tercih edilen bu framework, geleceğin iletişim protokolü olmaya aday. Ancak, her teknoloji gibi gRPC’nin de bazı dezavantajları bulunmaktadır. Tarayıcı destek eksikliği, zorlaşan hata yakalama süreçleri ve sınırlı test araçları, gRPC’nin karşılaştığı bazı zorluklardır. Bu dezavantajlar, gRPC’yi seçerken dikkate alınmalıdır, böylece doğru teknoloji seçimine yönlendirme yapabilirsiniz.

GraphQL

GraphQL, Facebook tarafından 2015 yılında tanıtılmış bir sorgu dilidir ve veri ihtiyaçlarınızı tam olarak tanımlamanıza olanak tanır. Bu, istemcilerin ihtiyaç duydukları veriyi kesin olarak belirtmelerini sağlar, böylece fazla veya yetersiz veri getirme sorunları minimize edilir. Peki, GraphQL’in teknoloji dünyasında bu kadar popüler olmasının sebepleri nelerdir? İşte karşınızda GraphQL’in bazı dikkat çekici avantajları:

• Veri Odaklı: İstemciler, ihtiyaç duydukları veriyi kesin olarak belirleyebilirler, bu da veri kullanımını optimize eder.
• Esnek: Geliştiriciler, mevcut API’ları değiştirmeden yeni özellikler ekleyebilir veya mevcut özellikleri modifiye edebilir.
• Tek Noktadan Erişim: Tüm verilere tek bir endpoint üzerinden erişebilirsiniz, bu da veri sorgulama sürecini basitleştirir.
• Tip Güvenliği: GraphQL şeması, veri tiplerini kesin olarak tanımlar, bu da potansiyel hataları önlemede yardımcı olabilir.

GraphQL’in benzersiz avantajlarını öğrendikten sonra, bu teknolojinin ne zaman en iyi şekilde kullanılacağını anlamak kritik bir öneme sahiptir. İşte GraphQL’i tercih etmeniz için bazı senaryolar:

• Özelleştirilmiş veri ihtiyaçlarına sahip farklı istemcileriniz (web, mobil vb.) olduğunda,
• Sık sık değişen veya evrilen bir API yapısına sahip olduğunuzda,
• Tek bir sorguda birçok kaynaktan veri almanız gerektiğinde.

Bu maddeler, GraphQL’in hangi durumlarda ideal olarak kullanılması gerektiğine ışık tutmaktadır.

GraphQL dezavantajları ise:

• Öğrenme Eğrisi: GraphQL, özellikle geleneksel REST API’lere aşina olanlar için yeni bir yaklaşımdır. Bu nedenle, öğrenme eğrisi başlangıçta zorlu olabilir.
• Performans Sorunları: Aşırı geniş veya karmaşık sorgular, sunucuda performans sorunlarına neden olabilir. Bu, özellikle sorgu derinliğini kontrol etmediğinizde veya sorgu karmaşıklığını sınırlandırmadığınızda ortaya çıkabilir.
• Cache Zorluğu: GraphQL, otomatik HTTP önbelleğe almanın yanı sıra CDNs ile kullanım için o kadar uyumlu değildir. Bu, performans ve verimlilikte sorunlara neden olabilir.
• Rate Limiting’in Karmaşıklığı: GraphQL ile her sorgu farklıdır. Bu, geleneksel API end-point bazlı rate limiting yöntemlerini kullanmayı zorlaştırır.
• Gelişmiş Güvenlik Önlemleri: Karmaşık sorgular, sunucular üzerinde istenmeyen yük oluşturabilir. Bu, DoS saldırılarına karşı koruma gereksinimini artırabilir.
• Büyük Sorgu Yanıtları: Kullanıcıların istedikleri veriyi belirtmeleri, gereksiz veri göndermeden verimliliği artırabilir. Ancak bu, bazı durumlarda beklenenden daha büyük yanıtlara neden olabilir.

Sonuç olarak, GraphQL, modern uygulamaların ve servislerin spesifik veri ihtiyaçlarını karşılamak için oldukça uygun bir seçenektir. Özellikle özelleştirilmiş veri ihtiyaçları ve dinamik API yapıları olan projelerde, GraphQL, veri sorgulama ve kullanma süreçlerini radikal bir şekilde iyileştirebilir. Ancak, her teknolojide olduğu gibi, GraphQL’in de bazı dezavantajları bulunmaktadır. Öğrenme eğrisi, karmaşık sorguların getirebileceği performans sorunları, önbelleğin karmaşıklığı ve rate limiting zorlukları bu dezavantajlardan sadece birkaçıdır. Bu nedenle, bir projede GraphQL’i benimseme kararı alırken hem avantajları hem de dezavantajları dikkatlice değerlendirmek önemlidir.

REST, GraphQL, and gRPC arasındaki temel farklar

Sonuç Olarak

• REST, web uygulamaları için genel amaçlı bir mimari tarzdır. Oldukça basit ve anlaşılırdır, ancak büyük ve karmaşık sistemlerde veri optimizasyonu konusunda sıkıntılar yaşayabilir.
• GraphQL, kullanıcının tam olarak ne istediğini belirtmesine olanak tanır, bu da veri erişimini optimize eder. Ancak bu esneklik, sunucu tarafında ek kompleksiteye neden olabilir.
• gRPC, yüksek performanslı ve düşük gecikmeli servisler için idealdir. Çoğunlukla servisler arasındaki iletişim için tercih edilir.

Uygulamanızın ihtiyaçlarına ve önceliklerine bağlı olarak bu teknolojilerden birini seçmek daha uygun olabilir. Örneğin, servisler arasında hızlı ve etkili iletişim istiyorsanız gRPC iyi bir seçenek olabilir. Ancak, uygulamanızda veri erişiminin esnek olmasını istiyorsanız GraphQL daha uygun olacaktır. REST ise genel amaçlı ve basit bir çözüm arayışındaysanız tercih edebilirsiniz.

Bu bağlantıda yer alan YTE Blog üzerindeki yazı, REST API ve gRPC’nin karşılaştırılmasını daha ayrıntılı bir şekilde ele alıyor. Bu blog yazısını inceleyebilirsiniz.

Mikroservis Mimarisinde Eş Zamanlı İletişimi Ne Zaman Tercih Etmemeliyiz?

Mikroservis mimarileri çoğu zaman eş zamansız iletişim modelleri ile daha uyumlu olabilir, özellikle de büyük, karmaşık ve ölçeklenebilir sistemler söz konusu olduğunda. İşte eş zamanlı iletişimi tercih etmemeniz için bazı detaylı nedenler:

• Bağımlılıklar
  • Kopuk Bağımlılıkların Önemi: Eş zamanlı iletişim, servisler arasında sıkı bağımlılıklar oluşturur. Bu da bir servisin değiştirilmesi veya güncellenmesi gerektiğinde, bağımlı olan diğer servisleri de etkileme riskini beraberinde getirir.
    • E-ticaret platformlarında, ödeme işlemleri ve envanter güncellemeleri genellikle bağımsız servisler olarak çalıştırılır. Ancak bu servisler arasında eş zamanlı bir iletişim modeli varsa, bir servisteki aksaklık veya hata diğer servisi de etkileyebilir. Örneğin:
      • Bir kullanıcı bir ürünü satın almak istediğinde ödeme işlemi gerçekleştirilir.
      • Ödeme işlemi başarılı olduğunda envanter servisi ürün stoğunu günceller.

    Bu süreçte eğer ödeme servisinde bir hata oluşursa, envanter servisinin güncellenmemesi veya yanıltıcı bir güncelleme yapması olasıdır. Bu durum, ürünün hâlâ stokta olduğu halde kullanıcıya “Stokta yok” mesajı gösterilmesi gibi kötü kullanıcı deneyimlerine yol açabilir.

• Performans ve Ölçekleme
  • Ölçekleme Zorlukları: Eş zamanlı iletişim, özellikle büyük ölçekli sistemlerde ölçekleme zorluklarına yol açabilir. Tek bir servis üzerindeki yük arttığında, tüm sistem bu durumdan olumsuz etkilenebilir.
    • Bir sosyal medya platformunda, milyonlarca kullanıcı olduğunu düşünelim. Popüler bir kullanıcının (örneğin, bir ünlü) bir gönderisini beğendiğinde bu beğeni eş zamanlı olarak tüm takipçilere bildirilmek istenirse, bu durumda milyonlarca kullanıcıya aynı anda bildirim göndermek gerekecektir. Eş zamanlı bir yaklaşımla bu işlemi gerçekleştirmek, sunucular üzerinde ciddi bir yük oluşturacaktır.
      • Bu yükün neden olduğu sorunlar:
        1. Sunucu Taşmaları: Sistem, aniden gelen yüksek talebi karşılayamazsa çökebilir.
        2. Yüksek Maliyet: Bu yükü karşılamak için ekstra sunucu kaynaklarına yatırım yapmak gerekebilir.
        3. Veri Tutarsızlığı: Eş zamanlı işlemler sırasında veri tutarsızlıkları oluşabilir. Örneğin, bazı kullanıcılara bildirim ulaşırken bazılarına ulaşmayabilir.

      Eğer bu gecikmeler toplam süreci ciddi anlamda uzatırsa, kullanıcı yorumunu gönderdikten sonra yorumunun anında görünmediğini düşünerek, yorumunu tekrar göndermeye çalışabilir veya sayfayı yenileyebilir. Bu da hem kullanıcı deneyimini olumsuz etkiler hem de sunucu üzerinde gereksiz yük oluşturabilir.

  • Ağ Gecikmesi: Eş zamanlı iletişimde herhangi bir gecikme veya aksama, tüm işlem sürecini etkileyebilir.
    • Bir haber portalında, kullanıcının yaptığı yorumun anında gösterilmesi isteniyorsa, bu işlem genellikle eş zamanlı bir süreçle gerçekleştirilir. Kullanıcı yorumu gönderdiğinde, bu yorum önce sunucuya ulaşır, veritabanına kaydedilir ve ardından kullanıcıya geri dönülerek yorumun gösterilmesi sağlanır.
      • Ancak bu süreçte aşağıdaki ağ gecikmeleri yaşanabilir:
        1. Kullanıcıdan Sunucuya İletim: Kullanıcının yorumunun sunucuya iletilmesi sırasında ağdaki gecikmeler.
        2. Sunucu İşlemleri: Sunucunun yorumu işleyip veritabanına kaydetmesi ve yanıtını kullanıcıya geri göndermesi sırasında yaşanabilecek gecikmeler.
        3. Sunucudan Kullanıcıya İletim: Sunucunun yanıtının kullanıcıya ulaştırılması sırasında ağdaki gecikmeler.

      Eğer bu gecikmeler toplam süreci ciddi anlamda uzatırsa, kullanıcı yorumunu gönderdikten sonra yorumunun anında görünmediğini düşünerek, yorumunu tekrar göndermeye çalışabilir veya sayfayı yenileyebilir. Bu da hem kullanıcı deneyimini olumsuz etkiler hem de sunucu üzerinde gereksiz yük oluşturabilir.
      

• Karmaşıklık ve Yönetim
  • Karmaşık Hata Yönetimi: Bir servis hata döndüğünde, bu hatanın nasıl yönetileceği karmaşıklaşabilir. Rollback işlemleri, zaman aşımı kontrolü gibi ek mekanizmaların getirilmesi gerekebilir.
    • Bir rezervasyon sistemi uygulamasında, otel odası ve uçuş rezervasyonunun aynı anda yapılmaya çalışılması durumunda, eğer iki işlem arasında eş zamanlı bir iletişim modeli kullanılırsa ve birinde başarısızlık yaşanırsa, bu durumun nasıl ele alınacağına dair karmaşık hata yönetimi gereklilikleri ortaya çıkar. Örneğin:
      1. Kullanıcı hem otel odası hem de uçuş rezervasyonu yapmak istiyor.
      2. Otel odası başarılı bir şekilde rezerve edildi ama uçuş rezervasyonunda bir hata meydana geldi.
      3. Bu durumda, otel rezervasyonunun geri alınması (rollback) gerekebilir. Çünkü kullanıcı her iki rezervasyonun da başarılı olmasını beklemektedir.

      Bu tür senaryolarda, sistemin otomatik olarak bu tür hataları ele alabilmesi için ekstra yönetim mekanizmaları (örn. işlem geri alımı, hata bildirimi, otomatik yeniden deneme vb.) oluşturulması gerekir. Ayrıca, bu tür bir senaryo, sadece başarısızlık durumunda değil, başarılı bir şekilde tamamlanan işlemlerin geri alınması gerektiğinde de karmaşıklığa yol açabilir. Asenkron iletişim modelleri, bu tür senaryolarda daha esnek bir yaklaşım sunarak karmaşıklığı azaltabilir. Ancak, bu tür işlemlerin düzgün bir şekilde ele alınabilmesi için dikkatlice tasarlanmış hata yönetimi stratejileri gerekmektedir.

  • Zor Debug ve İzleme: Sorun giderme ve hata ayıklama işlemlerini daha karmaşık hale getirebilir.
    • Bankacılık sistemlerinde gerçekleşen para transferi gibi kritik işlemler, çoğunlukla birçok alt servisin eş zamanlı çalışmasını gerektirir. Örneğin; kullanıcının hesap doğrulama servisi, bakiye kontrol servisi, döviz kur servisi, anti-kara para aklama servisi, transfer işlem servisi ve bildirim servisi gibi çoklu servisler bir arada çalışabilir.
      • Eğer bu süreçte bir hata meydana gelirse:
        1. Hangi servisin hata verdiğini belirlemek için tüm servislerin loglarını tek tek incelemek gerekebilir.
        2. Hatayı tam olarak hangi adımda aldığı, hangi servisle ilişkili olduğu ve hangi sebepten ötürü meydana geldiği gibi bilgilere erişmek için kapsamlı bir izleme (tracing) sistemi gerekebilir.
        3. Ayrıca, eş zamanlı çalışan servisler arasındaki etkileşimler ve bağımlılıklar nedeniyle bir servisteki hata diğer servislerde de yan etkilere yol açabilir. Bu da hata izleme ve debug işlemini daha da karmaşık hale getirebilir.

      Bu tür zorluklar, mikroservis mimarilerinde yaygın olarak kullanılan izleme araçlarıyla (örn. Jaeger, Zipkin vb.) hafifletilebilir. Bu araçlar, servisler arasındaki tüm çağrıları izleyerek hataların nerede meydana geldiğini daha kolay anlamaya yardımcı olabilir. Ancak, bu tür araçların kullanılması da kendi başına bir maliyet ve karmaşıklık getirebilir.

  • Sürüm Yönetimi: Farklı servisler arasında uyumlu versiyonların sağlanması için ekstra yönetim gereksinimleri oluşturabilir.
    • E-ticaret platformlarında, bir ürünün nihai fiyatını belirlemek için fiyatlandırma servisi ve indirim servisi birlikte çalışır. Örneğin:
      1. Fiyatlandırma servisi, ürünün temel fiyatını belirlerken, indirim servisi mevcut promosyonlar veya kullanıcıya özel indirimleri uygulayabilir.
      2. Fiyatlandırma servisi yeni bir versiyonla güncellendiğinde, örneğin yeni bir vergilendirme özelliği veya sezonluk fiyatlandırma modeli eklediğinde, bu değişiklik indirim servisinin çalışma şeklini etkileyebilir. Eğer indirim servisi bu yeni fiyatlandırma modelini desteklemiyorsa, kullanıcılara yanıltıcı veya hatalı fiyat bilgisi gösterilebilir.
      3. İşte bu noktada sürüm yönetiminin önemi devreye girer. Fiyatlandırma servisinin her yeni sürümü için, indirim servisinin de uyumlu bir sürümünün olup olmadığını kontrol etmek ve gerekirse güncellemek kritik bir adımdır.

      Bu senaryo, mikroservis mimarilerinde sürüm yönetiminin ne kadar kritik olduğunu ve servisler arasındaki uyumsuzlukların potansiyel olarak büyük sorunlara yol açabileceğini göstermektedir.

• Güvenlik ve İzolasyon
  • Güvenlik Riskleri: Açık bağlantıların daha fazla olması potansiyel güvenlik risklerini de artırabilir.
    • Sağlık platformları, genellikle kişisel ve hassas verilere erişim sağlar. Özellikle hasta kayıtları, özel bilgilere sahip olup, bu bilgilerin gizliliği ve güvenliği büyük önem taşır. Örneğin:
      1. Hasta kayıtları servisi, bir hastanın sağlık geçmişi, tanıları, alerjileri gibi önemli bilgilere sahip olabilirken, reçete servisi, hastanın alması gereken ilaçlar, dozajlar ve diğer tedavi bilgilerini içerebilir.
      2. Bu iki servis birbiriyle eş zamanlı iletişimde olduğunda, özellikle de bu iletişim sırasında kullanılan veri aktarım yöntemleri yeterince güvenli değilse, bu tür bilgilere yetkisiz erişimlerin ya da veri sızıntılarının olma riski artar.
      3. Aynı zamanda, eş zamanlı iletişim, bir servisin başka bir servise bağımlı olmasına neden olur. Bu nedenle, bir serviste bir güvenlik açığı bulunduğunda, diğer servis de bu açığa maruz kalabilir.

      Bu nedenle, sağlık platformları gibi hassas veriye sahip olan platformlarda, veri iletişimi sırasında güçlü şifreleme ve güvenlik protokolleri kullanılması kritik öneme sahiptir. Eş zamanlı iletişim kullanılıyorsa, bu iletişimin ne kadar güvende olduğunu sürekli olarak değerlendirmek ve izlemek gerekir.

    • Düşük Hata İzolasyonu: Servis çöktüğünde, bağımlı olduğu diğer servisler de hızlı bir şekilde etkilenebilir.
      • Streaming servislerde kullanıcıların izleme deneyimi, kritik bir öneme sahiptir. Öneri motoru, kullanıcıya daha kişiselleştirilmiş bir deneyim sunmak için kullanılan bir servistir ve bu servisin eş zamanlı olarak çalışması, kullanıcının izlediği içeriğe dayalı olarak anlık önerilerde bulunabilmesi için önemlidir.

      
      

      Ancak, öneri motorunun video izleme servisiyle eş zamanlı ve sıkı bir şekilde entegre edilmesi, öneri motorunda bir sorun oluştuğunda video izleme servisinin de etkilenmesine neden olabilir. Bu durum, düşük hata izolasyonunun tipik bir örneğidir. İdeal olarak, bir servisteki hata diğer servisleri etkilememelidir.

      Bu örnekte, öneri motorunun çökmesi kullanıcının video izleme deneyimini kesintiye uğratıyorsa, bu, servisler arasındaki sıkı bağımlılığın ve düşük hata izolasyonunun bir sonucu olabilir. Bu tür bir tasarım, kullanıcı deneyimi üzerinde olumsuz bir etkiye neden olabilir, bu yüzden hata izolasyonunun sağlam bir şekilde uygulanması önemlidir.

    
    

• İş Sürekliliği
  • Transaksiyon Yönetimi: Çoklu servisler arasında ACID transaksiyonlarını yönetmek genellikle daha karmaşık ve zordur.

    • E-ticaret platformları, bir alışveriş sepeti işleminin gerçekleştirilmesi sırasında birkaç aşamadan geçer. Bu aşamalar genellikle birden fazla servisi içerir. Örneğin, bir kullanıcı bir ürünü satın almak istediğinde, envanter servisi stok durumunu kontrol eder ve envanteri günceller. Aynı zamanda, ödeme servisi ödeme bilgilerini işler ve onaylar. Bu iki işlem, kohesif bir alışveriş deneyimi sağlamak için birlikte gerçekleştirilmelidir.

      Ancak, bu tür çoklu servis işlemlerinde bir sorun yaşandığında (örneğin, ödeme işlenirken bir hata oluştuğunda, ama envanter zaten güncellendiğinde) tutarlılık sorunları ortaya çıkabilir. Bu, ACID (Atomicity, Consistency, Isolation, Durability) özelliklerine sahip geleneksel transaksiyonların bu tür dağıtık sistemlerde zorlukla yönetilmesinin bir sonucudur.

      Bu senaryo, dağıtık sistemlerde transaksiyon yönetiminin karmaşıklığını ve e-ticaret platformları gibi gerçek dünya uygulamalarında bu karmaşıklığın nasıl ortaya çıkabileceğini mükemmel bir şekilde göstermektedir. Bu tür senaryolar, hata yönetimi, geri alma mekanizmaları ve hatta bazen “saklama” gibi tekniklerin kullanılmasını gerektirebilir.

Sonuç

Eş zamanlı iletişim, anlık ve hızlı bir geri bildirim mekanizması sunar, fakat yukarıda sıralanan dezavantajlar ve zorluklar göz önünde bulundurulduğunda, asenkron iletişim modelleri genellikle daha esnek ve sağlam bir çözüm sunar.

Blog serisinin ikinci yazısında mikroservis mimarisinde eş zamanlı iletişimi detaylı inceledik. Bir sonraki blog yazımızda, ‘Mikroservis Mimarisi: Eş Zamansız İletişimin Detaylı İncelemesi’ ile daha derinlere dalacağız.

Kaynakça

1. https://openai.com/
2. https://microservices.io/index.html
3. https://shadowmaster98.medium.com/http-in-detail-7203f6b0e6dd
4. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
5. https://www.zenesys.com/drawbacks-and-benefits-of-using-graphql
6. https://yteblog.bilgem.tubitak.gov.tr/rest-api-ve-grpc-mimari