blog

API va Kong Gateway kiritish sabablari

NEXTREE.

• 7 min read
API va Kong Gateway kiritish sabablari

1. Yangi funktsiya talablar: turli tizimlar o'rtasidagi ma'lumotlarni integratsiya qilish va statistikasi qayta ishlash

So'nggi paytlarda men mas'ul bo'lgan xizmatga yangi funktsiya qo'shildi. Boshqa tizimlarda tarqatilgan ma'lumotlarni bevosita olib kelib, bizning xizmatimiz maqsadiga muvofiq tozalab (tartibga solib) va statistik ma'lumotlarni chiqarib, foydalanuvchilarga intuitiv tarzda ko'rsatadigan funktsiya edi.

Ushbu funktsiyani amalga oshirish uchun ikkita asosiy vazifa mavjud edi.

  • Ma'lumotlar ishonchliligini ta'minlash: boshqa tizimlarning API-larini ishonchli chaqirish va katta hajmdagi ma'lumotlarni yo'qotmasdan olib kelib integratsiya qilish kerak edi.

  • Bog'lanish darajasini minimallashtirish: boshqa tizimlarning o'zgarishlari bizning xizmatimizga ta'sirini minimallashtiruvchi yengil bog'lanish (Loose Coupling) tuzilishi zarur edi.

1.1 Nima uchun Kong API Gateway? (ichki arxitektura standartlarini qabul qilish)

Yangi API endpointlarini ochish va boshqa tizimlar bilan aloqa dizayn qilayotganda, bizning jamoa kompaniyaning standart arxitektura siyosati bo'lgan 'Kong API Gateway'dan foydalanishga qaror qildi. Allaqachon yaxshi qurilgan ichki infratuzilmasidan foydalanish, oddiy qoidalarga rioya qilishdan tashqari, texnik jihatdan quyidagi kuchli afzalliklarni taqdim etadi.

  • Markazlashgan marşrutni boshqarish: yangi endpointning kirish nuqtasini Kong orqali yagona qilib, kelajakda xizmat kengaytirilsa yoki ichki URL tuzilmasi o'zgartirilsa ham, tashqi interfeysni ishonchli saqlash imkoniyati beradi.

  • Umumiy funktsiyalarni topshirish: autentifikatsiya (Authentication), ruxsatnoma (Authorization), So'rov cheklovi (Rate Limiting) kabi API xavfsizligi va boshqaruvida kerakli umumiy funktsiyalarni qo'llanmalmasdan, Kongning plagin ekotizimiga topshirish orqali biznes mantiqqa (ma'lumotni tozalash va statistik hisoblash) faqat diqqat qilish imkonini beradi.

  • Monitoring va trafikni boshqarish: boshqa tizimlardan kiruvchi yoki chiquvchi trafik holatini markazdan kuzatish va mavjudligini ta'minlash uchun eng yaxshi tanlov edi.

Natijada, ushbu ish"boshqa tizimlarning ma'lumotlarini xavfsiz olib kelib, ichki statistikaga qayta ishlash biznes mantiqi amalga oshirish"va"uni korxona standart arxitekturasi bo'lgan Kong Gateway bilan silliq bog'lab, barqaror xizmat oxirgi nuqtasini ta'minlash jarayoni"bu asosiy edi.

2. Kong API Gateway ning asosiy tushunchalari va marshrutlash sozlamalari jarayoni

2.1 Backend dasturchilar bilishi kerak bo'lgan Kong'ning 3 ta asosiy ob'ekti

Kong Gateway murakkab proksi va marshrutlash sozlamalarini dasturchilar intuitiv ravishda tushunishi uchun Service, Route, Consumer3 ta asosiy ob'ektni (Entity) abstraktsiyalash orqali boshqariladi. Ushbu yangi funksiyani ulash uchun bu tushunchalarni qanday bog'laganimizni misollar bilan ko'rib chiqamiz.

[외부/타 시스템 요청] ──> [ Route (/api/v1/realtime-analytics) ]

                      │ (토큰 검증: Consumer 인증)
                      ▼
            [ Service (internal-stats-cluster) ] ──> [실제 백엔드 API]

1) Service (ichki xizmat ta'rifi)

  • tushuncha: Kong trafikni uzatadigan haqiqiy backend dasturi (Upstream manzili)ni anglatadi. Ichki jismoniy serverning IP-si yoki domeni, vaqt tugashi siyosati va hokazo bu bosqichda belgilangan.

  • misol: boshqa tizimlarning ma'lumotlarini to'plab, statistika tayyorlaydigan ichki Spring Boot/Node serveri (http://internal-stats-cluster.local) bitta Service bo'ladi.

2) Route (tashqi kirish nuqtasi ta'rifi)

  • tushuncha: tashqi mijozlar yoki boshqa tizimlar Kong Gateway-ga kirish uchun ishlatiladigan endpoint (yo'l, domen, HTTP usuli va boshqalar)ni anglatadi. Bitta Service bir nechta Route ga ega bo'lishi mumkin.

  • misol: tashqi tizim real vaqt statistikani so'rab murojaat qiladigan ochiq URL yo'li /api/v1/realtime-analytics Route bo'ladi.

3) Consumer (foydalanuvchi/maqsadli tizim ta'rifi)

  • tushuncha : APIni iste'mol qiluvchi subyekt (klient, ilova yoki boshqa tizim)ni anglatadi. Kong Consumer blokida autentifikatsiya tokenlarini xaritalash yoki trafik cheklovi (Rate Limiting) qo'yishi mumkin.

  • misol : bizning tizimimizning APIsini chaqirib, real vaqt statistik ma'lumotlarini olish uchun tashqi ‘ma'lumot iste'mol tizimi (external-data-consumer)’ Consumer sifatida ro'yxatdan o'tadi.

2.2 Ilovani asoslangan token berish va gatewayga asoslangan tasdiqlashning hamkorlik arxitekturasi

bu real vaqt statistik funktsiyasi turli tizimlar o'rtasida xavfsiz ma'lumot uzatishni ta'minlash uchun, deklarativ konfiguratsiya (Declarative Configuration) muhitida "backend mantiqiga asoslangan token berish va gatewayga asoslangan tezkor tasdiqlash"gibrid arxitekturasini qabul qildik.

Tokenning berilishi va tugash vaqtini boshqarish kabi aniq biznes qoidalari backend ilova ichki mantig'i orqali to'g'ridan-to'g'ri amalga oshiriladiva nazorat qilinadi. Aksincha, allaqachon berilgan tokenni olib keladigan real vaqt API so'rovlarining amal qilishini tekshirish eng oldingi Kong Gateway qavati (JWT plagin)da o'g'irlanib bajarish uchun tuzilgan.

Ushbu tuzilma oddiy qulaylikdan tashqari, real vaqtda katta hajmdagi statistik hisob-kitoblarni amalga oshirishi kerak bo'lgan bizning orqa tomon tizimimizning CPU resurslarini himoya qilish va foydalanishni maksimal darajada oshirish uchun arxitektura tanlovi bo'ldi.

  • Qiziqishlarni ajratish (Separation of Concerns): tokenning biznes qoidalari maxsus orqa tomon logikasi tomonidan boshqariladi, va tarmoqning old qismida paket filtrasi va imzo tasdiqlash Kong tomonidan amalga oshiriladi. Shukrki, orqa tomon faqat 'statistik hisoblash va ma'lumotlarni tozalash' degan asl biznes logikasiga e'tibor qaratishi mumkin.

  • Tugma sirli kalit (Shared Secret) orqali ishonch zanjiri: orqa tomon tokenni imzolashda foydalanadigan sirli kalitni va Kong Gateway imzoni tasdiqlashda foydalanadigan kalitni sinxronlashtirib, har safar og'ir autentifikatsiya serverini nazorat qilishdan qochgan holda yuqori tezlikdagi taqsimlangan autentifikatsiya muhitini yaratdik.

  • Real vaqtda statistikalar uchun resurslarni optimallashtirish: noqulay tokenga ega bo'lgan haqiqatsiz so'rov Kong tomonidan oldindan 401 Unauthorized holatida birinchi marta to'sib qo'yilgani uchun, katta hajmdagi statistik hisob-kitoblarni amalga oshirayotgan orqa tomon ilovasining keraksiz resurs sarfini man etib qo'ydik.

3. Muammo hal qilish: infratuzilma mukammal, lekin trafik yo'q? (Ilova bo'sh ro'yxatini ro'yxatdan o'tkazishda xatolikni aniqlash)

3.1 Infratuzilma normal, lekin orqa tomonda javob yo'qligi sababi

Kong Gateway'ga virtual deklarativ sozlamalarni yakunlagan holda, mavjud ichki ko'rsatmalarga va logik qoidalarga muvofiq mukammal token asosidagi real vaqt statistik API orqa tomon kodini ishlab chiqdik. Barcha infratuzilma marshrutlash liniyalari tartibga solingani uchun albatta bir vaqtning o'zida ulanishni kutgan edik.

Lekin mahalliy ishlab chiqish muhitida Kong orqali API endpointini chaqirishda oxirgi-oxirgi (E2E) testi o'tkazayotganida, kutgan statistik natijalar o'rniga so'rov o'rtada nishonlashda yo'qolishi yoki orqa tomon ichkisini topa olmaslik muammosi yuzaga keldi.

[Mijoz so'rovi] ──> [ Kong Gateway (o'tgan) ] ──> [ Orqa tomon ilovasi (ulanish yo'qolishi) ]

Birinchida Kongning strip_path sozlamalari yoki sarlavha uzatish muammosi yoki tariqatli sirli kalit (Secret Key) mos kelmasligi sababli yuzaga kelgan gateway darajasidagi marshrutlash muammosi deb o'yladik va infratuzilma loglari va konteyner tarmog'ida diqqat bilan muammoga munosabat bildirdik. Lekin Kong aniq orqa tomon maqsadli serverga paketlarni marshrutlashni o'zgartirmagan edi. Muammo gatewayda emas, bizning orqa tomon ilovamiz ichidabor edi.

3.2 Sabab tahlili: ramka hayot tsikli va bean (Bean) ro'yxatdan o'tkazilmasligi

sababi ahmoqona tarzda eng asosiy va muhim backend konsepsiyasidir'bean (Bean) ro'yxatdan o'tkazilmasligi'edi.

mavjud kompaniya tizimining arxitektura qoidalari va ramka spetsifikatsiyasiga muvofiq real vaqt statistikalarini qayta ishlovchi yangi xizmat sinfi va token tekshirish handler/interceptor logikasini yozishga faqat e'tibor qaratganimiz sababli, ushbu ob'ektni Spring (Spring) ning nazoratni teskari (IoC) konteyneri tomonidan boshqarilishi uchun ro'yxatdan o'tkazuvchi annotatsiyalarni (masalan: @Service, @Component) o'tkazib yuborgan yoki sozlash faylida bean (Bean) sifatida aniqlamagan edik.

Ilova ishga tushayotganda, tegishli domendagi kontroller yoki interceptor normal yuklanmay qoladi, shuning uchun Kong Gateway to'g'ri ichki manzilga real vaqt trafikini uzatsa ham, ilova qatlamida buni qabul qiladigan kontekst mavjud emasligi sababli talablar yo'qolishiga to'g'ri keladi.

3.3 Hal etish va saboqlar

sababi aniqlangandan so'ng, yangi qo'shilgan ma'lumotni tozalash va statistika hisoblash biznes logika sinfigao'tkazib yuborilgan @Service annotatsiyasini belgilab IoC konteyneriga bean (Bean) sifatida normal ro'yxatga oldikqildik.

//Example:Register the misiing bean annotation in the IoC container
@Service
Public class RealtimeStateProcessingServie implements StateServie {
   //Logic for collecting data from external systems and processing real-time statistics

}

qaramlik qabul qilish (DI) normal amalga oshgach, mahalliy muhitda test API'sini chaqirganimizda Kongning JWT tasdiqlashini o’tkazib, backendning ichki logikasi bo’ylab to'siqsiz bir marta trafikning o’tishini tasdiqladik.

Ushbu muammolarni hal qilish orqali, qanchalik infrastrukturada (Kong Gateway) aloqa chiziqlarini tekis qilib o’tkaza olsangiz ham, nihoyat uni qabul qiluvchi backend ilovasining asosiy komponentlarini skanerlash va hayot tsiklini boshqarish aniq ravishda mos kelishi kerak, shunda katta tarqatilgan tizim samarali ravishda ishlaydi, degan asosiy ko'rsatmalarni yana bir bor eslatib o'tishim mumkin edi.

4. Xulosa: birinchi Kong Gateway ulanishini tugatib, olingan darslar

Ushbu loyiha menga'Allaqachon qurilgan ichki infratuzilmani foydalanib, backend arxitekturasini rivojlantirish tajribasi'Bu bizga taqdim etilgan ma'noli imkoniyat edi. Kompaniyada Kong Gateway muhitining allaqachon o'rnatilgan bo'lishiga qaramay, o'sha paytgacha uni bevosita ko'rish imkoniyatimiz bo'lmagan edi, shuning uchun birinchi marta yangi URLni yo'naltirish va token qatlamini bog'lash jarayoni yangi va qiziqarli qiyinchilik edi.

Dastlab, "tarmoq yo‘liga ulovchi uskunalar" deb o‘ylagan API Gateway ning backend dasturchi nuqtai nazaridan qanchalik kuchli qurol bo‘lishi mumkinligini to‘g‘ridan-to‘g‘ri his qildim.

  • Backend tomonidan to'g'ridan-to'g'ri amalga oshirilishi kerak bo'lgan og'ir autentifikatsiya tekshirish qatlamini avangardda o'z zimmasiga oladiIlovalarining CPU resurslarini samarali himoya qilishqila oldik,

  • Shu sababli men faqat boshqa tizimlarning ma'lumotlarini tozalash va aniq statistikalarni hisoblash bilan shug'ullanaman'yadroviy biznes mantiq'ga faqat e'tibor qaratingamalga oshirish mumkin edi.

Mahalliy test jarayonida bo'sh ro'yxatni o'tkazib yuborish kabi kichik tajribalar bo'lsa ham, ushbu xatolarni tuzatish jarayoni davomida infratuzilma tushunish istiqbali (Infrastructure-aware) nuqtai nazaridan dasturiy ta'minot ramkalarini ko'rishga bo'lgan ko'zimni kengaytirishga muvaffaq bo'ldim.

Infraning taqdim etadigan kuchli umumiy plagin ekotizimini aqlli foydalanish ham backend muhandisining asosiy qobiliyatlari ekanligini o'rgandim. Kelajakda quriladigan turli yangi mikroservis funksiyalarida korxona standarti bo'lgan Kong Gateway resurslarini faollik bilan birlashtirib, kengaytiriladigan va mustahkam tizim tuzilmasini loyihalashtirib boraman.

kina.j

Site footer