Microservice Architecture

Son dönemlerde sıklıkla bahsedilen microservice mimarisini araştırmayı ve öğrendiklerimi blog yazısı haline getirmeye niyetlendim. Microservice mimarisine geçmeden monolithic mimari hakkında kısaca bir özet geçelim.

Monolithic/Layered mimari aslında traditional SOA yaklaşımıdır. Standart web uygulamalarında, server side uygulama clientlardan gelen requestleri işleyip, veritabanından verileri çekip-güncelleyip sonrasında uygun html çıktısı olarak kullanıcılara göstermektedir. Tüm bu işlemler tek bir çatı altında toplanmıştır.

Tüm componentler tek bir yapı içerisinde birbirlerine bağlı durumdadırlar. Manageability (yönetim), maintenance (bakım) vb avantajlar nedeniyle tercih edilmektedir. Ancak büyüyen sistemler yönetimi zorlaştırmaktadır.

  • Uygulama büyüdükçe sistemin tekrar baştan ayağa kaldırılması uzun sürecektir.
  • Sistem içerisinde herhangi bir yapıyı tekrardan update etmek ve ettikten sonra tüm sistemi tekrardan deploy etmek zorunda kalabiliriz. Birbirine bağlı yapılar yeri geldiğinde  sorun çıkartabilir. Componentte yapılan değişim diğer componenti etkileyebilir.
  • Sistem içerisinde bulunan componentleri aynı dil ile geliştirilmek zorundayız.
  • Monolithic mimari olan sistemlerde scaling işlemi uygulama kopyaları oluşturularak, load balancer kullanılarak yapılır. Büyük uygulamalarda sıkıntı yaratacaktır. Küp yaklaşımında x ekseninde büyümeye tekabül eder. Birazdan inceleyeceğimiz microservice mimarisi y ekseninde büyümeye denktir.

  • Yeni teknolojileri veya dilleri sisteme adapte etmek zor olacaktır.

Bazı dezavantajlarını saydık. Avantajlarından birine değinecek olursak, componentler tek bir yapı içerisinde bulunduğundan birbirleri ile iletişimleri kolaydır. Nispeten küçük boyutlu ve karmaşıklığı az olan uygulamalarda tercih edilmelidir. Hızlı başlangıç için uygulamalara hız katar ancak uygulama boyutu arttıkça yönetilebilme sorunları ortaya çıkar.

Şimdi gelelim microservice mimarisinin nimetlerine ve getirdiği dezavantajlara. Martin fowler’ın sitesinde bulunan makalede detaylı bahsedilmektedir. Aslında microservis mimarisinin mantığı çok uzun zamandır biliniyor. Son dönemlerde popülaritesi artmıştır.

Microservis tabanlı uygulamalarda, componentler birbirinden ayrılmıştır ve ihtiyaç olduğu zaman birbirleri ile haberleşmektedirler. Microservis mimarisi mevcut uygulamanın boyutunu servislere bölüp azaltma amacındadır. Componentler birbirinden bağımsız tanımlanabilir. Yapılacak küçük bir değişim yüzünden tüm sistem tekrardan re-deploy edilmek zorunda değildir. Servislerin kendi aralarında haberleşmesi önem taşımaktadır.

Arayüz tamamen backend yapısından ayrılmıştır. Backend yapısı kendi içerisinde farklı servislere ve veritabanlarına ayrılmıştır. Bazı servisler NoSQL veritabanı kullanırken bazı servisler klasik veritabanı kullanabilir. Her servis üzerinde farklı yazılım ekibi çalışabileceği gibi her servis farklı bir dil kullanılarak yazılabilir. Servisler boyut olarak küçüktürler ve scale edilebilmeleri daha kolaydır.

Microservice mimarisine geçmeden önce uygulamamızın ihtiyacını karşılayıp karşılamadığını iyi anlamalıyız. Gereksiz yere kullanmaktan kaçınılmalıdır.

Microservice mimarisinin getirdiği dezavantajlara bakacak olursak;

  • Fazla zor bir case olmamasına rağmen geliştiriciler servisler arası mesajlaşma işini halletmelidir. Genelde servisler REST yolu ile iletişim kurarlar. Alternatif olarak async tabanlı AMQP protokolünü kullanabilirler.
  • Servisleri farklı yapılar ile geliştirme avantajı olsada yeri geldiği zaman karmaşıklığa yol açabilir.
  • Birbirinden bağımsız veritabanları kullanılan servislerde, verilerin birbirleri ile tutarsız olmaları sıkıntı yaratabilir. Servisler arasında kullanılan verilerin tutarlılığını sağlamak için Event-driven mimari kullanılabilir. Veritabanında bulunan veri değiştiği zaman servis olay mesajı olarak bilgilendirme yapar. Buna göre diğer servisler verilerini günceller.
  • Deployment süreci zorlaşabilir.

Uygulamanın boyutu küçükse ve fazla logic yoksa monolithic mimari tercih edilmelidir.

Kaynakça

Advertisements