Mikroservislar katta dasturni oddiy API orqali bir-biri bilan aloqa qiladigan erkin ulangan modullarga ajratish usulidir.
So'nggi paytlarda faqat soqovlar mikroservislar haqida gapirmaydilar. Bu tobora ommalashib bormoqda. Modulli arxitektura uslubi, ayniqsa, bulutga asoslangan muhitlar uchun juda mos ko'rinadi va tobora ommalashib bormoqda. Tafsilotlarga kirishdan oldin, keling, hamma narsaga qush nazari bilan qaraymiz . Shuning uchun: Mikroservislar katta loyihani kichik, mustaqil va erkin bog'langan modullarga ajratish usulidir. Mustaqil modullar aniq belgilangan va diskret vazifalar uchun mas'ul bo'lib, oddiy va qulay API orqali bir-biri bilan muloqot qiladi. Boshqacha qilib aytganda, mikroservislar murakkab, asosan veb-ilovalarni loyihalash uchun oddiygina boshqa arxitektura uslubidir. Ammo SOA (Xizmatga yo'naltirilgan arxitektura) kabi mavjud me'moriy yechimlarning nimasi yomon? SOA yordamida yozilgan ko'pgina zamonaviy korporativ echimlar juda yaxshi ishlaydi. Ayni kunlarda soha duch kelayotgan muammolar haqida gapirish uchun ajoyib vaqt bo‘lishi mumkin... Keling, oddiy misoldan boshlaylik. Aytaylik, men Java-da yozilgan klassik dasturni ishga tushirishim kerak. Avval foydalanuvchi interfeysini, so'ngra UI bilan o'zaro ta'sir qiladigan bir nechta komponentlar bilan biznes mantiqiy qatlamini va nihoyat doimiy ma'lumotlar bazasiga kirish mumkin bo'lgan ma'lumotlar bazasi qatlamini ishlab chiqaman. Endi men dasturni ishga tushirishni xohlayotganimga ko'ra, men WAR/EAR/JAR yarataman va uni serverga (JBoss, Tomcat yoki WebLogic kabi) o'rnataman. Bularning barchasi bittada amalga oshirilganligi sababli, men monolit dasturni olaman, ya'ni barcha komponentlar bir joyda ... Rasmdagi misol:
Ehtimol, siz ushbu yondashuv bilan allaqachon tanishsiz va undan foydalangansiz, ammo g'oya ushbu misoldan foydalanib, ishlab chiquvchilar ushbu me'moriy yechimdan foydalangan holda qanday qiyinchiliklarga duch kelishlarini ko'rsatishdir. Monolitik dastur: qiyinchiliklarga duch keladi
Ilova o'sib ulg'aygan sari, yozilgan kod miqdori ham oshib boradi, bu har safar uni ochishingiz kerak bo'lganda ishlab chiqish muhitini ortiqcha yuklashi mumkin. Bu, albatta, ishlab chiquvchining samaradorligini pasaytiradi.
Hamma narsa bir joyda o'rnatilishi kerakligi sababli, bu boshqa dasturlash tiliga o'tish yoki boshqa texnologiyalarga o'tish katta muammo bo'lishiga olib keladi. Misol uchun, siz Java-da dastur yozdingiz va bir muncha vaqt o'tgach, Kotlin chiqdi va siz uni qayta yozishni xohladingiz, chunki u sovuqroq, yaxshiroq va tezroq deb targ'ib qilingan . Monolitik dastur bilan, hatto refaktoring haqida o'ylash ham, jarayonning o'zi haqida gapirmasa ham, haqiqiy og'riqni keltirib chiqaradi. Hozirda shu tarzda yaratilgan ko'plab ilovalar mavjud va kod satrlari soni shunchaki aql bovar qilmaydi.
Agar biron bir sababga ko'ra komponentlardan biri ishlamay qolsa , butun dastur ham ishlamay qoladi. Tasavvur qiling-a, avtorizatsiya, to'lov, tarix va boshqalar kabi modullarga ega veb-ilova mavjud. Va negadir ulardan biri buziladi. Bu shunchaki biznes uchun va natijada ishlab chiquvchilar uchun zarba.
Monolitik dasturni masshtablash faqat bir xil turdagi boshqa dasturni ko'tarish orqali amalga oshirilishi mumkin. Ammo butun dasturni emas, balki faqat bitta komponentni o'lchashingiz kerak bo'lsa-chi. Qancha resurslar behuda ketadi?...
Bu dasturni ishlab chiqish va o'rnatish jarayoniga katta ta'sir ko'rsatishi mumkin. Ilova qanchalik katta bo'lsa, ishlab chiquvchilar dasturni kichikroq ishchi qismlarga bo'lishlari shunchalik muhim. Monolit ilovadagi barcha modullar bir-biriga ulanganligi sababli, ishlab chiquvchilar ushbu modullarni bir-biridan mustaqil ravishda ishlay olmaydi/o'rnatolmaydi. Ishlab chiquvchilar bir-biriga bog'liq bo'lganligi sababli, rivojlanish vaqti ortadi.
Shu bilan birga, biz mikroservislarning ma'nosini, ya'ni SOA uslubi bilan yo'qolgan moslashuvchanlikni tiklash uchun qanday foydalanish mumkinligini ko'rib chiqishga va tushunishga tayyormiz. God Microservices qutqarish uchun Har qanday arxitektura yechimining eng muhim xususiyatlaridan biri bu miqyoslilikdir. Men mikroservislarni birinchi marta o'rganayotganimda, hamma narsa "Mashq qilish san'ati" kitobidagi iqtiboslarga juda o'xshashligini ko'rdim. Bu ajoyib boshlanish va muhokama qilish uchun joy. Ushbu kitob uch o'lchovli masshtabli tizimni tavsiflovchi "Scalability Cube" deb nomlangan modelni belgilaydi:
Ko'rib turganingizdek, X o'qi "gorizontal masshtablash" ni tavsiflaydi (biz ko'rib turganimizdek, monolit arxitekturalar uchun ham mavjud), Y o'qi turli xil xizmat komponentlarini ajratish ma'nosida masshtabni ifodalaydi . Z o'qi g'oyasi ma'lumotlar bo'linganda va dastur ma'lumotlar joylashgan joyga so'rov yuborganda tushuniladi. Ya'ni, ularning hammasi bir joyda emas. Y o'qi g'oyasi biz batafsilroq to'xtalib o'tamiz. Ushbu eksa funktsional dekompozitsiyani ifodalaydi . Ushbu strategiyada turli funktsiyalarni mustaqil xizmatlar sifatida ko'rib chiqish mumkin. Shuning uchun, barcha dasturni faqat hamma narsa bajarilgandan keyingina o'rnatish orqali ishlab chiquvchilar alohida xizmatlarni bir-biridan mustaqil ravishda o'rnatishlari mumkin va boshqalar o'z modullari ustida ishlashni tugatishini kutmaydilar. Bu nafaqat ishlab chiqish vaqtini yaxshilaydi, balki dastur komponentlarining qolgan qismi haqida qayg'urmasdan o'zgartirish va qayta ulash uchun moslashuvchanlikni ham taklif qiladi. Keling, ushbu diagrammani oldingi monolit bilan taqqoslaylik:
Mikroservislar: Foyda Mikroservislarning afzalliklari Amazon, Netflix, Ebay kabi korporativ ishlab chiquvchilarni ushbu yondashuvdan foydalanishni boshlashga ishontirish uchun etarli. Monolitik arxitektura ilovalaridan farqli o'laroq, mikroservislar:
Komponentlarning ishdan chiqishini izolyatsiya qilishni yaxshilaydi: Katta ilovalar hatto bitta modul ishlamay qolsa ham samarali ishlashda davom etishi mumkin.
Ilovaning bitta texnologiya stekiga boʻlgan majburiyatini yoʻq qiladi: agar biron bir xizmatda yangi texnologiya stekini sinab koʻrmoqchi boʻlsangiz, davom eting. Bog'liqlar monolitga qaraganda ancha engilroq bo'ladi va hamma narsani orqaga qaytarish ham osonroq bo'ladi. Bitta dasturda kod qancha kam bo'lsa, ishlash shunchalik oson bo'ladi.
Yangi xodimlarga xizmatning funksionalligini tushunishni ancha osonlashtiradi.
Mikroservislar: o'rnatish va virtualizatsiya xususiyatlari Endi biz mikroservislar nima ekanligini tushunamiz. Va eng katta afzalligi shundaki, u bir nechta WAR/EAR/JAR arxivlari tomonidan o'rnatilgan. Lekin u qanday o'rnatiladi? Mikroservislarni konteyner ichiga o'rnatishning eng yaxshi usuli. Konteyner - bu to'liq konfiguratsiya qilingan virtual operatsion tizim bo'lib, kerakli muhit sozlangan bo'lib, u konteyner o'rnatilgan apparat tizimining resurslariga kirishni izolyatsiya qilishga yordam beradi. Bozordagi eng mashhur yechim, albatta, Docker . AWS kabi IaaS (xizmat sifatida infratuzilma) virtual mashinalari ham mikroservislarni o'rnatish uchun yaxshi ishlashi mumkin, ammo nisbatan engil mikroservislar virtual mashinadagi barcha resurslardan foydalanmasligi mumkin, bu esa foydalanish rentabelligini kamaytirishi mumkin. OSGI (Open Service Gateway Initiative) paketi yordamida mikroxizmatlaringizni ham oʻrnatishingiz mumkin . Bunday holda, barcha mikroservislar bitta JVMda ishlaydi, ammo bu nazorat va izolyatsiya o'rtasidagi kelishuv masalalarini o'z ichiga oladi. Mikroservislar: Kamchiliklar "Bularning barchasi ajoyib" va "biz buni ilgari ko'rmaganmiz" degani, hech qanday kamchiliklar yo'q degani emas. Quyida mikroservis arxitekturasi olib keladigan og'riqning mumkin bo'lgan sohalari ro'yxati keltirilgan:
Tarqalgan tizimlarni ishlab chiqish qiyin bo'lishi mumkin. Bu bilan men barcha komponentlar endi mustaqil xizmatlar ekanligini nazarda tutyapman - modullar o'rtasida o'tadigan so'rovlarni juda ehtiyotkorlik bilan bajarishingiz kerak. Bitta modul javob bermayotgan, tizimni buzmaslik uchun qo'shimcha kod yozishga majbur qiladigan stsenariy bo'lishi mumkin. Masofaviy qo'ng'iroqlar kechikishga sezgir bo'lsa, bu qiyinroq bo'lishi mumkin .
Bir nechta ma'lumotlar bazalari va tranzaktsiyalarni boshqarish haqiqiy og'riq bo'lishi mumkin.
mikroservis ilovalarini sinovdan o'tkazish mashaqqatli bo'lishi mumkin. Monolit dasturdan foydalanib, biz faqat serverda WAR/EAR/JAR arxivini ishga tushirishimiz va uning ma'lumotlar bazasiga ulanganligiga ishonch hosil qilishimiz kerak. Mikroservislarda esa har bir alohida xizmat test boshlanishidan oldin ishga tushirilishi kerak.
Ilovalarni o'rnatish qiyin bo'lishi mumkin. Ular Urush konteyneri kabi o'rnatish oson bo'lmagan bir nechta xizmatlar atrofida muvofiqlashtirishni talab qilishi mumkin.
.... Albatta, to'g'ri vositalar va yondashuvlar bilan bu kamchiliklarning oldini olish mumkin. Ammo ularning o'zlari yordamga muhtoj va barcha muammolarni to'liq hal qila olmaydi. Maqola CloudAcademy veb-saytidan tarjima qilingan . Bepul tarjima. Izohlarda har kim o'z fikrlarini bildirishi mumkin. Ular, albatta, o'qiladi. Asl maqola Mening Github hisobim
GO TO FULL VERSION