Salom, Xabr! E'tiboringizga taqdim etaman maqolaning muallif tarjimasi .
IT olami asta-sekin Kubernetes kabi mikroservislar va vositalarga o'tayotgan bir paytda, faqat bitta muammo tobora ko'proq e'tiborga olinmoqda. Bu muammo - mikroservis versiyalari. Shunday bo'lsa-da, IT hamjamiyati hozirgi vaziyat ancha yaxshi deb hisoblaydi oldingi avlod texnologiyalari. Biroq, mikroservislarning versiyalarini yaratish juda murakkab muammodir. Bunga bir dalil kabi maqolalar bo'lishi mumkin .
Agar siz ushbu matnni o'qib, muammoni hali ham tushunmasangiz, menga tushuntirib bering. Aytaylik, mahsulotingiz 10 ta mikroservisdan iborat. Keling, ushbu mikroservislarning har biri uchun 1 ta yangi versiya chiqarilgan deb faraz qilaylik. Faqat 1 ta versiya - Umid qilamanki, bu juda arzimas va ahamiyatsiz fakt ekanligiga barchamiz rozi bo'lamiz. Biroq, keling, mahsulotimizni yana bir bor ko'rib chiqaylik. Har bir komponentning atigi bitta yangi versiyasi bilan bizda mahsulotimiz qanday tuzilishi mumkinligi haqida 2^10 yoki 1024 ta almashtirish mavjud.
Agar hali ham tushunmovchilik bo'lsa, matematikani buzishga ijozat bering. Shunday qilib, bizda 10 ta mikroservis bor, ularning har biri bitta yangilanishni oladi. Ya'ni, biz har bir mikroservis uchun 2 ta mumkin bo'lgan versiyani olamiz (eski yoki yangi). Endi mahsulot komponentlarining har biri uchun biz ushbu ikkita versiyadan birini ishlatishimiz mumkin. Matematik jihatdan bu xuddi bizda 10 ta raqamli ikkilik raqamga ega bo'lganimiz bilan bir xil. Misol uchun, 1 yangi versiya, 0 esa eski versiya deylik - keyin bitta mumkin bo'lgan almashtirish 1001000000 sifatida belgilanishi mumkin - bu erda 1 va 4 komponentlar yangilanadi, qolganlari esa yangilanmaydi. Matematikadan bilamizki, 10 xonali ikkilik son 2^10 yoki 1024 qiymatga ega bo'lishi mumkin. Ya'ni, biz shug'ullanayotgan raqamning ko'lamini tasdiqladik.
Keling, fikrimizni davom ettiramiz - agar bizda 100 ta mikroservis bo'lsa va har birida 10 ta mumkin bo'lgan versiya bo'lsa, nima bo'ladi? Vaziyat juda yoqimsiz bo'lib qoladi - endi bizda 10 ^ 100 almashtirish mavjud - bu juda katta raqam. Biroq, men bu vaziyatni shunday belgilashni ma'qul ko'raman, chunki endi biz "kubernetes" kabi so'zlar orqasiga yashiringanimiz yo'q, balki muammoga qanday bo'lsa, shunday qaraymiz.
Nega bu muammo meni hayratda qoldirdi? Qisman, chunki ilgari NLP va AI dunyosida ishlaganimiz sababli, biz 5-6 yil oldin kombinatsion portlash muammosini ko'p muhokama qilganmiz. Faqat versiyalar o'rniga bizda individual so'zlar, mahsulotlar o'rniga esa jumlalar va paragraflar mavjud edi. Garchi NLP va AI muammolari hal qilinmagan bo'lsa-da, so'nggi bir necha yil ichida sezilarli yutuqlarga erishilganligini tan olish kerak. (Menimcha, taraqqiyotga erishish mumkinоSohadagi odamlar mashinani o'rganishga va boshqa texnikalarga biroz ko'proq e'tibor berishsa yaxshi bo'lardi - lekin bu allaqachon mavzudan tashqarida).
Keling, DevOps va mikroservislar dunyosiga qaytaylik. Biz Kunstkamerada fil qiyofasida bo'lgan juda katta muammoga duch keldik - chunki men tez-tez eshitadigan narsa: "shunchaki kubernet va rulni oling, shunda hammasi yaxshi bo'ladi!" Ammo yo'q, agar hamma narsa avvalgidek qolsa, hammasi yaxshi bo'lmaydi. Bundan tashqari, ushbu muammoning analitik yechimi uning murakkabligi tufayli qabul qilinishi mumkin emas. NLP-da bo'lgani kabi, biz birinchi navbatda qidiruv doirasini qisqartirish orqali bu muammoga murojaat qilishimiz kerak - bu holda, eskirgan almashtirishlarni yo'q qilish.
Yordam berishi mumkin bo'lgan narsalardan biri bu o'tgan yili yozgan narsam . Shuni ham ta'kidlash kerakki, yaxshi ishlab chiqilgan CI/CD jarayoni o'zgaruvchanlikni kamaytirishga katta yordam beradi. Biroq, CI/CD bilan ishlarning hozirgi holati komponentlarni hisobga olish va kuzatish uchun qo'shimcha vositalarsiz almashtirish muammosini hal qilish uchun etarli emas.
Bizga integratsiya bosqichidagi eksperimentlar tizimi kerak bo'lib, unda biz har bir komponent uchun xavf omilini aniqlashimiz mumkin, shuningdek, turli komponentlarni yangilash va operator aralashuvisiz sinovdan o'tkazish uchun avtomatlashtirilgan jarayonga ega bo'lamiz - nima ishlayotganini va nima ishlamasligini ko'rish uchun.
Bunday tajribalar tizimi quyidagicha ko'rinishi mumkin:
- Ishlab chiquvchilar testlarni yozadilar (bu juda muhim bosqich - chunki aks holda bizda baholash mezonlari yo'q - bu mashinani o'rganishda ma'lumotlarni belgilashga o'xshaydi).
- Har bir komponent (loyiha) o'zining CI tizimini oladi - bu jarayon hozirda yaxshi ishlab chiqilgan va bitta komponent uchun CI tizimini yaratish masalasi asosan hal qilingan.
- "Aqlli integratsiya tizimi" turli xil CI tizimlarining natijalarini to'playdi va yakuniy mahsulotga komponent loyihalarini yig'adi, sinovlarni o'tkazadi va nihoyat mavjud komponentlar va xavf omillari asosida kerakli mahsulot funksionalligini olishning eng qisqa yo'lini hisoblab chiqadi. Agar yangilash imkoni bo'lmasa, ushbu tizim ishlab chiquvchilarni mavjud komponentlar va ulardan qaysi biri xatoga sabab bo'layotgani haqida xabar beradi. Yana bir bor, test tizimi bu erda juda muhim ahamiyatga ega - chunki integratsiya tizimi testlardan baholash mezoni sifatida foydalanadi.
- CD tizimi, keyin Smart Integration Systemdan ma'lumotlarni oladi va yangilashni to'g'ridan-to'g'ri amalga oshiradi. Ushbu bosqich tsiklni tugatadi.
Xulosa qilib aytadigan bo'lsak, men uchun hozir eng katta muammolardan biri bu turli komponentlarni mahsulotga bog'laydigan va shu tariqa butun mahsulot qanday yig'ilganligini kuzatish imkonini beradigan bunday "Aqlli integratsiya tizimi"ning yo'qligi. Jamiyatning bu boradagi fikrlari bilan qiziqaman (spoiler - hozir loyiha ustida ishlayapman , bu shunday aqlli integratsiya tizimiga aylanishi mumkin).
Men eslatib o'tmoqchi bo'lgan oxirgi narsa shundaki, men uchun monolit hatto o'rta o'lchamdagi har qanday loyiha uchun ham qabul qilinishi mumkin emas. Men uchun monolitga qaytish orqali amalga oshirish vaqtini va rivojlanish sifatini tezlashtirishga urinishlar katta shubha tug'diradi. Birinchidan, monolit tarkibiy qismlarni boshqarishning o'xshash muammosiga ega - u o'z ichiga olgan turli kutubxonalar orasida, ammo bularning barchasi unchalik sezilmaydi va birinchi navbatda ishlab chiquvchilar tomonidan sarflangan vaqtda namoyon bo'ladi. Monolit muammosining oqibati kodga o'zgartirish kiritishning virtual mumkin emasligi va rivojlanish tezligining juda sekinligidir.
Mikroservislar vaziyatni yaxshilaydi, ammo keyin mikroservis arxitekturasi integratsiya bosqichida kombinatsion portlash muammosiga duch keladi. Ha, umuman olganda, biz bir xil muammoni rivojlanish bosqichidan integratsiya bosqichiga o'tkazdik. Biroq, mening fikrimcha, mikroservislar yondashuvi hali ham yaxshi natijalarga olib keladi va jamoalar natijalarga tezroq erishadilar (ehtimol, asosan ishlab chiqish birligi hajmining qisqarishi tufayli - yoki partiya hajmi). Biroq, monolitdan mikroservislarga o‘tish jarayonni hali yetarli darajada takomillashtirgani yo‘q – mikroservis versiyalarining kombinatsion portlashi juda katta muammo bo‘lib, biz uni hal qilishda vaziyatni yaxshilash uchun katta imkoniyatlarga egamiz.
Manba: www.habr.com
