Hammaga salom! Bizda ajoyib yangilik bor, OTUS kursni iyun oyida yana boshlaydi , shu munosabat bilan biz an'anaviy ravishda siz bilan foydali materiallarni baham ko'ramiz.
Agar siz ushbu mikroservislar bilan hech qanday kontekstsiz duch kelgan bo'lsangiz, buni biroz g'alati deb o'ylaganingiz uchun kechirasiz. Ilovani tarmoq orqali ulangan bo'laklarga bo'lish, albatta, olingan taqsimlangan tizimga murakkab xatolarga chidamlilik rejimlarini qo'shishni anglatadi.
Garchi bu yondashuv uni ko'plab mustaqil xizmatlarga ajratishni o'z ichiga olsa ham, yakuniy maqsad bu xizmatlarni turli mashinalarda ishlatishdan ko'ra ko'proqdir. Bu erda biz tashqi dunyo bilan o'zaro ta'sir qilish haqida gapiramiz, u ham o'z mohiyatiga ko'ra taqsimlanadi. Texnik ma'noda emas, balki ko'p odamlar, jamoalar, dasturlardan iborat ekotizim ma'nosida va bu qismlarning har biri qandaydir tarzda o'z ishini bajarishi kerak.
Masalan, kompaniyalar ma'lum bir maqsadga erishishga birgalikda hissa qo'shadigan taqsimlangan tizimlar to'plamidir. Biz o'nlab yillar davomida bu haqiqatni e'tibordan chetda qoldirib, FTP fayllarini birlashtirish yoki korporativ integratsiya vositalaridan foydalanish orqali o'zimizning alohida maqsadlarimizga e'tibor qaratdik. Ammo xizmatlar paydo bo'lishi bilan hamma narsa o'zgardi. Xizmatlar bizga ufqdan tashqariga qarashga va birgalikda ishlaydigan o'zaro bog'liq dasturlar dunyosini ko'rishga yordam berdi. Biroq, muvaffaqiyatli ishlash uchun ikkita tubdan farq qiladigan dunyoni tan olish va loyihalash kerak: biz ko'plab boshqa xizmatlar ekotizimida yashayotgan tashqi dunyo va biz yolg'iz hukmronlik qiladigan shaxsiy, ichki dunyomiz.
Bu taqsimlangan dunyo biz o'sgan va o'rganib qolgan dunyodan farq qiladi. An'anaviy monolit arxitekturani qurish tamoyillari tanqidga dosh berolmaydi. Shunday qilib, ushbu tizimlarni to'g'ri yo'lga qo'yish ajoyib doska diagrammasi yoki kontseptsiyaning ajoyib isbotini yaratishdan ko'proq narsani anglatadi. Gap shundaki, bunday tizimning uzoq vaqt davomida muvaffaqiyatli ishlashini ta'minlash. Yaxshiyamki, xizmatlar har xil ko'rinishga ega bo'lsa-da, ancha vaqtdan beri mavjud. Hali ham dolzarb, hatto Docker, Kubernetes va biroz eskirgan hipster soqollari bilan tajribali.
Shunday qilib, bugun biz qoidalar qanday o'zgarganini, nima uchun xizmatlarga va ular bir-biriga uzatadigan ma'lumotlarga yondashuvimizni qayta ko'rib chiqishimiz kerakligini va buni amalga oshirish uchun nima uchun mutlaqo boshqa vositalar kerakligini ko'rib chiqamiz.
KapsΓΌlleme har doim ham sizning do'stingiz bo'lmaydi
Mikroservislar bir-biridan mustaqil ishlashi mumkin. Aynan shu xususiyat ularga eng katta qiymat beradi. Xuddi shu xususiyat xizmatlarni kengaytirish va rivojlantirish imkonini beradi. Kvadrillionlab foydalanuvchilar yoki petabaytlar ma'lumotlarini kengaytirish ma'nosida emas (garchi bular ham yordam berishi mumkin), lekin jamoalar va tashkilotlar doimiy ravishda o'sib borishi sababli odamlar nuqtai nazaridan masshtablash ma'nosida.
Vaholanki, mustaqillik ikki qirrali qilichdir. Ya'ni, xizmatning o'zi oson va tabiiy ravishda ishlashi mumkin. Ammo agar funksiya boshqa xizmatdan foydalanishni talab qiladigan xizmat doirasida amalga oshirilsa, biz deyarli bir vaqtning o'zida ikkala xizmatga ham o'zgartirish kiritishga majbur bo'lamiz. Monolitda buni qilish oson, siz shunchaki o'zgartirish kiritasiz va uni chiqarishga yuborasiz, ammo mustaqil xizmatlarni sinxronlashtirishda ko'proq muammolar bo'ladi. Jamoalar va bo'shatish davrlari o'rtasidagi muvofiqlashtirish chaqqonlikni buzadi.
Standart yondashuvning bir qismi sifatida ular shunchaki zerikarli oxirigacha o'zgarishlardan qochishga harakat qilishadi, funksionallikni xizmatlar o'rtasida aniq ajratadilar. Bir martalik kirish xizmati bu erda yaxshi misol bo'lishi mumkin. U boshqa xizmatlardan ajratib turadigan aniq belgilangan rolga ega. Bu aniq ajratish shuni anglatadiki, uning atrofidagi xizmatlarga bo'lgan tez o'zgaruvchan talablar dunyosida yagona tizimga kirish xizmati o'zgarishi dargumon. U qat'iy cheklangan kontekstda mavjud.
Muammo shundaki, real dunyoda biznes xizmatlari doimo rollarning bir xil sof ajratilishini saqlab turolmaydi. Masalan, bir xil biznes xizmatlari boshqa shunga o'xshash xizmatlardan keladigan ma'lumotlar bilan ko'proq ishlaydi. Agar siz onlayn chakana savdo bilan shug'ullansangiz, buyurtma oqimi, mahsulot katalogi yoki foydalanuvchi ma'lumotlarini qayta ishlash ko'plab xizmatlaringiz uchun talabga aylanadi. Xizmatlarning har biri ishlashi uchun ushbu ma'lumotlarga kirish kerak bo'ladi.
Aksariyat biznes xizmatlari bir xil ma'lumotlar oqimini baham ko'radi, shuning uchun ularning ishi doimo bir-biriga bog'langan.
Shunday qilib, biz gapirishga arziydigan muhim nuqtaga keldik. Xizmatlar asosan yakka holda ishlaydigan infratuzilma komponentlari uchun yaxshi ishlayotgan bo'lsa-da, aksariyat biznes xizmatlari bir-biri bilan chambarchas bog'lanib qoladi.
Ma'lumotlar dixotomiyasi
Xizmatga yo'naltirilgan yondashuvlar allaqachon mavjud bo'lishi mumkin, ammo ular hali ham xizmatlar o'rtasida katta hajmdagi ma'lumotlarni qanday almashish haqida tushunchaga ega emaslar.
Asosiy muammo shundaki, ma'lumotlar va xizmatlar ajralmasdir. Bir tomondan, inkapsulyatsiya bizni xizmatlarni bir-biridan ajratish va ularning o'sishi va keyingi o'zgarishlarini osonlashtirishi uchun ma'lumotlarni yashirishga undaydi. Boshqa tomondan, biz boshqa har qanday ma'lumotlar kabi umumiy ma'lumotlarni erkin ajratish va zabt etish imkoniyatiga ega bo'lishimiz kerak. Gap shundaki, boshqa axborot tizimida bo'lgani kabi zudlik bilan ishni boshlash imkoniyatiga ega bo'lishdir.
Biroq, axborot tizimlarining inkapsulyatsiya bilan aloqasi yo'q. Aslida esa buning aksi. Ma'lumotlar bazalari o'zlari saqlaydigan ma'lumotlarga kirishni ta'minlash uchun hamma narsani qiladi. Ular kuchli deklarativ interfeys bilan birga keladi, bu sizga kerakli ma'lumotlarni o'zgartirish imkonini beradi. Bunday funksionallik dastlabki tadqiqot bosqichida muhim ahamiyatga ega, lekin doimiy rivojlanayotgan xizmatning o'sib borayotgan murakkabligini boshqarish uchun emas.
Va bu erda dilemma paydo bo'ladi. Qarama-qarshilik. Dixotomiya. Axir, axborot tizimlari ma'lumotlarni taqdim etish, xizmatlar esa yashirishdir.
Bu ikki kuch asosiy hisoblanadi. Ular bizning ko'p ishlarimizga asos bo'lib, biz qurayotgan tizimlarda doimo mukammallikka erishish uchun kurashadilar.
Xizmat ko'rsatish tizimlari o'sishi va rivojlanishi bilan biz ma'lumotlar dixotomiyasining oqibatlarini ko'p jihatdan ko'ramiz. Yoki xizmat interfeysi yanada kengroq funksiyalarni taqdim etish uchun o'sib boradi va juda chiroyli uy sharoitida ishlab chiqarilgan ma'lumotlar bazasiga o'xshay boshlaydi yoki biz hafsalamiz pir bo'lib, butun ma'lumotlar to'plamini xizmatdan xizmatga ko'chirish yoki olishning qandaydir yo'lini amalga oshiramiz.
O'z navbatida, uy sharoitida ishlab chiqarilgan ma'lumotlar bazasiga o'xshash narsalarni yaratish ko'plab muammolarga olib keladi. Nima uchun xavfli ekanligi haqida batafsil ma'lumot bermaymiz umumiy ma'lumotlar bazasi, Aytaylik, bu muhim muhandislik va ekspluatatsion xarajatlarni ifodalaydi undan foydalanishga harakat qilayotgan kompaniya uchun.
Eng yomoni shundaki, ma'lumotlar hajmi xizmat chegarasidagi muammolarni oshiradi. Xizmatda qancha umumiy ma'lumotlar bo'lsa, interfeys shunchalik murakkablashadi va turli xizmatlardan keladigan ma'lumotlar to'plamini birlashtirish shunchalik qiyin bo'ladi.
Butun ma'lumotlar to'plamini olish va ko'chirishning muqobil yondashuvi ham o'z muammolariga ega. Bu savolga umumiy yondashuv oddiygina butun ma'lumotlar to'plamini olish va saqlash, so'ngra uni har bir iste'molchi xizmatda mahalliy saqlash kabi ko'rinadi.
Muammo shundaki, turli xizmatlar ular iste'mol qilgan ma'lumotlarni boshqacha talqin qiladi. Ushbu ma'lumotlar har doim qo'lda. Ular mahalliy darajada o'zgartiriladi va qayta ishlanadi. Tez orada ular manbadagi ma'lumotlar bilan umumiy narsaga ega bo'lishni to'xtatadilar.
Nusxalar qanchalik o'zgaruvchan bo'lsa, ma'lumotlar vaqt o'tishi bilan shunchalik ko'p o'zgaradi.
Eng yomoni, bunday ma'lumotlarni orqaga qarab tuzatish qiyin ( Bu erda u haqiqatan ham yordamga kelishi mumkin). Darhaqiqat, korxonalar duch keladigan ba'zi hal qilib bo'lmaydigan texnologiya muammolari dasturdan ilovaga ko'payadigan turli xil ma'lumotlardan kelib chiqadi.
Ushbu muammoning yechimini topish uchun biz umumiy ma'lumotlar haqida boshqacha fikr yuritishimiz kerak. Ular biz quradigan arxitekturada birinchi darajali ob'ektlarga aylanishi kerak. bunday ma'lumotlarni "tashqi" deb ataydi va bu juda muhim xususiyatdir. Xizmatning ichki xususiyatlarini oshkor qilmaslik uchun bizga inkapsulyatsiya kerak, lekin xizmatlar oβz vazifalarini toβgβri bajarishlari uchun umumiy maβlumotlarga kirishini osonlashtirishimiz kerak.
Muammo shundaki, na xizmat interfeyslari, na xabar almashish, na umumiy ma'lumotlar bazasi tashqi ma'lumotlar bilan ishlash uchun yaxshi echim taklif qilmagani uchun bugungi kunda na yondashuv dolzarb emas. Xizmat interfeyslari har qanday miqyosda ma'lumotlar almashinuvi uchun juda mos emas. Xabarlar ma'lumotlarni ko'chiradi, lekin uning tarixini saqlamaydi, shuning uchun ma'lumotlar vaqt o'tishi bilan buziladi. Birgalikda ma'lumotlar bazalari bir nuqtaga juda ko'p e'tibor beradi, bu esa taraqqiyotni to'xtatadi. Biz muqarrar ravishda ma'lumotlarning ishdan chiqishi davriga tushib qolamiz:
Ma'lumotlarning buzilishi tsikli
Streams: ma'lumotlar va xizmatlarga markazlashmagan yondashuv
Ideal holda, xizmatlarning umumiy ma'lumotlar bilan ishlash usulini o'zgartirishimiz kerak. Shu nuqtada, har ikkala yondashuv ham yuqorida aytib o'tilgan dixotomiyaga duch keladi, chunki uni yo'q qilish uchun unga sehrli chang sepib bo'lmaydi. Biroq, biz muammoni qayta ko'rib chiqishimiz va murosaga erishishimiz mumkin.
Bu murosaga ma'lum darajada markazlashtirish kiradi. Biz taqsimlangan jurnal mexanizmidan foydalanishimiz mumkin, chunki u ishonchli, kengaytiriladigan oqimlarni ta'minlaydi. Endi biz xizmatlar ushbu umumiy mavzularga qoΚ»shilish va ularda ishlash imkoniyatiga ega boΚ»lishini xohlaymiz, lekin biz bu jarayonni amalga oshiradigan murakkab markazlashgan Xudo xizmatlaridan qochmoqchimiz. Shuning uchun, eng yaxshi variant - har bir iste'molchi xizmatida oqimni qayta ishlashni yaratish. Shunday qilib, xizmatlar turli manbalardan olingan ma'lumotlar to'plamlarini birlashtira oladi va ular bilan kerakli tarzda ishlaydi.
Ushbu yondashuvga erishishning bir usuli - oqim platformasidan foydalanish. Ko'p variantlar mavjud, ammo bugun biz Kafkani ko'rib chiqamiz, chunki uning Stateful Stream Processing-dan foydalanish bizga taqdim etilgan muammoni samarali hal qilish imkonini beradi.
Tarqalgan ro'yxatga olish mexanizmidan foydalanish bizga yaxshi bosib o'tilgan yo'ldan borishga va ular bilan ishlash uchun xabar almashishdan foydalanishga imkon beradi. . Ushbu yondashuv so'rov-javob mexanizmiga qaraganda yaxshiroq masshtablash va qismlarga ajratishni ta'minlaydi, chunki u oqimni jo'natuvchiga emas, balki qabul qiluvchiga nazorat qiladi. Biroq, bu hayotda hamma narsa uchun siz to'lashingiz kerak va bu erda sizga broker kerak. Ammo katta tizimlar uchun o'zaro kelishuv bunga arziydi (bu sizning o'rtacha veb-ilovangiz uchun bo'lmasligi mumkin).
Agar broker an'anaviy xabar almashish tizimidan ko'ra taqsimlangan ro'yxatga olish uchun javobgar bo'lsa, siz qo'shimcha funktsiyalardan foydalanishingiz mumkin. Transport deyarli chiziqli miqyosda, shuningdek taqsimlangan fayl tizimida bo'lishi mumkin. Ma'lumotlar jurnallarda juda uzoq vaqt saqlanishi mumkin, shuning uchun biz nafaqat xabar almashinuvini, balki ma'lumotlarni saqlashni ham olamiz. O'zgaruvchan umumiy holatdan qo'rqmasdan kengaytiriladigan saqlash.
Keyin iste'mol qilinadigan xizmatlarga deklarativ ma'lumotlar bazasi vositalarini qo'shish uchun statistik oqimlarni qayta ishlashdan foydalanishingiz mumkin. Bu juda muhim fikr. Ma'lumotlar barcha xizmatlar kirishi mumkin bo'lgan umumiy oqimlarda saqlangan bo'lsa-da, xizmatni birlashtirish va qayta ishlash shaxsiydir. Ular o'zlarini qat'iy cheklangan kontekstda yakkalanib qolishadi.
O'zgarmas holat oqimini ajratish orqali ma'lumotlar dixotomiyasini yo'q qiling. Keyin ushbu funksiyani Stateful Stream Processing yordamida har bir xizmatga qo'shing.
Shunday qilib, agar sizning xizmatingiz buyurtmalar, mahsulot katalogi, ombor bilan ishlashi kerak bo'lsa, u to'liq kirish huquqiga ega bo'ladi: faqat siz qanday ma'lumotlarni birlashtirishni, ularni qayerda qayta ishlashni va vaqt o'tishi bilan qanday o'zgarishini hal qilasiz. Ma'lumotlar almashishiga qaramay, u bilan ishlash butunlay markazlashtirilmagan. U har bir xizmat doirasida, hamma narsa sizning qoidalaringizga muvofiq ketadigan dunyoda ishlab chiqariladi.
Ma'lumotlarning yaxlitligini buzmasdan baham ko'ring. Unga muhtoj bo'lgan har bir xizmatda manbani emas, balki funksiyani qamrab oling.
Ma'lumotlarni ommaviy ravishda ko'chirish kerak bo'ladi. Ba'zan xizmat tanlangan ma'lumotlar bazasi mexanizmida mahalliy tarixiy ma'lumotlar to'plamini talab qiladi. Hiyla shundan iboratki, agar kerak bo'lsa, tarqatilgan ro'yxatga olish mexanizmiga kirish orqali nusxani manbadan tiklash mumkinligiga kafolat bera olasiz. Kafkadagi konnektorlar buni juda yaxshi bajaradi.
Shunday qilib, bugungi kunda muhokama qilingan yondashuv bir qator afzalliklarga ega:
- Ma'lumotlar jurnallarda uzoq vaqt saqlanishi mumkin bo'lgan umumiy oqimlar ko'rinishida qo'llaniladi va umumiy ma'lumotlar bilan ishlash mexanizmi har bir alohida kontekstda mustahkam bog'langan bo'lib, bu xizmatlarning oson va tez ishlashiga imkon beradi. Shunday qilib, ma'lumotlarning dixotomiyasini muvozanatlash mumkin.
- Turli xizmatlardan keladigan ma'lumotlar osongina to'plamlarga birlashtirilishi mumkin. Bu umumiy ma'lumotlar bilan o'zaro aloqani soddalashtiradi va ma'lumotlar bazasida mahalliy ma'lumotlar to'plamini saqlash zaruratini yo'q qiladi.
- Stateful Stream Processing faqat ma'lumotlarni keshlaydi va haqiqat manbai umumiy jurnallar bo'lib qoladi, shuning uchun vaqt o'tishi bilan ma'lumotlarning buzilishi muammosi unchalik keskin emas.
- Asosan, xizmatlar ma'lumotlarga asoslangan, ya'ni doimiy ravishda o'sib borayotgan ma'lumotlar hajmiga qaramay, xizmatlar biznes voqealariga tezda javob bera oladi.
- Kengaytirish masalalari xizmatlarga emas, balki brokerga tushadi. Bu yozish xizmatlarining murakkabligini sezilarli darajada kamaytiradi, chunki miqyoslash haqida o'ylashning hojati yo'q.
- Yangi xizmatlarni qo'shish eskilarini o'zgartirishni talab qilmaydi, shuning uchun yangi xizmatlarni ulash osonroq bo'ladi.
Ko'rib turganingizdek, bu faqat REST emas. Biz markazlashtirilmagan tarzda umumiy ma'lumotlar bilan ishlash imkonini beruvchi vositalar to'plamini oldik.
Bugungi maqolada barcha jihatlar yoritilmagan. Biz hali ham so'rov-javob paradigmasi va voqealarga asoslangan paradigma o'rtasidagi muvozanatni qanday aniqlashimiz kerak. Ammo keyingi safar bu bilan shug'ullanamiz. Siz yaxshiroq bilishingiz kerak bo'lgan mavzular mavjud, masalan, Stateful Stream Processing nima uchun juda yaxshi. Bu haqda uchinchi maqolada gaplashamiz. Va boshqa kuchli tuzilmalar ham borki, agar biz ularga murojaat qilsak, ulardan foydalanishimiz mumkin, masalan, . Bu taqsimlangan biznes tizimlari uchun o'yinni o'zgartiruvchi vositadir, chunki u tranzaksiya kafolatlarini beradi kengaytiriladigan shaklda. Bu to'rtinchi maqolada muhokama qilinadi. Nihoyat, biz ushbu tamoyillarni amalga oshirish tafsilotlarini ko'rib chiqishimiz kerak.
Ammo hozircha shuni esda tuting: ma'lumotlar dixotomiyasi biznes xizmatlarini yaratishda duch keladigan kuchdir. Va biz buni yodda tutishimiz kerak. Hiyla hamma narsani o'z tomoniga o'girib, umumiy ma'lumotlarni birinchi darajali ob'ektlar sifatida ko'rib chiqishni boshlashdir. Stateful Stream Processing buning uchun noyob murosani ta'minlaydi. Bu taraqqiyotni to'xtatadigan markazlashtirilgan "Xudo komponentlari" dan qochadi. Bundan tashqari, u ma'lumotlar oqimi quvurlarining chaqqonligi, kengaytirilishi va moslashuvchanligini ta'minlaydi va ularni har bir xizmatga qo'shadi. Shuning uchun biz har qanday xizmat o'z ma'lumotlari bilan bog'lanishi va ishlashi mumkin bo'lgan umumiy ong oqimiga e'tibor qaratishimiz mumkin. Bu xizmatlarni kengaytiriladigan, almashtiriladigan va avtonom qiladi. Shunday qilib, ular nafaqat doska va gipoteza testlarida yaxshi ko'rinadi, balki ular o'nlab yillar davomida ishlaydi va rivojlanadi.
Manba: www.habr.com