Салам, Хабр! назарыңыздарга сунуштайм макаланын автордук котормосу .
IT дүйнөсү акырындык менен 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 системасы, андан кийин Smart Integration Системинен маалыматтарды кабыл алып, жаңыртууну түздөн-түз аткарат. Бул этап циклди аяктайт.
Жыйынтыктап айтканда, мен үчүн азыр эң чоң көйгөйлөрдүн бири - бул ар кандай компоненттерди бир продуктка бириктире турган жана ошону менен бүтүндөй продукт кантип бириктирилгенин көзөмөлдөөгө мүмкүндүк берүүчү "Акылдуу интеграция тутумунун" жоктугу. Мен бул боюнча коомчулуктун ойлоруна кызыгам (спойлер - Мен азыр бир долбоордун үстүндө иштеп жатам , мындай акылдуу интеграция системасы болуп калышы мүмкүн).
Мен айткым келген акыркы нерсе, мен үчүн монолит орто өлчөмдөгү долбоор үчүн кабыл алынбайт. Мен үчүн монолитке кайтып, ишке ашыруунун убактысын жана сапатын тездетүү аракеттери чоң ишенбөөчүлүктөрдү жаратат. Биринчиден, монолитте компоненттерди башкаруу боюнча окшош көйгөй бар - ал турган ар кандай китепканалардын арасында, бирок мунун баары анча деле байкалбайт жана биринчи кезекте иштеп чыгуучулар өткөргөн убакытта көрүнөт. Монолит көйгөйүнүн натыйжасы - кодго өзгөртүүлөрдү киргизүүнүн виртуалдык мүмкүн эместиги - жана өтө жай өнүгүү ылдамдыгы.
Микросервистер кырдаалды жакшыртат, бирок андан кийин микросервис архитектурасы интеграция стадиясында комбинатордук жарылуу көйгөйүнө туш болот. Ооба, жалпысынан биз ошол эле маселени өнүгүү баскычынан интеграциялык баскычка өткөрдүк. Бирок, менин оюмча, микросервистердин мамилеси дагы эле жакшы натыйжаларга алып келет, ал эми командалар тезирээк натыйжаларга жетишет (балким, негизинен иштеп чыгуу бирдигинин көлөмүнүн кыскарышынан улам - же партия өлчөмү). Бирок, монолиттен микросервистерге өтүү процессти али жетишээрлик жакшырта элек – микросервис версияларынын комбинатордук жарылуусу абдан чоң көйгөй жана бизде аны чечүү менен кырдаалды жакшыртуу үчүн көптөгөн мүмкүнчүлүктөр бар.
Source: www.habr.com