19 sentyabr Moskvada mikroservislarga bag'ishlangan HUG (Highload++ User Group) birinchi tematik uchrashuvi. "Mikroservislardan foydalanish: sizda Kubernetlar bo'lsa ham o'lcham muhim" taqdimoti bo'lib o'tdi, unda biz Flantning mikroservis arxitekturasi bilan loyihalarni boshqarish bo'yicha katta tajribasi bilan o'rtoqlashdik. Avvalo, bu yondashuvni joriy yoki kelajakdagi loyihalarida qo'llash haqida o'ylayotgan barcha ishlab chiquvchilar uchun foydali bo'ladi.
Tanitish (50 daqiqa, maqoladan ko'ra ko'proq ma'lumotli), shuningdek, matn shaklida undan asosiy ko'chirma.
Eslatma: Ushbu post oxirida video va taqdimot ham mavjud.
kirish
Odatda yaxshi hikoyaning boshlanishi, asosiy syujeti va qarori bor. Bu hisobot ko'proq muqaddimaga o'xshaydi va fojiali. Shuni ham ta'kidlash kerakki, u mikroservislar haqida begonaning ko'rinishini ta'minlaydi. ekspluatatsiya.
Men ushbu grafikdan boshlayman, uning muallifi (2015 yilda) Martin Fauler:
Bu ma'lum bir qiymatga erishgan monolit dasturda qanday qilib unumdorlik pasayishni boshlaganini ko'rsatadi. Mikroservislar ular bilan dastlabki unumdorlik pastligi bilan ajralib turadi, ammo murakkablik oshgani sayin samaradorlikning pasayishi ular uchun unchalik sezilmaydi.
Men Kubernetes-dan foydalanish uchun ushbu grafikga qo'shaman:
Nima uchun mikroservislarga ega dastur yaxshiroq? Chunki bunday arxitektura arxitekturaga jiddiy talablar qo‘yadi, bu esa o‘z navbatida Kubernetes imkoniyatlari bilan mukammal qamrab olinadi. Boshqa tomondan, ushbu funksionallikning ba'zilari monolit uchun foydali bo'ladi, ayniqsa, bugungi kunda odatiy monolit to'liq monolit emasligi sababli (batafsil ma'lumotlar keyinroq hisobotda bo'ladi).
Ko'rib turganingizdek, yakuniy grafik (monolit va mikroservis ilovalari Kubernetes infratuzilmasida bo'lganda) asl nusxadan unchalik farq qilmaydi. Keyinchalik biz Kubernetes yordamida boshqariladigan ilovalar haqida gaplashamiz.
Foydali va zararli mikroservislar
Va bu erda asosiy fikr:
Nima bu oddiy mikroservis arxitekturasi? Bu sizga haqiqiy foyda keltirishi, ish samaradorligini oshirishi kerak. Agar biz grafikaga qaytadigan bo'lsak, bu erda:
Agar siz uni chaqirsangiz foydali, keyin grafikning boshqa tomonida bo'ladi zararli mikroservislar (ishga xalaqit beradi):
"Asosiy g'oya" ga qaytsak: o'z tajribamga umuman ishonishim kerakmi? Bu yil boshidan beri men qaradim 85 ta loyiha. Ularning hammasi ham mikroservislar emas edi (ularning taxminan uchdan yarmida bunday arxitektura bor edi), lekin bu hali ham katta raqam. Biz (Flant kompaniyasi) autsorser sifatida kichik kompaniyalarda (5 ta dasturchi bilan) va yirik kompaniyalarda (~500 ta dasturchi) ishlab chiqilgan turli xil ilovalarni ko'rishga muvaffaq bo'lamiz. Qo'shimcha afzallik shundaki, biz ushbu ilovalarning yillar davomida jonli va rivojlanayotganini ko'ramiz.
Nima uchun mikroservislar?
Mikroservislarning afzalliklari haqida savol tug'iladi Yuqorida aytib o'tilgan Martin Faulerdan:
- modullikning aniq chegaralari;
- mustaqil joylashtirish;
- texnologiyalarni tanlash erkinligi.
Men dasturiy ta'minot arxitektorlari va ishlab chiquvchilari bilan ko'p suhbatlashdim va ularga mikroservislar nima uchun kerakligini so'radim. Va men ularning umidlari ro'yxatini tuzdim. Mana nima bo'ldi:
Agar biz ba'zi fikrlarni "sezgilarda" tasvirlasak, unda:
- modullarning aniq chegaralari: bu erda bizda dahshatli monolit bor va endi hamma narsa "javonlarda" bo'lgan, issiq va yumshoq aralashmagan Git omborlarida chiroyli tarzda joylashtiriladi;
- tarqatish mustaqilligi: biz xizmatlarni mustaqil ravishda ishlab chiqish imkoniyatiga ega bo'lamiz, shunda rivojlanish tezroq ketadi (parallel ravishda yangi xususiyatlarni nashr etish);
- Rivojlanish mustaqilligi: biz ushbu mikroservisni bitta jamoaga/ishlab chiquvchiga, ikkinchisiga esa boshqasiga bera olamiz, buning natijasida biz tezroq rivojlana olamiz;
- боko'proq ishonchlilik: agar qisman buzilish sodir bo'lsa (20 ta mikroservisdan bittasi tushib qolsa), unda faqat bitta tugma ishlashni to'xtatadi va butun tizim ishlashda davom etadi.
Oddiy (zararli) mikroservis arxitekturasi
Nima uchun haqiqat biz kutgandek emasligini tushuntirish uchun men taqdim etaman kollektiv ko'plab turli loyihalar tajribasiga asoslangan mikroservis arxitekturasining tasviri.
Misol sifatida Amazon yoki hech bo'lmaganda OZON bilan raqobatlashadigan mavhum onlayn-do'kon bo'lishi mumkin. Uning mikroservis arxitekturasi quyidagicha ko'rinadi:
Bir nechta sabablarga ko'ra, ushbu mikroservislar turli platformalarda yozilgan:
Har bir mikroservis avtonomiyaga ega bo'lishi kerakligi sababli, ularning ko'pchiligi o'z ma'lumotlar bazasi va keshiga muhtoj. Yakuniy arxitektura quyidagicha:
Uning oqibatlari qanday?
Faulerda ham shunday bor — mikroxizmatlardan foydalanganlik uchun “toʻlov” haqida:
Va bizning kutganlarimiz bajarilganligini ko'ramiz.
Modullar chegaralarini aniqlang...
lekin qancha mikroservisni tuzatishimiz kerak?o'zgarishlarni amalga oshirish uchunmi? Biz hamma narsa taqsimlangan kuzatuvchisiz qanday ishlashini aniqlay olamizmi (axir, har qanday so'rov mikroservislarning yarmi tomonidan qayta ishlanadi)?
naqsh bor "", va bu erda u tarqalgan axloqsizlik bo'lagi bo'lib chiqdi. Buni tasdiqlash uchun so'rovlar qanday ketishining taxminiy tasviri:
Joylashtirish mustaqilligi...
Texnik jihatdan bunga erishildi: biz har bir mikroservisni alohida ishlab chiqarishimiz mumkin. Lekin amalda siz doimo chiqib ketishini hisobga olishingiz kerak ko'plab mikroservislar, va biz hisobga olishimiz kerak ularni tarqatish tartibi. Yaxshi ma'noda, biz odatda alohida sxemada relizni to'g'ri tartibda chiqaryapmizmi yoki yo'qligini sinab ko'rishimiz kerak.
Texnologiyani tanlash erkinligi...
U. Shuni yodda tutingki, erkinlik ko'pincha qonunsizlik bilan chegaralanadi. Bu erda texnologiyalarni faqat ular bilan "o'ynash" uchun tanlamaslik juda muhimdir.
Rivojlanishning mustaqilligi ...
Butun dastur uchun sinov tsiklini qanday qilish kerak (ko'p komponentlar bilan)? Lekin siz hali ham uni yangilab turishingiz kerak. Bularning barchasi shunga olib keladi sinov davrlarining haqiqiy soni, biz printsipial jihatdan o'z ichiga olishimiz mumkin, minimal bo'lib chiqadi.
Bularning barchasini mahalliy miqyosda joylashtirishga nima deysiz?.. Ma'lum bo'lishicha, ko'pincha ishlab chiquvchi o'z ishini mustaqil ravishda bajaradi, lekin "tasodifiy", chunki u sxema sinovdan o'tguncha kutishga majbur bo'ladi.
Alohida masshtablash...
Ha, lekin u ishlatiladigan DBMS sohasida cheklangan. Berilgan arxitektura misolida Kassandrada muammolar bo'lmaydi, lekin MySQL va PostgreSQLda muammolar bo'ladi.
Боko'proq ishonchlilik ...
Haqiqatda nafaqat bitta mikroservisning ishlamay qolishi ko'pincha butun tizimning to'g'ri ishlashini buzadi, balki yangi muammo ham mavjud: har bir mikroservisni xatoga chidamli qilish juda qiyin. Mikroservislar turli xil texnologiyalardan (memcache, Redis va boshqalar) foydalanganligi sababli, har biri uchun siz hamma narsani o'ylab ko'rishingiz va uni amalga oshirishingiz kerak, bu, albatta, mumkin, lekin katta resurslarni talab qiladi.
Yukni o'lchash imkoniyati...
Bu haqiqatan ham yaxshi.
Mikroservislarning "engilligi"...
Bizda nafaqat ulkan tarmoq yuki (DNS so'rovlari ko'paymoqda va hokazo), lekin biz boshlagan ko'plab pastki so'rovlar tufayli ma'lumotlarni takrorlash (do'kon keshlari), bu esa katta hajmdagi saqlashga olib keldi.
Va bizning umidlarimizni qondirish natijasi:
Lekin bu hammasi emas!
Chunki:
- Katta ehtimol bilan bizga xabarlar avtobusi kerak bo'ladi.
- Qanday qilib o'z vaqtida doimiy zaxira nusxasini yaratish kerak? Yagona haqiqiy variant - buning uchun trafikni o'chirish. Lekin buni ishlab chiqarishda qanday qilish kerak?
- Agar biz bir nechta hududlarni qo'llab-quvvatlash haqida gapiradigan bo'lsak, unda ularning har birida barqarorlikni tashkil etish juda mehnat talab qiladigan vazifadir.
- Markazlashtirilgan o'zgarishlarni amalga oshirish muammosi paydo bo'ladi. Misol uchun, agar biz PHP versiyasini yangilashimiz kerak bo'lsa, biz har bir omborga kirishimiz kerak (va ularning o'nlablari bor).
- Operatsion murakkablikdagi o'sish, o'z-o'zidan, eksponentdir.
Bularning barchasi bilan nima qilish kerak?
Monolitik dastur bilan boshlang. Fauler tajribasi Deyarli barcha muvaffaqiyatli mikroservis ilovalari monolit sifatida boshlangan, ular juda katta bo'lib, keyin buzilgan. Shu bilan birga, mikroservis sifatida yaratilgan deyarli barcha tizimlar boshidanoq ertami-kechmi jiddiy muammolarga duch keldi.
Yana bir qimmatli fikr shundaki, mikroservis arxitekturasiga ega loyiha muvaffaqiyatli bo'lishi uchun siz juda yaxshi bilishingiz kerak va mavzu sohasi va mikroservislarni qanday qilish. Va mavzuni o'rganishning eng yaxshi usuli - monolit qilish.
Ammo biz allaqachon bu holatda bo'lsak-chi?
Har qanday muammoni hal qilish uchun birinchi qadam - bu bilan rozi bo'lish va bu muammo ekanligini tushunish, biz endi azob chekishni xohlamaymiz.
Agar monolit o'sib ketgan bo'lsa (uning uchun qo'shimcha resurslarni sotib olish imkoniyati tugab qolsa), biz uni kesib tashlasak, bu holda teskari voqea paydo bo'ladi: ortiqcha mikroservislar endi yordam bermay, to'sqinlik qilganda - ortiqcha qismini kesib oling va kattalashtiring!
Masalan, yuqorida muhokama qilingan jamoaviy tasvir uchun ...
Eng shubhali mikroservislardan xalos bo'ling:
Frontend yaratish uchun mas'ul bo'lgan barcha mikroservislarni birlashtiring:
... bitta (zamonaviy va oddiy, o‘zingiz o‘ylagancha) tilda/ramkada yozilgan bitta mikroservisga:
Unda bitta ORM (bitta DBMS) va birinchi navbatda bir nechta ilovalar bo'ladi:
... lekin umuman olganda siz u erga ko'proq narsani o'tkazishingiz mumkin va quyidagi natijaga erishasiz:
Bundan tashqari, Kubernetesda biz bularning barchasini alohida misollarda bajaramiz, ya'ni biz hali ham yukni o'lchashimiz va ularni alohida o'lchashimiz mumkin.
Xulosa
Kattaroq rasmga qarang. Ko'pincha, mikroservislar bilan bog'liq bu muammolarning barchasi kimdir o'z vazifasini o'z zimmasiga olgani, lekin "mikroservislar bilan o'ynashni" xohlaganligi sababli yuzaga keladi.
"Mikroservislar" so'zida "mikro" qismi ortiqcha.. Ular "mikro" dir, chunki ular ulkan monolitdan kichikroqdir. Lekin ularni kichik narsa deb o'ylamang.
Va yakuniy fikr uchun, keling, asl jadvalga qaytaylik:
Unda yozilgan eslatma (yuqori o'ng) bu haqiqatga to'g'ri keladi loyihangizni amalga oshiradigan jamoaning mahorati har doim asosiy hisoblanadi — ular mikroservislar va monolit o'rtasidagi tanlovingizda asosiy rol o'ynaydi. Agar jamoa etarli ko'nikmalarga ega bo'lmasa, lekin u mikroservislarni ishlab chiqarishni boshlasa, voqea, albatta, halokatli bo'ladi.
Video va slaydlar
Nutqdan video (~ 50 daqiqa; afsuski, u tashrif buyuruvchilarning ko'p sonli his-tuyg'ularini bildirmaydi, bu asosan hisobotning kayfiyatini aniqladi, ammo bu shunday):
Hisobot taqdimoti:
PS
Bizning blogimizdagi boshqa hisobotlar:
- «» (Dmitriy Stolyarov; 28 yil 2018-may, RootConf da);
- «» (Dmitriy Stolyarov; 7 yil 2017 noyabr HighLoad++ da);
- «» (Dmitriy Stolyarov; 6 yil 2017 iyunda RootConf da);
- «» (Dmitriy Stolyarov; 8 yil 2016 noyabr HighLoad++ da);
- «» (Dmitriy Stolyarov; 31 yil 2016-may, RootConf da).
Sizni quyidagi nashrlar ham qiziqtirishi mumkin:
- «";
- «";
- «".
Manba: www.habr.com