NGINX-i kaasaegsete rakenduste arendamise põhimõtted. Osa 1

Tere, sõbrad. Kursuse «Backend arendaja PHP-s», traditsiooniliselt jagame teiega kasulikku materjali.

Tarkvara lahendab üha enam igapäevaseid ülesandeid, samal ajal muutudes järjest keerulisemaks. Nagu kord ütles Mark Andreessen, see neelab maailma.

Seetõttu on viimase paarikümne aasta jooksul rakenduste arendamise ja tarnimise lähenemised muutunud. Need on olnud tektoonilised muutused, mis on toonud kaasa põhimõtete kogumi. Need põhimõtted osutusid kasulikuks teie meeskonna loomisel, projekteerimisel, arendamisel ja rakenduse lõppkasutajatele tarnimisel.

Põhimõtted saab kokku võtta järgmiselt: rakendus peab olema väike, võrgupõhine ja arendajale suunatud arhitektuuriga. Tuginedes nendele kolmele põhimõttele, saate luua usaldusväärse, keeruka rakenduse, mida saab kiiresti ja turvaliselt lõppkasutajale tarnida ning mida on kerge skaleerida ja laiendada.

Iga ettepaneku põhimõtte alusel on mitmeid aspekte, mida arutame, et näidata, kuidas iga põhimõte aitab kaasa peamise eesmärgi saavutamisele, milleks on usaldusväärsete rakenduste kiire tarnimine, mis on lihtsad hooldada ja kasutada. Arutame põhimõtteid nende vastanditega, et selgitada, mida tähendab näiteks „Veenduge, et kasutate väikuse põhimõtet».

Loodame, et see artikkel julgustab teid kasutama ettepanekut, et luua modernseid rakendusi, mis tagavad ühtse lähenemise projekteerimisel pidevalt kasvavas tehnoloogia virnas.

Nende põhimõtete rakendamisel leiate, et kasutate uusimaid tarkvaraarenduse suundi, sealhulgas lähenemist DevOps rakenduste arendusele ja tarnimisele, konteinerite kasutamine (näiteks Docker) ja konteinerite orkestreerimise raamistikud (näiteks Kubernetes), mikroteenuste kasutamine (sealhulgas Mikroteenuste Arhitektuur NGINX ja võrgusuhtluse arhitektuur mikroteenuste rakenduste jaoks.

Mis on kaasaegne rakendus?

Kaasaegsed rakendused? Kaasaegne virn? Mida täpselt tähendab „kaasaegne“?

Enamik arendajatest omab vaid üldistatult arusaama, millest tänapäevane rakendus koosneb, seetõttu tuleb selle mõistele selge määratlus anda.

Tänapäevane rakendus toetab mitut klienti, olgu need siis kasutajaliidese komponent JavaScripti raamatukogus React, mobiilirakendus Androidile või iOS-ile või rakendus, mis ühendub teisega API kaudu. Tänapäevane rakendus eeldab, et tal on määramata arv kliente, kellele ta andmeid või teenuseid pakub.

Tänapäevane rakendus pakub API-t, et pääseda juurde nõutud andmetele ja teenustele. API peab olema muutumatu ja püsiv, mitte kirjutatud spetsiaalselt teatud kliendi ühe konkreetse päringu jaoks. API on saadaval HTTP(S) kaudu ja tagab juurdepääsu kogu funktsionaalsusele, mis on saadaval GUI või CLI kaudu.

Andmed peavad olema kergesti ligipääsetavas, ühilduvas formaadis, näiteks JSON. API pakub objekte ja teenuseid arusaadavas, organisatsioonilises vormis, näiteks RESTful API või GraphQL tagab kvaliteetse liidese.

Tänapäevased rakendused on üles ehitatud kaasaegsele tehnoloogiapinnale, mis toetab selliseid rakendusi. Selline tehnoloogiapind võimaldab arendajal kergesti luua rakendusi, millel on HTTP-liides ja selged API lõpp-punktid. Valitud lähenemine võimaldab teie rakendusel hõlpsasti vastu võtta ja saata andmeid JSON-formaadis. Teisisõnu, kaasaegne tehnoloogia vastab Kaheteistkümne Faktoriga rakenduse elementidele. Mikroteenused.

Selle tüüpi tehnoloogiapinna populaarsed versioonid põhinevad Java, Python, Node, Ruby, PHP ja Go. Mikroteenuste arhitektuur NGINX toob esile näite kaasaegsest tehnoloogiapinnast, mis on rakendatud igas eespool nimetatud keeles.

Pange tähele, et me ei propageeri ainult mikroteenuste lähenemist. Paljud teist töötavad monoliitide kallal, mis peavad arenema, samas kui teised tegelevad SOA rakendustega, mis laienevad ja arenevad, et muutuda mikroteenuste rakendusteks. Kolmandad liiguvad suunas serverita (serverless) rakenduste rakendamine ning mõned rakendavad eelpool nimetatud kombinatsioone. Artiklis esitatud põhimõtted on kohaldatavad igasugustele nendele süsteemidele, ulatudes mõningate väikeste muudatusteni.

Põhimõtted

Nüüd, kui oleme saavutanud üldise arusaama sellest, mis on tänapäevane rakendus ja kaasaegne tehnoloogiaplatvorm, on aeg süveneda arhitektuuri ja arenduse põhimõtetesse, mis toovad kasu teie rakenduse loomisel, elluviimisel ja hooldamisel.

Üks põhimõtteid on «looge väikeseid rakendusi», nimetagem seda lihtsalt väike rakendusprintsiip. On olemas uskumatult keerulisi rakendusi, mis koosnevad paljusid liikuvatest komponentidest. See omakorda muudab rakenduse ehitamise väikestest eraldiseisvatest komponentidest lihtsamaks projekteerimise, hooldamise ja üldise kasutamise osas. (Pange tähele, et me ütlesime «lihtsamaks», mitte «lihtsaks»).

Teine põhimõte seisneb selles, et saame suurendada arendajate tootlikkust, aidates neil keskenduda neile funktsioonidele, mida nad arendavad, vabastades nad samas infrastruktuuri ja CI/CD hooldamise muredest elluviimise ajal. Nii et lühidalt öeldes, meie lähenemine on arendajale suunatud.

Lõpuks peab kõik teie rakendusega seonduv olema ühendatud võrku. Viimase 20 aasta jooksul oleme teinud suuri edusamme võrgu tuleviku suunas, kuna võrgud on muutunud kiiremaks ja rakendused keerukamaks. Nagu juba selgitasime, peab kaasaegne rakendus olema võrgu kaudu saadaval paljude erinevate klientide jaoks. Võrgupõhise mõtlemise rakendamine arhitektuuris toob kaasa märkimisväärseid eeliseid, mis sobivad hästi kokku väike rakendusprintsiip ja lähenemise mõistega, mille fookus on arendajatel.

Kui peate oma rakenduse arendamise ja kasutuselevõtu käigus silmas neid põhimõtteid, on teil vaieldamatu eelis oma toote arendamisel ja kohandamisel.

Uurime neid kolme põhimõtet lähemalt.

Väike rakendusprintsiip

Inimese ajul on keeruline samal ajal tajuda suurt hulka teavet. Psühholoogias tähendab kognitiivne koormus üldist vaimset pingutust, mis on vajalik info mäletamiseks. Arendajate kognitiivse koormuse vähendamine on prioriteet, kuna sel juhul saavad nad keskenduda probleemide lahendamisele, selle asemel et hoida peas praegust keerulist mudelit kogu rakendusest ja arendatavatest funktsioonidest.

Rakendused dekomponeeritakse järgmiste põhjusel:

• Arendajate kognitiivse koormuse vähendamine;
• Testimise kiirendamine ja lihtsustamine;
• Muudatuste kiire kohaletoimetamine rakenduses.

On mitu viisi, kuidas vähendada arendajate kognitiivset koormust, ja siin tulebki mängu väikeste asjade põhimõte.

Nii et kolm viisi kognitiivse koormuse vähendamiseks:

1. Vähendage ajavahemikke, mida nad peavad uue funktsiooni arendamisel arvestama – mida lühem on ajavahemik, seda madalam on kognitiivne koormus.
2. Vähendage korraga käsitletava koodi hulka – vähem koodi, vähem koormust.
3. Lihtsustage rakenduses inkrementaalsete muudatustega tegelemise protsessi.

Ajavahemike lühendamine arenduses

Naaseme aega, mil metodoloogia waterfall oli arendusprotsessi standardiks ja kuue kuu kuni kahe aasta pikkused ajavahemikud rakenduse arendamiseks või uuendamiseks olid tavaline praktika. Üldiselt lugesid esiteks insenerid asjakohaseid dokumente, nagu toote nõuded (PRD), süsteemi viidatud dokument (SRD), arhitektuuri plaani ja alustasid nende kõikide kokku panemist ühte kognitiivsesse mudelisse, mille kohaselt nad koodi kirjutasid. Nõuete ja seega ka arhitektuuri muutudes pidi vähemalt tiim olema pidevalt kurssi viidud kognitiivse mudeli uuendamisega. See lähenemine halvas töö kõige halvemal juhul täielikult.

Suurem muutus rakenduste arendamise protsessis oli agil-semetoodika kasutuselevõtt. Üks agili metodoloogia peamisi jooni on korduv arendamine. See omakorda toob kaasa inseneride kognitiivse koormuse vähenemise. Selle asemel, et nõuda arendajate meeskonnalt rakenduse elluviimist ühe pika tsükli jooksul, lubab lähenemine keskenduda väikestele koodihulkadele, mida on võimalik kiiresti testida ja juurutada, samal ajal kui saadakse ka tagasisidet. Rakenduse kognitiivne koormus on nihkunud kuue kuu kuni kahe aasta ajavahemikust koos tohutu hulkade spetsifikatsioonidega kahele nädalasele funktsiooni lisamiseks või muutmiseks, mis on suunatud ebaselgele mõistmisele suurest rakendusest. – on iteratiivne arendus. See omakorda vähendab inseneride kognitiivset koormust. Selle asemel, et nõuda arendusmeeskonnalt rakenduse elluviimist ühe pika tsükli jooksul, lubab lähenemine keskenduda väikestele koodihulkadele, mida on võimalik kiiresti testida ja juurutada, samal ajal kui saadakse ka tagasisidet. Rakenduse kognitiivne koormus on nihkunud kuue kuu kuni kahe aasta ajavahemikust koos tohutu hulkade spetsifikatsioonidega kahele nädalasele funktsiooni lisamiseks või muutmiseks, mis on suunatud ebaselgele mõistmisele suurest rakendusest. võimaldab lähenemine keskenduda väikestele koodimahtudele, mida saab kiiresti testida ja juurutada, samal ajal saades ka tagasisidet. Rakenduse kognitiivne koormus on nihkunud kuue kuu kuni kahe aasta ajakavast, arvestades suuri spetsifikatsioone, kahe nädala jooksul toimuvale funktsiooni lisamisele või muutustele, mis on suunatud rohkem hägusele arusaamisele suurest rakendusest.

Keskendumine massiivsetest rakendustest konkreetsetele väikestele funktsioonidele, mis saab lõpule viia kahe nädala sprintide jooksul, ja vaadates ette mitte rohkem kui üks funktsioon järgmisest sprintist, on märkimisväärne muutus. See on võimaldanud suurendada arenduse tootlikkust, vähendades samal ajal pidevalt kõikuvat kognitiivset koormust.

Metoodikas lubab lähenemine keskenduda väikestele koodihulkadele, mida on võimalik kiiresti testida ja juurutada, samal ajal kui saadakse ka tagasisidet. Rakenduse kognitiivne koormus on nihkunud kuue kuu kuni kahe aasta ajavahemikust koos tohutu hulkade spetsifikatsioonidega kahele nädalasele funktsiooni lisamiseks või muutmiseks, mis on suunatud ebaselgele mõistmisele suurest rakendusest. eeldatakse, et lõplik rakendus on mõnevõrra muudetud versioon algsest kontseptsioonist, seega peab arenduse lõpp-punkt olema kindlasti ebamugavalt määratletud. Üksikasjalikud ja selged võivad olla ainult iga konkreetse sprindi tulemused.

Väikesed koodibaasid

Järgmine samm kognitiivse koormuse vähendamisel on koodibaasi vähendamine. Tüüpiliselt on tänapäevased rakendused mahukad – usaldusväärne, ettevõtte rakendus võib koosneda tuhandetest failidest ja sadadest tuhandetest koodiridadest. Sõltuvalt failide struktuurist võivad koodide ja failide seosed ja sõltuvused olla ilmsed või vastupidi. Isegi koodi täitmise tõrkeotsing võib tekitada probleeme, sõltuvalt kasutatavatest teekidest ja sellest, kui hästi tõrkeotsingu tööriistad eraldavad teegid/paketid/moodulid ja kasutajakoode.

Rakenduse koodi töötava vaimse mudeli loomine võib võtta märkimisväärselt palju aega ja taaskoormata arendajat suurt kognitiivset koormust. See on eriti iseloomulik monoliitsetele koodibaasile, kus palju koodi, mille funktsionaalsete komponentide omavaheline suhtlemine ei ole selgelt määratletud, ning tähelepanerakkude jaotumine on sageli hägune, kuna funktsionaalsed piirid ei ole täidetud.

Üks tõhusamaid viise inseneride kognitiivse koormuse vähendamiseks on mikroteenuste arhitektuurile üleminek. Mikroteenuste lähenemisviisis keskendub iga teenus ühele funktsioonide kogumile; samas on teenuse tähendus tavaliselt määratletud ja arusaadav. Teenuse piirid on samuti selged – pidage meeles, et teenusega suhtlemine toimub API kaudu, seega võivad ühe teenuse genereeritud andmed kergesti edastada teise.

Koostoime teiste teenustega on tavaliselt piiratud mõne kasutajateenuse ja mõne teenusepakkuja teenusega, mis kasutavad lihtsaid ja selgeid API kutsungeid, näiteks REST-i abil. See tähendab, et inseneri kognitiivne koormus väheneb märkimisväärselt. Kõige keerulisemaks ülesandeks jääb teenuste koostöömudeli mõistmine ja selle mõistmine, kuidas sellised asjad nagu tehingud toimivad mitmes teenuses. Lõppkokkuvõttes vähendab mikroteenuste kasutamine kognitiivset koormust, vähendades koodi mahtu, määratledes teenuse selged piirid ja tagades kasutajate ja teenusepakkujate suhete mõistmise.

Väikesed inkrementaalsed muutused

Põhimõtte viimane element tühine – see on muutuste juhtimine. Arendajatele on suur ahvatlus vaadata koodibaasi (võib-olla isegi omaenda vanemat koodi) ja kuulutada: „See on jama, peame kõik ümber kirjutama.” Mõnikord on see õige otsus, mõnikord mitte. See seab arendajate meeskonna õlule globaalse mudeli muutmise koorma, mis omakorda toob kaasa ulatusliku kognitiivse koormuse. Paremini on, kui insenerid keskenduvad muudatustele, mida nad saavad sprinti jooksul ellu viia, et seejärel õige funktsionaalsus õigeaegselt välja tuua, isegi kui see juhtub järk-järgult. Lõpp-tulemus peaks meenutama eelnevalt planeeritud tulemust, kuid mõningate muudatustega ja testimisega, et vastata kliendi vajadustele.

Suure koodilõikude ümberkirjutamisel osutub aeg-ajalt muudatuste kiire tarnimine võimatuks, kuna mängu astuvad süsteemi muud sõltuvused. Muudatuste voogu kontrollimiseks võib kasutada funktsionaalsuse peitmist (feature hiding). See tähendab, et funktsionaalsus on olemas tootmises, kuid ei ole kergelt juurdepääsetav keskkonnamuutujate (env-var) või mõne muu konfigureerimismehhanismi kaudu. Kui kood on läbinud kõik kvaliteedi kontrollimise protsessid, võib see jõuda tootmisse varjatud olekus. Siiski toimib see strateegia ainult siis, kui funktsioon lõppkokkuvõttes aktiveeritakse. Muul juhul lisab see lihtsalt koodi ülekoormust ja tõstab arendaja kognitiivset koormust, millega tuleb tulemuslikuks tööks toime tulla. Muudatuste haldamine ja järkjärgulised muudatused aitavad iseenesest hoida arendajate kognitiivset koormust talutaval tasemel.

Insenerid peavad isegi lisafunktsionaalsuse lihtsal rakendamisel ületama palju raskusi. Juhtkonna poolt on mõistlik vähendada tiimi liigset koormust, et nad saaksid keskenduda funktsionaalsuse põhielementidele. On kolm asja, mida saate teha, et aidata oma arendustiimi:

1. Kasutage metoodikat lubab lähenemine keskenduda väikestele koodihulkadele, mida on võimalik kiiresti testida ja juurutada, samal ajal kui saadakse ka tagasisidet. Rakenduse kognitiivne koormus on nihkunud kuue kuu kuni kahe aasta ajavahemikust koos tohutu hulkade spetsifikatsioonidega kahele nädalasele funktsiooni lisamiseks või muutmiseks, mis on suunatud ebaselgele mõistmisele suurest rakendusest., et piirata ajaraame, mille jooksul tiim peab keskenduma võtmefunktsioonidele.
2. Rakendage oma rakendust mitme mikroteenuse kujul. See piirab rakendatavate funktsioonide arvu ja tugevdab piire, mis hoiab kognitiivset koormust töö meatmisel.
3. Eelistage järkjärgulisi muudatusi massiivsete ja koormavate üle, muutke väikseid koodilõike. Kasutage funktsioonide peitmist, et viia ellu muudatusi, isegi kui need ei ole kohe nähtavad pärast lisamist.

Kui rakendate oma töös väikese ulatuse põhimõtet, muutub teie meeskond kindlasti õnnelikumaks, suudab paremini keskenduda vajalike funktsioonide elluviimisele ja on tõenäolisem, et kvaliteetseid muudatusi hakatakse kiiremini ellu viima. Kuid see ei tähenda, et töö ei võiks keerulisemaks muutuda; mõnikord nõuab uue funktsionaalsuse rakendamine mitme teenuse muutmist ning see protsess võib olla keerulisem kui sarnane monoliitses arhitektuuris. Igatahes tasuvad väikese ulatuse lähenemise eelised end ära.

Esimese osa lõpp.

Peagi avaldame tõlke teise osa, kuid praegu ootame teie kommentaare ja kutsume teid osalema avatud uste päev, mis toimub juba täna kell 20.00.

Allikas: habr.com