Kaasaegsete rakenduste arendamise printsiibid NGINX-ilt. Osa 1

Tere, sõbrad. Enne kursuse käivitamist „PHP tagasiside arendaja”, jagame traditsiooniliselt teiega kasuliku materjali tõlget.

Tarkvara lahendab üha rohkem igapäevaseid ülesandeid, muutudes samas järjest keerulisemaks. Kuidas ütles kord Marc Andreessen, see neelab maailma.

Seetõttu on viimastel aastatel lähenemisviisid rakenduste arendamisele ja kohaletoimetamisele tõsiselt muutunud. Need on olnud tektoonilised muudatused, mis on lõpuks viinud uusi põhimõtteid. Need põhimõtted on osutunud kasulikeks teie meeskonna, projekteerimise, arendamise ja rakenduse lõppkasutajatele kohaletoimetamise kujundamisel.

Põhimõtted saab kokku võtta järgmiselt: rakendus peab olema väike, võrkturundus- ja arendajakeskne arhitektuur. Nende kolme põhimõtte abil saate luua usaldusväärse, kompleksse rakenduse, mida saab lõppkasutajale kiiresti ja turvaliselt edastada ning mis on hõlpsasti skaleeritav ja laiendatav.

Iga pakutav põhimõte sisaldab mitmeid aspekte, millest räägime, et näidata, kuidas iga põhimõte aitab saavutada lõppeesmärki — kiirelt usaldusväärsete rakenduste tarnimist, mis on lihtsad hooldada ja kasutada. Vaatame põhimõtteid nende vastanditega võrreldes, et selgitada, mida tähendab näiteks "Veenduge, et kasutate väikse põhimõtet».

Loodame, et see artikkel innustab teid kasutama kaasaegsete rakenduste ehitamise soovitatud põhimõtteid, mis tagavad ühtse lähenemise disainile pidevalt kasvavas tehnoloogiate virnas.

Nende põhimõtete rakendamisega avastate, et järgite tarkvaraarenduse uusimaid suundi, sealhulgas lähenemist DevOps rakenduste arendusele ja tarnimisele, konteinerite kasutamisele (näiteks Docker), konteinerite orkestreerimise raamistike (näiteks Kubernetes), mikroteenuste kasutamisele (sh Mikroteenuste Arhitektuur NGINX ja võrgustiku arhitektuur mikroteenuste rakendustele.

Mis on kaasaegne rakendus?

Kaasaegsed rakendused? Kaasaegne tehnoloogia? Mida täpselt tähendab ‘kaasaegne’?

Enamikel arendajatel on vaid üldine ettekujutus, millest kaasaegne rakendus koosneb, seetõttu on oluline selle mõiste selgelt määratleda.

Kaasaegne rakendus toetab mitut klienti, olgu need siis kasutajaliides JavaScripti raamatukogul React, mobiilirakendus Androidi või iOS-i jaoks või rakendus, mis suhtleb teisega API kaudu. Kaasaegne rakendus tähendab, et see teenindab määramatut arvu kliente, kellele pakutakse andmeid või teenuseid.

Kaasaegne rakendus pakub API-d, et pääseda ligi nõutud andmetele ja teenustele. API peab olema püsiv ja ühtne, mitte spetsiaalselt mõne konkreetse kliendi jaoks kirjutatud. API on saadaval üle HTTP(S) ja tagab juurdepääsu kogu funktsionaalsusele, mis on saadaval GUI või CLI kaudu.

Andmed peavad olema kergesti kättesaadavad tuntud, ühilduvas formaadis, näiteks JSON. API pakub objekte ja teenuseid arusaadavas, organiseeritud vormis; näiteks RESTful API või GraphQL pakuvad kvaliteetset liidest.

Kaasaegsed rakendused põhinevad kaasaegsel tehnoloogiakihil, mis toetab selliseid rakendusi. See tehnoloogiakiht võimaldab arendajal hõlpsasti luua rakendust, millel on HTTP-liides ja selged API lõpp-punktid. Valitud lähenemine võimaldab teie rakendusel hõlpsasti andmeid vastu võtta ja edastada JSON-formaadis. Teisisõnu, kaasaegne tehnoloogiakiht vastab Kaheteistkümne Faktoriga Rakenduse elementidele. mikroteenustena.

Selle tehnoloogiakihtide populaarsetes versioonides põhinevad Java, Python, Sõlm, Ruby, PHP ja Go. Mikroteenuste arhitektuur NGINX on näide kaasaegsest tehnoloogiakihist, mis on rakendatud igas mainitud keeles.

Pange tähele, et me ei propageeri ainult mikroteenuste lähenemist. Paljude teie seas töötavad monoliitidega, mis peavad arenema, samas kui teised tegelevad SOA rakendustega, mis laienevad ja arenevad mikroteenuste rakendusteks. Kolmandad liiguvad suunas, kus rakendatakse serverita (serverless) lahendusi, ning mõned rakendavad teile ülaltoodud kombinatsioone. Artiklis esitatud põhimõtted kehtivad igaühe kohta, tehes vaid mõned pisikesed muudatused.

Põhimõtted

Nüüd, kui oleme saavutanu ühise arusaama sellest, mis on kaasaegsed rakendused ja kaasaegne tehnoloogia, on aeg süveneda arhitektuuri ja arenduse põhimõtetesse, mis aitavad teil kaasaegsete rakenduste arendus-, rakendamis- ja hooldusprotsessis.

Üks põhimõte kõlab nagu „looge väikeseid rakendusi“, nimetame seda lihtsalt väikuse põhimõtteks. On eksisteerivad uskumatult keerulised rakendused, mis koosnevad paljusid liikuvatest komponentidest. Seetõttu lihtsustab rakenduse loomine väikestest eraldiseisvatest komponentidest selle projekteerimist, hooldamist ja üldiselt selle kasutamist. (Tähelepanu, me ütlesime „lihtsustab“, mitte „muudab lihtsaks“).

Teine põhimõte on, et saame suurendada arendajate tootlikkust, aidates neil keskenduda neile funktsioonidele, mida nad arendavad, samal ajal vabastades nad infrastruktuuri ja CI/CD muredest rakendamise ajal. Nii et lühidalt, meie lähenemine on suunatud arendajatele.

Lõpuks peab kõik, mis on seotud teie rakendusega, olema ühendatud võrguga. Viimase 20 aasta jooksul oleme teinud suuri edusamme võrgupõhise tuleviku poole, kuna võrgud on muutunud kiiremateks ja rakendused keerukamateks. Nagu juba selgus, peab kaasaegne rakendus olema kõige erinevatesse klientidesse kasutusele võetud üle võrgu. Võrgupõhise mõtteviisi rakendamine arhitektuuris toob kaasa olulisi eeliseid, mis sobivad hästi kokku väikuse põhimõtteks ja lähenemise kontseptsiooniga, mis on suunatud arendajatele.

Kui arvestate rakenduse arendamisel ja rakendamisel neid põhimõtteid, on teil konkurentsieelis oma toote arendamisel ja pakkumisel.

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

Mugavuse põhimõte

Inimese ajul on raske korraga suurt hulka teavet vastu võtta. Psühholoogias tähendab kognitiivne koormus kogu vaimset pingutust, mis on vajalik teabe meeles hoidmiseks. Arendajate kognitiivse koormuse vähendamine on prioriteet, kuna see võimaldab neil keskenduda probleemi lahendamisele, mitte hoida meeles rakenduse keerulist mudelit ja arendatavaid funktsioone.

Rakendused dekoneeritakse mitmel põhjusel:

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

On mitmeid viise arendajate kognitiivse koormuse vähendamiseks, ja siin tuleb mängu mugavuse põhimõte.

Nii et kolm meetodit kognitiivse koormuse vähendamiseks:

1. Lühendage aega, mille nad peavad uue funktsiooni väljatöötamisel arvesse võtma – mida lühem on ajaraam, seda madalam on kognitiivne koormus.
2. Vähendage koodi hulka, millega töötatakse korraga – vähem koodi = vähem koormust.
3. Lihtsustage protsessi inkrementaalsete muudatuste tegemisel rakenduses.

Arenduse ajaraamide vähendamine

Naaseme tagasi aega, mil metoodika waterfall oli standard arendusprotsessis ning kuue kuu kuni kahe aasta ajaraamid rakenduse väljatöötamiseks või värskendamiseks olid tavaline praktika. Üldjuhul lugesid insenerid esmalt vastavaid dokumente, nagu toote nõuded (PRD), süsteemi viidatud dokument (SRD), arhitektuuriplaan ja hakkasid neid kõiki kokku viima ühte kognitiivsesse mudelisse, mille alusel nad koodi kirjutasid. Nõuete ja seetõttu ka arhitektuuri muutudes tuli tükkaega pingutada, et kogu meeskonda värskendustest teavitada kognitiivse mudeli osas. Selline lähenemine suutis halvimal juhul lihtsalt tööd täielikult halvatud tekitada.

Ainus suurima muudatusena rakenduste arendusprotsessis on muutunud agile metodoloogia rakendamine. Üks metodoloogia peamisi tunnuseid agile on iteratiivne areng. See omakorda vähendab inseneride kognitiivset koormust. Selle asemel, et nõuda arendustiimilt rakenduse elluviimist pikaajalise tsükli jooksul, agile võimaldab lähenemine keskenduda väikestele koodikogumitele, mida saab kiiresti testida ja juurutada, samal ajal saadud tagasisidet kaasates. Rakenduse kognitiivne koormus on nihkunud kuue kuu kuni kahe aasta ajaraamist suure hulga spetsifikatsioonide arvelt kahele nädalale uue funktsiooni lisamiseks või muudatuste tegemiseks, suunates seda rohkem hägusa arusaamise suunas suurest rakendusest.

Fookuse suunamine suurtelt rakendustelt konkreetsetele väikestele funktsioonidele, mis saab lõpetada kahe nädala sprintide jooksul, vaadates ette mitte rohkem kui ühe funktsiooni järgmistest sprintidest, on oluline muudatus. See on võimaldanud suurendada arenduse tootlikkust, samas vähendades pidevalt muutuvat kognitiivset koormust.

Metoodikas agile eeldatakse, et lõplik rakendus on mõnevõrra muudetud versioon algsest kontseptsioonist, seetõttu on lõplik arenduspunt tingimata ebamugav. Selged ja konkreetsed saavad olla vaid iga konkreetse sprindi tulemused.

Väikesed koodibaasid

Järgmine samm kognitiivse koormuse vähendamisel on koodibaasi vähendamine. Üldiselt on tänapäevased rakendused mahukad – usaldusväärne, ettevõtte tasandi rakendus võib koosneda tuhandetest failidest ja sadadest tuhandetest koodiridadest. Olenevalt failide organisatsioonist võivad koodi ja failide omavahelised seosed ja sõltuvused olla ilmseid või vastupidi, tähelepanuväärseid. Isegi koodi soorituse tõrkeotsing võib tekitada probleeme, sõltuvalt kasutatavatest raamatukogudest ja sellest, kuivõrd hästi tõrkeotsingu vahendid eristavad raamatukogusid/pakette/mooduleid ja kasutajakoodi.

Rakenduse koodi töötava vaimse mudeli loomine võib võtta märkimisväärselt aega, ja see seab taas suure kognitiivse koormuse arendajale. See on eriti iseloomulik monoliitsetele koodibaasidele, kus on suur hulk koodi, mille funktsionaalsete komponentide vaheline seos ei ole selgelt määratletud ning tähelepanu objektide jagunemine on sageli udune, kuna funktsionaalseid piire ei järgita.

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

Suhtlemine teiste teenustega on tavaliselt piiratud paari kasutajateenuse ja paari teenusepakkuja teenusega, mis kasutavad lihtsaid ja puhtaid API-kutseid, näiteks REST-i abil. See tähendab, et inseneri kognitiivne koormus väheneb märkimisväärselt. Kõige keerulisemaks ülesandeks jääb arusaamine teenuste koostöömudelist ja sellest, kuidas erinevad toimingud, nagu tehingud, toimuvad mitmete teenuste vahel. Kokkuvõttes vähendab mikroteenuste kasutamine kognitiivset koormust, vähendades koodi hulka, tuvastades teenuse selged piirid ja tagades kasutajate ning teenusepakkujate suhete arusaamise.

Väikesed inkrementaalsed muudatused

Viimase element prosessis väikesused – see on muudatuste juhtimine. Arendajatele on ahvatlev vaadata koodibaasi (võib-olla isegi oma vanamat koodi) ja öelda: 'See on jama, me peame selle kõik ümber kirjutama.' Mõnikord on see õige otsus, teinekord mitte. See seab arendustiimi peale globaalsete muudatuste koorma, mis omakorda toob kaasa suurt kognitiivset koormust. Paremini on, kui insenerid keskenduvad muudatustele, mida nad saavad sprintide jooksul teha, et seejärel õigel ajal vajalik funktsionaalsus välja tuua, isegi kui see toimub järk-järgult. Lõpptoot peab meenutama eelnevalt planeeritud, kuid mõningate muudatustega ja testimisega, et vastata kliendi vajadustele.

Suuremate koodilõikude üle kirjutamise korral ei pruugi muudatuste kiirel edastamisel alati õnnestuda, kuna mängu tulevad sisse süsteemi teised sõltuvused. Kuidas muutuste voogu kontrollida? Selleks saab kasutada funktsioonide varjamist (feature hiding). Sisuliselt tähendab see, et funktsioon on tootmisserveris olemas, kuid pole saadaval keskkonnamuutujate seadistuse (env-var) või mõne muu konfigureerimismehhanismi kaudu. Kui kood on läbinud kõik kvaliteedikontrolli etapid, võib see tootmisse jõuda varjatud olekus. Siiski toimib see strateegia vaid siis, kui funktsioon saab lõpuks aktiveeritud. Vastupidisel juhul koormab see lihtsalt koodi ja lisab arendajale kognitiivset koormust, millega tuleb produktiivse töö tegemiseks toime tulla. Muudatuste juhtimine ja inkrementaalsed muudatused aitavad isegi iseenesest hoida arendajate kognitiivset koormust normaalsetes piirides.

Arendajad peavad paljusid keerulisi kitsendusi ületama, isegi kui nad rakendavad uusi funktsioone. Juhtkonna poolelt oleks mõistlik vähendada meeskondade liigset koormust, et nad saaksid keskenduda funktsioonide võtmeelementidele. On kolm asja, mida saate teha, et aidata oma arendajate meeskonda:

1. Kasutage metoodikat agile, et piirata ajaraame, mille jooksul meeskond peab keskenduma võtmefunktsioonidele.
2. Rakendage oma rakendus mitme mikroteenusena. See piirab rakendatavate funktsioonide arvu ja tugevdab piire, mis aitavad hallata kognitiivset koormust tööl.
3. Eelistage inkrementaalseid muutusi suurtele ja mahukatele, muutes väikseid koodilõike. Rakendage funktsioonide peitmist, et muudatusi rakendada, isegi kui need ei ole kohe pärast lisamist nähtavad.

Kui te rakendate oma töös väikese suuruse põhimõtet, muutub teie meeskond palju õnnelikumaks, suudab paremini keskenduda vajalike funktsioonide rakendamisele ja on tõenäolisemalt kiiremini kvaliteetseid muudatusi toomas. Kuid see ei tähenda, et töö ei saaks keerulisemaks minna; mõnikord nõuab uue funktsiooni rakendamine mitme teenuse kohandamist ja see protsess võib olla keerulisem kui analoogne monoliitses arhitektuuris. Igal juhul tasuvad väikese suuruse 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