Dinamik marshrutlash infratuzilmasi va oldinda turgan muammolar
Avvalgi maqolada Spring Cloud Gateway (bundan keyin SCG) yordamida qat’iy, statik YAML konfiguratsiya tuzilmasidan voz kechish va ma’lumotlar bazasiga asoslangan, ishlash vaqtida uzilishlarsiz dinamik marshrutlash arxitekturasini yaratish jarayonini bayon qilgandim. Asosiy infratuzilma konfiguratsiyasi elementlarini ilovaning biznes ma’lumotlari domeniga ko‘chirish orqali tizimni qayta yig‘masdan yoki qayta joylashtirmasdan, ishlash jarayonida marshrutlash qoidalarini real vaqt rejimida o‘zgartirish moslashuvchanligini ta’minladik. Murakkab, bir nechta vendor ishtirok etadigan muhitda bu rivojlantirish kompaniyalarining joylashtirish jadvallaridagi farqlar va endpointlardagi o‘zgarishlarga moslashuvchan javob berish imkonini beruvchi kuchli buferga aylandi.
Biroq amaliy nuqtayi nazardan, uzilishlarsiz dinamik marshrutlash muhitini yaratish ancha katta maqsad sari qo‘yilgan dastlabki qadam edi. Infratuzilma darajasida trafik kanallarini moslashuvchan tarzda ochganimiz zahoti, taqsimlangan mikroxizmatlar arxitekturasi (MSA) oldida turgan yanada fundamental va muhim amaliy muammolar yuzaga chiqa boshladi. Ularning markazida ikkita asosiy masala turardi: o‘nlab bo‘laklarga ajratilgan xizmatlar bo‘ylab yagona xavfsizlik standartlarini qanday saqlash va muayyan vaqtlarda oldindan aytib bo‘lmaydigan tarzda keladigan katta hajmdagi trafikdan ichki tizimlarni qanday xavfsiz himoyalash. Bular tizim mavjudligini ta’minlash uchun xavfsizlik funksiyalarini markazlashtirish hamda trafikni boshqarish va navbatni boshqarish masalalaridir.
Ushbu maqolada avvalgi maqolada ishlab chiqilgan GatewayRoute domen modeli va dinamik infratuzilma asosida integratsiyalashgan autentifikatsiya va avtorizatsiya filtrlarini amalga oshirishni, shuningdek katta hajmdagi trafikni ishonchli qabul qiladigan va boshqaradigan navbatni boshqarish xizmatini amaliy jihatdan joriy etish strategiyasini batafsil ko‘rib chiqamiz.
Integratsiyalashgan autentifikatsiya va avtorizatsiya filtri
Bir nechta vendor ishtirok etadigan muhitda MSAni joriy etishda uchraydigan birinchi texnik zaif nuqta — xavfsizlik standartlarining izchilligidir. Turli domenlarga ixtisoslashgan bir nechta rivojlantirish kompaniyalari o‘z mikroxizmatlarini mustaqil ravishda ishlab chiqadigan va joylashtiradigan tuzilmada autentifikatsiya va avtorizatsiya mexanizmlari har bir xizmat ichida osonlikcha bo‘linib ketadi. Xususan, ushbu loyiha uchun yaratilgan infratuzilma tashqi tizimlar bilan tartibsiz aloqani bloklaydigan yopiq ichki tarmoqda ishlagan. Shu sababli ichki mikroxizmatlar tarmoq topologiyasini tashqi integratsiya nuqtalariga bevosita oshkor qilmasdan, har bir kiruvchi so‘rovning shaxsini izchil tekshira oladigan va uni biznes ruxsatlariga muvofiq to‘liq boshqara oladigan kuchli Secure Gate zarur edi. Biz Spring Cloud Gateway qatlamida global asinxron autentifikatsiya/avtorizatsiya filtrini joriy etdik. Bu xavfsizlik bilan bog‘liq yuklamani butunlay olib tashlab, har bir xizmatga faqat o‘z biznes mantiqiga e’tibor qaratish imkonini berdi va butun tizim xavfsizlik darajasini yaxlit tarzda oshirdi.
Birinchidan, Spring Cloud Gateway ichki jihatdan Spring WebFlux va Netty dvigateliga asoslangan reaktiv arxitekturaga ega. Shu sababli har bir so‘rovni alohida oqimda qayta ishlaydigan Servlet modeliga asoslangan an’anaviy sinxron filtr o‘rniga, kam sonli Event Loop oqimlari yordamida ko‘plab parallel ulanishlarni bloklamaydigan usulda qayta ishlay oladigan reaktiv WebFilter dizayni talab etiladi. Biz joriy etgan integratsiyalashgan autentifikatsiya va avtorizatsiya filtri oddiy JWT (JSON Web Token) dekodlashdan ancha kengroq vazifani bajaradi. U bir nechta vendorlar o‘rtasidagi murakkab integratsiya spetsifikatsiyalarini bitta filtr ichida uyg‘un tarzda boshqaradi va ma’lumotlar bazasiga asoslanib, so‘rovlarni real vaqt rejimida har bir API yo‘li uchun ruxsat berilgan xizmatlarga moslashtirish orqali avtorizatsiya nazoratini amalga oshiradi. Ushbu murakkab filtr arxitekturasi bloklamaydigan API gateway muhitida hatto bir lahzalik kechikishsiz barqaror va tezkor ishlay olganining sababi reaktiv oqimlar xususiyatlarini mukammal tushunadigan va ulardan to‘g‘ri foydalanadigan uchta asosiy texnik mexanizmga bog‘liq.
Ikkinchidan, u bir nechta integratsiya spetsifikatsiyalarini shaffof tarzda qo‘llab-quvvatlash uchun dinamik token almashtirish va protokol adapteri mexanizmidan foydalanadi. Ushbu filtr oddiy gateway kirish nuqtasi bo‘lib qolmay, bir nechta rivojlantirish kompaniyalari va eski platformalarni o‘z ichiga olgan yopiq ichki tarmoqdagi aloqa spetsifikatsiyalarini moslashuvchan tarzda boshqaradigan markazlashtirilgan adapter vazifasini ham samarali bajaradi. Bir nechta vendor ishtirok etadigan muhitda har bir tizim ko‘pincha turli credential sxemasidan foydalanadi. Mijozdan har bir holatni alohida boshqarishni talab qilish o‘rniga, gatewayni so‘rov manzilini aniqlaydigan va so‘rovni real vaqt rejimida quyi oqimdagi xizmat talab qiladigan formatga dinamik ravishda o‘zgartiradigan qilib loyihalashtirdik. Xususan, eski platforma bilan integratsiya qilishda asl tashqi tokenni tekshiradigan, ichki biznes domeni bilan aloqa uchun zarur bo‘lgan infratuzilma tokenini fonda dinamik tarzda oladigan, headerni yangi credential bilan almashtiradigan va so‘rovni uzatadigan dinamik token almashtirish arxitekturasini joriy etdik. Natijada bir nechta rivojlantirish kompaniyalari va eski interfeyslar belgilagan xilma-xil hamda murakkab autentifikatsiya/avtorizatsiya spetsifikatsiyalarini gateway qatlami ostida to‘liq yashirishga va ichki tizimlar o‘rtasidagi bog‘liqlikni misli ko‘rilmagan darajada kamaytirishga erishdik.
Uchinchidan, u bloklamaydigan loglarni qayta ishlash jarayonidan foydalanadi. Xavfsizlik maxfiyligini ta’minlash uchun loglarni (GateLogCdo) saqlash jarayoni asosiy marshrutlash oqimining javob tezligiga salbiy ta’sir ko‘rsatmasligi uchun nihoyatda aniq tarzda ajratib qo‘yildi. Audit loglarini ma’lumotlar bazasiga yozish va ularni tarmoq orqali uzatish bilan bog‘liq barcha I/O yuklamasi asosiy bajarilish oqimidan to‘liq ajratilgan mustaqil fon oqimlari havzasiga topshirildi. Bu har qanday so‘rovning log saqlanishi sababli kechikishining oldini olib, gatewayning xavfsizlikni tekshirish va marshrutlashni vositachilik qilish kabi asosiy vazifalarini to‘liq yaxlitlikda saqlaydigan arxitekturani yaratish imkonini berdi.
Navbatni boshqarish tizimi
MSA muhitida muayyan domen xizmatidagi nosozlik yoki unumdorlikning pasayishi faqat bitta komponentning ishlamay qolishi bilan tugamaydi. Taqsimlangan tizimda marketing tadbiri yoki trafikning to‘satdan oshishi ma’lum bir mikroxizmatga jamlanganda, ushbu xizmatning kechikkan javoblari ko‘pincha kaskadli nosozlikka olib keladi: yuqori qatlamdagi chaqiruvchi API gatewayning ulanishlar havzasi tugab qoladi. Ayniqsa, bir nechta rivojlantirish kompaniyalari o‘z domenlarini mustaqil boshqaradigan ko‘p vendorli muhitda faqat apparat darajasidagi yagona IP bloklash yoki infratuzilma bandwidth cheklovlari yordamida biznes talablariga moslashuvchan javob berish qiyin. Shu sababli navbatga qo‘yish va mavjudlikni boshqarish arxitekturasi zarur bo‘ladi. U infratuzilma sozlamalariga bog‘liq bo‘lmaydi, har bir API yo‘lining muhimligi va mavjud sig‘imiga qarab trafik chegaralarini dinamik o‘zgartiradi hamda chegaradan oshgan foydalanuvchilarni shartsiz rad etish o‘rniga ularga navbat bilan kirish imkonini beradi. Shu maqsadda biz ma’lumotlar bazasiga asoslangan maxsus dinamik navbat tizimini yaratdik. U gateway ishlayotgan vaqtda har bir xizmatning mavjud sig‘imini real vaqt rejimida sozlaydi va ortiqcha trafikni reaktiv, bloklamaydigan oqim ichida xavfsiz navbatga qo‘yadi.
Navbatni boshqarishning kirish nuqtasi bo‘lgan QueueFilter SCGning standart kengaytirish spetsifikatsiyasi — AbstractGatewayFilterFactorydan meros olish orqali joriy etildi. Har bir so‘rovda ushbu filtr mustaqil trafik izolyatsiyasi to‘sig‘ini o‘rnatish uchun route IDni ajratib oladi va foydalanuvchining navbati kelguniga qadar Netty event loop oqimlarini band qilmaydigan, bloklamaydigan usulda kutish signallarini boshqaradi.
Ushbu navbat tizimiga gatewayning o‘z resurslarini tugatmasdan backendni himoyalash imkonini beradigan asosiy jihat uning reaktiv oqimlarni Java standart concurrency API bilan uzluksiz bog‘laydigan arxitekturaviy integratsiyasidir.
Birinchidan, u CompletableFuture va reaktiv oqimlar o‘rtasida bloklamaydigan ko‘prikni ta’minlaydi. An’anaviy bloklaydigan tuzilmada navbatni joriy etish oqimlarni uxlatishni talab qiladi, shuning uchun kutayotgan foydalanuvchilar soniga mutanosib ravishda oqimlar tugab, avval gateway ishdan chiqadi. Buni bartaraf etish uchun QueueContext har bir kutayotgan sessiya uchun bo‘sh CompletableFuture yaratadigan va ularni ConcurrentHashMapda boshqaradigan qilib loyihalandi. Foydalanuvchilar navbati kelguniga qadar qimmatli Netty event loop oqimlarini hatto 1 ms davomida ham ushlab turmasdan, o‘zlariga ajratilgan oqimni qaytaradi. Faqat ichki operatsiya yakunlanib, QueueContext navbat kelgani haqidagi signalni chiqargandagina reaktiv pipeline uyg‘onadi va keyingi marshrutlash zanjiri bo‘ylab davom etadi. Natijada resurslardan nihoyatda yuqori samaradorlik bilan foydalaniladi.
Ikkinchidan, u tizim cheklovlarini boshqarish uchun asinxron backend integratsiyasi bilan birga ikki yo‘nalishli bloklash strategiyasidan foydalanadi. Xotiradagi navbat ruxsat bergan diapazondagi trafik QueueContextda saqlanadi va reaktiv pending holatida xavfsiz kutadi. Biroq xotiradagi navbat ham sig‘imiga yetganda, kutayotgan sessiya ma’lumotlari taqsimlangan hodisani ishga tushirish uchun backendga uzatiladi, shundan so‘ng QueueFullException chiqarilib, qayta ishlanadi. Natijada gateway xotira to‘lib ketishi xavfidan to‘liq himoyalanadi, mijoz esa standart HTTP javobi orqali navbat ID sini oladi va backend bilan tarmoqdan tashqari aloqa qilish uchun mustahkam arxitekturaviy buferga ega bo‘ladi.
Uchinchidan, u reaktiv lifecycle asosida resurslarning sizib chiqishini tubdan oldini oladigan mexanizmni ta’minlaydi. Taqsimlangan navbat muhitidagi eng keng tarqalgan amaliy nosozliklardan biri foydalanuvchi kutish vaqtida sahifani yangilashi yoki oynani yopishi natijasida ulanish uzilib, xotira resurslari yoki concurrency slotlari bo‘shatilmay qolishi va deadlock yuzaga kelishidir. Ushbu tizim reaktiv oqimlarning lifecycle signallarini aniq tutib qolish orqali muammoni tubdan bartaraf etadi. Xususan, oqim bekor qilinganda ishga tushadigan doOnCancel ghost sessiyalarni darhol olib tashlaydi, doFinally bloki esa HTTP so‘rov-javob sikli har qanday sababga ko‘ra, jumladan muvaffaqiyatli yakunlanish, tarmoq xatolari yoki timeout tufayli tugaganda keyingi kutayotgan foydalanuvchini navbat bilan uyg‘otadi. Agar u mavjud slotni egallashdan oldin bekor qilingan phantom waiterga duch kelsa, bu kutuvchini xotiradan sezdirmay olib tashlash uchun tozalash mantiqini ham bajaradi. Ushbu o‘zaro bog‘langan lifecycle nazorati orqali birorta ham resurs sizib chiqishi yoki deadlocksiz barqarorlikni saqlashdek muhim natijaga erishdik.
Xulosa
Shu paytgacha integratsiyalashgan autentifikatsiya va avtorizatsiya filtrini hamda navbatni boshqarish xizmatini qanday joriy etishni ko‘rib chiqdik. Ilgari tashqi so‘rovlarni backendga uzatish bilangina shug‘ullangan API gatewaydan foydalanib, xavfsizlik va trafik boshqaruvini markazlashtirdik, ko‘p vendorli muhitda rivojlantirish samaradorligini maksimal darajaga oshirdik va navbatni boshqarish xizmati orqali infratuzilma barqarorligini ta’minladik.
Oxir-oqibat, arxitekturaning rivojlanishi biznesni qat’iy apparat yoki infratuzilma cheklovlariga moslashtirishdan iborat emas. Bu dasturiy ta’minotning o‘zini tez o‘zgaradigan biznes talablarini va murakkab hamkorlik tuzilmalarini qo‘llab-quvvatlay oladigan tarzda moslashuvchan rivojlantirish jarayonidir. Umid qilamanki, ushbu loyihada biz yaratgan SCG markazidagi dinamik boshqaruv arxitekturasi ko‘p vendorli muhitlarda MSAni ko‘rib chiqayotgan hamda bo‘linib ketgan taqsimlangan xavfsizlik va katta hajmdagi trafikni boshqarish muammolarini hal qilish ustida ishlayotgan boshqa dasturchilar uchun foydali namuna bo‘lib xizmat qiladi.
Hustle Paul