Mimari Örüntüler
Event-Driven Architecture
Olay-denetimli mimari(Event-Driven Architecture) stili dağıtık asenkron yüksek ölçeklenebilir uygulama geliştirmekte oldukça popüler olarak kullanılır. Hem küçük çaplı, hemde büyük kompleks uygulamalarda kolayca adapte edilebilir. Olay-denetimli mimari bileşenlerin birbirlerinden tamamı ile bağımsız sadece belli amaçlardaki olayları işlemek ayrıştırılmış, yeni bileşenler eklemesi kolay yapılardır.
Event-Driven Mimari Stili 2 ana topolojiden oluşur
- Mediator
- Broker
Mediator topolojide olaylar(events) önce merkezi bir mediator bileşeni tarafından ele alınıp çoklu adımları olacak şekilde orkestra edip yeni event serisi oluşturur, Broker topolojide ise zincir olaylar şekilde merkezi bir mediator kullanmadan arka arkaya işletilir.
1. Mediator Topoloji
Merkezi bir yerde gelen eventler ele alarak bunlar ile ilgili yapılacak adımları orkestra edip bunların seri ve paralel olarak işleten yapıya mediator topoloji mimarisi denir .
Örneğin hisse senedi almak istiyorsunuz. Gittiniz ekrandan senedi seçtiniz ve al dediniz. Al Eventi arkaplanda Mediator tarafından bir dizi olay adımına dönüştürülür ve çalıştırılır.
- Alışverişi doğrulamanız.
- Uyum kurallarını kontrol etmeniz
- Komisyoncuya atamanız
- Komisyonu hesaplamanız
- Alışverişi tamamlamanız
Tüm bu adımların hangi sırada olacağı bu adımların seri mi yoksa paralel mi işletileceğini mediator bilir.
Mediator topoloji 4 mimari bileşenden oluşur;
- event queue (olay kuyruğu): Olayları event mediator taşıyan yapıdır.
- event mediator: başlangıçtaki işlenmemiş olayı alıp buna orkestra ederek yeni eventlerde ekleyerek asenkron olarak event channel bu dizi eventi yollayan bileşendir
- event channel (olay kanalları) : Burda artık olaylar belli işleyiciler tarafından işlenmesi için ilgili kanallara aktarılır.
- event processor: Kanallardaki eventleri dinleyerek bunları işletirler.
Bu mimari event queue(olay kuyruklarını) nasıl oluşturacağınız konusunda, kaç tane olması gerektiği konusunda bir sınırlandırma ve tanımlamada bulunmaz. Bu bir mesaj kuyruğu, web servis endpoint, Restful servis endpoint vb kombinasyonlarda olabilir.
2 tip event mevcut, birincisi initial event yani dış kaynaklardan ilk event mediator giriş yapan işlenmemiş eventler birde event mediator tarafından processing event olarak oluşturulan processor/worker bileşenlerin alıp işleyeceği eventler.
Event mediator bileşeni initial eventi alarak business logic (iş mantığının) detayında neler yapılacağını bilmeden üst seviye adımları bilecek şekilde processing eventleri oluşturan mekanizmadır. Bu bişeni kendiniz geliştirebilirsiniz veya açık kaynaklı hazır kütüphanelerden faydalanabilirsiniz. Bunlar Enterprise Integration Pattern gerçekleştirimlerini içeren kütüphanelerdir. (Detay için bu konudaki yazımı okuyabilirsiniz)
Burada daha önceden anlatmış olduğum SOA kısmındaki ESB(Enterprise Service Bus) Mediation/Orkestrasyon işlemini gerçekleştirildiği kısımlardır. Olay akışlarının genelde hard coded veya DSL(Domain Spesific Language) gerçekleştirilir. Çok karmaşık iş akışları içinse BFEL((business process execution language)) gibi XML tabanlı diller ile yazılarak gerçekleştirilir. Bazı iş akışlarında ve orkestrasyon adımlarında insanlar ile etkileşim (imza/onay/yönlendirme) ihtiyaçları olabilir bunun içinde BPM (Business Process Manager) kullanılır.
Event processor bileşeni uygulama iş mantıklarının içeren, bağımsız, sadece kendi işini yapmaya odaklanmış bileşenlerdir . Bu bileşenlerin büyüklüğü yapacağı işin büyüklüğü ve karmaşıklığına göre değişiklik gösterir. Alışveriş üzerindeki vergiyi hesaplayan bileşen büyüklüğünden , sigorta için verelicek poliçe fiyatını hesaplayacak bileşen büyüklüğü gibi;
- f(order)= order * 0.18
- fInsurance(yaş, cinsiyet, hastalık, şehir …)= algorithm, decision tables …
Burada asıl önemli olan bileşenlerin diğer bileşenlere ihtiyaç duymaması ve tek bir işe odaklanarak bunu gerçekleştirmesidir.
Aşağıdaki örnekte Sigortacılık anlamında bir kişinin adresinin değişmesinin sigorta sistemine nasıl yansıtıldığı anlatılmış..
- Adım 1: Relocation (Yer değiştirme initial eventi oluşturuyor)
- Adım 2: Event mediator bu eventi alarak kendi içerisinde 5 tane processing event adımı oluşturuyor (Adresi değiştir, Hesaplamayı yenile, Sigorta taleplerini güncelle, talepleri ayarla, ve bu güncellemeler ile ilgili uyarı yap)
- Adım 3,4,5….. ilgili işlemciler kendileri ile ilgili processing eventleri işletir.
2. Broker Topoloji
Broker Topoloji’de merkezi bir event mediator (yönetim) mekanizması yerine mesaj akışının dağıtık olarak event processor üzerinden zincir şeklinde yapılan daha lightweight mesaj broker olan (ActiveMQ, RabitMQ, HornetQ) gibi sistemler kullanılır. Bu topoloji basit olay/iş akışlarının olduğu merkezi bir olay orkestrasyonuna gerek olmayan mimarilerde tercih edilmelidir.
Broker topoloji 2 mimari bileşenden oluşur;
Broker: Broker merkezi veya gruplar halinde iş akışında kullanılan tüm olay kanallarını (event channels) içerirler. Bu event channel mesaj kuyruğu, mesaj topic veya bunların birleşimi olabilir.
Event Processor: Biraz önce yukarıda da bahsettiğim iş mantıklarını gerçekleştiren işlemci/işçilerdir.
Bu mekanizmada merkezi akıllı bir orkestrasyoncu yerine bileşenler initial event işledikten sonra yeni bir event oluşturarak bunu broker iletir. Bunu başka bir bileşen alarak ilerletir. Burda ilerletilen eventleri bir processor alıp işletmesi ve ilerletmesi temel önceliktir.
Aşağıda aynı sigortacılık yer değiştirme örneğinin Broker topoloji ile nasıl yapıldığını görebilirsiniz. Bu sefer Processor kendilerin yaptığı işlemden sonra ortaya attığı eventleri diğer processor bileşenlerinden ilgilileri alıp işletir. Bunların seri veya paralel olacağı dağıtık bir şekilde bileşenlerde durur. Bundan dolayı çok karmaşık iş/olay akışları olan mimari için broker mimarisi çok uygun bir yapıda değildir.
Broker mimarisinin işleyişini anlatan en iyi görsellerden bir taneside bayrak yarışıdır. Processor bir tanesi bayrağı diğer processor vermek için taşır sonra bir diğeri …
3. Avantaj ve Dezavantajları
Event Driven Mimari stili avantajları;
- Ölçeklenebilir, Dağıtık Çalışabilir, Yüksek performanslı, Çevik , Her bir parçanın ayrı ayrı yüklenebilmesi, bileşenlerin sadece kendi mantıklarını bilmesi ve buna göre test yapılması açısından oldukça güzel bir mimari stildir. Bundan dolayı zaten dağıtık yapılarda sıkça tercih edilir.
Ama bazı dezavantajlarıda bulunur;
- Consistency(tutarlılık), atomicity (atomik), sistemin takip edilebilirliği, bir hata oluştuğunda yapılan işlemlerin geri alınması, tüm sistemin testi vb..
Referanslar
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
