Hallo, Habr! Ik presintearje jo oandacht skriuwer syn oersetting fan it artikel .
Yn in tiid dat de IT-wrâld stadichoan ferhuzet nei mikrotsjinsten en ark lykas Kubernetes, wurdt mar ien probleem hieltyd mear opfallend. Dit probleem - microservice ferzjes. Dochs fynt de IT-mienskip dat de hjoeddeistige situaasje folle better is as foarige generaasje technology. Ferzjearjen fan mikrotsjinsten is lykwols in heul kompleks probleem. Ien bewiis hjirfan kin wêze artikels lykas .
As jo it probleem noch net begripe troch dizze tekst te lêzen, lit my dan útlizze. Litte wy sizze dat jo produkt bestiet út 10 mikrotsjinsten. Litte wy no oannimme dat 1 nije ferzje is frijjûn foar elk fan dizze mikrotsjinsten. Allinnich 1 ferzje - ik hoopje dat wy it allegear iens kinne wêze dat dit in heul triviaal en ûnbelangryk feit is. Litte wy no lykwols nochris nei ús produkt sjen. Mei mar ien nije ferzje fan elke komponint hawwe wy no 2^10 - of 1024 permutaasjes fan hoe't ús produkt kin wurde gearstald.
As der noch in misferstân is, lit my de wiskunde ôfbrekke. Dat wy hawwe 10 mikrotsjinsten, dy't elk ien update krije. Dat is, wy krije 2 mooglike ferzjes foar elke mikrotsjinst (âld of nij). No, foar elk fan 'e produktkomponinten, kinne wy ien fan dizze twa ferzjes brûke. Wiskundich is it itselde as hienen wy in binêr getal fan 10 sifers. Litte wy bygelyks sizze dat 1 de nije ferzje is, en 0 de âlde ferzje is - dan kin ien mooglike permutaasje oanjûn wurde as 1001000000 - wêr't de 1e en 4e komponinten bywurke wurde, en alle oaren net. Ut de wiskunde witte wy dat in 10-sifers binêr getal 2^10 of 1024 wearden kin hawwe. Dat is, wy hawwe de skaal befêstige fan it nûmer wêrmei wy te krijen hawwe.
Litte wy ús redenearring fierder trochgean - wat sil der barre as wy 100 mikrotsjinsten hawwe en elk 10 mooglike ferzjes hat? De hiele situaasje wurdt frij onaangenaam - wy hawwe no 10 ^ 100 permutaasjes - dat is in grut oantal. Ik wol dizze sitewaasje lykwols leaver op dizze manier markearje, want no skûlje wy ús net mear efter wurden as "kubernetes", mar stean foar it probleem sa't it is.
Wêrom bin ik sa fassinearre troch dit probleem? Foar in part om't wy earder wurke hawwe yn 'e wrâld fan NLP en AI, hawwe wy it probleem fan kombinatoryske eksploazje in protte oer 5-6 jier lyn besprutsen. Allinnich ynstee fan ferzjes hiene wy yndividuele wurden, en ynstee fan produkten hienen wy sinnen en paragrafen. En hoewol de problemen fan NLP en AI foar it grutste part net oplost bliuwe, moat it wurde talitten dat wichtige foarútgong is makke yn 'e ôfrûne jierren (yn myn miening koe foarútgong makke wurdeоIt soe better wêze as minsken yn 'e yndustry in bytsje minder omtinken jouwe oan masine learen en in bytsje mear oan oare techniken - mar dit is al off-topic).
Litte wy weromgean nei de wrâld fan DevOps en mikrotsjinsten. Wy wurde konfrontearre mei in enoarm probleem, ferklaaid as in oaljefant yn 'e Kunstkamera - om't wat ik faak hear is "nim gewoan kubernetes en roer, en alles sil goed wêze!" Mar nee, alles komt net goed as alles sa bliuwt. Boppedat liket in analytyske oplossing foar dit probleem net akseptabel fanwegen syn kompleksiteit. Lykas yn NLP, moatte wy dit probleem earst benaderje troch de sykromte te beheinen - yn dit gefal troch ferâldere permutaasjes te eliminearjen.
Ien fan 'e dingen dy't miskien helpe kinne is wat ik ferline jier skreau . It is ek wichtich om te merken dat in goed ûntwurpen CI / CD proses sterk helpt by it ferminderjen fan fariaasjes. De hjoeddeistige stân fan saken mei CI / CD is lykwols net goed genôch om it probleem fan permutaasjes op te lossen sûnder ekstra ark foar rekkenjen en folgjen fan komponinten.
Wat wy nedich binne in systeem fan eksperimintearjen yn 'e yntegraasjepoadium, wêr't wy de risikofaktor foar elke komponint kinne bepale, en ek in automatisearre proses hawwe foar it bywurkjen fan ferskate komponinten en testen sûnder yntervinsje fan operator - om te sjen wat wurket en wat net.
Sa'n systeem fan eksperiminten kin der sa útsjen:
- Untwikkelders skriuwe tests (dit is in kritysk stadium - om't wy oars gjin evaluaasjekritearia hawwe - it is as it labeljen fan gegevens yn masine learen).
- Elke komponint (projekt) krijt in eigen CI-systeem - dit proses is no goed ûntwikkele, en it probleem fan it meitsjen fan in CI-systeem foar ien komponint is foar in grut part oplost
- It "tûke yntegraasjesysteem" sammelt de resultaten fan ferskate CI-systemen en sammelet komponintprojekten yn it definitive produkt, rint testen en berekkent úteinlik it koartste paad om de winske produktfunksjonaliteit te krijen basearre op besteande komponinten en risikofaktoaren. As in fernijing net mooglik is, stelt dit systeem ûntwikkelders op 'e hichte oer de besteande komponinten en wa fan har de flater feroarsaket. Nochris is it testsysteem hjir fan kritysk belang - om't it yntegraasjesysteem testen brûkt as evaluaasjekritearium.
- CD-systeem, dat dan gegevens ûntfangt fan it Smart Integration System en de fernijing direkt útfiert. Dit stadium einiget de syklus.
Om gearfetsje, foar my is ien fan 'e grutste problemen no it ûntbrekken fan sa'n "Smart Integration System" dat de ferskate komponinten yn in produkt keppelje soe en jo sadwaande kinne folgje hoe't it produkt as gehiel gearstald is. Ik sil ynteressearre wêze yn 'e gedachten fan' e mienskip oer dit (spoiler - ik wurkje op it stuit oan in projekt , dat sa'n tûk yntegraasjesysteem kin wurde).
Ien lêste ding dat ik neame wol is dat, foar my, in monolyt net akseptabel is foar elk projekt fan sels in middelgrutte. Foar my feroarsaakje besykjen om ymplemintaasjetiid en kwaliteit fan ûntwikkeling te fersnellen troch werom te gean nei in monolith grutte skepsis. As earste, in monolith hat in ferlykber probleem fan it behearen fan komponinten - ûnder de ferskate biblioteken dêr't it bestiet út, lykwols, dit alles is net sa merkber en manifestearret him benammen yn 'e tiid bestege troch ûntwikkelders. De konsekwinsje fan it monolytprobleem is de firtuele ûnmooglikheid om wizigingen oan 'e koade te meitsjen - en ekstreem trage ûntwikkelingssnelheid.
Microservices ferbetterje de situaasje, mar dan stiet de mikroservice-arsjitektuer foar it probleem fan kombinatoryske eksploazje by it yntegraasjepoadium. Ja, yn 't algemien hawwe wy itselde probleem ferpleatst fan' e ûntwikkelingsstadium nei it yntegraasjestadium. Neffens my liedt de oanpak fan mikrotsjinsten lykwols noch altyd ta bettere resultaten, en teams berikke resultaten rapper (wierskynlik benammen troch de fermindering fan 'e grutte fan' e ûntwikkelienheid - of batch grutte). It ferpleatsen fan monolith nei mikrotsjinsten hat it proses lykwols noch net genôch ferbettere - de kombinatoryske eksploazje fan mikrotsjinstferzjes is in enoarm probleem, en wy hawwe in protte potensjeel om de situaasje te ferbetterjen as wy it oplosse.
Boarne: www.habr.com