Monolitlar va mikroservislar ilovalarni yaratishda ikkita asosiy yondashuvdir. Ba'zi odamlar ularni mos ravishda meros va zamonaviy deb hisoblashadi. Lekin bu unchalik to'g'ri emas. Ulardan birini tanlash juda murakkab savol bo'lib, ularning ijobiy va salbiy tomonlari bor.
Aksariyat yangi ilovalar boshidanoq mikroservis bo'lishi shart emas. Monolit sifatida boshlash tezroq, osonroq va arzonroq, agar foydali bo'lsa, keyinroq mikroservislarga o'tish.
Vaqt o'tishi bilan, monolit ilovalar kamroq va kamroq texnik xizmat ko'rsatish imkoniyatiga ega bo'lib, ba'zi jamoalar muammoni hal qilishning yagona yo'li ularning ilovalarini mikroservislarga bo'lish orqali qayta ishlashni boshlash deb qaror qilishadi. Boshqa jamoalar bu qarorni faqat "mikroservislar ajoyib" deb qabul qilishadi. Bu jarayon juda ko'p vaqtni oladi va ba'zida undan ham ko'proq texnik xarajatlarni talab qiladi. Bunga kirishdan oldin, barcha ijobiy va salbiy tomonlarini diqqat bilan ko'rib chiqish va hozirgi monolit arxitektura chegaralariga erishganingizga ishonch hosil qilish juda muhimdir. Va unutmangki, qurishdan ko'ra sindirish osonroq.
Ushbu maqolada biz monolitlarni mikroservislar bilan solishtirmoqchi emasmiz. Buning o'rniga, biz sizga yordam beradigan fikrlar, naqshlar va tamoyillarni muhokama qilamiz:
Siz qilishingiz kerak bo'lgan birinchi narsa - loyihangizning tuzilishiga qarash. Agar sizda modullar bo'lmasa, ularni ko'rib chiqishingizni tavsiya qilaman. Ular sizni arxitekturangizni mikroservislarga o'zgartirishga majbur qilmaydi (bu yaxshi, chunki biz barcha tegishli texnik xizmat ko'rsatishdan qochishni xohlaymiz), lekin ulardan ko'p afzalliklarni oladi.
Loyihangizni avtomatlashtirish vositasiga (masalan, maven, gradle yoki boshqa) qarab, siz loyihangizni alohida, mustaqil modullarga bo'lishingiz mumkin. Ba'zi modullar boshqalar uchun umumiy bo'lishi mumkin, boshqalari esa ma'lum domen hududlarini qamrab olishi yoki ilovangizga mustaqil funksionallikni olib keladigan xususiyatga xos bo'lishi mumkin.
Bu sizga quyidagi afzalliklarni beradi:
Ko'rib turganingizdek, modulli monolit har ikki dunyodan ham eng yaxshisini olishning yo'lidir. Bu bitta monolit ichida mustaqil mikroservislarni ishga tushirishga o'xshaydi, lekin garov mikroxizmatlarini qo'shimcha xarajatlardan qochadi. Sizda bo'lishi mumkin bo'lgan cheklovlardan biri bu turli modullarni mustaqil ravishda kengaytira olmaslikdir. Sizda eng ko'p yuklangan modul talab qiladigan darajada ko'p monolit nusxaga ega bo'lasiz, bu esa ortiqcha resurs sarflanishiga olib kelishi mumkin. Yana bir kamchilik - turli texnologiyalardan foydalanish cheklovlari. Masalan, siz Java, Golang va Python-ni modulli monolitda aralashtira olmaysiz, shuning uchun siz bitta texnologiyaga yopishib olishga majbur bo'lasiz (odatda bu muammo emas).
Strangler Fig naqshini o'ylab ko'ring. U o'z nomini o'ralgan va oxir-oqibat uy egasining o'rnini bosadigan daraxtdan oladi. Xuddi shunday, naqsh eski dastur qismlarini yangi xizmatlar bilan birma-bir almashtirishni, eski tizimni sezilarli uzilishlarga olib kelmasdan modernizatsiya qilishni taklif qiladi.
Xavfli, birdaniga ta'mirlash o'rniga, siz tizimni parcha-parcha yangilaysiz. Bu usul katta, murakkab monolitlar bilan ishlashda foydali bo'ladi, ularni bir harakat bilan almashtirish juda qiyin. Strangler Fig naqshini qo'llash orqali jamoalar asta-sekin eski tizimdan voz kechishlari mumkin, shu bilan birga yangi tizimning o'sishini rag'batlantirish, xavflarni minimallashtirish va doimiy qiymat yetkazib berishni ta'minlash.
Strangler Fig naqshini amalga oshirish uchun siz uchta qadamni bajarishingiz kerak:
Ushbu uchta qadamni bajarib, siz asta-sekin monolitni mikroservislarga aylantirasiz.
Strangler Fig naqshidan foydalanishning asosiy afzalliklari quyidagilardan iborat:
Strangler Fig naqshini qo'llaganingizda, migratsiya strategiyasini diqqat bilan rejalashtirishingiz kerak. Bu birinchi navbatda qaysi komponentlarni almashtirishni aniqlash, eski va yangi qismlar o'rtasida to'g'ri integratsiyani ta'minlash va izchil ma'lumotlar modellarini saqlashni o'z ichiga oladi. Jamoalar, shuningdek, har bir almashtirishning borishi va ta'sirini kuzatish uchun aniq aloqa kanallari va monitoring tizimlarini yaratishi kerak.
Yuqorida aytib o'tganimizdek, mikroservislarga o'tish foyda keltiradi. Biroq, u boshqa ko'plab narsalarni qiyinlashtiradi va qimmatroq qiladi.
Masalan, QA va Dev guruhlari mahalliy mashinalarda endi sinovdan o'tkaza olmaydigan vaziyatga duch kelishlari mumkin, chunki mahalliy darajada bir nechta mikroservislarni ishga tushirish imkoniyati cheklangan. Yoki sizning jurnallaringiz unchalik tushunarsiz bo'lib qolishi mumkin, chunki bitta xizmat bitta oqimni qayta ishlash o'rniga, bir nechta xizmatlar uni hozir qayta ishlaydi. Natijada, to'liq jurnallar ketma-ketligini ko'rish uchun siz tegishli asbob-uskunalar va kuzatuvni amalga oshirishingiz kerak.
Keling, siz ko'rib chiqishingiz kerak bo'lgan bir nechta muhim jihatlarni muhokama qilaylik va mikroservislaringizni o'zgartirishni boshlashdan oldin rejalashtirishingiz mumkin.
Monolit va mikroservislar turli minimal infratuzilma talablariga ega.
Monolit ilovasini ishga tushirishda siz odatda oddiyroq infratuzilmani saqlab qolishingiz mumkin. Virtual mashinalar yoki PaaS yechimlari (masalan, AWS EC2) kabi variantlar kifoya qiladi. Bundan tashqari, siz o'lchov, konfiguratsiya, yangilash va monitoringning ko'p qismini qo'lda yoki oddiy vositalar yordamida boshqarishingiz mumkin. Natijada, siz murakkab infratuzilma sozlamalaridan qochishingiz va DevOps bo'yicha keng ko'lamli tajribani talab qilmasdan ishlab chiquvchilar yoki yordamchi muhandislarga tayanishingiz mumkin.
Biroq, mikroservislar arxitekturasini qabul qilish bu dinamikani o'zgartiradi. Xizmatlar soni ortib borayotganligi sababli, qo'lda, amaliy yondashuv tezda amaliy bo'lmaydi. Bir nechta xizmatlarni samarali tartibga solish, masshtablash va boshqarish uchun sizga Kubernetes kabi maxsus platformalar yoki hech bo‘lmaganda yangi murakkablik va operatsion talablarni joriy qiluvchi boshqariladigan konteyner xizmati kerak bo‘ladi.
Monolit ilovasini saqlash nisbatan oddiy. Agar CVE paydo bo'lsa, siz ta'sirlangan bog'liqlikni bir joyda yangilaysiz. Tashqi xizmat aloqasini standartlashtirish kerakmi? Bitta o'ramni amalga oshiring va uni butun kod bazasida qayta ishlating.
Mikroservislar muhitida bu oddiy vazifalar ancha murakkablashadi. Ilgari ahamiyatsiz bo'lgan narsa endi bir nechta mustaqil xizmatlar bo'yicha o'zgarishlarni muvofiqlashtirishni o'z ichiga oladi, ularning har biri o'z hayot aylanishi va bog'liqliklari bilan. Qo'shimcha murakkablik vaqt va resurslarda xarajatlarni oshiradi. Va agar sizda ko'plab jamoalar va turli xil xizmatlar mavjud bo'lsa, vaziyat yomonlashadi.
Shu sababli, ko'plab tashkilotlar odatda platforma jamoasi tomonidan boshqariladigan maxsus platforma qatlamini joriy qiladi. Maqsad - barcha mikroservislar meros bo'lishi mumkin bo'lgan poydevor yaratish: umumiy bog'liqliklarni boshqarish, standartlashtirilgan naqshlarni amalga oshirish va tayyor o'ramlarni taqdim etish. Ushbu elementlarni platforma darajasida birlashtirib, siz texnik xizmat ko'rsatishni sezilarli darajada soddalashtirasiz va butun tizim bo'ylab izchillikni ta'minlaysiz.
Monolitni mikroservislarga ajratish jiddiy arxitektura o'zgarishi bo'lib, ehtiyotkorlik bilan ko'rib chiqish va rejalashtirishni talab qiladi.
Ushbu maqolada biz unga tayyorgarlik ko'rish va jarayonni muammosiz bajarish uchun qanday qadamlar qo'yishingiz mumkinligini muhokama qildik. Strangler Fig naqshiga rioya qilish sizni bosqichma-bosqich jarayon bilan ta'minlaydi va butun transformatsiya davomida tizim barqarorligini ta'minlaydi. Bundan tashqari, modulli monolit nafaqat foydali tayyorgarlik bosqichi bo'lishi mumkin, balki sizni mikroservisni o'zgartirish qarorini qayta ko'rib chiqishga va tegishli operatsion murakkablikdan qochishga undashi mumkin bo'lgan foyda keltirishi mumkin.