Merhaba Arkadaşlar
Sizinle bu yazımızda mikroservis mimariye giriş yapmış olacağız. Bildiğiniz üzere günümüzde proje mimarileri SOA(Service Oriented Architecture) temeline dayanmaktadır. Ve bu SOA mimarisi monolithic dediğimiz her iş biriminin bir arada bulunduğu bir yaklaşıma inşa edilmiştir. Yani tüm modüller bir aradadır. Buna veritabanı, service katmanı, facade katmanı vs vs örnek verebiliriz. Farklı projeler aynı veritabanı üzerinden hareket edip web servisler ile dış ortama açılmaktadır. Dilerseniz şöyle bir örnek ile monolithic sistemi açıklayalım. Şekildeki gibi Uber tarzı bir sitemiz olduğunu düşünelim.
Şekli inceleyecek olursak
- Sitenin ödeme modülü, sürücü yönetim modülü, yolcu yönetim modülü gibi tüm modülleri tek bir çatı altındadır. Haliyle tüm işlemler tek bir sisteme yüklenir. Bununla beraber sistemin karmaşıklığı da çok fazladır.
- Tüm modüller bir arada olduğu için build, deployment gibi süreçler oldukça uzun zaman alacaktır. Bununla beraber bu işlemler birbirine bağlı olacağından dolayı bir projede olacak bir hata diğer bağlı olduğu projeleri de etkileyecektir.
- Tek çatı olduğundan kullanılan programlama dilleri de benzer olmalıdır. Yani .NET kullanılıyorsa aynı projede Java’ya yer veremezsiniz. Bu da programlama dillerini amaçları dışında kullanmaya sebebiyet verir. Örnek vermek gerekirse bir Java projesi ele alalım istatisliksel işlemleri Julia ya da R gibi o amaca yönelik bir programlama dili ile yapmaktansa bu sistem sizi Java ile yapmaya zorlayacaktır. Bu aynı zamanda Polyglot Persistence anlayışı için de pek yararlı olmayacaktır.
- Projeye yeni katılan bir developer arkadaşımız olduğunu düşünelim. Bu arkadaşımızın iş karmaşıklığı oldukça fazla olacaktır. Çünkü projedeye uyum sürecinde tüm modüller hakkında az da olsa bilgi sahibi olması gerekecek ve bu da projeye uyum sürecini uzatacaktır.
- Projede kullanılan bağımlılıkların yönetimi zorlaşacaktır. Çünkü bu sistemlerde bir kütüphane birden fazla modülde kullanıldığı için olası bir versiyon değişikliği tüm sistemi etkileyecektir.
- Proje sürekli dikey anlamda büyüyecektir. Ve bu büyüyen projeyi kontrol altına almak oldukça sıkıntılı bir süreç olacaktır.
Monolithic sistemin bu tarz eksileri SOA mimarisine farklı bir bakış açısı getirmeye zorlamış ve mikroservis yaklaşım ortaya atılmıştır.
Nedir Bu Mikroservis?
Mikroservislerin temel amacı her modül birbirinden bağımsız olsun ve tekil bir işlem gerçekleştirsin. Ve bununla beraber mikroservis mimariler sadece bir veritabanı ile ilgilensin. -İleride de göreceğiz- Her bir mikroservis yapı bir veritabanına özelleştirilip ayağa kaldırılmalıdır. Bu ne anlama geliyor? Şeklimizi inceleyelim.
- Sistemdeki tüm modüller birbirinden bağımsız hale gelmiştir. Her modül başka bir server üzerinde başka bir database kullanarak çalışıyor olabilir. Burada sadece analiz ile görevli bir mikroservis çalışıp sadece mongodb kullanırken başka bir mikroservis CRUD işlemleri için oracle kullanabilir. Ve bu iki sistem birbirinden bağımsız hareket eder.
- Her modülün build, deployment süreçleri bağımsız olacağından oldukça zaman kazancı olacaktır.
- Modüller birbirinden bağımsız olduğu için kullanılan programlama dilleri de, frameworkler de birbirinden bağımsızdır. Haliyle her programlama dilini amacına göre kullanılabilir.
- Polglot Persistence yaklaşımını en ideal şekilde kullanmamızı sağlar. Her mikroservis kendine atanmış görev için ilgili veritabanını kullanır.
- Projeye yeni katılan arkadaşımızın sadece bir modülden sorumlu olması projeye uyum sürecini oldukça hızlandıracaktır.
- Her modül bağımsız olduğundan bağımlılık yönetimi oldukça basit olacaktır. Çünkü her bağımlılık sadece kendi modülüyle alakalı olacaktır.
- En önemlisi projemiz artık yatay eksende büyüyecektir. Haliyle kontrolü elimiz altında olacaktır. Yani bir mikroserviste aşırı yoğunluk olduğu takdirde aynı servisten bir tane daha rahat bir şekilde oluşturabiliriz.
Fakat her iyi şeyin bir de eksi yönü var. Mikroservislerdeki bu bağımsız modüller beraberinde bir takım sıkıntılar da doğurmaktadır. Yine sitemizden devam edersek
- Sorgulama modülü ve satın alma modüllerimizi ele alalım. Bir kişi bir ürün satın aldığı zaman veritabanından ilgili ürün adedi güncellenir. Fakat bu güncelleme sorgulama modülü üzerinde olmazsa? Elimizdeki ürün bittiği halde var olarak göstereceğiz fakat kişi o ürünü alamayacak. Burada dağıtık transaction yönetimi ortaya çıkmaktadır. Bir modülde veritabanı güncellenirken onunla alakalı diğer modülde de veritabanı güncellenmelidir. Aksi halde sistem işleyişinde sıkıntılar meydana gelecektir.
- Bununla beraber modüller birbirleriyle iletişim kurarken aynı business objeleri kullanacağından kod tekrarı kaçınılmaz olacaktır.
Tabi yukarıdaki sıkıntılar için bir takım Mikroservis Tasarım Kalıpları ortaya atılmıştır. Bir sonraki yazımızda bu tasarım kalıplarına değineceğiz. Sağlıcakla kalın…
