Erfenisdienste in jou infrastruktuur

Hallo! My naam is Pasha Chernyak, ek is 'n toonaangewende ontwikkelaar by QIWI, en vandag wil ek oor die onvermydelike praat. Oor Legacy.

Kom ons begin met die vraag: wat is Legacy-diens? Is 'n erfenisdiens 'n diens wat die ontwikkelaar vir 'n week/maand/jaar nie aangeraak het nie? Of is dit 'n diens wat deur 'n minder ervare programmeerder geskryf is, byvoorbeeld deur jou spesifiek, maar 'n jaar gelede? En nou is jy koeler en meer ervare. Of is die Legacy-diens 'n diens wat jy besluit het om nooit weer te verbind nie en stadig besig is om 'n plaasvervanger daarvoor voor te berei? Om so 'n diens sonder toesig te laat en nie op te dateer nie, is in elk geval 'n tydbom wat later kan ontplof.

Voordat ek verder gaan na hoe ons by QIWI met ons Legacy-dienste werk, sal ek jou vertel hoe ons orde in die dienste in die Wallet gebring het. Ek is nou al vir twee jaar verantwoordelik vir die prestasie daarvan. As daar enige probleem is, bel hulle my altyd eerste. Ek het gewoonlik nie die moed om iemand anders om 11:XNUMX te bel nie, so ek moes gaan sit en al die dienste op ons domein uitvind.

Maar ek, soos enige persoon, hou daarvan om snags te slaap, so ek het probeer om die uitbuiting te hanteer: "Manne, hoekom bel julle my?" Waarop ek 'n taamlik lakoniese antwoord gekry het soos "Wie anders?" Want ek maak dienste reg, en die ouens weet eenvoudig nie wie om te bel nie.

Daarom, by een van die terugskouings van die Wallet-agtergrondspan, het ons besluit dat ons 'n bord moet maak met 'n lys van ons dienste, mikrodienste en beursie-monoliete, en diegene wat daarvoor verantwoordelik is. Tekens is oor die algemeen nuttig, binne redelike perke.

Benewens inligting oor wie waarvoor verantwoordelik is, was daar antwoorde op die vrae: wie is die eienaar van die diens, wie is verantwoordelik vir die ontwikkeling, argitektuur en lewensiklus daarvan. Die mense wat vir hierdie diens verantwoordelik is, is die mense wat dit kan regmaak as iets gebeur. Die eienaar van die diens het die reg om +2 in commits te verlaat, diegene wat verantwoordelik is moet ook teenwoordig wees by die hersiening voordat hierdie diens 'n nuwe commit aanvaar.

Soos die tyd aangestap het, het nuwe praktyke begin toegepas word, byvoorbeeld migrasie na Kubernetes, allerhande checkstyle, spotbugs, ktlint, die teenwoordigheid van logs in Kibana, outo-ontdekkingsdienste in plaas daarvan om adresse direk te spesifiseer en ander nuttige dinge. En oral het ons tafel ons toegelaat om die relevansie van ons dienste te handhaaf. Vir ons is dit 'n soort kontrolelys wat sê dat hierdie diens dit kan doen, maar dit doen nog nie. Maar ons het aanbeweeg en besef dat ons nie inligting oor ons dienste het nie, wat ons monitor, waar die diensbronne geleë is, waar monteertake in TeamCity geloods word, hoe dit ontplooi word, waar die bronne van end2end-toetse gestoor word, foto's van versorgingsessies oor die argitektuur, oor die besluite wat geneem is. Ideaal gesproke wil ek graag hê dat al hierdie inligting iewers lê en byderhand moet wees wanneer dit nodig is. Daarom het ons teken die beginpunt geword om na inligting te soek.

Maar QIWI, hoewel dit die gees van 'n begin behou, is 'n groot maatskappy. Ons is reeds 12 jaar oud, en spanne verander: mense vertrek, mense kom, nuwe spanne word gevorm. En ons het verskeie dienste op ons domein ontdek wat ons geërf het. Sommige het van ontwikkelaars van ander spanne gekom, sommige het bloot op een of ander manier indirek met die Wallet verband gehou, so ons het nou die diens op ons balansstaat. Om te verstaan ​​wat en hoe dit werk - hoekom? Die diens werk, en ons het produkkenmerke wat beslis verbeter moet word.

Hoe dit gebeur

Maar op 'n sekere tydstip ontdek ons ​​dat die diens ophou om sy funksie te verrig, iets is stukkend - wat om te doen in so 'n situasie? Die diens het eenvoudig opgehou werk. Enigsins. En ons het hiervan uitgevind, eerstens per ongeluk, en tweedens, ses maande later. Dit gebeur. Die enigste ding wat ons geweet het, was op watter virtuele masjiene die diens ontplooi sou word, waar die bronne daarvan geleë was, en dit is al. Ons doen 'n git-kloon en duik in die gedagtes van die persoon wat dit 'n paar jaar gelede geskryf het, maar wat sien ons? Nie een van die Spring Boot wat aan ons bekend is nie, alhoewel ons aan alles gewoond is, het ons 'n vol stapel en al die dinge. Miskien is daar 'n Lenteraamwerk daar? Maar nee.

Die ou wat dit alles geskryf het, was taai en het alles in pure Java geskryf. Daar is geen gewone gereedskap vir 'n ontwikkelaar nie, en 'n idee ontstaan: ons moet dit alles herskryf. Ons het mikrodienste, en uit elke broodrooster kom die gewone "Ouens, mikrodienste is wat jy nodig het!" As iets skielik verkeerd loop, kan jy rustig enige taal neem en alles sal reg wees.

Die ding is dat ons nou nie 'n kliënt het wat vir hierdie diens verantwoordelik is nie. Watter besigheidsvereistes het hy gehad, wat moet hierdie diens doen? En die diens is stewig geïntegreer in jou besigheidsprosesse.

Sê nou vir my, hoe maklik is dit om 'n diens te herskryf sonder om die besigheidsvereistes te ken? Dit is nie duidelik hoe die diens aangeteken word nie; of daar maatstawwe is, is onbekend. Wat hulle is, indien enige, is des te meer onbekend. En terselfdertyd bevat die diens 'n groot aantal klasse van onverstaanbare besigheidslogika. Iets is ingesluit in een of ander databasis, waarvan ons ook nog niks weet nie.

Waar begin jy?

Van die mees logiese punt - die beskikbaarheid van toetse. Daar is gewoonlik ten minste 'n mate van logika daar geskryf en jy kan gevolgtrekkings maak oor wat aan die gebeur is. Nou is TDD modieus, maar ons sien dat 5 jaar gelede alles amper dieselfde was as wat dit nou is: daar is amper geen eenheidstoetse nie, en hulle sal ons glad nie iets vertel nie. Wel, behalwe miskien 'n soort verifikasie, hoe sommige xml onderteken is met 'n pasgemaakte sertifikaat.

Ons kon niks van die kode verstaan ​​nie, so ons het gaan kyk wat in die virtuele masjien is. Ons het die dienslogboeke oopgemaak en 'n http-kliëntfout daarin gevind; die selfondertekende sertifikaat wat in die toepassinghulpbronne ingebed was, was skaamteloos vrot. Ons het ons ontleders gekontak, hulle het 'n nuwe sertifikaat gevra, hulle het dit aan ons uitgereik en die diens werk weer. Dit wil voorkom asof dit al is. Of nie? Die diens werk immers, dit verrig een of ander funksie wat ons besigheid nodig het. Ons het sekere standaarde vir toepassingsontwikkeling, wat u waarskynlik ook het. Byvoorbeeld, moenie logs op die nodus in 'n vouer stoor nie, maar stoor dit in 'n soort berging, soos rek, en kyk daarna in Kibana. Jy kan ook die goue maatstawwe onthou. Dit wil sê die las op die diens, die aantal versoeke vir die diens, of hy lewe of nie, hoe sy HealthCheck gaan. Ten minste sal hierdie maatstawwe jou help om te weet wanneer dit met 'n skoon gewete uit diens geneem kan word en soos 'n slegte droom vergeet kan word.

Wat om te doen

Daarom voeg ons so 'n ou diens by die tafel, en dan gaan soek ons ​​vrywilligers onder die ontwikkelaars wat vir die diens sal sorg en dit in orde sal bring: hulle sal ten minste 'n bietjie inligting oor die diens skryf, skakels byvoeg na dashboards in grafana, om take te monteer, en verstaan ​​hoe die toepassing ontplooi, moenie lêers met die hand oplaai met ftp nie.

Die belangrikste ding is hoe lank sal al hierdie nuttige vrywilligersaktiwiteit neem? Een naelloop vir 'n min of meer ervare ontwikkelaar, byvoorbeeld tydens 'n 20% tegniese skuld. Hoe lank het dit geneem om al die ingeburgerde logika van kommunikasie met 'n sekere staatstelsel te verstaan ​​en dit na nuwer tegnologieë te bring? Ek kan nie hiervoor instaan ​​nie, miskien 'n maand of dalk twee van die span se werk. Ek sê dit uit ondervinding van huidige integrasie met een of ander nuwe diens.

Terselfdertyd is daar geen vrystelling van besigheidswaarde nie. Enigsins. Dit is normaal om 'n diens vir ondersteuning te huur en 'n bietjie tyd daaraan te spandeer. Maar na ons standaard danse met die diens, het ons dit by die tafel gevoeg, inligting daaroor bygevoeg en, miskien, sal dit eendag herskryf. Maar nou voldoen dit aan ons diensstandaarde.

Gevolglik wil ek graag met 'n plan vorendag kom vir wat om met Legacy-dienste te doen.

Om nalatenskap van nuuts af te herskryf is 'n slegte idee
Ernstig, jy hoef nie eers daaraan te dink nie. Dit is duidelik dat ek daarvan sal hou, en daar is 'n paar voordele, maar gewoonlik het niemand dit nodig nie, insluitend jyself.

Directory
Grawe die bronkodes van jou toepassings uit, maak 'n naslaanboek wat sal aandui wat is waar en hoe dit werk, voer 'n beskrywing van die projek daar in (voorwaardelike readme.md) om vinnig te verstaan ​​waar die logs en metrieke geleë is. Die ontwikkelaar wat dit na jou sal hanteer, sal net dankie sê.

Verstaan ​​die domein
As jy 'n domein besit, probeer om jou vinger op die pols te hou. Dit klink triviaal, ja, maar nie almal maak seker dat die dienste in 'n enkele sleutel is nie. Maar om in een standaard te werk, is eintlik aansienlik makliker.

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Wat doen jy met jou nalatenskap?

• 31.5%Ek herskryf van voor af, dit is meer korrek 12

• 52.6%Amper dieselfde as jy20

• 10.5%Ons het nie nalatenskap nie, ons is wonderlik4

• 5.2%Ek sal in die kommentaar skryf2

38 gebruikers het gestem. 20 gebruikers het buite stemming gebly.

Bron: will.com