Integration Patterns — Mikro Servis Mimarisi

Bir mikro servis mimarisi oluştururken, karşılaşacak zorluklar çokta farklı değildir; birden çok uygulama teknolojisi, bir ağ tarafından fiziksel olarak ayrılır ve birbiriyle iletişim kurması gerekir. Mikro servis entegrasyonu, son kullanıcı açısından sorunsuz bir deneyim oluşturmada hayati bir rol oynar.

API Gateway Pattern

Bir uygulama daha küçük mikro servislere bölündüğünde, ele alınması gereken birkaç sorun vardır.

  • Farklı kanallar tarafından birden çok mikro servis için birden fazla çağrı yapılabilir.
  • Farklı tipte Protokolleri işlemeye ihtiyaç vardır.
  • Farklı tüketiciler(consumers), farklı bir yanıt formatına(soap,rest..) ihtiyaç duyabilir.

Bir API Ağ Geçidi, yukarıdakilerle sınırlı olmamak üzere mikro servis uygulamasının ortaya çıkardığı birçok endişeyi gidermeye yardımcı olur.

  • Bir API Ağ Geçidi, herhangi bir mikro servis çağrısı için giriş noktasıdır.
  • Bir isteği ilgili mikro servise yönlendirmek için bir proxy hizmeti olarak çalışabilir.
  • Tüketiciye(consumer) geri göndermek için sonuçları bir araya getirebilir.
  • Bu çözüm, her belirli istemci türü için ayrıntılı bir API oluşturabilir.
  • Ayrıca protokol talebini dönüştürebilir ve yanıtlayabilir.
  • Ayrıca mikro servisler kimlik doğrulama/yetkilendirme sorumluluğunu da kaldırabilir.

Aggregator Pattern

İş işlevselliğini birkaç küçük mantıksal kod parçasına böldüğünde, her servis tarafından döndürülen verilerin nasıl işbirliği yapılacağını düşünmek gerekir. Bu sorumluluk tüketiciye(consumers) bırakılamaz.
Aggregator deseni, bunun ele alınmasına yardımcı olur. Farklı servislerden gelen verileri nasıl toplayabileceğimize ve ardından son yanıtı tüketiciye nasıl gönderebileceğimize çözüm sunmaktadır.

Bu iki şekilde yapılabilir :

  • Kompozit bir mikro servis, gerekli tüm mikro servislere çağrı yapar, verileri birleştirir ve geri göndermeden önce verileri dönüştürür.
  • Bir API Ağ Geçidi(API Gateway), isteği birden çok mikro servise bölümleyebilir ve tüketiciye göndermeden önce verileri toplayabilir.

Herhangi bir iş mantığının(business Logic) uygulanacak ise bir kompozit mikro servis seçilmesi önerilir. Aksi takdirde, API Ağ Geçidi alternatif çözümdür.

Proxy Pattern

API ağ geçidi kullanarak, Mikro servisleri API ağ geçidi üzerinden yayınlayarak güvenlik ve kategorize edilmiş entegrasyon noktaları belirleyebilmiş oluyoruz. Bu örnekte, API ağ geçidinin üç farklı API modülü vardır:

  • FTGO mobil(Food to Go ->örn: Yemek Sepeti) istemcisi için API uygulayan Mobil API
  • Tarayıcıda çalışan JavaScript uygulamasına API uygulayan Browser API
  • Üçüncü taraf geliştiriciler için API uygulayan Public API

Gateway Routing Pattern

API ağ geçidi, isteklerin yönlendirmesinden sorumludur. Bir API ağ geçidi, istekleri ilgili servislere yönlendirerek bazı API işlemlerini uygular. Bir istek aldığında, API ağ geçidi, isteğin hangi servise yönlendirileceğini belirten bir yönlendirme haritasına(routing map) başvurur.

Bir yönlendirme eşlemesi, örneğin, bir HTTP yöntemini ve servisin HTTP URL’sine giden yolu eşleyebilir. Bu işlev, NGINX gibi web sunucuları tarafından sağlanan ters(reverse) proxy özellikleriyle aynıdır.

Chained Micro-service Pattern

Tek bir servis veya servisler için birden çok bağımlılık olabilir, örneğin: satış mikro servisi, ürün ve sipariş mikro servisiyle bağlı olabilir. Chained mikro servis tasarım modeli, isteğinize konsolide sonucu sağlamanıza yardımcı olur.

Bir mikro servis ( A ) tarafından alınan istek, daha sonra mikro servis ( B ) ile iletişim kuruyor ve mikro servis ( C ) ile iletişim kuruyor olabilir. Tüm iletişim senkronize olmaktadır.

Branch Pattern

Bir mikro servisin, diğer mikro servisler dahil olmak üzere birden çok kaynaktan veri alması gerekebilir. Branch modeli, Aggregator ve Chain tasarım modellerinin bir karışımıdır ve iki veya daha fazla mikro servisten eşzamanlı istek/yanıt işlemeye olanak tanır.

Çağrılan mikro servis, mikro servisi zincirleri(chained) olabilir. Branch modeli, iş ihtiyaçlarınıza göre farklı mikro servis zincirlerini veya tek bir zinciri çağırmak için de kullanılabilir.

Client-Side UI Composition Pattern

Servisler, iş yetenekleri(Business Capabilities)/alt alanları(subdomains) ayrıştırılarak geliştirildiğinde, kullanıcı deneyiminden(UX) sorumlu arayüzlerin birkaç mikro servisten veri çekmesi gerekir.

Monolitik dünyada, tüm verileri almak ve UI sayfasını yenilemek/göndermek için kullanıcı arayüzünden arka uç(Backend) servislere yalnızca bir çağrı yaparlar.

Fakat mikro servisler, kullanıcı arayüzü, ekranın/sayfanın birden çok bölümü/bölgesi olan bir iskelet olarak tasarlanmalıdır. Her bölüm, verileri çekmek için bağımsız bir arka uç mikro servise bir çağrı yapacaktır.

AngularJS ve ReactJS gibi frameworkler bunu kolayca yapmanıza yardımcı olur. Bu ekranlar Tek Sayfalı Uygulamalar (SPA-single page application) olarak bilinir.

Her ekip, servisleri için sayfanın/ekranın bölgesini uygulayan bir AngularJS yönergesi(Directive - Angular) gibi bir istemci tarafı UI bileşeni geliştirir. Bir UI ekibi, birden çok özel UI bileşeni oluşturarak sayfaları/ekranları oluşturan sayfa iskeletlerini uygulamaktan sorumludur.