Mikroservislar (Microservices) arxitekturasi deb dasturni kichik-kichik mustaqil komponentlar asosida tashkil etishga aytiladi.
Mikroservislarni batafsil tushuntirishdan oldin, dastlab biz dasturlarni ishlab chiqish evolyutsiyasi, qanday qilib mikroservislarga zaruriyat hosil bo’lgani haqida to’xtalamiz.
2000-yillar boshlarini qarasak, dasturlar yaxlit, bir butun bo’lib, frontend va backend bitta loyiha ichida aralashib ketgan. Tabiiyki, o’shanda dasturchi frontend va backend’ga ajratib o’tirilmagan. Hozirgi til bilan aytganda full-stack dasturchilar bo’lishgan. 2000-yillar o’rtalaridan boshlab, CMSlar (kontent menejment tizimlari) ommalasha borgan. WordPress, Drupal, Magento dasturlashda keng qo’llanila boshlangan. Ushbu davrdagi dasturlarni monolit – bir butun loyiha deb ataladi.
Monolit dasturlarni ishlab chiqishda va rivojlantirib borishda asosiy kamchilik – tizimdagi bir xatolik dastur ishini to’xtatib qo’yishi mumkin. Shuningdek, o’zgarishlarni production’ga chiqarishda (deployment) bitta kichkina o’zgarish uchun butun tizimni qaytadan deploy qilish kerak bo’lardi.
2010-yillar boshlaridan, dasturlash frontend va backend qismlarga ajraldi. Single page application’lar paydo bo’la boshladi. Frontend qismi alohida dastur bo’lib, backend qismi API orqali ma’lumot yetkazib beradigan bo’ldi.
Endi monolit dasturdagi kamchiliklar backend’ga ko’chdi. API bazasi kattalashib keta boshladi va backend qismida qilinadigan xatolikning badali ortib ketdi. Shu sabab, backend’ni bir necha mustaqil qismlarga bo’lish zaruriyati tug’ildi. Shu tariqa mikroservislar arxitekturasi paydo bo’ldi.
Mikroservislar arxitekturasining afzalliklari
Katta loyihalarni bir biridan mustaqil kichik servislarga bo’lib yuborishning asosiy afzalligi – bir servis bitta yoki bir necha dasturchilar jamoasi tarafdan ishlab chiqiladi. Ularning ishi umumiy tizimga ta’sir ko’rsatmaydi.
Bitta servisda uchraydigan xato faqat o’sha servisning ishini to’xtatib qo’yishi mumkin.
Servislar qo’llab-quvvatlash uchun ham oson, o’zgarishlarni production’ga qo’shish uchun faqat servisning o’zini deploy qilinadi. Shuningdek, umumiy tizim uchun reliz chiqarishni kutib o’tirmasdan, o’zgarishlarni davomli qo’shib borish imkoni bor.
Yana bir eng katta afzalliklardan biri – servisni ishlab chiqish uchun dasturlash texnologiyasini tanlash imkoni bor. Baribir yakunda servis yagona standartdagi (JSON) API orqali xizmat ko’rsatadi. Masalan bir servis Nodejs’da ishlasa, boshqasi Python’da, yana biri Java’da dasturlanadi. Umuman, servisning qiladigan ishiga qarab ham dasturlash texnologiyasini tanlash imkoni bor.
Mikroservislar sabab, umumiy tizim biror dasturlash tiliga bog’liq bo’lib qolmaydi. Demak, jamoaga dasturchilar qo’shilganda ular sharoitga qarab, o’zlari biladigan dasturlash texnologiyasida ishlayverishadi.
Risklarning katta emasligi o’z-o’zidan yangi chiqayotgan texnologiyalarni loyihada sinab ko’rishga imkon beradi.
Qanday qilib monolit loyiha mikroservislarga o’tkaziladi?
Bu savolga aniq instruksiya qilib javob berish imkonsiz, barchasi loyiha qanday dasturlanganiga bog’liq. Agar dasturda frontend va backend ajratilmagan bo’lsa, dastlab uni ajratishdan boshlash kerak bo’ladi.
Backend alohida ishlaydigan bo’lsa, uni mantiqiy bir necha qismlarga bo’lishni reja qilinadi. Qismlar keyin mikroservislar sifatida paydo bo’ladi. Masalan onlayn do’kon misolida qismlar:
- Mahsulotlar katalogini boshqarish
- Omborni boshqarish
- Buyurtmalar
- Yetkazib berish
- Foydalanuvchilar
- Mahsulotlarni tavsiya qilish
Qismlar mikroservislar sifatida yasaladi. Agar loyihada API ishlab turgan bo’lsa, mikroservislarni ishlab chiqish katta qiyinchilik tug’dirmasa kerak. Chunki frontendga API’dan keladigan ma’lumotlar strukturasi o’zgarmaydi. Mikroservislar yasalib bo’lingach, ideal holatda frontenddagi o’zgarish faqat API URL’larini o’zgartirish bo’ladi.
Servislarni ishlab chiqishda va ularning baza bilan aloqasida bir muhim jihatni e’tiborga olish kerak:
Bir turdagi ma’lumot ustida amallarni faqat bir servis ishlashi zarur.
Masalan foydalanuvchi ma’lumotlarini bazaga yozish/o’qish uchun faqat «foydalanuvchilar» mikroservisi ishlasin, boshqa mikroservisda foydalanuvchi ma’lumotlarini o’zgartirishi kerak bo’lganda u bazaga murojaat qilmasin, «foydalanuvchilar» servisiga murojaat qilsin. Bu tizim kattalashganda ham baza ustidan nazoratni saqlashning imkonini beradi.
Bir OS’da birnecha mikroservislar
Bu model osonroq va loyiha yagona dasturlash tilida, yagona dasturlash tili versiyasida yozilgan bo’lsa qulay. Oddiyroq tushuntirganda, lokal serverda yoki hostingda, bir operatsion tizim ichida har bir mikroservis o’z portida ishlayveradi.
Kamchiligi
- servislarning imkoniyatlarini cheklab qo’yadi. Masalan bir hostingdagi barcha Java’da yozilgan servislar bir xil Java versiyasini ishlatishi kerak.
- mikroservislar ko’payib borgani sari, ular orasida texnik-konfliktlar chiqishni boshlaydi.
Bir mikroservis uchun bir OS
Bir OSdagi mikroservislardagi kamchilik sababli, bir mikroservis uchun bir OS modeli afzal ko’riladi. Ushbu modelda servis ko’proq izolyatsiyalangan bo’ladi, OSni servis uchun moslash imkoni beriladi.
Albatta har bir mikroservis uchun kompyuterda yoki hostingda alohida OS o’rnatilmaydi. Eng keng tarqalgan ko’rinishi – Docker, mikroservislarni konteynerlarda saqlab, har bir konteynerda OS o’rnatiladi.
* * *
Maqolada ko’pgina yangi terminlardan foydalanildi, shu sababli tushunarsiz qismlarida terminlarni google’dan qidirib batafsil ma’lumot topishingiz mumkin.