Merhaba bu yazımda sizlere reaktif mikroservis(Java ve Spring ile birlikte geliştirilen) tasarlarken doğru strateji seçimiyle alakalı bilgi vermeye çalışacağım.

Öncelikle reaktif ve reaktif olmayan nedir buradan başlayalım.

Reaktif mikroservisler: Asenkron ya da non-blocking senkron bileşenlerini kullanarak oluşturulan mikroservisler diyebiliriz.

Reaktif olmayan mikroservisler: Senkron ve blcking i/o bileşenleriyle oluşturulan mikroservisler diyebiliriz.

Tam bu noktada I/O ve Non-blocking I/O terimlerini kısaca açıklamak istiyorum.

IO: Basitçe bir thread’in bir tasktan baştan sona sorumlu olduğu yapı diyebiliriz.

NIO: Burada IO’daki thread sorumlulukları arasında bazı farklılıklar bulunmakta. Bir thread bir i/o mekanizmasında sadece read ve write methodlarını tetikleyip serbest bırakılıyor. Bu sayede threadler bloklanmıyor.

Daha sonra IO ve NIO yu detaylı inceleyeceğim bir yazı yazacağım.

Şimdi tekrar reaktif servislere geri dönelim. Aslında Java ve Spring ortamlarında geliştirilmek istenilen reaktif mikroservislerde göze çarpan 2 seçenek oluyor;

• Non-blocking Senkron yapı: Yüksek performanslı NIO özelliklerini kullanan senkron yapı.
• Event-driven Asenkron yapı: Event mesajlarının işlenmesiyle çalışan Non-blocking asenkron yapı. Event mesajlarını Kafka Rabbit MQ gibi uygulamalarla yönetebiliriz.

Peki biz reaktif mikroservis yazarken doğru mimariyi nasıl tercih edeceğiz?

Normalde asenkron yapılar daha ölçeklenebilir, güçlü ve sadece mesaj sistemlerine bağımlılıları olduğundan en mantıklı seçenek gibi gelebilir. Ama bazı durumlarda senkron yapıları tercih etmek bize daha sağlıklı sistemler oluşturmakta fayda sağlayacaktır. Bu tip durumlara örnek vermek gerekirse;

1. Genelde read işlemi yapan istemciler bu işlemin sonucunu beklerler burada istemciye senkron bir yapıyla yanıt vermek daha sağlıklı olacaktır.
2. Senkron yapıya daha uygun yapılarda örneğin; SPA(Single Page Web app) web ve mobile vb. İletişim için senkron yapıyı kullanmak uygulamanın doğasına uyacaktır.
3. Farklı organizasyonlarla iletişim kurarken event driven yapı kullanmak mesaj kuyruğu yönetim sistemleri kullanılacağından geliştirme ortamını zorlaştırıp uygulamayı kompleks hale sokacaktır.(Gönderilen ve beklenilen mesaj fieldlari değişebilir channellar değişebilir vb.)

Yukarıda bahsettiğim durumlarda da asenkron yapılar kullanılabilir fakat gerek kullanıcı deneyimi gerek geliştirme ortamı zorlukları düşünüldüğünde Non-blocking senkron yapılar da tercih edilebilirler.

İlk blog yazımı okuduğun için teşekkürler, lütfen yorumların ya da eleştirilerin iletişime geçmekten çekinme.