Event-Driven Mimari ve AWS Kinesis


(Ali Atakan) #1

Mikroservislerde Event-Driven Veri Yönetimi

Bu yazı da küçük bir senaryo ile bir mikroservisin sahip olduğu veriyi güncellemek ihtiyacı olan diğer bir mikroservisin event store kullanarak (AWS Kinesis) bunu nasıl yaptığını modelleyeceğiz. Bu sayede mikroservisler arasındaki veri yönetimi ve loosely couple servis mimarisi yaklaşım konseptlerinin yanı sıra kolayca ölçeklenebilen ve sunduğu API’ ler sayesinde kolayca entegre edilebilen AWS Kinesis’ i deneyimleyeceğiz. İlgili kodları https://github.com/aliatakan adresinden indirip çalıştırabilirsiniz.

Mikroservislerde Veri Yönetimi Zorluğu
Monolith uygulamalarımız genelde bir ilişkisel veritabanı ile çalışır. Tüm veri, tablolar vs aynı veritabanındadır ve sonuç olarak bir transaction bloğu başlattığınızda gerekirse farklı farklı tablolarda birçok CRUD (Create, Read, Update, Delete) işlemi yapılır.

Fakat microservice mimari ile devam etme kararı alındığında veri yönetimi işinin monolith yapılardaki kadar kolay olmadığı görülmektedir. Her mikroservis kendi verisine hatta veritabanına sahip olabilir. Dolayısıyla da sahip olduğu veriyi yönetme işi ona ait olmalıdır. “Loosely coupled” bir mimari için de bir mikroservisin sahip olduğu veriye diğer mikroservislerin erişememesi ve değiştirememesi gerekir.

service-application kendine ait olmayan bir veriye ulaşmamalı !
Yukarıda da görüldüğü üzere, service-application kendine ait olmayan bir veriye ulaşmaya çalışmamalı. Aynı durum service-curriculum için de geçerlidir.

Event-Driven Mimari
Servislerin kendilerine ait olmayan verilere ulaşmayacak şekilde bir mimari kurma senaryomuzda iki adet mikroservisimiz olsun. Kullandığımız araçlar Java, Spring boot, Postgres, Kinesis, Kinesis Client Library.

service-application

Öğrenciler kayıt döneminde müfredattan bir ders seçecek ve bu derse kayıt olmak için bir başvuru başlatacaklar. Kayıt işlemi service-application tarafından yapılacak. Alınan başvurular application tablosuna “NEW” statüsü ile kaydedilecek ve başvurunun son statüsünü belirlemesi için APPLICATION_CREATED event i produce edilecek. Başvurunun kabul edilebilmesi için ilgili dersin kontenjanı yeterli mi sorusunun cevabı “lesson” tablosu içerisinde ve bu tablodaki CRUD işlemlerinden sorumlu olan servis başka.

Bu başvuruların “APPROVED” veya “RECEJTED” olması o dersin yeterli kontenjanının kalıp kalmaması ile ilgili ve service-curriculum un yapacağı kontrol sonrası stream e yazacağı mesajı tüketmesi (consume) ile değişecek.

Yani servis-application servisinin hem “producer” hem de “consumer” rolü var.

service-curriculum

Öğrencilerin başvurdukları derslerin kontenjanı kalmışmı diye kontrol eder. Tek görevi kinesis’ te bulunan “stream-application” stream’ ini consume etmek. Buradaki APLLICATION_CREATED mesajını consume eder ve gelen mesajda, eline aldığı başvurudaki dersin kontenjanı varsa APPLICATION_APPROVED, yoksa APPLICATION_REJECTED mesajını emit eder.

Her dersin 20 kontenjanı vardır ve her başvuru için dersin kontenjanını postgres ten çeker ve > 0 ise bir eksiltir (lesson tablosundaki studentlimit alanı) ve “stream-application” stream ine ilgili başvuru için APPLICATION_APPROVED mesajını gönderir.

Eğer kontenjan = 0 ise bu sefer stream e ilgili başvuru için APPLICATION_REJECTED mesajını gönderecektir.

“Loosely coupled” servisler için gerekli olan kuralı tekrarlayalım.

service-application başvuruyu alıp application tablosuna kayıt yaptıktan sonra service-curriculum servisinin tablosu olan lesson tablosunu sorgulayarak bu ders için kontenjan kalıp kalmadığın bakıp, duruma göre başvurunun statüsünü güncelleyebilir ve lesson tablosundaki dersin kontenjanını 1 azaltabilirdi.

Veya benzer şekilde, service-curriculum ilgili başvurudaki dersin kontenjanını kontrol ettikten sonra service-application servisinin tablosu olan application tablosunun başvuru statüsünü Approved/Rejected olarak güncelleyebilirdi.

Ancak bu yaklaşım konsepte uygun olmadığından dolayı kendisine ait olmayan servislerin verilerini stream üzerinden güncelliyoruz.

Burada kullandığımız senaryo gerçek hayata uymayabilir. Öğrenci ders için başvuru yaptığında sonucunun ne olduğunu anında göremez ise bu bir sıkıntı değil midir ? Burada asıl anlatılmak istenen,

  1. Loosely-coupled mimari nedir ve neden gereklidir
  2. Event-store kullanarak mesajlar üzerinden ölçeklenebilir mimariler nasıl yapabiliriz
  3. AWS Kinesis’ e nasıl mesaj yazarız/okuruz
  4. Spring boot ile consumer ve producer olabilecek servisleri nasıl yazarız