Hallo, Habr! Ek bied aan u aandag skrywer se vertaling van die artikel .
In 'n tyd dat die IT-wêreld geleidelik na mikrodienste en nutsmiddels soos Kubernetes beweeg, word net een probleem meer en meer opvallend. Hierdie probleem - mikrodiens weergawes. Tog glo die IT-gemeenskap dat die huidige situasie baie beter is as vorige generasie tegnologieë. Die weergawe van mikrodienste is egter 'n baie komplekse probleem. Een bewys hiervan kan artikels soos .
As jy steeds nie die probleem verstaan deur hierdie teks te lees nie, laat ek verduidelik. Kom ons sê jou produk bestaan uit 10 mikrodienste. Kom ons neem nou aan dat 1 nuwe weergawe vir elk van hierdie mikrodienste vrygestel word. Slegs 1 weergawe - ek hoop ons kan almal saamstem dat dit 'n baie onbenullige en onbeduidende feit is. Kom ons kyk egter nou weer na ons produk. Met net een nuwe weergawe van elke komponent, het ons nou 2^10 - of 1024 permutasies van hoe ons produk saamgestel kan word.
As daar nog 'n misverstand is, laat ek die wiskunde afbreek. Ons het dus 10 mikrodienste wat elkeen een opdatering ontvang. Dit wil sê, ons kry 2 moontlike weergawes vir elke mikrodiens (óf oud of nuut). Nou, vir elk van die produkkomponente, kan ons een van hierdie twee weergawes gebruik. Wiskundig is dit dieselfde asof ons 'n binêre getal van 10 syfers gehad het. Byvoorbeeld, kom ons sê dat 1 die nuwe weergawe is, en 0 is die ou weergawe - dan kan een moontlike permutasie aangedui word as 1001000000 - waar die 1ste en 4de komponente opgedateer word, en al die ander nie. Uit wiskunde weet ons dat 'n 10-syfer binêre getal 2^10 of 1024 waardes kan hê. Dit wil sê, ons het die skaal van die getal waarmee ons te doen het, bevestig.
Kom ons gaan verder met ons redenasie – wat sal gebeur as ons 100 mikrodienste het en elkeen het 10 moontlike weergawes? Die hele situasie raak nogal onaangenaam - ons het nou 10^100 permutasies - wat 'n groot getal is. Ek verkies egter om hierdie situasie so te benoem, want nou skuil ons nie meer agter woorde soos “kubernetes” nie, maar staar eerder die probleem in die gesig soos dit is.
Hoekom is ek so gefassineer deur hierdie probleem? Deels omdat ons, nadat ons voorheen in die wêreld van NLP en KI gewerk het, ongeveer 5-6 jaar gelede die probleem van kombinatoriese ontploffing baie bespreek het. Slegs in plaas van weergawes het ons individuele woorde gehad, en in plaas van produkte het ons sinne en paragrawe gehad. En hoewel die probleme van NLP en KI grootliks onopgelos bly, moet daar erken word dat aansienlike vordering gemaak is oor die afgelope paar jaar (na my mening kan vordering gemaak wordоDit sal beter wees as mense in die bedryf 'n bietjie minder aandag gee aan masjienleer en 'n bietjie meer aan ander tegnieke - maar dit is reeds buite die onderwerp).
Kom ons keer terug na die wêreld van DevOps en mikrodienste. Ons word gekonfronteer met 'n groot probleem, wat ons as 'n olifant in die Kunstkamera voordoen - want wat ek gereeld hoor is "vat net kubernetes en stuur, en alles sal regkom!" Maar nee, alles sal nie reg wees as alles net so gelaat word nie. Boonop lyk 'n analitiese oplossing vir hierdie probleem nie aanvaarbaar nie weens die kompleksiteit daarvan. Soos in NLP, moet ons eers hierdie probleem benader deur die soekomvang te verklein—in hierdie geval deur verouderde permutasies uit te skakel.
Een van die dinge wat dalk kan help, is iets wat ek verlede jaar geskryf het . Dit is ook belangrik om daarop te let dat 'n goed ontwerpte CI/CD-proses baie help om variasie te verminder. Die huidige stand van sake met CI/CD is egter nie goed genoeg om die probleem van permutasies op te los sonder bykomende gereedskap vir rekeningkundige en naspeuring van komponente nie.
Wat ons nodig het, is 'n stelsel van eksperimentering by die integrasiestadium, waar ons die risikofaktor vir elke komponent kan bepaal, en ook 'n geoutomatiseerde proses kan hê vir die opdatering van verskeie komponente en toetsing sonder ingryping van die operateur - om te sien wat werk en wat nie.
So 'n stelsel van eksperimente kan soos volg lyk:
- Ontwikkelaars skryf toetse (dit is 'n kritieke stadium - want anders het ons geen evalueringskriterium nie - dit is soos om data in masjienleer te etiketteer).
- Elke komponent (projek) ontvang sy eie GI-stelsel - hierdie proses is nou goed ontwikkel, en die kwessie van die skep van 'n GI-stelsel vir 'n enkele komponent is grootliks opgelos
- Die "slim-integrasiestelsel" versamel die resultate van verskeie CI-stelsels en stel komponentprojekte saam tot die finale produk, voer toetse uit en bereken uiteindelik die kortste pad na die verkryging van die gewenste produkfunksionaliteit gebaseer op bestaande komponente en risikofaktore. As 'n opdatering nie moontlik is nie, stel hierdie stelsel ontwikkelaars in kennis van die bestaande komponente en watter van hulle die fout veroorsaak. Weereens is die toetsstelsel hier van kritieke belang - aangesien die integrasiestelsel toetse as 'n evalueringskriterium gebruik.
- CD-stelsel, wat dan data van die Smart Integration System ontvang en die opdatering direk uitvoer. Hierdie stadium eindig die siklus.
Om op te som, vir my is een van die grootste probleme nou die gebrek aan so 'n "Slim Integrasiestelsel" wat die verskillende komponente in 'n produk sal koppel en jou dus toelaat om op te spoor hoe die produk as geheel saamgestel is. Ek sal belangstel in die gemeenskap se gedagtes hieroor (bederf - ek werk tans aan 'n projek , wat so 'n slim integrasiestelsel kan word).
Een laaste ding wat ek wil noem, is dat, vir my, 'n monoliet nie aanvaarbaar is vir enige projek van selfs 'n medium grootte nie. Vir my veroorsaak pogings om implementeringstyd en kwaliteit van ontwikkeling te bespoedig deur terug te keer na 'n monoliet, groot skeptisisme. Eerstens het 'n monoliet 'n soortgelyke probleem om komponente te bestuur - onder die verskillende biblioteke waaruit dit bestaan, is dit alles egter nie so opvallend nie en manifesteer hom hoofsaaklik in die tyd wat ontwikkelaars spandeer. Die gevolg van die monolietprobleem is die feitlik onmoontlikheid om veranderinge aan die kode aan te bring - en uiters stadige ontwikkelingspoed.
Mikrodienste verbeter die situasie, maar dan staar die mikrodiensargitektuur die probleem van kombinatoriese ontploffing in die integrasiestadium in die gesig. Ja, oor die algemeen het ons dieselfde probleem van die ontwikkelingstadium na die integrasiestadium verskuif. Na my mening lei die mikrodienstebenadering egter steeds tot beter resultate, en spanne behaal vinniger resultate (waarskynlik hoofsaaklik as gevolg van die vermindering in die grootte van die ontwikkelingseenheid - of bondel grote). Die skuif van monoliet na mikrodienste het egter nog nie genoeg verbetering aan die proses gebring nie – die kombinatoriese ontploffing van mikrodiensweergawes is 'n groot probleem, en ons het baie potensiaal om die situasie te verbeter soos ons dit oplos.
Bron: will.com