Event-driven architecture (EDA) nima? Pub/Sub va event streaming

Assalamu Alaykum hech onlayn do'kondan narsa xarid qilib ko'rganmisiz to'lov qabul qilindi tezda chiqadi ammo bu haqida email biroz muddatdan so'ng keladi . Nega ? Sababi ular Hodisalarga asoslangan arxitektura (EDA) asosida qurilgan bo'ladi. Bugun bu nimaligini ko'rib chiqamiz

Intro

Biz odatda servis qurganda so’rov/javob (request/response) uslubidan foydalanamiz . Bu holat sinxron bo’lib biz serverdan javob kelishini (hamma amallar bajarilgandan keyin) kutib turamiz , agarda biz yuborgan so’rov bitta emas bir necha servisni o’z ichiga olsa demak har bittasi uchun qo’shimcha ko’proq vaqt kutamiz(chunki hammasi tugatilgandan keyin javob yuboriladi) hatto qolgan ishlar bajarilsa ham . Ba’zi holatlarda foydalanuvchi buni kutishi shart emas masalan elektron magazindan sotib olishda pul to’lashdan so’ng u hammasini kutib o’tirishi shart emas . Foydalanuvchiga buyurtma qabul qilingani va uning holati ko’rsatilsa bo’ldi . U keyin to’planishi , yetkazib berishga yuborilgani va qaysi joyda ekanligini har vaqtda yangilangan ma’lumot bilan ko’rib turishi mumkin, (emailga xarid haqida xabar ham 1 soatdan keyin kelishi qabul qilinadi) .

Message driven arxitektura

Endi bizda mikroservislar o’rtasida aloqa qilishning boshqa uslubi ham mavjud bu esa message driven architecture . Bu holatda servislar o’zaro asinxron gaplashadi message broker yoki queuedan foydalangan holda . Bu yerda xabarlar 2 xil bo’lishi mumkin : 

1. Buyruqlar (qabul qiluvchiga nima ish qilishini aytadi) . Masalan CreateOrder , SendEmail . Buyruqlar odatda bir servisdan 2-siga boradi .

2. Hodisalar( bunda servis o’zida nima o’zgarish bo’lganini bildiradi ), OrderCreated , PaymentCharged . Hodisalar odatda birdaniga bir necha servisga yuboriladi.

Event driven esa shu arxitekturaning bir ko’rinishi 

Note: Asosiy g’oyasi komponentlar to’g’ridan to’g’ri gaplashmasligi

Event (hodisa) nima? 

Hodisa (event) — bu sistemada sodir bo'lgan o'zgarishning yozuvi (masalan, buyurtma yaratilishi yoki parol almashtirilishi). EDA ana shunday hodisalar ketma-ketligiga tayanadi.

Har bir hodisa (event) ushbu qismlar bo’ladi : kalit hodisa yoki obyektni bildiradigan, haqiqiy ma’lumot, hodisa qachon bo’lgan vaqti ba’zan esa hodisa haqida qo’shimcha ma’lumot masalan sxema versiyasi. Bular birgalikda keyingi servis uchun kerakli bo’lgan hamma ma’lumotni o’z ichiga oladi. 

Hodisalarga asoslangan arxitektura bundan keyin EDA deb aytib ketiladi.

Event driven Arxitekture nima ? 

Event-driven arxitektura (EDA) bu software design pattern bo’lib real vaqtda hodisalarga reaksiya qilishga yordam beradi . EDAda hodisa sodir bo’lgan paytda hamma servis va odamlarga reaksiya qilinishi uchun yuboriladi (eventga subscribe bo'lganlarga) . 

Asosiy xarakteristikalari : 

• xabarlarni asinxron process qilish

• servislar orasidagi bog’liqlikni kamaytiradi. 

• servislar oson kengayadi va moslashuvchan bo’ladi. 

U qanday ishlaydi ?

EDA da g’oya oddiy ammo har bir hodisa odata bir necha servislardan o’tib borishi kerak va har bir servis har xil tilda yozilgan va turli xil protokollar bilan muloqot qiladi va bu ba'zan murakkab bo'lishi mumkin.

Sinxron aloqa bu http(https) orqali servislar gaplashishi asinxron esa EDA message queue yoki event brokerlar orqali bo’ladi. 

Eng muhim jihati event(hodisa) yuborayotgan servis buni qabul qilayotgan servis ishlayotgan yoki hatto borligi haqida qiziqmaydi , hodisani yuboradi tamom. EDA uchun eng mashhur tanlovlardan biri bu Kafka. 

EDAda mikroservislar alohida serverga yuklanishi mumkin bo’lgan va bir biri bilan standart protokolda gaplashadigan kichkina dasturlar deb ko’riladi. Unda 3 ta asosiy narsa bor bu Producer (hodisalarni joylaydigan servis) , event broker bu kelgan event larni boshqa servislarga yektazib beruvchi qisma, consumer esa kelgan eventga qarab ish qiladigan servis. 

Bizda 2 xil uslub bor eventlarni berish uchun pub/sub modeli va event streaming : 

Pub sub modeli

• Hodisa bir nechta consumerlarga uzatiladi (har bir consumer hodisani bir marta oladi va u hech qayerda saqlanmaydi , ular hammasi bir vaqtda eventlarni qabul qilib oladi ) 

• rabbitMQ va AWS SNS ( real vaqtdagi notficationlar uchun yaxshi)

Event streaming

• hodisalar saqlanadi va ketma-ketlikda qabul qilinadi

• consumerlar o’zi xohlagan qismda bo’lishi mumkin

• Kafka va AWS kinesis ishlatilinadi ( bu sizga tarix kerak bo’lganda va ketma-ketlik muhim bo’lganda yaxshi ) 

Event Streaming va Pub/Sub o’rtasidagi farq 

Pub-sub uslubida hodisa(event) sodir bo’lsa masalan (OrderPlaced) ,u brokerga kelgach darhol , barcha aktiv subscriberlarga yuboriladi. Bu holatda , analitika servis, notfication servis va inventory (omborxona) servis hammasi birdaniga eventni oladi (agarda ular ishlayotgan bo’lsa) broker eventni saqlab turmaydi u yetkazib berilgandan keyin u yoq, bu alerting sistemalari va notificationlar uchun yaxshi .

Event Streaming uslubida OrderPlaced hodisasi o’chmaydigan bo’lib saqlanadi . Har bir servis o’zi xohlagan tezlikda o’qiydi va o’zi qayerga kelganini cursor orqali bildiradi. Agarda notification servis o’chib qolsa ham keyin qolib ketgan eventlarni o’qib olib uzatadi ,yangi consumerlar ham ham oldingi loglardan boshlab o'qiy oladi . Bu uslub audit loglar uchun juda qulay. 

Asosiy farq ular orasidagi yetkazib berish va saqlab qolishda bo’ladi .Pub-sub tarixsiz ularni yetkazib beradi, Event streaming esa saqlab turadi va servisni o’ziga o’qib olishga qo’yib beradi .

Nega uni ishlatishimiz kerak

EDAning foydasi sistema komponentlarini orasida bog’liqligini uzadi va ular alohida yaratilishi va yuklanishi mumkin va buni natijasida sistema fault tolerant bo’ladi.

• sistema reaksiya tezligini oshiradi

• real vaqtda hodisalar bilan ishlashga yordam beradi

• bir vaqtda bir hodisaga bir nechta servislar reaksiya qilishi mumkin

• yangi qo’shilgan servis (oldin bo’lgan hodisalardan boshlab o’qib kelishi mumkin)

EDA ning yaxshi va yomon tomonlari 

EDAda yomon tomoni eventual consistency muammo bo’ladi , eventlar ketma-ket process qilinmasligi mumkinligi muammosi , va debugging juda qiyinlashib ketishi . Qo’shimcha element bu yana bosh og’riq dasturchi uchun.

Yaxshi tomonlari :

• Servislar oson kengaya oladi va bir biriga bog’liq bo’lmaydi

• Real vaqtda hodisalarni process qilish va reaksiya qilish 

• Fault tolerance va Reliability 

Best practices

• hodisa qayta ishlash servislarda Idempotent bo’lishi kerak

• dead letter queuelar (DLQ) implementatsiya qilinishi  kerak

• Sistemaga qarab to’g’ri event broker tanlash

• hodisalarni sxemalarini versiyalash 

Real hayotda qayerlarda ishlatilinadi 

Internet of Things (IoT) eventlarni real vaqtda ko'rib boshqarib turish uchun qulay . Workflow Management vazifalar qaysidir darajaga yetganda ma’sul shaxslarga xabar yuborish va ular vazifani tekshirib olishi va boshqa juda ko’p joylarda ishlatish mumkin

Xulosa

Xulosa qilib aytadigan bo’lsak EDA foydalanuvchiga natija hozir kerak bo’lmagan va bir nechta hodisalar ketna-ket sodir bo’lib amalga oshadigan holatlar uchun juda qulay . Request/Response esa tezda javob keladigan va juda muhim natijasi hozir kerak bo’ladigan vaziyatlarda yaxshiroq tanlov. 

E'tiboringiz uchun rahmat !!! Xato va kamchiliklar uchun uzr .