Сәлем, Хабр! назарларыңызға ұсынамын мақаланың авторлық аудармасы .
АТ әлемі бірте-бірте Kubernetes сияқты микросервистерге және құралдарға қарай жылжып жатқан уақытта, тек бір мәселе барған сайын байқалады. Бұл мәселе- микросервис нұсқалары. Десе де, IT қауымдастығы қазіргі жағдай бұрынғыдан әлдеқайда жақсы деп санайды технологиялардың алдыңғы буыны. Дегенмен, микросервистерді нұсқалау өте күрделі мәселе. Осының бір дәлелі сияқты мақалалар болуы мүмкін .
Егер сіз осы мәтінді оқу арқылы мәселені әлі де түсінбесеңіз, түсіндіруге рұқсат етіңіз. Сіздің өніміңіз 10 микросервистен тұрады делік. Енді осы микросервистердің әрқайсысы үшін 1 жаңа нұсқа шығарылды делік. Тек 1 нұсқа – бұл өте тривиальды және елеусіз факт екенін бәріміз келісе аламыз деп үміттенемін. Алайда, енді біздің өнімге тағы бір назар аударайық. Әрбір құрамдастың бір ғана жаңа нұсқасы арқылы бізде өніміміздің қалай құрастырылатыны туралы 2^10 немесе 1024 ауыстыру бар.
Егер әлі де түсінбеушілік болса, математиканы бөлуге рұқсат етіңіз. Сонымен, бізде әрқайсысы бір жаңартуды алатын 10 микросервис бар. Яғни, біз әрбір микросервис үшін 2 ықтимал нұсқаны аламыз (ескі немесе жаңа). Енді өнім құрамдастарының әрқайсысы үшін біз осы екі нұсқаның кез келгенін пайдалана аламыз. Математикалық тұрғыдан бұл бізде 10 таңбалы екілік сан болғанмен бірдей. Мысалы, 1 - жаңа нұсқа, ал 0 - ескі нұсқа делік - онда бір ықтимал ауыстыруды 1001000000 деп белгілеуге болады - мұнда 1-ші және 4-ші компоненттер жаңартылады, ал қалғандары жаңартылмайды. Математикадан біз 10 таңбалы екілік санның 2^10 немесе 1024 мәні болуы мүмкін екенін білеміз. Яғни, біз айналысатын санның ауқымын растадық.
Әрі қарай ойымызды жалғастырайық - егер бізде 100 микросервис болса және әрқайсысында 10 ықтимал нұсқа болса, не болады? Бүкіл жағдай өте жағымсыз болады - бізде қазір 10 ^ 100 ауыстыру бар - бұл үлкен сан. Дегенмен, мен бұл жағдайды осылай белгілеуді жөн көрдім, өйткені қазір біз «кубернетес» сияқты сөздердің артына жасырынып емеспіз, керісінше, проблемаға тап боламыз.
Неліктен мені бұл мәселе қызықтырды? Ішінара себебі, бұрын NLP және AI әлемінде жұмыс істегендіктен, біз комбинаторлық жарылыс мәселесін шамамен 5-6 жыл бұрын талқылаған болатынбыз. Тек нұсқалардың орнына жеке сөздер, ал туындылардың орнына сөйлемдер мен абзацтар болды. NLP және AI мәселелері негізінен шешілмеген болса да, соңғы бірнеше жылда айтарлықтай прогреске қол жеткізілгенін мойындау керек. (менің ойымша, прогресс болуы мүмкіноСаладағы адамдар машинаны оқытуға аздап, басқа әдістерге көбірек көңіл бөлсе жақсы болар еді - бірақ бұл қазірдің өзінде тақырыптан тыс).
DevOps және микросервис әлеміне оралайық. Біз Кунсткамерада пілге ұқсайтын үлкен мәселеге тап болдық, өйткені мен жиі еститінім «кубернет пен рульді алыңыз, сонда бәрі жақсы болады!» Бірақ жоқ, егер бәрі бұрынғыдай қалса, бәрі жақсы болмайды. Оның үстіне бұл мәселенің аналитикалық шешімі оның күрделілігіне байланысты қабылданбайды. NLP-дегі сияқты, біз бұл мәселеге алдымен іздеу ауқымын тарылту арқылы жақындауымыз керек - бұл жағдайда ескірген ауыстыруларды жою арқылы.
Көмектесетін нәрселердің бірі - өткен жылы жазған нәрсем . Жақсы жобаланған CI/CD процесі вариацияларды азайтуға көп көмектесетінін атап өту маңызды. Дегенмен, CI/CD-мен жұмыстың ағымдағы жағдайы құрамдастарды есепке алу және қадағалау үшін қосымша құралдарсыз ауыстыру мәселесін шешу үшін жеткілікті жақсы емес.
Бізге интеграциялық кезеңдегі эксперименттер жүйесі қажет, онда біз әрбір құрамдас үшін қауіп факторын анықтай аламыз, сонымен қатар әртүрлі компоненттерді жаңартудың автоматтандырылған процесі және оператордың араласуынсыз тестілеу - ненің жұмыс істейтінін және не істемейтінін көру үшін.
Мұндай эксперименттер жүйесі келесідей болуы мүмкін:
- Әзірлеушілер сынақтар жазады (бұл маңызды кезең - өйткені бізде бағалау критерийі жоқ - бұл машиналық оқытудағы деректерді таңбалау сияқты).
- Әрбір компонент (жоба) өзінің CI жүйесін алады - бұл процесс қазір жақсы дамыған және бір компонент үшін CI жүйесін құру мәселесі негізінен шешілді.
- «Ақылды интеграция жүйесі» әртүрлі CI жүйелерінің нәтижелерін жинайды және құрамдас жобаларды түпкілікті өнімге жинайды, тестілеуді жүргізеді және ең соңында бар құрамдас бөліктер мен қауіп факторлары негізінде қажетті өнім функционалдығын алудың ең қысқа жолын есептейді. Жаңарту мүмкін болмаса, бұл жүйе әзірлеушілерге бар құрамдас бөліктер және олардың қайсысы қатені тудыратыны туралы хабарлайды. Бұл жерде тағы да тест жүйесі өте маңызды, өйткені интеграциялық жүйе тесттерді бағалау критерийі ретінде пайдаланады.
- Смарт интеграция жүйесінен деректерді қабылдайтын және жаңартуды тікелей орындайтын CD жүйесі. Бұл кезең циклді аяқтайды.
Қорытындылай келе, мен үшін қазіргі кездегі ең үлкен проблемалардың бірі - әртүрлі компоненттерді өнімге байланыстыратын және осылайша тұтастай алғанда өнімнің қалай біріктірілгенін бақылауға мүмкіндік беретін мұндай «Ақылды интеграциялық жүйенің» болмауы. Мені бұл туралы қауымдастықтың ойлары қызықтырады (спойлер - мен қазір жобамен жұмыс істеп жатырмын. , ол осындай ақылды интеграциялық жүйеге айналуы мүмкін).
Тағы бір айта кететін жайт, мен үшін монолит тіпті орташа өлшемдегі кез келген жоба үшін жарамсыз. Мен үшін монолитке оралу арқылы іске асыру уақытын және даму сапасын жылдамдату әрекеттері үлкен күмән тудырады. Біріншіден, монолитте компоненттерді басқарудың ұқсас проблемасы бар - ол тұратын әртүрлі кітапханалар арасында, бірақ мұның бәрі соншалықты байқалмайды және ең алдымен әзірлеушілер жұмсаған уақытта көрінеді. Монолит мәселесінің салдары - кодқа өзгертулер енгізудің виртуалды мүмкін еместігі - және өте баяу даму жылдамдығы.
Микросервис жағдайды жақсартады, бірақ содан кейін микросервис архитектурасы біріктіру сатысында комбинаторлық жарылыс мәселесіне тап болады. Иә, жалпы, біз сол мәселені даму сатысынан интеграциялық кезеңге көшірдік. Дегенмен, менің ойымша, микросервистерге деген көзқарас әлі де жақсы нәтижелерге әкеледі, ал командалар нәтижелерге тезірек қол жеткізеді (мүмкін, негізінен әзірлеу бірлігінің көлемінің қысқаруына байланысты - немесе партия мөлшері). Дегенмен, монолиттен микросервистерге көшу процесті әлі жеткілікті түрде жетілдіре қойған жоқ - микросервис нұсқаларының комбинаторлық жарылысы үлкен мәселе болып табылады және біз оны шешу барысында жағдайды жақсартуға әлеуетіміз көп.
Ақпарат көзі: www.habr.com