Saluton, Habr! Mi prezentas al via atento traduko de la aŭtoro de la artikolo .
En tempo, kiam la IT-mondo iom post iom moviĝas al mikroservoj kaj iloj kiel Kubernetes, nur unu problemo fariĝas pli kaj pli rimarkebla. Ĉi tiu problemo - versioj de mikroservoj. Tamen, la IT-komunumo kredas, ke la nuna situacio estas multe pli bona ol antaŭa generacio de teknologioj. Tamen, versio de mikroservoj estas tre kompleksa problemo. Unu pruvo de tio povas esti artikoloj kiel .
Se vi ankoraŭ ne komprenas la problemon legante ĉi tiun tekston, mi klarigu. Ni diru, ke via produkto konsistas el 10 mikroservoj. Nun ni supozu, ke 1 nova versio estas publikigita por ĉiu el ĉi tiuj mikroservoj. Nur 1 versio - mi esperas, ke ni ĉiuj povas konsenti, ke tio estas tre bagatela kaj sensignifa fakto. Nun, tamen, ni rigardu alian nian produkton. Kun nur unu nova versio de ĉiu komponanto, ni nun havas 2^10 - aŭ 1024 permutaĵojn de kiel nia produkto povas esti formita.
Se ankoraŭ estas miskompreno, mi malkonstruu la matematikon. Do ni havas 10 mikroservojn, ĉiu ricevante unu ĝisdatigon. Tio estas, ni ricevas 2 eblajn versiojn por ĉiu mikroservo (aŭ malnova aŭ nova). Nun, por ĉiu el la produktaj komponantoj, ni povas uzi ajnan el ĉi tiuj du versioj. Matematike, ĝi estas la sama kvazaŭ ni havus binaran nombron de 10 ciferoj. Ekzemple, ni diru, ke 1 estas la nova versio, kaj 0 estas la malnova versio - tiam unu ebla permutaĵo povas esti indikita kiel 1001000000 - kie la 1-a kaj 4-a komponantoj estas ĝisdatigitaj, kaj ĉiuj aliaj ne. El matematiko ni scias, ke 10-cifera binara nombro povas havi 2^10 aŭ 1024 valorojn. Tio estas, ni konfirmis la skalon de la nombro, pri kiu ni traktas.
Ni daŭrigu nian rezonadon plu - kio okazos se ni havas 100 mikroservojn kaj ĉiu havas 10 eblajn versiojn? La tuta situacio fariĝas sufiĉe malagrabla - ni nun havas 10^100 permutaĵojn - kio estas grandega nombro. Tamen mi preferas etikedi ĉi tiun situacion tiel, ĉar nun ni ne plu kaŝas sin malantaŭ vortoj kiel "kubernetes", sed prefere alfrontas la problemon kia ĝi estas.
Kial mi tiom fascinas ĉi tiun problemon? Parte ĉar, antaŭe laboris en la mondo de NLP kaj AI, ni multe diskutis pri la problemo de kombina eksplodo antaŭ ĉirkaŭ 5-6 jaroj. Nur anstataŭ versioj ni havis individuajn vortojn, kaj anstataŭ produktoj ni havis frazojn kaj alineojn. Kaj kvankam la problemoj de NLP kaj AI restas plejparte nesolvitaj, oni devas konfesi, ke signifa progreso estis farita dum la lastaj jaroj. (laŭ mi, oni povus progresiоPli bone estus, se homoj en la industrio atentus iom malpli al maŝinlernado kaj iom pli al aliaj teknikoj – sed ĉi tio jam estas ekstertema).
Ni revenu al la mondo de DevOps kaj mikroservoj. Ni estas alfrontitaj kun grandega problemo, maskante kiel elefanto en la Kunstkamera - ĉar kion mi ofte aŭdas estas "nur prenu kubernetojn kaj stirilon, kaj ĉio estos en ordo!" Sed ne, ĉio ne estos en ordo, se ĉio restos kiel estas. Krome, analiza solvo de ĉi tiu problemo ne ŝajnas akceptebla pro sia komplekseco. Kiel en NLP, ni unue devus aliri ĉi tiun problemon malvastigante la serĉamplekson — en ĉi tiu kazo, forigante malmodernajn permutojn.
Unu el la aferoj, kiuj povus helpi, estas io, kion mi skribis pasintjare . Ankaŭ gravas noti, ke bone desegnita CI/KD-procezo multe helpas redukti variadon. Tamen, la nuna stato de aferoj kun CI/KD ne sufiĉas por solvi la problemon de permutaĵoj sen pliaj iloj por kontado kaj spurado de komponantoj.
Kion ni bezonas estas sistemo de eksperimentado ĉe la integriga stadio, kie ni povas determini la riskan faktoron por ĉiu komponanto, kaj ankaŭ havi aŭtomatigitan procezon por ĝisdatigi diversajn komponantojn kaj testadon sen interveno de operaciisto - por vidi kio funkcias kaj kio ne.
Tia sistemo de eksperimentoj povus aspekti jene:
- Programistoj skribas testojn (ĉi tio estas kritika etapo - ĉar alie ni ne havas taksadkriterion - estas kiel etikedado de datumoj en maŝina lernado).
- Ĉiu komponento (projekto) ricevas sian propran CI-sistemon - ĉi tiu procezo nun estas bone evoluinta, kaj la problemo pri kreado de CI-sistemo por ununura komponento estas plejparte solvita.
- La "integriga sistemo" kolektas la rezultojn de diversaj CI-sistemoj kaj kunvenas komponentajn projektojn en la finan produkton, faras testadon kaj finfine kalkulas la plej mallongan vojon por akiri la deziratan produktan funkcion bazitan sur ekzistantaj komponentoj kaj riskfaktoroj. Se ĝisdatigo ne eblas, ĉi tiu sistemo sciigas programistojn pri la ekzistantaj komponantoj kaj kiu el ili kaŭzas la eraron. Denove, la testsistemo estas de kritika graveco ĉi tie - ĉar la integriga sistemo uzas testojn kiel taksadkriterion.
- KD-sistemo, kiu tiam ricevas datumojn de la Smart Integration System kaj elfaras la ĝisdatigon rekte. Ĉi tiu etapo finas la ciklon.
Resume, por mi unu el la plej grandaj problemoj nun estas la manko de tia "Smart Integration System" kiu ligus la diversajn komponantojn en produkton kaj tiel permesus al vi spuri kiel la produkto kiel tuto estas kunmetita. Mi interesiĝos pri la pensoj de la komunumo pri tio (spoiler - mi nuntempe laboras pri projekto , kiu povas fariĝi tia inteligenta integriga sistemo).
Lastan aferon, kiun mi volas mencii, estas ke, laŭ mi, monolito ne estas akceptebla por ajna projekto eĉ de meza grandeco. Por mi, provoj akceli efektivigtempon kaj kvaliton de evoluo per reveno al monolito kaŭzas grandan skeptikon. Unue, monolito havas similan problemon pri administrado de komponantoj - inter la diversaj bibliotekoj, el kiuj ĝi konsistas, tamen ĉio ĉi ne estas tiel rimarkebla kaj manifestiĝas ĉefe en la tempo pasigita de programistoj. La sekvo de la monolitproblemo estas la virtuala malebleco fari ŝanĝojn al la kodo - kaj ekstreme malrapida disvolva rapideco.
Mikroservoj plibonigas la situacion, sed tiam la mikroserva arkitekturo alfrontas la problemon de kombina eksplodo ĉe la integriga stadio. Jes, ĝenerale, ni movis la saman problemon de la evolustadio al la integriga stadio. Tamen, laŭ mi, la aliro al mikroservoj ankoraŭ kondukas al pli bonaj rezultoj, kaj teamoj atingas rezultojn pli rapide (verŝajne ĉefe pro la redukto de la grandeco de la evoluunuo - aŭ aro grandeco). Tamen, transiri de monolito al mikroservoj ankoraŭ ne sufiĉe plibonigis la procezon - la kombina eksplodo de mikroservo-versioj estas grandega problemo, kaj ni havas multe da potencialo plibonigi la situacion dum ni solvas ĝin.
fonto: www.habr.com