26-fevral kuni biz Apache Ignite GreenSource uchrashuvini o‘tkazdik, unda ochiq manbali loyihaga hissa qo‘shuvchilar so‘zlashdi. . Ushbu jamoa hayotidagi muhim voqea tarkibiy qismni qayta qurish edi , bu sizga maxsus mikroservislarni to'g'ridan-to'g'ri Ignite klasteriga joylashtirish imkonini beradi. Yig‘ilishda bu murakkab jarayon haqida gapirdi , dasturiy ta'minot muhandisi va ikki yildan ortiq Apache Ignite yordamchisi.
Umuman olganda, Apache Ignite nima ekanligini boshlaylik. Bu SQL, tranzaksiya va keshlashni qo'llab-quvvatlaydigan taqsimlangan kalit/qiymat xotirasi bo'lgan ma'lumotlar bazasi. Bundan tashqari, Ignite sizga maxsus xizmatlarni bevosita Ignite klasteriga joylashtirish imkonini beradi. Ishlab chiquvchi Ignite taqdim etgan barcha vositalardan foydalanish huquqiga ega - tarqatilgan ma'lumotlar tuzilmalari, Xabarlar, Streaming, Hisoblash va Data Grid. Masalan, Data Grid-dan foydalanganda, ma'lumotlarni saqlash uchun alohida infratuzilmani boshqarish muammosi va natijada yuzaga keladigan qo'shimcha xarajatlar yo'qoladi.
Service Grid API-dan foydalanib, siz shunchaki joylashtirish sxemasini va shunga mos ravishda konfiguratsiyada xizmatning o'zini ko'rsatish orqali xizmatni o'rnatishingiz mumkin.
Odatda, joylashtirish sxemasi klaster tugunlarida joylashtirilishi kerak bo'lgan misollar sonining ko'rsatkichidir. Ikkita odatiy joylashtirish sxemasi mavjud. Birinchisi, Cluster Singleton: istalgan vaqtda foydalanuvchi xizmatining bir nusxasi klasterda mavjud bo'lishi kafolatlanadi. Ikkinchisi - Node Singleton: xizmatning bir nusxasi har bir klaster tugunida joylashtirilgan.
Foydalanuvchi shuningdek, butun klasterdagi xizmat ko'rsatish namunalari sonini belgilashi va mos tugunlarni filtrlash uchun predikatni belgilashi mumkin. Ushbu stsenariyda Service Grid o'zi xizmatlarni joylashtirish uchun optimal taqsimotni hisoblab chiqadi.
Bundan tashqari, Affinity Service kabi xususiyat mavjud. Affinity - bu kalitlarning bo'limlarga bo'lgan munosabatini va topologiyadagi tomonlarning tugunlarga bo'lgan munosabatini belgilaydigan funktsiya. Kalit yordamida siz ma'lumotlar saqlanadigan asosiy tugunni aniqlashingiz mumkin. Shu tarzda siz o'z xizmatingizni kalit va yaqinlik funksiyasi keshi bilan bog'lashingiz mumkin. Agar yaqinlik funktsiyasi o'zgarsa, avtomatik qayta joylashtirish sodir bo'ladi. Shunday qilib, xizmat har doim manipulyatsiya qilish kerak bo'lgan ma'lumotlarga yaqin joyda joylashgan bo'ladi va shunga mos ravishda ma'lumotlarga kirish xarajatlarini kamaytiradi. Ushbu sxemani o'ziga xos biriktirilgan hisoblash deb atash mumkin.
Endi biz Service Gridning go'zalligi nima ekanligini tushunib oldik, keling, uning rivojlanish tarixi haqida gapiraylik.
Oldin nima bo'lgan
Service Grid-ning oldingi joriy etilishi Ignite-ning tranzaksiyali takrorlangan tizim keshiga asoslangan edi. Ignite-dagi "kesh" so'zi saqlashni anglatadi. Ya'ni, bu siz o'ylagandek vaqtinchalik narsa emas. Kesh replikatsiya qilinganiga va har bir tugun to'liq ma'lumotlar to'plamini o'z ichiga olganiga qaramay, kesh ichida u bo'lingan ko'rinishga ega. Bu saqlashni optimallashtirish bilan bog'liq.
Foydalanuvchi xizmatni o'rnatmoqchi bo'lganida nima bo'ldi?
- Klasterdagi barcha tugunlar o'rnatilgan Uzluksiz so'rov mexanizmidan foydalangan holda saqlashdagi ma'lumotlarni yangilashga obuna bo'ldi.
- O'qishga topshirilgan tranzaksiya ostida boshlang'ich tugun ma'lumotlar bazasida xizmat konfiguratsiyasi, jumladan, ketma-ketlashtirilgan namunani o'z ichiga olgan yozuvni yaratdi.
- Yangi yozuv haqida xabar berilganda, koordinator konfiguratsiya asosida taqsimotni hisoblab chiqdi. Olingan ob'ekt ma'lumotlar bazasiga qayta yozildi.
- Agar tugun tarqatishning bir qismi bo'lsa, koordinator uni joylashtirishi kerak edi.
Bizga nima to'g'ri kelmadi
Bir nuqtada biz shunday xulosaga keldik: bu xizmatlar bilan ishlash usuli emas. Buning bir qancha sabablari bor edi.
Agar tarqatish paytida biron bir xatolik yuz bergan bo'lsa, uni faqat hamma narsa sodir bo'lgan tugun jurnallaridan bilib olish mumkin edi. Faqat asinxron joylashtirish mavjud edi, shuning uchun foydalanuvchiga joylashtirish usulidan boshqaruvni qaytargandan so'ng, xizmatni ishga tushirish uchun biroz qo'shimcha vaqt kerak bo'ldi - va bu vaqt davomida foydalanuvchi hech narsani boshqara olmadi. Xizmatlar tarmog'ini yanada rivojlantirish, yangi xususiyatlarni yaratish, yangi foydalanuvchilarni jalb qilish va barchaning hayotini osonlashtirish uchun nimadir o'zgarishi kerak.
Yangi Service Gridni loyihalashda biz birinchi navbatda sinxron joylashtirish kafolatini taqdim qilmoqchi edik: foydalanuvchi APIdan boshqaruvni qaytarishi bilanoq u xizmatlardan darhol foydalanishi mumkin edi. Shuningdek, men tashabbuskorga tarqatish xatolarini hal qilish qobiliyatini berishni xohladim.
Bundan tashqari, men amalga oshirishni soddalashtirmoqchi bo'ldim, ya'ni tranzaktsiyalardan va muvozanatni tiklashdan uzoqlashdim. Kesh takrorlangan va muvozanat yo'qligiga qaramay, ko'plab tugunlar bilan katta joylashtirish paytida muammolar paydo bo'ldi. Topologiya o'zgarganda, tugunlar ma'lumot almashishi kerak va katta joylashtirish bilan bu ma'lumotlar juda og'irlashishi mumkin.
Topologiya beqaror bo'lganda, koordinator xizmatlarni taqsimlashni qayta hisoblashi kerak edi. Va umuman olganda, siz beqaror topologiyada tranzaktsiyalar bilan ishlashingiz kerak bo'lganda, bu oldindan aytish qiyin bo'lgan xatolarga olib kelishi mumkin.
Muammolar
Muammolarsiz global o'zgarishlar nima? Ulardan birinchisi topologiyaning o'zgarishi edi. Siz tushunishingiz kerakki, istalgan vaqtda, hatto xizmatni o'rnatish vaqtida ham, tugun klasterga kirishi yoki uni tark etishi mumkin. Bundan tashqari, agar joylashtirish vaqtida tugun klasterga qo'shilsa, xizmatlar haqidagi barcha ma'lumotlarni yangi tugunga doimiy ravishda o'tkazish kerak bo'ladi. Va biz nafaqat allaqachon joylashtirilgan narsalar haqida, balki hozirgi va kelajakdagi joylashtirishlar haqida ham gapiramiz.
Bu alohida ro'yxatda to'planishi mumkin bo'lgan muammolardan biri:
- Tugunni ishga tushirishda statik sozlangan xizmatlarni qanday joylashtirish mumkin?
- Klasterdan tugunni tark etish - agar tugun xizmatlarga ega bo'lsa nima qilish kerak?
- Agar koordinator o'zgargan bo'lsa, nima qilish kerak?
- Agar mijoz klasterga qayta ulansa nima qilish kerak?
- Faollashtirish/o'chirish so'rovlarini qayta ishlash kerakmi va qanday qilib?
- Agar ular keshni yo'q qilishni talab qilsalar va bizda unga aloqadorlik xizmatlari mavjud bo'lsa-chi?
Va bu hammasi emas.
qaror
Maqsad sifatida biz xabarlar yordamida jarayonli aloqani amalga oshirish bilan Voqealarga asoslangan yondashuvni tanladik. Ignite allaqachon tugunlarga o'zaro xabarlarni yo'naltirish imkonini beruvchi ikkita komponentni qo'llaydi - aloqa-spi va Discovery-spi.
Communication-spi tugunlarga to'g'ridan-to'g'ri muloqot qilish va xabarlarni yuborish imkonini beradi. U katta hajmdagi ma'lumotlarni yuborish uchun juda mos keladi. Discovery-spi sizga klasterdagi barcha tugunlarga xabar yuborish imkonini beradi. Standart amalga oshirishda bu halqa topologiyasi yordamida amalga oshiriladi. Zookeeper bilan integratsiya ham mavjud, bu holda yulduz topologiyasi qo'llaniladi. Yana bir muhim jihat shundaki, Discovery-spi xabarning barcha tugunlarga to'g'ri tartibda yetkazilishini kafolatlaydi.
Keling, joylashtirish protokolini ko'rib chiqaylik. Joylashtirish va o'chirish uchun barcha foydalanuvchi so'rovlari Discovery-spi orqali yuboriladi. Bu quyidagilarni beradi kafolatlar:
- So'rov klasterdagi barcha tugunlar tomonidan qabul qilinadi. Bu koordinator o'zgarganda so'rovni qayta ishlashni davom ettirish imkonini beradi. Bu shuningdek, bitta xabarda har bir tugun xizmat konfiguratsiyasi va uning ketma-ketlashtirilgan namunasi kabi barcha kerakli metama'lumotlarga ega bo'lishini anglatadi.
- Xabar yetkazib berishning qat'iy tartibi konfiguratsiya ziddiyatlari va raqobatdosh so'rovlarni hal qilishga yordam beradi.
- Tugunning topologiyaga kirishi kashfiyot-spi orqali ham amalga oshirilganligi sababli, yangi tugun xizmatlar bilan ishlash uchun zarur bo'lgan barcha ma'lumotlarni oladi.
So'rov qabul qilinganda, klasterdagi tugunlar uni tasdiqlaydi va ishlov berish vazifalarini yaratadi. Bu vazifalar navbatga qo'yiladi va keyin alohida ishchi tomonidan boshqa ish zarrachasida qayta ishlanadi. U shu tarzda amalga oshiriladi, chunki joylashtirish ko'p vaqt talab qilishi va qimmat kashfiyotlar oqimini chidab bo'lmas darajada kechiktirishi mumkin.
Navbatdagi barcha so'rovlar tarqatish menejeri tomonidan qayta ishlanadi. Bu navbatdan vazifani olib tashlaydigan va joylashtirishni boshlash uchun uni ishga tushiradigan maxsus ishchiga ega. Shundan so'ng quyidagi harakatlar sodir bo'ladi:
- Har bir tugun yangi deterministik tayinlash funksiyasi tufayli taqsimotni mustaqil ravishda hisoblab chiqadi.
- Tugunlar joylashtirish natijalari bilan xabar yaratadi va uni koordinatorga yuboradi.
- Koordinator barcha xabarlarni jamlaydi va butun joylashtirish jarayonining natijasini yaratadi, bu kashfiyot-spi orqali klasterdagi barcha tugunlarga yuboriladi.
- Natija olinganda, joylashtirish jarayoni tugaydi, shundan so'ng vazifa navbatdan olib tashlanadi.
Voqealarga asoslangan yangi dizayn: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Agar tarqatish paytida xatolik yuzaga kelsa, tugun darhol ushbu xatoni koordinatorga yuboradigan xabarga kiritadi. Xabarlarni jamlagandan so'ng, koordinator joylashtirish paytidagi barcha xatolar haqida ma'lumotga ega bo'ladi va bu xabarni Discovery-spi orqali yuboradi. Xato haqida ma'lumot klasterdagi istalgan tugunda mavjud bo'ladi.
Xizmatlar tarmog'idagi barcha muhim voqealar ushbu operatsion algoritm yordamida qayta ishlanadi. Masalan, topologiyani o'zgartirish ham Discovery-spi orqali xabardir. Va umuman olganda, avvalgisi bilan solishtirganda, protokol juda engil va ishonchli bo'lib chiqdi. Joylashtirish paytida har qanday vaziyatni hal qilish uchun etarli.
Keyingi nima bo'ladi?
Endi rejalar haqida. Ignite loyihasidagi har qanday katta o'zgartirish Ignite takomillashtirish tashabbusi sifatida yakunlanadi, IEP deb ataladi. Xizmatlar tarmog'ini qayta loyihalashda IEP ham mavjud - "Xizmat ko'rsatish tarmog'ida moy almashinuvi" masxara sarlavhasi bilan. Lekin, aslida, biz dvigatel moyini emas, balki butun dvigatelni almashtirdik.
IEPdagi vazifalarni 2 bosqichga ajratdik. Birinchisi, asosiy bosqich bo'lib, u joylashtirish protokolini qayta ishlashdan iborat. U allaqachon masterga kiritilgan, siz 2.8 versiyasida paydo bo'ladigan yangi Service Grid-ni sinab ko'rishingiz mumkin. Ikkinchi bosqich ko'plab boshqa vazifalarni o'z ichiga oladi:
- Issiq qayta joylashtirish
- Xizmat versiyasi
- Xatolarga chidamlilikning ortishi
- Yupqa mijoz
- Turli ko'rsatkichlarni kuzatish va hisoblash uchun asboblar
Nihoyat, biz sizga nosozliklarga chidamli, mavjudligi yuqori bo'lgan tizimlarni yaratish uchun xizmat ko'rsatish tarmog'i bo'yicha maslahat beramiz. Shuningdek, sizni bizga tashrif buyurishga taklif qilamiz и tajribangiz bilan o'rtoqlashing. Sizning tajribangiz hamjamiyat uchun haqiqatan ham muhim; u keyingi qayerga o'tishni, kelajakda komponentni qanday rivojlantirishni tushunishga yordam beradi.
Manba: www.habr.com