Микросервис - комбинаторна експлозија на верзии

Здраво, Хабр! Ви го претставувам вашето внимание авторски превод на статијата Microservices – Комбинаторна експлозија на верзии.

Во време кога ИТ светот постепено се движи кон микросервисите и алатките како Кубернетес, само еден проблем станува се позабележлив. Овој проблем - комбинаторна експлозија верзии на микросервис. Сепак, ИТ заедницата верува дека сегашната ситуација е многу подобра од „Пекол на зависност“ претходната генерација на технологија. Сепак, верзиирањето на микросервисите е многу сложен проблем. Еден доказ за ова може да бидат написите како „Врати ми го монолитот“.

Ако сè уште не го разбирате проблемот со читањето на овој текст, дозволете ми да ви објаснам. Да речеме дека вашиот производ се состои од 10 микроуслуги. Сега да претпоставиме дека е пуштена 1 нова верзија за секоја од овие микроуслуги. Само 1 верзија - се надевам дека сите ќе се согласиме дека ова е многу тривијален и незначаен факт. Сега, сепак, да погледнеме уште еднаш на нашиот производ. Со само една нова верзија на секоја компонента, сега имаме 2^10 - или 1024 пермутации за тоа како може да се состави нашиот производ.

Ако сепак има некакво недоразбирање, да ја разбијам математиката. Значи, имаме 10 микросервиси, од кои секоја добива по едно ажурирање. Односно, добиваме 2 можни верзии за секој микросервис (било стара или нова). Сега, за секоја од компонентите на производот, можеме да користиме која било од овие две верзии. Математички е исто како да имаме бинарен број од 10 цифри. На пример, да речеме дека 1 е новата верзија, а 0 е старата верзија - тогаш една можна пермутација може да се означи како 1001000000 - каде што 1-та и 4-та компонента се ажурирани, а сите други не се. Од математиката знаеме дека 10-цифрен бинарен број може да има 2^10 или 1024 вредности. Односно, ја потврдивме скалата на бројката со која си имаме работа.

Ајде да продолжиме со нашето размислување понатаму - што ќе се случи ако имаме 100 микросервиси и секоја има 10 можни верзии? Целата ситуација станува прилично непријатна - сега имаме 10^100 пермутации - што е огромна бројка. Сепак, претпочитам да ја означам оваа ситуација на овој начин, бидејќи сега веќе не се криеме зад зборовите како „кубернети“, туку се соочуваме со проблемот таков каков што е.

Зошто сум толку фасциниран од овој проблем? Делумно затоа што, откако претходно работевме во светот на НЛП и вештачката интелигенција, многу разговаравме за проблемот со комбинаторната експлозија пред околу 5-6 години. Само наместо верзии имавме поединечни зборови, а наместо производи имавме реченици и параграфи. И иако проблемите на НЛП и вештачката интелигенција остануваат во голема мера нерешени, мора да се признае дека е постигнат значителен напредок во изминатите неколку години (според мое мислење, може да се постигне напредокоБи било подобро луѓето во индустријата да посветат малку помалку внимание на машинското учење и малку повеќе на другите техники - но ова е веќе надвор од темата).

Да се ​​вратиме во светот на DevOps и микросервисите. Се соочуваме со огромен проблем, маскиран во слон во Кунсткамера - затоа што она што често го слушам е „само земете кубернети и кормило, и се ќе биде во ред!“ Но не, нема да биде се во ред ако се остане како што е. Покрај тоа, аналитичкото решение на овој проблем не изгледа прифатливо поради неговата сложеност. Како и во НЛП, прво треба да му пристапиме на овој проблем со стеснување на опсегот на пребарување - во овој случај, со елиминирање на застарените пермутации.

Една од работите што може да помогне е нешто што го напишав минатата година за потребата да се одржи минимална разлика помеѓу верзиите објавени за клиенти. Исто така, важно е да се забележи дека добро дизајнираниот процес CI/CD во голема мера помага во намалувањето на варијациите. Сепак, моменталната состојба на работите со CI/CD не е доволно добра за да се реши проблемот со пермутациите без дополнителни алатки за сметководство и следење на компонентите.

Она што ни треба е систем на експериментирање во фазата на интеграција, каде што можеме да го одредиме факторот на ризик за секоја компонента, а исто така да имаме автоматизиран процес за ажурирање на различни компоненти и тестирање без интервенција на операторот - за да видиме што функционира, а што не.

Таквиот систем на експерименти може да изгледа вака:

1. Програмерите пишуваат тестови (ова е критична фаза - затоа што во спротивно немаме критериум за оценување - тоа е како етикетирање на податоци во машинското учење).
2. Секоја компонента (проект) добива свој CI систем - овој процес сега е добро развиен, а прашањето за создавање на CI систем за една компонента е во голема мера решено
3. „Системот за паметна интеграција“ ги собира резултатите од различни CI системи и ги составува компонентите проекти во финалниот производ, врши тестирање и конечно го пресметува најкраткиот пат до добивање на саканата функционалност на производот врз основа на постоечките компоненти и факторите на ризик. Ако ажурирањето не е можно, овој систем ги известува програмерите за постоечките компоненти и кои од нив ја предизвикуваат грешката. Уште еднаш, системот за тестирање е од клучно значење овде - бидејќи системот за интеграција користи тестови како критериум за оценување.
4. ЦД систем, кој потоа прима податоци од Smart Integration System и директно го извршува ажурирањето. Оваа фаза го завршува циклусот.

Да резимираме, за мене еден од најголемите проблеми сега е недостатокот на таков „Систем за паметна интеграција“ кој би ги поврзал различните компоненти во производот и на тој начин ќе ви овозможи да следите како производот како целина е склопен. Ќе ме интересираат размислувањата на заедницата за ова (спојлер - моментално работам на проект Релиза, кој може да стане таков паметен систем за интеграција).

Последно што сакам да напоменам е дека монолитот за мене не е прифатлив за ниту еден проект со средна големина. За мене, обидите да се забрза времето на имплементација и квалитетот на развојот со враќање во монолит предизвикуваат голем скептицизам. Прво, монолитот има сличен проблем со управувањето со компонентите - меѓу различните библиотеки од кои се состои, сепак, сето тоа не е толку забележливо и се манифестира првенствено во времето поминато од програмерите. Последица на проблемот со монолитот е виртуелната неможност да се направат промени во кодот - и екстремно бавната брзина на развој.

Микросервисите ја подобруваат ситуацијата, но тогаш микросервисната архитектура се соочува со проблемот на комбинаторна експлозија во фазата на интеграција. Да, генерално, истиот проблем го префрливме од фазата на развој во фазата на интеграција. Сепак, според мое мислење, пристапот на микросервис сè уште води до подобри резултати, а тимовите постигнуваат резултати побрзо (веројатно главно поради намалувањето на големината на развојната единица - или големина на серијата). Сепак, преминувањето од монолит кон микросервис сè уште не го подобри процесот доволно - комбинаторната експлозија на микросервисните верзии е огромен проблем и имаме голем потенцијал да ја подобриме ситуацијата додека ја решаваме.

Извор: www.habr.com