habarni orada yo'q bo'lib qolmaydi, jo'natilmagan statusda qolaveradi va outbox jadvalni monitor qilib qayta MQga yuboruvchi process habarni jo'natishga urinib ko'raveradi qachonki Message Queuega habar muvaffaqiyatli jo'natilguncha
Assalomu alaykum Ustoz. Qilayotgan video darsliklaringiz juda foydali. Alloh kuch quvvat bersin, bardavom qilsin. Ustoz sizni javascript va nodejs qo'llanma darsliklaringizni ko'rib ishga kirdim. Yaqinda 1 yil bo'lib qoladi. Sizga katta rahmat. Alloh rozi bo'lsin
Farhod aka agar saas proyektlarda monilit tizimni DDD(Domein Driven Designe) arxitekturasiga yozsa micro servicega o'tmasa ham bo'ladimi? Sababi DDD prinsipi bo'yicha har bir biznes protsess(domein service) alohida izolyatsya qilinadi. Umuman olganda DDD arxitekturasi micro service ga alternative bo'la olishi mumkinmi? Masalan ta'lim sohasida CRM va LMS tizimlarini ichiga olgan saas proyekt bo'lsa?
Assalomu alaykum Ustoz. Savolim bor edi sizga . Sizni vdiolaringiz javascript va nodjs darslarini korib ishga kirsa boladimi ? Nodjs ni organmoqchidim .
Vaalaykum assalom. Bu odamni oʻziga bogʻliq. Astoydil harakat qilib qunt bilan oʻqisa, oʻrgangan bilimini tajribada qoʻllab oʻzi mustaqil har hil muammolarni hal qilib, loyihalar ustida ishlab borsa albatta yaxshi ish topa oladi.
Savolim bor edi. Microservice tizimlari bilan ishlaganda bazalargacha bo'lib olamiz, ya'ni tizimlarni ajratayotganda qandaydir kalit ma'lumotlar asosida tizimlarni bog'laymiz. Meni o'ylantirgan narsa, tizimlar bir biriga juda kuchli bog'langan bo'lsa qanday yechim bera olasiz? Ajratay desa juda ko'p bog'lanish bor, ajratmay desa 1 tasini o'ziga juda katta nagruzka beradi
1. Tizimda mahkam bog'langan klasslarni interfeys asosida ajratib olish - SOLID ning "D" tamoyili. 2. Hizmatlarni ajratishda "qancha ko'p maydalasam shuncha yaxshi" degan qarash to'g'ri kelmaydi. Ajratishdan maqsad bir tomondan, hizmatlarni aniq bir biznes muammoni hal qilishini ko'zda tutgan holda ajratish bo'ladi. Zero har bir metodni, klassni, modulni, hizmatni yagona mas'uliati bo'lishi kerak - - SOLID dagi "S" tamoyili. Ikkinchi tomondan o'sha alohida hizmatdan mustaqil tarzda, "release" olish va "deploy qilish" imkoniyati bo'ladi. Uchinchidan bunday holda ko'p hizmatlarni alohida "scale" qila olamiz. Shuning uchun "monolith"ni ajratishda undagi modullarni biznesdagi mas'uliyat chegaralarini aniqlab olishimiz kerak va shu asosida keyin yuqoridagi "D" tamoyili asosida ajratamiz. 3. Ba'zi holatlarda ikkita hizmatda bitta ma'lumotlar omborini ishlatishga ham to'g'ri kelib qoladi. Bunday holatda imkon boricha bazadagi ma'lumotni faqat bitta hizmat yozadigan\yangilaydigan bo'lishi kerak. Boshqa hizmat faqat o'qiydigan bo'lsa muammo ancha kamayadi. Ba'zida alohida ajratilgan ma'lumotlar omborlarida bitta ma'lumot qaytarilishi ham mumkin. Bunisi endi trade-off.
Savol: Bu holatda agar Message Queue tizimi bilan aloqa boʻlmasa, yani habarni jo'nata olmasak Outbox jadvali nimasi bilan bizga yordam beradi?
habarni orada yo'q bo'lib qolmaydi, jo'natilmagan statusda qolaveradi va outbox jadvalni monitor qilib qayta MQga yuboruvchi process habarni jo'natishga urinib ko'raveradi qachonki Message Queuega habar muvaffaqiyatli jo'natilguncha
holati sent bo'lmagan xabarlarni qayta ishlashda yordam beradi menimcha
Queue tizimi yonganda unga tushmagan xabarlarni aniqlab olib qayta yubora olish imkoniyatini beradi
Agar MQ tizimi bilan aloqa bo'lmasa Outbox jadvalidagi status(PENDING) o'zgarmasdan qolaveradi. Bu esa qaytadan yuborish kerakligini anglatadi
👍👍
MashaAlloh. Robbim foydali darslaringizni ko'paytirsin va ko'p ajrlar bilan mukofotlasin
Assalomu alaykum Ustoz.
Qilayotgan video darsliklaringiz juda foydali. Alloh kuch quvvat bersin, bardavom qilsin.
Ustoz sizni javascript va nodejs qo'llanma darsliklaringizni ko'rib ishga kirdim. Yaqinda 1 yil bo'lib qoladi. Sizga katta rahmat. Alloh rozi bo'lsin
Assalomu Alaykum Farkhod oka ! Yaxshi kayfiyat sizga va salomatlik tilayman!
Farhod aka agar saas proyektlarda monilit tizimni DDD(Domein Driven Designe) arxitekturasiga yozsa micro servicega o'tmasa ham bo'ladimi?
Sababi DDD prinsipi bo'yicha har bir biznes protsess(domein service) alohida izolyatsya qilinadi. Umuman olganda DDD arxitekturasi micro service ga alternative bo'la olishi mumkinmi? Masalan ta'lim sohasida CRM va LMS tizimlarini ichiga olgan saas proyekt bo'lsa?
Assalomu alaykum Ustoz. Savolim bor edi sizga .
Sizni vdiolaringiz javascript va nodjs darslarini korib ishga kirsa boladimi ? Nodjs ni organmoqchidim .
Vaalaykum assalom. Bu odamni oʻziga bogʻliq. Astoydil harakat qilib qunt bilan oʻqisa, oʻrgangan bilimini tajribada qoʻllab oʻzi mustaqil har hil muammolarni hal qilib, loyihalar ustida ishlab borsa albatta yaxshi ish topa oladi.
holati set bo'lmagan xabarlarni qayta ishlashda yordam beradi menimcha
Toʻgʻri!
Savolim bor edi.
Microservice tizimlari bilan ishlaganda bazalargacha bo'lib olamiz, ya'ni tizimlarni ajratayotganda qandaydir kalit ma'lumotlar asosida tizimlarni bog'laymiz.
Meni o'ylantirgan narsa, tizimlar bir biriga juda kuchli bog'langan bo'lsa qanday yechim bera olasiz? Ajratay desa juda ko'p bog'lanish bor, ajratmay desa 1 tasini o'ziga juda katta nagruzka beradi
1. Tizimda mahkam bog'langan klasslarni interfeys asosida ajratib olish - SOLID ning "D" tamoyili.
2. Hizmatlarni ajratishda "qancha ko'p maydalasam shuncha yaxshi" degan qarash to'g'ri kelmaydi. Ajratishdan maqsad bir tomondan, hizmatlarni aniq bir biznes muammoni hal qilishini ko'zda tutgan holda ajratish bo'ladi.
Zero har bir metodni, klassni, modulni, hizmatni yagona mas'uliati bo'lishi kerak - - SOLID dagi "S" tamoyili.
Ikkinchi tomondan o'sha alohida hizmatdan mustaqil tarzda, "release" olish va "deploy qilish" imkoniyati bo'ladi.
Uchinchidan bunday holda ko'p hizmatlarni alohida "scale" qila olamiz.
Shuning uchun "monolith"ni ajratishda undagi modullarni biznesdagi mas'uliyat chegaralarini aniqlab olishimiz kerak va shu asosida keyin yuqoridagi "D" tamoyili asosida ajratamiz.
3. Ba'zi holatlarda ikkita hizmatda bitta ma'lumotlar omborini ishlatishga ham to'g'ri kelib qoladi. Bunday holatda imkon boricha bazadagi ma'lumotni faqat bitta hizmat yozadigan\yangilaydigan bo'lishi kerak. Boshqa hizmat faqat o'qiydigan bo'lsa muammo ancha kamayadi. Ba'zida alohida ajratilgan ma'lumotlar omborlarida bitta ma'lumot qaytarilishi ham mumkin. Bunisi endi trade-off.