Mikroservis Mimarisi Nedir?

Bu haftaki yazım son zamanlarda adından çok sık bahsedilen ama tam olarak ne olduğunu ve nasıl bir yapı kullanıldığını bilmediğini düşünen herkese hitap ediyor.

Peki nedir bu Mikroservis? Hep birlikte bakalım.

Mikroservislerin ne olduğuna geçmeden önce monolitik uygulama ile karşılaştırırsak daha net şekilde kavrayabiliriz.

Mimari Desenlerin Görsel Yorumlanması

Monolitik mimariler, her türlü bileşeni içinde barındırabilen ve bir yere gidip kurulması gereken uygulamaların hepsidir. Tüm işletmeler açısından bakarsak, 20 sene öncesine işletmeler otomasyon ihtiyacı doğduğu zaman yapabileceği en hızlı çözüm hemen bunu bir uygulama halinde yapmaktır. Sonrasında bu uygulamaların içi bir takım yeniden kullanılabilirlik ilkeleri, nesne tabanlı ilkeler olarak daha doğal yapmak bir takım bileşen tabanlı, bazı kütüphaneleri alıp kullanarak kodlamaların yaygın olduğu yapılara dönüştü.

Sonrasında da daha farklı yerlerde kullanım açısından bu uygulamayı farklı firmalarda kurma ihtiyacı doğdu. Bu seferde server sıkıntısı oluştu bununla beraber veritabanını ayırma gibi ihtiyaçlarda ortaya çıktı. Bunların hepsi aslında monolitik uygulamaları kastediyor.

Monolitik bir bütün demektir. Farklı farklı serverlarda her bir uygulama bütün bütün vardır.

Mikroservisler aslında bu tür firmaların temel ihtiyacını servis odaklı nasıl çözebilirizi birincil olarak seçiyor. Buradaki her tür bağımsız mantık tek bir uygulama olmalı bakış açısıyla bakıyoruz. Burada her bir bileşen(component) bir uygulamadır.

Her bir bağımsız işi yapan bileşen ayrı bir süreçtir. Süreçler arasındaki haberleşme aynı bilgisayar mimarisi üzerinde olduğu için bir alt yapı üzerinden bu alt yapı mesajlaşma tabanlı bir alt yapıda olabilir ya da daha da Enterprice Service Bus mantığı (soket kanalı gibi) ile de olabilir.

Mikroservisler aslında bir SOA varyasyonu diyebileceğimiz boyutları da var ve SOA’dan farklı monolitikten esinlenmiş olduğu yanları da vardır.

Tek bir uygulamayı birden fazla servisler bütünü gibi düşünmemizi sağlar.

Tek bir uygulama içinde birden fazla süreç çalışıyormuş gibi bir modelleme vardır. Bize sunmuş olduğu avantajlara bakacak olursak;

• Her hangi bir parçası farklı bir programlama dili ile yazılabilir ve farklı bir platformda çalışıyor olabilir. Şu an hayal edemediğimiz başka bir platform da gelse SOA’nın uygun gördüğü mesajlaşma servisi olduğu sürece onunla da çalışır. Bu yapıya platform agnostic de denebilir.
• Farklı farklı zamanlarda kendi başına deploy edilebilmesi ve güncelleme amaçlı değişiklikler yapabiliriz.
• Veri saklama teknoloji olarak ayrı teknolojiler geliştirdiği için onları da entegre etmemiz bütün süreçlerden bağımsız olacaktır.
• Yazılım seviyesinde minimum düzeyde bir merkezi yönetim olacaktır. Buyuk firmalar için temel bir ihtiyaçtır. Çünkü uzmanlaşmış ekipleri geliştirmekte zorlaşıyor, her bir personel şu işi yapsın bakış açısı ile çok daha dağıtık merkezci olmayan bir yaklaşım ile firmalar geliştirmelerini yapıyor.

Öncü firmalardan Amazon , Microsoft, eBay ve Netflix microservis mimarisi kullanıyor.

Bununla birlikte artık bankalarda kendilerini bu mikroservis mimarisine doğru adapte ediyor. Çünkü bankaların servis alt yapılarının çok daha fazla isteğe cevap verebiliyor olması gerekmektedir. Herkes bankacılık sistemini daha da fazla online olarak kullanmayı tercih etmeye başladı.

Mikroservis Mimarisinin Avantajları

Tek bir bağımsız uygulama yapıyormuş gibi servis geliştirmek en önemli avantajlardandır. Çünkü tasarımsal düzeyde servis odaklı yaklaşımlarımızın hepsi mikroservis tasarımlarında da yapılan yöntemlerdir. Bu anlamda bir farklılık söz konusu değildir.

Modellenmiş servislerin hayata geçirilmesi sırasında web servislerin SOA mimarisini kullanması en tipik yaklaşımdı. Bu yüzden de web servisler ile mikroservislerin karşılaştırılması daha doğru olabilir.

Servis modellemesi olarak yapılan işler çok buyuk farklılık içermiyor bunun hayata geçirilmesi noktasında yapılan isler avantaj sağlıyor.

Birden fazla isteğe cevap vermesi için çoklanması, sanallaştırılması. Son dönemin mimari düzeyde donanım ve uygulamaların kullanıldığı platform çoklaması üzerine çok revaçta kavramlardır.

Mesela bu mikroservis mimarileri oralarda otomatik olarak ölçeklenebiliyor. Bunu biraz daha açacak olursak zaten servisler çok daha birbirinden bağımsız şekilde modellenebildiği için bir bütün halinde tek bir uygulama gibi davranabildiği için bu mümkün olabiliyor.

Üç şekilde kolayca ölçeklenebilir:
• Basit fonksiyonların servis seviyesinde hayata geçirilmesi, sunulması (mikroservisler)
• Çalışan uygulamanın çoklanması. Aynı yaşam döngüsü ve çalışan parametreleri ile beraber kopyalanması (cloning)
• Farklı küme yapıları üzerinde verinin bölümlenmesi işi mümkün olabiliyor. Bunun daha büyük avantajı veriye erişim kısmını her zaman ayrı bir servis üzerinden yapın diyor. Temel bir fonksiyon bile olsa saklanmış veriye doğrudan erişemesin. Her zaman servis API’si üzerinden erişebilsin.

Mikroservis Mimarisi Uygulama Örneği

DOT EIP on Cloud Infrastructure (Şekil-2)

Mikroservis tasarımcıları Cloud Provider olarak adlandırılan alanları benim için ver diyor.

Bir mikroservis geliştirmek istiyorsam modellememi yaptım, servis düzenimi belirledim. En yukarıda kırmızı ile belirtmiş olduğum her biri ayrı uygulama olsun. Bunların hepsi bir servis alt yapısı üzerinde çalışacak. Bu alt yapı bana bir bulut hizmeti gibi servisi sağlayan taraf olsun.

Alt yapı ben ne diyorsam onu yapsın mantığı ile oluşturulsun. Önemli olan mikroservislerimin olduğu kısımdır.

Core Servisleri, temel bir izleme servisi versin

Orkestrasyon katmanı, sistemi yönetecek şekilde Auto-scaling yapsın, performans işleri, çoklama vs.

En alt katmanda ise veri saklama veri yönlendirme gibi işleri sunsun.

Bunları bana verdikten sonra sistem ile alakalı diğer tüm işleri ben mikroservis katmanında yapabileyim.

Mikroservisleri Nasıl Hayata Geçirebiliriz

Hayata geçirmek için yardımcı olacak hususlar;

• Kod karmaşıklığını azaltmış oluruz. Çünkü daha basit servisleri hayata geçirmiş oluyoruz ama beraberinde operasyonel zorlukla karşılaşabiliriz.
• Veriyi farklı süreçler arasında dağıtabiliriz. Bu işlemi, her bir veri saklaması gereken benim kendi Api’si üzerinden haberleştiği için birbiri ile o veriyi birçok kez dağıtabilirim. Bununla beraber veriyi kontrol edecek bir yapıyı da hayata geçirmem gerekir.
• Bireysel hizmetleri basitleştirirken aynı zamanda birçok hizmeti koordine etmenin karmaşıklığı getirmiş olabiliriz

Temel İlkeler

• Hataya göre tasarım yapmak temel ilkelerden bir tanesidir. Çünkü bu bağımsız bileşenlerden herhangi biri zaten bağımsız kalabildiği için bu servisler başarısız olursa, hata olursa ne yapabilirim? sorusunu tasarım yaparken düşün. Yani o kadar bağımsız yap ki hata olursa bile orayı aksatmayacak bir şekilde tasarım yapılmalıdır.
• Hedef tasarladığım an direk çalışması gerekir. Çok hızlı bir şekilde bağımsız olarak deploy edebilmeli, tasarım bitti ve ben direk sistemi hayata geçirebilmeliyim.
• Platforma göre veya bazı uzmanlık alanına göre personeli, ekibi geliştirmek yerine tüm ekibi her alanda gelişmesine imkan sağlamak daha doğru bir yaklaşım olacaktır.

Bir çok firmanın SOA hedefleri, ilk SOA’yı hayata geçirmede kullandığı bir web servis ile beraber ‘Enterprise Service Bus’ diye bir yapı vardır. Bu yapı akıllı işler yapıyordu yani business logic de üzerine alan bir yapıda tasarlanıyordu. Mikroservis bu yapıya karşı çıkıyor. Eğer ki Enterprise service bus’a iş mantığını devrederseniz bazı ölçeklerde ki firmalar için bir sure sonra çok daha karmaşık bir yapıya dönüşmeye başlıyor.

Çizimde belirtmiş olduğum (Şekil 2) gibi benim yapım Enterprice yapıda olmak yerine daha basit bir yapıda ölçeklenebilir olması gerekir. Benim uygulamalarım çok daha zeki(smart endpoints) olsun. Zeki taraf benim uç uygulamalarım olsun ve altta ki veri yapısı(bus) basit bir yapıda olsun.

Çok temel düzeyde bir veri dağıtımı düşünülmüştür. Hangi bileşen ne kadarlık bir tabloya erişecek ise, o tablo sadece o bileşene ait bir veri yapısında tutulur. Hatta veri tabanlarının mimarileri de farklı farklı sistemler olabilir. Herhangi bir bileşen başka bir bileşenin altındaki veritabanına erişmek istiyorsa temel apiden erişir. Bu seçenek süreyi uzatabilir ama bileşenlerin çok daha bağımsız olması hayata geçirebilmesi olanağını sunar.

Sürekli entegre bir şekilde test ve daha sonrasında kodu yaz test et ve ardından hemen sisteme dahil et.

Mikroservisler ile sürekli olarak canlı sistem üzerinden hayata geçirebiliriz.

Continuous Delivery, kullanıcılardan gelen bir takım hatalar toplanıyor veya ilk iterasyon da yapılmamış yeni bir sistem modellemesi gibi bir takım işler önce analiz yapılıyor sonra tasarım yapılıyor bu süreçler belirli bir süre sonra hayata geçirildiği için çoğu zaman geç kalınma gibi riskler ile karşılaşılıyordu. Continuous delivery bunu daha da kısaltmak için bir çözümdür. Sürekli olarak canlı sistem üzerinden hayata geçirilebilirdir.

Mikroservisler ve Web Servisler Arasındaki Farklar

Genellikle mikroservisler, web servisler ile karşılaştırılmaz. Bu doğrultu da web servisler ve mikroservisleri karşılaştıracak olursak;

• Mikroservisler, bir yazılım geliştirme yaklaşımı olarak değil daha çok hayata geçirilecek modüler bir yaklaşım açısından farklılık gösteriyor. Web servisler ise alttaki protokol ya da network mantığı sabit kabul edilip HTTP, XML üzerine SOAP protokolü ile mesajlaşma olarak düşünülebilir.
• Mikroservis biraz daha mimari stil açısından SOA’nın bir alt kümesi olarak bir varyasyonu düşünülür. Web servis ise tamamını SOA yapmak için webin kullandığı bir yaklaşımmış gibi hayal edilir.
• Platformdan bağımsız yapılar mikroservisler ile mümkünken web servislerde aslında XML mantığıyla platform bağımsızlık düzeyinde sunuluyor olacaktır.

Mikroservisler ile ilgili mutlaka herkesin izlemesini düşündüğüm Martin Fowler’ın mikroservis mimarisini anlattığı videosunu da izleyebilirsiniz.

Bir daha ki yazımda görüşmek üzere 👋🏻