Null-seisakute refaktoreerimine: kuidas süsteeme refaktoreerida ilma neid võrguühenduseta eemaldamata

Tootmissüsteemidel ei ole lubatud seiskuda. Finantsplatvorm, mis töötleb tehinguid kell 2 öösel, tervishoiuteenuste andmete süsteem, mis teenindab kliinilisi töötajaid eri ajavööndites, logistikarakendus, mis jälgib saadetisi üle mandrite: ühelgi neist pole hooldusaega, mis võimaldaks refaktoriseerimist. Ometi koguvad nad kõik tehnilist võlga, kannavad endas varasemate piirangute kohaselt tehtud arhitektuurilisi otsuseid ja vajavad lõpuks struktuurilisi muudatusi, et jääda hooldatavaks, skaleeritavaks ja turvaliseks. Null-seisakute refaktoriseerimine on distsipliin, mis lahendab selle pinge: reaalajas süsteemi arendamine ilma pakutavat teenust katkestamata.

Väljakutse ei ole puhtalt tehniline. See on organisatsiooniline ja arhitektuuriline. Süsteemi, mis ei saa võrguühenduseta minna, refaktoreerimine nõuab teistsugust mõttemudelit kui arendusjärgus süsteemi refaktoreerimine: iga muudatus peab olema tagasiühilduv, kuni see enam ei ole, iga struktuurimuutus peab olema pöörduv, iga valideerimine peab toimuma reaalse liikluse, mitte sünteetiliste testide suhtes. Selle võimalikuks tegevad tehnikad, sealhulgas sinakasrohelised juurutused, funktsioonide lülitamine, kägistaja figuurmuster, laiendatud lepinguga andmebaasi migratsioonid ja idempotentsed sündmuspõhised arhitektuurid, on eraldi hästi dokumenteeritud. Harvemini käsitletakse seda, kuidas need koos toimivad sidusa strateegiana püsivate ja ohutute struktuurimuutuste jaoks süsteemides, mis peavad kasutajaid kogu protsessi vältel teenindama.

Milline peab teie arhitektuur välja nägema, et muudatused ei tekitaks seisakuid

Kõige levinum küsimus, mida meeskonnad nullseisakuteta refaktoreerimisele pühendudes esitavad, on arhitektuuriline: mis peab süsteemi ülesehituses muutuma enne, kui refaktoreerimine ise saab alata? Vastus ei ole üks muster, vaid struktuuriliste omaduste kogum, mida süsteem peab enne reaalajas refaktoreerimise ohutuks muutmist omama. Nende omaduste mõistmine on selle juhendi kõige muu eeltingimus.

Esimene omadus on iseseisev juurutatavus. Iga ümberkujundatav komponent peab olema juurutatav ilma, et oleks vaja samaaegselt juurutada selle sõltuvusi. Kui teenuse A muutmine nõuab teenuse B ja teenuse C samaaegset muutmist rikke vältimiseks, siis on teenuse A nullseisakuteta juurutamine struktuurilt võimatu: need kolm teenust on sisuliselt üks juurutusüksus, olenemata sellest, kui mitmes hoidlas nad asuvad. Sõltumatu juurutatavus nõuab tagasiühilduvaid liideseid, versioonitud lepinguid ja teenuste vaheliste koordineeritud juurutamisnõuete kõrvaldamist.

Teine omadus on pöörduvus. Iga juurutus, mis muudab reaalajas käitumist, peab olema pöörduv minutite, mitte tundide jooksul. Pöörduvus ei seisne ainult vana binaarfaili kättesaadavana hoidmises. See nõuab, et andmebaasi olek, vahemälu olek, seansi olek ja mis tahes uue versiooni poolt muudetud välise süsteemi olek oleksid vana versiooniga ühilduvad. Kui uus versioon kirjutab andmeid vormingus, mida vana versioon lugeda ei suuda, on juurutus definitsiooni järgi pöördumatu ja nullseisakuid pole võimalik, sest iga tagasipööramine tekitab vigu.

Kolmas omadus on jälgitavad oleku üleminekud. Refaktoriseerimine, mis liigutab käitumist ühelt kooditeelt teisele ilma mõlema tee jälgitavaid mõõdikuid teadmata, toimib pimesi. Meeskond ei saa teada, kas üleminek õnnestub või ebaõnnestub, ei saa regressioone varakult tuvastada ega saa teha andmepõhiseid otsuseid selle kohta, millal migratsiooni kiirendada või peatada. Jälgitavus tuleb instrumenteerida enne refaktoriseerimise algust, mitte lisada pärast probleemi ilmnemist. Nagu on uuritud kontekstis täiendav refaktoreerimine ja tehniline võlg, koodi toimimise ja sellest sõltuva struktuuri nähtavus on aluseks mis tahes muudatuste planeerimisele, mis ei saa endale lubada ebaõnnestumist tootmises.

Siniroheline juurutamine: baasmuster

Sinine-roheline juurutamine on nullseisakutega versioonide alusmuster. On olemas kaks identset tootmiskeskkonda: sinine keskkond, mis teenindab reaalajas liiklust, ja roheline keskkond, mis võtab vastu uue versiooni. Uus versioon juurutatakse, testitakse ja valideeritakse rohelises keskkonnas, samal ajal kui sinine keskkond jätkab kasutajate teenindamist katkestusteta. Kui roheline keskkond on valideeritud, lülitatakse liiklus aatomiliselt ümber. Tagasipööramine on vastupidine: liiklus lülitatakse tagasi sinisele, mis jääb kogu aeg kättesaadavaks.

Muster kõlab otsekoheselt. Selle raskus seisneb andmebaasikihis. Kui mõlemad keskkonnad peavad samast andmebaasist lugema ja sinna kirjutama, peab andmebaasi skeem olema samaaegselt mõlema versiooniga ühilduv. Migratsioon, mis eemaldab veeru, nimetab välja ümber või muudab andmetüüpi, lõhub vana keskkonna koheselt. Seetõttu on sinakasroheline juurutamine lahutamatu selle juhendi andmebaasiosas kirjeldatud laiendatud-lepingulise skeemi migreerimismustrist.

Canary väljalasked ja etapiviisilise levitamise tehnikad

Canary versioonid laiendavad sinakasrohelist mudelit, suunates uude versiooni teatud protsendi liiklusest, selle asemel et kogu liiklust korraga ümber lülitada. Canary juurutamine võib alata ühe protsendi kasutajatega, jälgida selle kohordi veamäärasid, latentsust ja ärimõõdikuid ning seejärel protsenti järk-järgult suurendada: viis, kakskümmend, viiskümmend, sada. Igas etapis kontrollivad automatiseeritud väravad, et peamised mõõdikud ei oleks halvenenud üle määratletud lävede. Kui värav ebaõnnestub, peatatakse juurutamine ja Canary protsent vähendatakse tagasi nullini.

Järkjärgulise juurutamise tehnikad lisavad sellele edenemisele sihtimisloogikat. Liiklust ei saa marsruutida ainult protsendi alusel, vaid segmenteerida kasutajarühma, geograafilise piirkonna, tellimustaseme või seansi omaduste järgi. See võimaldab uut versiooni valideerida enne selle populatsiooni täielikku migreerimist selle konkreetse kasutajaskonna suhtes, kes seda kõige rohkem koormab. Peamine nõue on, et marsruutimise infrastruktuur, olgu see siis koormuse tasakaalustaja, API-lüüs või teenusevõrk, toetaks juurutamise jaoks vajalikku sihtimise detailsust.

Enne juurutamise algust tuleb määratleda mõõdikud, mis reguleerivad nn kanaariväravaid. Veamäär, p99 latentsus, andmebaasi päringu aeg ja ettevõttespetsiifilised mõõdikud, näiteks konversioonimäär või maksete edukuse määr, on kõik kehtivad väravakriteeriumid. Väravakünniseid tuleks kalibreerida olemasoleva versiooni võrreldava koormuse all mõõdetud baasjoone suhtes, mitte teoreetiliste eesmärkide suhtes. Juurutamist, mis läbib värava kahe protsendi liikluse korral, kuid ebaõnnestub kahekümne protsendi juures, ei ole valideeritud: kanaarivärav oli liiga väike, et olla representatiivne. Nõuetekohane etapiviisiline juurutamine nõuab igas etapis piisavat liikluskoormust, et saada statistiliselt oluline võrdlus.

Funktsioonide lülitid ja tapmislülitid

Funktsioonilülitid lahutavad koodi juurutamise käitumise aktiveerimisest. Ümberkujundatud kooditee juurutatakse passiivses olekus, seda kontrollib lüliti, mis määrab, millised kasutajad või päringud uut loogikat käivitavad. Lülitit saab lubada järk-järgult, sihtida konkreetsetele kohortidele või tühistada koheselt ilma ümberjuurutamiseta. See teeb funktsioonilülititest peamise mehhanismi äriloogika nullseisakuajaliseks migreerimiseks, erinevalt infrastruktuurimuudatustest, kus sinakasrohelised või kanaarikujulised mustrid on sobivamad.

Funktsioonilülitite kaitsev vaste on tapmislülitid: need ei ole mõeldud uue käitumise lubamiseks, vaid selle koheseks keelamiseks, kui see valesti toimib. Ümberkujundatud arveldusarvutuse, uue autentimisvoo või asendatud andmepääsukihi tapmislüliti annab valvetehnikule ühe toiminguga taastamistee, mis ei nõua juurutamist, andmebaasi tagasipööramist ega meeskondadevahelist koordineerimist. Tapmislüliti tuleks konfigureerida süsteemis, mis võimaldab selle käivitamist API-kõne, funktsioonilipu halduskonsooli või automaatse hoiatuste integratsiooni kaudu, nii et päästiku latentsusaeg oleks sekundid, mitte minutid.

Lüliti hügieen on tõsine operatiivne probleem. Lülitid, mida kunagi ei puhastata, kogunevad koodibaasi, muutes juhtimisvoo selgitamise üha raskemaks ning luues lüliti oleku ja andmeoleku vahel varjatud sõltuvusi. Igal lülitil peaks olema dokumenteeritud omanik, planeeritud aegumiskuupäev ja puhastuspilet. Lüliti võlg on sama reaalne kui iga teine ​​tehnilise võla vorm ja see kuhjub kiiremini, kuna lülitid valvavad tavaliselt süsteemi kõige aktiivsemalt muutuvaid osi.

Andmebaasi refaktoreerimine ilma seisakuteta

Andmebaasi muudatused on nullseisakuteta refaktoreerimise kõige keerulisem osa, kuna andmebaasid on olekupõhised, jagatud ja aeglaselt suures mahus muudetavad. Rakendust saab minutitega juurutada ja tagasi võtta. Andmebaasi migreerimine, mis muudab sadade miljonite ridadega tabelit, võib võtta tunde, seda ei saa pärast kinnitamist kergesti tagasi võtta ning see sisaldab lukke, mis blokeerivad lugemise ja kirjutamise kogu perioodiks. Andmebaasi õigesti refaktoreerimine nõuab teistsugust lähenemist kui rakenduse koodi refaktoreerimine ja enamik meeskondi avastab selle esimesel korral, kui nad proovivad skeemi muuta aktiivsel suure liiklusega tabelil.

Keskne põhimõte on, et iga andmebaasi muudatus peab olema tagasiühilduv rakenduse eelmise versiooniga, kuni eelmist versiooni enam ei juurutata. See kõlab ilmselgelt, kuid sellel on mitteilmselged tagajärjed. Veeru ümbernimetamine nõuab uue nime lisamist aliasena või duplikaadina, enne kui vana nime saab eemaldada. Veeru tüübi muutmine nõuab uue tüübi varikolumni paralleelset asustamist, enne kui vana veeru saab eemaldada. Tabeli eemaldamine nõuab kinnitust, et ükski rakenduse juurutatud versioon ei loe sellest. Kõik need toimingud on mitmeastmeline protsess, mis on jaotatud mitme juurutuse vahel, mitte üks migreerimine, mis toimub üks kord. Nagu laiemas kontekstis käsitletud COBOL-i refaktoreerimine pärandandmestruktuurides, on ettevõttetasandi refaktoreerimise üks peamisi raskusi andmestruktuuride arenemine, mida jagatakse mitme programmi ja süsteemi vahel ilma koordineeritud üleminekuta.

Laiendus-lepingu muster

Laienda-lehitse muster vormistab skeemimuudatuste mitmeastmelise lähenemisviisi. Laiendamisfaasis lisatakse uued skeemielemendid aditiivselt: uus veerg vana kõrvale, uus tabel vana kõrvale, uus indeks vana kõrvale. Rakendust värskendatakse nii, et see kirjutaks nii vanasse kui ka uude struktuuri, kuid jätkab lugemist vanast struktuurist. Andmeid ei lähe kaduma, ükski olemasolev päring ei katke ja rakenduse vana versioon toimib edasi, kuna vanad skeemielemendid on endiselt olemas.

Kokkutõmbamise faasis, mis toimub eraldi juurutuse käigus pärast uue versiooni täielikku juurutamist ja valideerimist, eemaldatakse vanad skeemielemendid. Selleks ajaks ei sõltu neist enam ükski rakenduse töötav versioon. Eemaldamine on ohutu, kuna see on pigem vaatluse teel kinnitatud kui planeerimise käigus eeldatud.

Laiendus-lepingu muster nõuab juurutamise järjestamise osas distsipliini. Andmebaasi migratsioon, mis lisab uue veeru, tuleb juurutada enne rakenduse versiooni, mis sinna kirjutab. Andmebaasi migratsioon, mis eemaldab vana veeru, tuleb juurutada pärast seda, kui kõik sellest lugevad rakenduse versioonid on eemaldatud. Need järjestamise nõuded tuleks juurutamistorustikus kodeerida, et migratsioone ei saaks rakendada vales järjekorras.

Tööriistad pärandandmekanalite ümberkujundamiseks ilma koodi ümberkirjutamata

Pärandandmete torujuhtmed, eriti need, mis on üles ehitatud partiitöötlusraamistikele, ETL-tööriistadele või suurarvutipõhisele andmeliikumisele, kujutavad endast spetsiifilist väljakutset: need teisendavad ja liigutavad andmeid pidevalt, neid ei saa migratsiooni ajaks peatada ning need on sageli nii aladokumenteeritud, et nende tegevuse täielik ulatus pole teada enne, kui midagi katki läheb. Nende torujuhtmete refaktoriseerimine ilma täieliku ümberkirjutamiseta nõuab tööriistu, mis suudavad jälgida torujuhtme praegust tegevust, valideerida, et refaktoreeritud versioon annab samaväärse väljundi, ja võimaldada üleminekut etapiviisiliselt, mitte järsult.

Muutusandmete jäädvustamine on reaalajas toimuva konveieri ümberkujundamise kõige laiemalt kasutatav tööriist. CDC jäädvustab iga kirjutamisoperatsiooni lähtekooditabelis sündmuste vooguna, mis võimaldab toita andmeid nii vanale konveierile kui ka uuele asenduskonveierile samast allikast ilma kumbagi muutmata. Vana konveier jätkab tööd, uus konveier töötab paralleelselt sama sündmuste vooga ja väljundeid võrreldakse. Lahknevused tuvastavad teisendusloogika, mida pole õigesti uuesti rakendatud. Kui pariteet on kinnitatud, deaktiveeritakse vana konveier.

Skeemide migreerimise tööriistad, sealhulgas Liquibase ja Flyway, pakuvad versioonitud ja järjestatud migreerimisi, mida saab rakendada järk-järgult ja tagasi pöörata koos laiendatud lepingu distsipliiniga. Need jälgivad, milliseid migreerimisi on igas keskkonnas rakendatud, ja ennetavad valejärjekorras rakendusi. Suurarvutites või VSAM-põhistes andmehoidlates töötavate pärandtorustike puhul hallatakse samaväärset toimingut... JCL-i laiendamine ja andmekogumite haldamine mis kontrollib, kuidas programmid ülemineku ajal andmetele juurde pääsevad, tagades, et ei vana ega uus programm ei tööta ühildumatu andmestiku paigutusega.

Kuidas vananenud andmebaase seisakuid vältides kaasajastada

Pärandandmebaasi kaasajastamise, suurarvuti DB2 skeemilt pilvepõhises keskkonnas asuvale relatsioonandmebaasile ülemineku, failipõhiselt VSAM-struktuurilt relatsioonskeemile migreerimise või mitme pärandandmebaasi koondamise uude ühendatud poodi spetsiifiline väljakutse nõuab kõigi ülaltoodud tehnikate järjestikku rakendamist pikema aja jooksul.

Järjepidevalt toimiv lähenemisviis on järgmine: alusta lugemispaarsusega, seejärel saavuta kirjutamispaarsus, seejärel migreeri lugemised, seejärel migreeri kirjutamised ja lõpuks pärandsalvestuse dekomisjoneerimine. Lugemispaarsus tähendab, et uus salvestus sisaldab kõiki andmeid, mis vanas salvestuses, ja saab teenindada kõiki rakenduse tehtud päringuid. Kirjutamispaarsus tähendab, et iga kirjutus, mille rakendus teeb vanasse salvestusse, rakendatakse ka uude salvestusse, kas rakenduse topeltkirjutamise või CDC replikatsiooni kaudu. Kui mõlemad pariteeditingimused on tootmiskoormuse all kinnitatud, saab lugemised uude salvestusse migreerida (väljundite valideerimine), seejärel saab kirjutused migreerida ja seejärel saab pärandsalvestuse dekomisjoneerida.

Selle järjestuse üheski etapis ei katkestata ühtegi teenust. Igal etapil saab eelmise oleku taastada, viies lugemised või kirjutused tagasi eelmisesse salve. Iga etapi kestus määratakse valideerimise teel saadud usaldusväärsuse, mitte fikseeritud kalendrikuupäeva järgi.

Tööriistad pärandsüsteemide ümberkujundamiseks ilma koodi ümberkirjutamata

Pärandsüsteemi nullist ümberkirjutamine on peaaegu alati kallim ja riskantsem kui selle järkjärguline ümberkirjutamine. Täielik ümberkirjutamine nõuab samaaegselt vana süsteemi töös hoidmist, võrreldava funktsionaalsusega asendaja loomist, kahe süsteemi vahelise funktsioonide pariteedi erinevuse haldamist ja ümberlülituse teostamist, mis on sisuliselt täiesti uue süsteemi nullseisakuajaline juurutamine. Enamik organisatsioone, kes proovivad täielikku ümberkirjutamist, avastavad poolelioleva protsessi käigus, et vanas süsteemis oli käitumist, mida nad ei dokumenteerinud, mida asendus veel ei kopeeri ja millest kasutajad sõltuvad.

Õigete tööriistadega inkrementaalne refaktoriseerimine väldib seda lõksu, muutes vana süsteemi enne muutmist loetavaks. Lähtepunkt on struktuurianalüüs: olemasoleva süsteemi iga komponendi tegevuse, sellest sõltuva ja süsteemi enda komponendi mõistmine. Seda analüüsi ei saa teha dokumentatsiooni lugedes (mis pärandsüsteemide puhul tavaliselt puudub või on ebatäpne) ega koodi käsitsi suures mahus lugedes. See nõuab automatiseeritud tööriistu, mis parsivad olemasolevat koodi, konstrueerivad sõltuvusgraafiku ja muudavad selle graafi päringutele sobivaks. Nagu on kirjeldatud kontekstis pärandsüsteemide integreerimisega seotud väljakutsete haldamine, on iga pärandrefaktorimisprogrammi esimene samm struktuurilise nähtavuse loomine, mida ei eksisteeri üheski inimese poolt hooldatud artefaktis.

Monoliitide kägistaja viigimarja muster

Kägistaja figuuri muster on domineeriv arhitektuuristrateegia monoliidi järkjärguliseks asendamiseks ilma täieliku ümberkirjutamise või üleminekuta. Uus funktsionaalsus luuakse monoliidi kõrvale iseseisvate teenustena. Marsruutimiskiht, tavaliselt API-lüüs või pöördproksi, peatab sissetulevad päringud ja suunab need marsruutimisreeglite alusel kas monoliiti või uude teenusesse. Monoliit jätkab kogu veel migreerimata liikluse teenindamist. Uus teenus haldab ainult sellele otseselt suunatud liiklust.

Aja jooksul lisatakse üha rohkem marsruutimisreegleid. Uutele teenustele suunatakse rohkem teid. Monoliit haldab üha väiksemat osa kogu liiklusest. Lõpuks ei halda monoliit enam midagi ja selle saab kasutusest kõrvaldada. Selle protsessi käigus ei ole ükski juurutus piisavalt suur, et kujutada endast olulist riski. Iga marsruutimisreegli muudatust saab eraldi testida ja eraldi tagasi pöörata. Kägistava meetodi puhul ei ole tegemist kiire teisenduse tehnikaga: see on mõeldud ohutuks teisenduseks nädalate, kuude või aastate jooksul, olenevalt kägistatava süsteemi keerukusest.

Strangler fig mustri kriitiline rakendusnõue on see, et marsruutimiskiht oleks nii monoliitist kui ka uutest teenustest lahutatud. Monoliiti integreeritud marsruutimiskiht ei saa liiklust monoliitist eemale suunata. Proksi peab asuma mõlema ees ja suutma suunata liiklust kummassegi konfiguratsiooni põhjal, mida saab muuta ilma monoliiti ega uut teenust muutmata.

Vananenud API-de ümberfaktoreerimine pilvepõhisteks teenusteks ilma seisakuid tekitamata

Pärand-API migreerimine pilvepõhisele asendusele on strangler fig mustri spetsiifiline rakendus, millel on täiendavad piirangud: pärand-API-l võivad olla tarbijad, keda ei saa samaaegselt värskendada, API lepingut tuleb kogu ülemineku vältel säilitada ja pilvepõhisel asendusel võivad olla erinevad jõudlusomadused, mis mõjutavad tarbijaid ootamatutel viisidel.

Standardmeetodiks on pilvepõhine asendus juurutada sama API-lepingu taha kui pärand-API, suunata teatud protsent liiklusest asendajale, kasutades canary-tehnikaid, valideerida selle liiklusprotsendi väljundpariteedi ja suurendada suunamise protsenti järk-järgult. Tarbijad ei pea selle ülemineku ajal midagi muutma, kuna API-leping säilib. Marsruutimiskiht haldab üleminekut läbipaistvalt.

Nullseisakuteta üleminek põhiintegratsioonidelt vahevara API-dele, mis selle artikli Search Console'i ​​andmetes kuvatakse kõrge kavatsusega päringuna, on täpselt selline stsenaarium: hetk, mil marsruutimiskihti värskendatakse, et suunata sada protsenti liiklusest uude süsteemi, ja pärand-API deaktiveeritakse. See üleminek ei tohiks kunagi olla ühekordne sündmus. See peaks olema järkjärgulise juurutamise viimane samm, mis on juba valideerinud uue süsteemi üha suurema liikluse protsendi juures. Lõpliku ülemineku ajaks on uus süsteem juba kogu liiklusmahu käsitlenud; üleminek eemaldab lihtsalt varuvariandi, mida enam ei vajata.

Idempotentsus, uuestikatsed ja tõrkesiire ümberkujundatud süsteemides

Sündmustepõhist arhitektuuri, sõnumijärjekordi või hajutatud teenusekõnesid kasutava süsteemi refaktoriseerimine toob kaasa probleemide klassi, mida puhtalt juurutamisele keskendunud mustrid ei lahenda: mis juhtub teenuse käitamisega, kui teenus läheb üle vanalt versioonilt uude versiooni? Vanas versioonis avaldatud sündmused võivad jõuda uut versiooni käitava käitlejani. Vana API vastu algatatud päringud võivad jõuda käitlejani, mis on juba uuele sisemisele struktuurile refaktoreeritud. Tehingud, mis vana loogika alusel osaliselt lõpule viidi, võidakse uue loogika alusel kas lõpule viia või kompenseerida.

Kõigi nende probleemide lahendus on idempotentsus: iga operatsiooni kujundamine nii, et see annaks sama tulemuse olenemata sellest, kas seda käivitatakse üks või mitu korda. Idempotentne käitleja, mis saab juurutamise ülemineku ajal duplikaadi, annab sama väljundi kui see, mis saab sündmuse täpselt üks kord. Idempotentne kirjutamisoperatsioon, mida korratakse tagasipööramise osana, annab sama andmebaasi oleku kui algne kirjutamine. Idempotentsus ei ole ainult refaktoriseerimisega seotud probleem: see on vastupidavate hajutatud süsteemide üldine omadus. Kuid just refaktoriseerimise üleminekute ajal põhjustab selle puudumine kõige nähtavamaid tõrkeid.

Uuesti proovimise ja pakkuja tõrkesiirde lisamine ilma suure ümbertegemiseta

Üks levinumaid küsimusi selle artikli Search Console'i ​​andmetes on see, kuidas lisada olemasolevale rakendusele, eriti Railsi või sarnasele raamistikurakendusele, uuesti proovimise ja tõrkesiirde võimalusi ilma põhjalikku ümbertegemist ette võtmata. Vastus on, et uuesti proovimise ja tõrkesiirde saab lisada läbiva funktsioonina infrastruktuuri tasandil ilma üksikute teenuste rakendamist muutmata.

Taristukihil saab teenusevõrku, näiteks Istiot või Linkerdi, konfigureerida ebaõnnestunud päringute automaatseks uuesti proovimiseks kuni määratletud uuestiproovimiste arvuni, eksponentsiaalse tagasilükkamise ja värinaga, et vältida äkilist karjakäitumist. See ei nõua rakenduse koodi muutmist, kuna uuesti proovimise käitumine on rakendatud kõrvalserveris, mis pealt kuulab kõik sissetulevad ja väljaminevad päringud. Pakkuja tõrkesiirde saab rakendada sarnaselt: kui peamine pakkuja tagastab läviväärtust ületava vea, suunab võrk järgnevad päringud teisele pakkujale, kuni peamine pakkuja taastub.

Rakenduskihis, kui infrastruktuuri tasemel uuestiproovimisest ei piisa, kuna uuestiproovimise loogika peab olema teadlik ettevõtte olekust, saab rakenduse ja väliste sõltuvuste piirile luua kerge uuestiproovimise teeki või tööjärjekorra ilma rakendust sisemiselt ümber korraldamata. Peamine on uuestiproovimise ja tõrkesiirde loogika isoleerimine integratsioonipiirile, mitte selle jaotamine kogu äriloogika kihi ulatuses. See muudab uuestiproovimise käitumise nähtavaks, testitavaks ja konfigureeritavaks ilma rakenduse põhistruktuuri puudutamata. Nagu arutletud kontekstis agiilsed refaktoreerimise praktikadTaristu tasemel usaldusväärsusmustrite kasutuselevõtt enne äriloogika refaktoreerimist vähendab iga muudatuse järel valideeritava teabe hulka.

Idempotentsus sündmuspõhistes arhitektuurides Redis Streamsi abil

Redis Streamsi või sarnaseid tehnoloogiaid kasutavad madala latentsusega sündmustepõhised arhitektuurid seisavad refaktoreerimise ajal silmitsi spetsiifilise idempotentsuse probleemiga: tarbijarühmad võivad sündmusi töödelda erineva kiirusega, uue versiooni sündmusi lugev tarbija võib olla juba sündmusi töödelnud, mida vana versioon pole, ning kordus- või taastamistoimingud võivad sama sündmuse mitu korda edastada käitlejatele, mis ei ole loodud duplikaatide käsitlemiseks.

Standardmeetodiks on määrata igale sündmusele avaldamise ajal unikaalne identifikaator ja jälgida töödeldud sündmuste identifikaatoreid püsivas salves. Enne sündmuse töötlemist kontrollib käitleja, kas identifikaatorit on juba töödeldud. Kui on, siis sündmus kinnitatakse ja see visatakse uuesti töötlemiseta. Kui ei ole, siis sündmus töödeldakse ja identifikaator salvestatakse. See deduplikatsiooniloogika peab olema aatomiline: kui käitleja töötleb sündmust, kuid ebaõnnestub enne identifikaatori salvestamist, töödeldakse sündmust uuesti järgmisel edastamisel. Redise aatomiliste toimingute või tehinguliste kirjutamiste kasutamine identifikaatori salvestamiseks töötlemistoimingu osana hoiab ära selle võidujooksu tingimuse.

Refaktoreerimise ülemineku ajal, mille käigus tarbijaloogika muutub, pakuvad idempotentsuse identifikaatorid täiendavat eelist: need võimaldavad sündmuste voogu uue tarbijaloogika suhtes taasesitada ja väljundeid vana tarbijaloogika salvestatud väljunditega võrrelda, võimaldades võrdlustestimist ilma kasutajatele uut loogikat paljastamata.

Refaktoreerimise automatiseerimine CI/CD torujuhtmetes

Null-seisakuaja refaktoriseerimise distsipliini ei saa käsitsi protsessidega säilitada. Iga juurutamine null-seisakuaja programmis nõuab valideerimiste jada: juurutamiseelsed kontrollid, et uus versioon ühildub praeguse andmebaasi olekuga, iga liiklusprotsendi suurenemise korral kontrollitakse nn. Canary Gate'i, vanade ja uute kooditeede väljundite automaatne võrdlemine ning juurutamisjärgne kontroll, et peamised mõõdikud pole halvenenud. Nende sammude käsitsi sooritamine iga muudatuse puhul ei ole operatiivselt jätkusuutlik ja toob kaasa inimlikke vigu protsessi kõige kriitilisemates punktides.

Null-seisakuaja refaktoriseerimiseks mõeldud CI/CD torujuhe ei ole lihtsalt ehitus- ja juurutamistorujuhe. See on valideerimistorujuhe: automatiseeritud väravate jada, mis kõik peavad läbima enne, kui muudatus liigub juurutamise järgmisse etappi. Iga värav on konkreetne, mõõdetav kriteerium. Värava ebaõnnestumine peatab torujuhe ja käivitab hoiatuse. Kõigi väravate läbimine viib juurutamise automaatselt järgmisse etappi. Nagu on kirjeldatud laiemas arutelus teema kohta CI/CD tavad suurarvutite ja ettevõttekeskkondade jaoks, on põhinõue, et torujuhe rakendaks iga muudatuse puhul sama juurutamisdistsipliini, olenemata selle suurusest, ning et jõustamine oleks automatiseeritud, mitte sõltuks üksikute inseneride tähelepanelikkusest.

Reaalajas refaktoreerimise torujuhtme etapiväravad

Etapiväravad on valideerimispunktid, mille juurutamine peab enne edasiliikumist läbima. Null-seisakuajaga refaktoreerimistorustiku jaoks on minimaalne väravate komplekt järgmine.

Eeljuurutamine: skeemi ühilduvuskontroll kinnitab, et andmebaasi migratsioon on tagasiühilduv rakenduse praeguse versiooniga, automatiseeritud lepingutestid kontrollivad, kas uue versiooni API vastused on ühilduvad eelmise versiooni lepinguga, ja staatiline sõltuvusanalüüs kinnitab, et ükski uue versiooni tekitatav sõltuvus ei ole vastuolus olemasoleva keskkonna nõutava sõltuvusega.

Pärast juurutamist Canarysse: Canary ja baasliikluse veamäära võrdlus, latentsuse võrdlus p50, p95 ja p99 juures, ärimõõdikute võrdlus kõigi mõõdikute puhul, mida muudetud kooditee mõjutab, ja minimaalne vaatlusaken, mille jooksul Canary peab jääma stabiilseks enne liikluse protsendi suurendamist.

Pärast täielikku juurutamist: regressioonitestide komplekt tootmiskeskkonna lõpp-punktide suhtes, andmebaasi järjepidevuse kontrollid, mis kinnitavad, et mis tahes topeltkirjutamise või laiendatud lepinguga migreerimine on säilitanud järjepidevuse, ja kinnitus, et eelmine juurutamise artefakt on endiselt tagasipööramiseks saadaval.

Nõuetele vastav refaktoreerimine ja jõustamine

Vastavusest lähtuv refaktoriseerimine toob kaasa täiendava piirangu, mida konveieri väravad peavad jõustama: iga muudatus peab olema tõendatavalt kooskõlas kohaldatavate regulatiivsete või organisatsiooniliste poliitikanõuetega. Reguleeritud tööstusharudes tähendab see, et juurutamiskonveier peab looma auditeerimisjälje, mis näitab, mida muudeti, millal see juurutati, millist valideerimist teostati ja kes selle heaks kiitis. Automatiseeritud konveieri väravad, mis salvestavad omaenda teostuse, sealhulgas sisendoleku, värava kriteeriumid ja läbimise/mitte läbimise tulemuse, pakuvad seda auditeerimisjälge ilma käsitsi dokumenteerimise vaevata.

Nutikad refaktorimisplatvormid, millel on meeskonnaülesed jõustamisvõimalused ja mis kuvatakse selle artikli Search Console'i ​​andmetes päringuna, on tööriistad, mis integreerivad vastavuse valideerimise refaktoreerimise töövoogu: tagades, et refaktorimismustreid rakendatakse meeskondades järjepidevalt, et aegunud liideseid ei taaskehtestata ja et struktuurimuudatused vastavad organisatsiooni tasandil määratletud arhitektuuristandarditele. Need võimalused ulatuvad kaugemale sellest, mida pakub ainult CI/CD torujuhe, kuna need nõuavad muudetava koodi semantika mõistmist, mitte ainult seda, kas see luuakse ja läbib teste.

Suurarvutite ja CICS-ide refaktoreerimine ilma seisakuteta

Suurarvutikeskkonnad pakuvad nullseisakute refaktoreerimise kõige nõudlikumat versiooni, kuna piirangud on pigem struktuurilised kui konfigureeritavad. CICS-i tehinguprogrammi ei saa asendada uue konteineri kujutise juurutamise ja koormuse tasakaalustaja vahetamisega. Programmi asendamine CICS-is nõuab käsku NEWCOPY või PHASEIN, mis laadib programmi uue versiooni mällu. NEWCOPY asendab vana versiooni kohe, mõjutades kõiki tehinguid, mis algavad pärast käsu täitmist. PHASEIN ootab enne vana versiooni asendamist, kuni kõik aktiivsed tehingud on vana versiooni kasutades lõpule viidud, pakkudes pikalt kestvatele tehingutele sujuvamat üleminekut.

Kumbki mehhanism ei paku kohest tagasipööramist. Kui programmi uues versioonis on defekt, tuleb vana versiooni juurde naasmiseks koos eelmise laadimismooduliga uuesti väljastada käsk NEWCOPY või PHASEIN. See eeldab, et eelmine laadimismoodul säilitatakse laadimisteegis ning et tagasipööramise protseduur dokumenteeritakse, harjutatakse ja käivitatakse valvemeeskonna poolt ilma algse arendaja kaasamiseta.

Jagatud VSAM-failid lisavad täiendava piirangu. Mitu CICS-tehingut ja pakktöötlusprogrammi võivad samale VSAM-failile samaaegselt juurde pääseda. Faili paigutuse struktuurimuutus, näiteks kirjesegmendi lisamine või laiendamine, nõuab, et kõik failile juurde pääsevad programmid oleksid enne paigutuse muutmist või sellega samaaegselt uuendatud või et fail toetaks üleminekuperioodil mitut kirjevormingut. See on laiendamis-leping-mustri suurarvuti vaste: uus paigutus peab ülemineku ajal olema vanade programmidega ühilduv ja vanad programmid tuleb enne vana paigutuse kasutusest kõrvaldamist uuendada. Andmekogumite paigutuste ja programmidele juurdepääsu parameetrite kontrollitud laiendamine on mehhanism, mis muudab selle ühilduva kooseksisteerimise võimalikuks ilma faili asendamiseta.

Partiiakna elimineerimise strateegiad

Traditsiooniline suurarvuti partiitöötlus eeldab partiiakna olemasolu: periood, mille jooksul veebitehingute töötlemine on peatatud, partiitööd töötavad ilma konkurentsita ja saadud andmed on valmis järgmiseks veebitöötlusperioodiks. Partiiakna kaotamine, mis on vajalik tõeliselt seisakuteta tööks, tähendab partiitöötlusmudeli ümberkujundamist nii, et partiitööd saaksid töötada samaaegselt veebitehingutega ilma jagatud andmeid rikkumata.

Standardmeetodid on ressursitasemel lukustamine kirje, mitte faili tasandil, sündmustepõhine minipaketttöötlus, mis töötleb väikeseid töökoormusi pidevalt, mitte suuri töökoormusi perioodiliselt, ja lugemis-replikaadi andmebaasid, mis teenindavad partiiaruandluse töökoormusi, konkureerimata kirjutamisõiguse pärast veebipõhise tehingutöötlusega. Kõik need lähenemisviisid nõuavad muudatusi nii programmides kui ka andmetele juurdepääsu mustrites, kuid ükski ei nõua, et partiiaken jääks ülemineku ajal alles: üleminekut ennast saab läbi viia sama kahekordse valideerimise lähenemisviisi abil, mida kasutatakse mis tahes muu reaalajas süsteemi ümberfaktoriseerimise puhul.

COBOL-programmi refaktoreerimine mõjuanalüüsi abil

COBOL-programmi ohutuks refaktoreerimiseks on enne mis tahes muudatuse tegemist vaja teada täpselt, millised teised programmid seda kutsuvad, milliseid käsiraamatuid see teiste programmidega jagab, milliseid andmekogumeid see loeb ja kirjutab ning millised allavoolu süsteemid sõltuvad selle loodud andmetest. Ilma selle struktuurilise teadmiseta kaasneb programmi mis tahes muudatusega tundmatu risk: refaktoreeritud programm võib murda tuvastamata kutsuja, toota väljundit vormingus, mida allavoolu süsteem ei saa parsida, või muuta jagatud andmestruktuuri viisil, mis mõjutab teisi programme, mis sisaldavad sama käsiraamatut.

Automatiseeritud mõjuanalüüs lahendab selle probleemi, luues enne refaktoriseerimise algust COBOL-programmi täieliku sõltuvusgraafiku. Graafik näitab iga kutsujat, iga jagatud käsikirja, iga andmestiku juurdepääsu ja iga allavoolu tarbijat, mis on korraldatud seose tüübi ja konkreetse viitekoha järgi. Seejärel tuletatakse refaktoriseerimisplaan mõjugraafikust: muudetud programmi kutsuvaid programme tuleb testida uue versiooni suhtes, muudetud käsikirjad tuleb valideerida kõigi neid sisaldavate programmide suhtes ja muudetud andmestiku paigutused tuleb valideerida kõigi programmide suhtes, mis pääsevad juurde samadele andmekogumitele. Nagu on kirjeldatud jaotises mõjuanalüüsi lahendused mida IN-COM pakub, on see erinevus refaktoreerimisprogrammi, mis avastab oma tagajärjed pärast juurutamist, ja programmi vahel, mis kvantifitseerib need enne juurutamist.

Kontrollimine, tagasipööramine ja jälgitavus

Nullseisakuteta refaktoriseerimine annab pideva väljundi, mida tuleb pidevalt jälgida. Monitooring ei ole tagantjärele kontroll, kas kõik toimis: see on aktiivne kontroll juurutamisprotsessi igas etapis ja peamine mehhanism, mille kaudu probleemid tuvastatakse piisavalt varakult, et vältida kasutajate mõjutamist.

Null-seisakuteta refaktoreerimise verifitseerimismudelil on kolm kihti. Esimene on sünteetiline monitooring: skriptitud tehingud, mis simuleerivad kasutaja käitumist ja töötavad pidevalt tootmiskeskkonnas, valideerides, et võtmevood on edukalt lõpule viidud. Sünteetilised monitooringud püüavad kinni vigu, mis esinevad teatud koodiradadel, mida päris kasutajad vähese liiklusega perioodidel ei pruugi kasutada, ning pakuvad käitumise baasjoont, millega saab võrrelda eeldatavaid tulemusi.

Teine kiht on diferentsiaalmonitooring: canary-juurutuse ja baasjuurutuse mõõdikute reaalajas võrdlus, sealhulgas veamäärad, latentsusjaotused, ärimõõdikud ja ressursikasutus. Diferentsiaalmonitooring ei nõua absoluutseid lävesid: see nõuab suhtelist võrdlust. Canary-juurutus, mis näitab kaks protsenti kõrgemaid veamäärasid kui baasjuurutus, on probleem olenemata sellest, kas absoluutne veamäär ületab mõnda individuaalselt määratletud läve.

Kolmas kiht on andmete järjepidevuse kontrollimine. Igasuguse refaktoreerimise puhul, mis hõlmab kahekordset kirjutamist, skeemide migreerimist või paralleelseid süsteemikäitusi, tuleb vana ja uue esituse vahelist andmete järjepidevust pidevalt valideerida. Kontrollsummade võrdlused, kirjete arvu võrdlused ja pistelise kontrolli päringud, mis kontrollivad konkreetsete väljaväärtuste vastavust oodatavatele teisendustele, aitavad kõik kaasa kindlusele, et andmekiht käitub ülemineku ajal õigesti. Nagu on uuritud kontekstis Mis on mõjuanalüüs ja miks see on oluline, on struktureeritud refaktoreerimise ja spekulatiivse muudatuse erinevuseks võime kontrollida muudatuse tagajärgi määratletud ootuste kogumi suhtes.

Kohese tagasipööramise mehhanismid

Tagasipöördumisplaan, mille täitmiseks kulub kolmkümmend minutit, ei ole nullseisakutega süsteemile mõeldud tagasipöördumisplaan. Selle valmimise ajaks on kasutajatele juba osutatud kolmkümmend minutit halvenenud teenust. Kohene tagasipööramine eeldab, et iga juurutus oleks algusest peale kavandatud pöörduvusega, mitte hiljem, kui probleem tekib.

Rakenduste juurutamise puhul tähendab kohene tagasipööramine eelmise juurutamise artefakti kättesaadavaks tegemist, eelsoojendamist ja samale andmebaasi olekule suunamist. Liikluse vahetamine koormuse tasakaalustaja või API lüüsi reegli muutmise kaudu peaks olema ainus toiming, mis on vajalik eelmise versiooni taastamiseks. See on saavutatav siis, kui andmebaasi olek on tagasiühilduv eelmise versiooniga, mida tagab andmebaasi migreerimiskihi laiendatud lepingu distsipliin.

Andmebaasi migratsioonide puhul nõuab kohene tagasipööramine, et iga laiendamisfaasis rakendatud migratsioon oleks tagasipööratav ilma andmete kadumiseta. Laiendamisfaasis lisatud veeru saab tagasipööramise käigus eemaldada. Destruktiivselt muudetud veergu ei saa ilma varukoopiata taastada. Seetõttu ei tohiks destruktiivseid skeemimuudatusi, mis eemaldavad veerge, muudavad tüüpe ühildumatul viisil või vähendavad täpsust, kunagi rakendada enne, kui uus versioon on täielikult juurutatud ja valideeritud ning vana versioon on täielikult eemaldatud.

Kuidas SMART TS XL Toetab nullseisakuid vältivaid refaktoreerimisprogramme

SMART TS XL käsitleb struktuurilise nähtavuse probleemi, mis on iga seisakuteta refaktoreerimise tõrke aluseks: meeskonnad üritavad reaalajas süsteeme refaktoreerida ilma täieliku ülevaateta sellest, mida need süsteemid sisaldavad, mis millest sõltub ja millised on iga kavandatud muudatuse tagajärjed. Platvorm võtab alla lähtekoodi kõigist keskkonna keeltest ja platvormidest, sealhulgas COBOL, JCL, Java, .NET, Python, JavaScript ja SQL, ning loob ühtse ristviidete mudeli, mis esindab kogu süsteemi struktuurilisi seoseid.

Enne refaktoreerimismuudatuse tegemist SMART TS XLmõjuanalüüsi võimalus jälgib sõltuvusgraafikut muudetavast komponendist väljapoole läbi iga kutsuja, iga jagatud andmestruktuuri, iga allavoolu tarbija ja iga programmi, mida muudatus mõjutab. Tulemuseks on konkreetne, loetletud tagajärgede loend, mis on järjestatud tõsiduse ja komponendi järgi, mitte üldine riskihinnang. See loend võimaldab õigesti planeerida nullseisakuajalist refaktoriseerimisjärjestust: teades, milliseid tarbijaid tuleb enne muudetud komponendi juurutamist värskendada, milliseid andmebaasi migratsioone tuleb enne milliseid rakenduste juurutusi järjestada ja milliseid allavoolu süsteeme tuleb enne vana versiooni eemaldamist valideerida.

SMART TS XLkoodi visualiseerimise võimalus muudab sõltuvusgraafiku navigeeritavaks meeskondadele, kellel puudub sügav ülevaade igast ümberkujundatava süsteemi kihist. Arhitektid näevad enne ühendusstruktuuri ümberkujundamist, kuidas komponendid ühenduvad. Arendajad näevad enne funktsiooni signatuuri muutmist, mis seda kutsub. Operatsioonimeeskonnad näevad enne paigutuse muutmist, mille poolt andmestikku kasutatakse. See nähtavus on eeltingimus struktureeritud, pöörduva ja etapiviisilise ümberfaktoriseerimise programmi jaoks, mida nullseisakuaeg nõuab.

Null-seisakute refaktoreerimine kui pidev praktika

Selles juhendis kirjeldatud meetodid ei ole ühekordsed sekkumised. Need on arendusorganisatsiooni operatiivne sõnavara, mis on otsustanud käsitleda tootmissüsteeme pidevalt arenevatena, mitte perioodiliselt asendatavatena. Sinirohelised juurutused, nn. „canary releases”, funktsioonide lülitamised, laiendatud lepingute migratsioonid, kägistaja figuuride ekstraheerimine, idempotentsete sündmuste töötlemine ja konveieri poolt jõustatud juurutamisväravad ei ole hädaolukorra protseduurid: need on meeskonna standardsed tööprotseduurid, mis edastavad struktuurimuudatusi ohutult ja suure sagedusega.

Selle oleku saavutamiseks on vaja investeeringuid tööriistadesse, infrastruktuuri ja organisatsioonilistesse praktikatesse, mis ulatuvad kaugemale igast individuaalsest ümberfaktoriseerimise algatusest. Tööriistad peavad toetama sõltumatut juurutatavust, jälgitavaid oleku üleminekuid ja kohest tagasipööramist. Infrastruktuur peab toetama liikluse jagamist, sinakasrohelisi keskkondi ja CDC-põhist andmete sünkroniseerimist. Organisatsiooniline praktika peab hõlmama juurutamiseelset mõjuanalüüsi, juurutamisjärgset erinevuste jälgimist ja regulaarseid tagasipööramise proove, mis kinnitavad tagasipööramise tee toimimist realistlikes tingimustes.

Organisatsioonid, kes selle investeeringu teevad, leiavad, et muudatuse maksumus väheneb praktika küpsedes: iga järgnev refaktoriseerimine on vähem riskantne kui eelmine, kuna toetav infrastruktuur on juba olemas, meeskond on välja töötanud hinnangu selle kohta, millised läviväärtused sobivad milliste muudatuste jaoks, ja kogunenud struktuurilised teadmised sellistes tööriistades nagu SMART TS XL muudab iga planeeritud muudatuse ulatuse täpsemaks kui eelmise. Null-seisakuaja refaktoreerimise eesmärk ei ole ühe muudatuse turvaline tegemine. See on iga muudatuse turvaline ja pidev tegemine, ilma et kasutajatelt kunagi hooldusaknaga nõustumist küsitaks.