Turinys[Slėpti][Rodyti]
Mikropaslaugų idėja pastaruoju metu sulaukė daug dėmesio ir daugelis firmų ja naudojasi siekdamos panaikinti dideles, monolitines užpakalines sistemas.
Eiti tuo pačiu keliu su sąsaja vis dar yra iššūkis daugeliui įmonių, net jei toks paskirstytas žiniatinklio programų serverio pusės kūrimo būdas yra daugiau ar mažiau patikimas tyrimų ir vykdymo požiūriu.
Dėl glaudžios priklausomybės kliento pusės monolitas paprastai apsunkina naujų funkcijų integravimą, naujų technologijų pritaikymą ir atskirų komponentų mastelį.
Šie ir kiti iššūkiai paskatino frontend kūrėjus ištirti naudojant mikro paslaugas.
Dėl to buvo sukurta visiškai nauja architektūrinė strategija, žinoma kaip mikro sąsaja, skirta sukurti priekinį svetainių ir žiniatinklio programų sluoksnį.
Pirmą kartą šis terminas buvo pavartotas 2016 m., o nuo tada jis sulaukė daug dėmesio dėl geros priežasties.
Šis straipsnis suteiks bendrą supratimą apie tai, kas yra mikro sąsajos ir kokias problemas jos sprendžia. tai veikia, taip pat privalumai ir trūkumai.
Įvadas į mikro front-end architektūrą
Šiuolaikinis front-end kūrimo metodas, vadinamas mikro priekinės dalies architektūra, suskirsto a interneto programa į mažas, nepriklausomas dalis.
Galutiniam vartotojui šios dalys atrodo kaip vienas vienetas, net jei jos buvo sukonstruotos atskirai ir vėliau sujungtos.
Atsižvelgiant į skirtumą, kad mikro sąsajos yra susijusios su internetinių sprendimų kliento, o ne serverio puse, jų pagrindimas yra toks pat, kaip ir mikropaslaugų.
Kurti sudėtingus žiniatinklio produktus yra prasmingiausia naudojant mikro sąsajos metodą.
Mikro sąsajos, priešingai nei įprastesnis priekinės dalies monolitas, leidžia daugeliui komandų atskirai bendradarbiauti vykdant įvairius programinės įrangos projektus.
Naudodami šį architektūrinį dizainą programuotojai gali greičiau kurti žiniatinklio programas, didesnę mastelio keitimą ir priežiūrą.
Paprasčiau tariant, kiekviena mikro sąsaja yra tik atskiro tinklalapio komponento kodo dalis.
Šias funkcijas valdo atskiros komandos, kurių kiekviena specializuojasi tam tikroje pramonės šakoje ar tikslu.
Monolitinė vs mikropaslaugos vs mikro frontend architektūra
Pagalvokite apie persikėlimą. Ar jums bus paprasčiau viską suskirstyti į keletą mažų, profesionaliai paženklintų dėžučių ir perkelti kiekvieną atskirai, ar supakuoti visą personalą į vieną didžiulę dėžę ir pervežti į naują vietą?
Akivaizdus sprendimas yra.
Ši analogija lygina dvi skirtingas žiniatinklio programų architektūras, monolitus ir mikropaslaugas (taip pat žinomas kaip mikro sąsajos).
Monolitinė architektūra
Galbūt galėsite prisiminti „senus gerus laikus“, kai visa programa buvo sukurta kaip vienas vientisas subjektas. Toks metodas vadinamas monolitu, kuris yra senas didelio akmens luito terminas.
Tai turi prasmę.
Monolitinės sistemos turi tarpusavyje priklausomus elementus. Todėl, jei norite ką nors pakeisti ar pridėti naują funkciją, gali sugesti visa sistema.
Nors jis pasenęs, kartais vis dar egzistuoja. Taip, mes žinome jūsų dabartinę išraišką.
Koncepcinis kodų bazės padalijimas į du skirtingus komponentus – frontend (kliento pusėje) ir backend (serverio pusė) – tapo neišvengiamas, nes buvo kuriamos naujos technologijos ir programinės įrangos produktai tapo sudėtingesni.
Šiuo metu populiariausias veikimo būdas yra atskirti pristatymo sluoksnį, su kuriuo sąveikauja galutinis vartotojas, ir visko, kas vyksta fone.
Tam reikia dviejų programinės įrangos inžinierių komandų, kurių pagrindinė komanda kurtų vaizdinius komponentus, o užpakalinė komanda kurtų žiniatinklio paslaugas, verslo logiką, prieigą prie duomenų, integracijas ir kt.
Tačiau nepaisant šio atskyrimo, ši strategija vis tiek išlieka monolitinė.
Pagrindinis pakeitimas yra tas, kad vietoj vienos didžiulės programos dabar turime du didelius kodo blokus – priekinę ir užpakalinę dalį. Monolitinės architektūros neturi būti baisios; jie turi keletą privalumų, įskaitant
- Paprastas ir greitas mažų programų kūrimas su viena šaltinio kodo baze ir labai paprastu dizainu;
- Testavimas ir derinimas yra labai nesudėtingi, nes visas kodas yra vienoje vietoje, todėl komandai lengviau sekti užklausos eigą ir nustatyti klaidas;
- Programos kūrimo pradžioje išlaidos yra pigesnės, nes nei infrastruktūros, nei kūrimo išlaidos nepatiriamos, kol nebus pridėtos naujos funkcijos.
Šios strategijos trūkumai atsispindi
- Ribotas diegimo lankstumas – komandos turi laukti, jei projekte dirba tik keletas jų ir kiekvieną kartą atnaujinant kodą reikia įdiegti naują;
- Naujų technologijų pritaikymas yra sudėtingas, nes norint tai padaryti, reikia perrašyti didelę dalį, jei ne visą projektą.
- Kai daugėja kūrėjų, kodų sistema tampa glaudžiai susijusi, sudėtinga, sunkiai valdoma ir suvokiama.
- Organizaciniai klausimai – kiekvienas komandos narys turi naudoti tą pačią bibliotekų versiją ir pranešti apie bet kokius pakeitimus, jei prie monolitinio projekto dirba daug komandų.
- Susirūpinimas dėl mastelio – kadangi projekto komponentai yra tarpusavyje susiję, juos atskiriant iškyla sunkumų, dėl kurių atsiranda didelių prastovų ir didesnės išlaidos.
- Naujiems komandos nariams gali būti sunku suprasti sudėtingą projekto logiką, ypač jei iš pradžių su juo dirbę inžinieriai nebedirba.
Kuriant mikropaslaugas ir jų artimus giminaičius bei mikro sąsajas buvo išspręstos pagrindinės monolitinių sistemų problemos.
Mikro paslaugų architektūra
Architektūrinis metodas, žinomas kaip mikropaslaugos, leidžia sukurti daug laisvai susietų ir savarankiškai dislokuojamų mažesnių komponentų arba paslaugų, sudarančių programos užpakalinę sistemą.
Kiekviena paslauga turi savo kodų bazę, CI / CD vamzdynus, „DevOps“ procedūras ir procesus joms vykdyti.
Galite pamatyti, kad monolitinė užpakalinė komanda yra padalinta į atskiras komandas, žiūrėdami aukščiau esantį paveikslėlį.
Kiekviena atskirai sutelkia dėmesį į skirtingą programos aspektą (pvz., produkto paslaugą, paieškos paslaugą ir mokėjimo paslaugą).
Ryšys tarp paslaugų vyksta naudojant nustatytus protokolus, žinomus kaip API, pvz., lengvąjį REST API protokolą, kuris naudoja sinchroninius užklausų ir atsakymo šablonus.
Kita galimybė yra naudoti asinchroninį ryšį naudojant programinę įrangą, pvz., Kafka, kuri siūlo publikavimo / prenumeratos komunikacijos struktūras ir įvykius.
Mikropaslaugos integruojamos su sąsaja per sąsajos (BFF) paslaugos užpakalinę dalį arba API šliuzą per tinklą. BFF kiekvienam klientui siūlo pritaikytą API, o API šliuzai suteikia vieną prieigos tašką mikropaslaugoms.
Tačiau net ir naudojant autonominius užpakalinės dalies komponentus ir visus jų teikiamus privalumus, priekinė dalis vis tiek yra monolitinė.
Todėl čia naudingos mikro sąsajos.
Mikro frontendų architektūra
Panašiai kaip mikropaslaugos, kur laisvai susietus komponentus valdo kelios komandos, mikro sąsajos architektūra šią koncepciją pritaiko naršyklei.
Šios žiniatinklio programos vartotojo sąsajos atitinka šią struktūrą, kurią sudaro šiek tiek savarankiški komponentai.
Komandos taip pat kuriamos atsižvelgiant į klientų poreikius ar naudojimo atvejus, o ne į konkrečias žinias ar technologijas.
Todėl komandos dalyvauja mikropaslaugų ir mikro frontend projektuose.
- vertikaliai supjaustyti – kadangi prie to paties projekto taip pat dirba frontend kūrėjai, duomenų ekspertai, backend inžinieriai, kokybės užtikrinimo inžinieriai ir kt., jie kuria savo funkcijas iš vartotojo sąsaja į duomenų bazes; ir
- daugiafunkcinis – kiekvienas komandos narys prisideda prie grupės savo kompetencijos.
Komandos taip pat gali pasirinkti technologijų paketą, kuris geriausiai atitinka jų konkrečią verslo sritį.
Viena komanda gali naudoti „React“, kad užprogramuotų savo fragmentą. Kita komanda kuria naują Angular versiją. Vue.js yra vienas iš tokių pavyzdžių.
Mikro priekinės dalys naudojamos kartu su susijusiomis mikropaslaugomis, siekiant išspręsti problemas, su kuriomis paprastai susiduria kūrimo komandos dėl monolitų. Strategija siūlo šiuos privalumus.
- Technologijų laisvė: „Frontend“ inžinieriai gali pasirinkti alternatyvias „JavaScript“ sistemas, vykdymo aplinkas ir visą technologijų paketą, atsižvelgdami į įmonės poreikius. Be pasenusios architektūros, gali būti taikoma nauja sistema.
- Galimas didesnis lankstumas, nes kiekviena mikro sąsaja yra savarankiška ir gali būti kuriama, išbandyta, įdiegta ir atnaujinta atskirai. Todėl, jei viena komanda dirba su funkcija ir ištaisė riktą, o kita komanda turi pridėti savo funkciją, jai nereikia laukti, kol pirmoji komanda atliks savo užduotį.
- Savarankiškos komandos ir sistemos: kiekviena produktų komanda, taigi ir kiekviena funkcija, gali veikti mažai priklausydami nuo kitų, o tai leidžia toliau veikti net tada, kai šalia esantys komponentai nepasiekiami.
- Kelios mažesnės kodų bazės: kiekviena mikro sąsaja turės savo, lengviau valdomą, mažesnę kodų bazę. Mažiau žmonių sutelks dėmesį į konkretų vartotojo sąsajos komponentą, supaprastins kodo peržiūras ir pagerins bendrą organizavimą.
- Paprastas programos mastelio keitimas: Kitas mikro sąsajų privalumas yra galimybė keisti kiekvienos funkcijos mastelį atskirai. Priešingai nei monolitai, kai visos programos mastelis turi būti keičiamas kiekvieną kartą pridedant naują funkciją, todėl visas procesas tampa efektyvesnis tiek laiko, tiek pinigų atžvilgiu.
Kaip veikia mikro sąsaja?
Kaip jau minėjome, komandos yra vertikaliai suskirstytos mikro sąsajos architektūroje, o tai reiškia, kad jos yra atskirtos domeno žiniomis arba tikslais ir nuo pradžios iki pabaigos yra atsakingos už konkretų produktą.
Jis gali turėti vieną ar dvi užpakalinės dalies mikropaslaugas, taip pat nedidelę priekinę dalį. Išsamiau panagrinėkime šio vaizdo elemento ypatybes, sąveiką su kitais vartotojo sąsajos komponentais ir įtraukimą į pagrindinį puslapį.
Gali būti mikro priekinė dalis
- visas puslapis (pvz., produkto informacijos puslapis) arba
- puslapio skiltys, kurias gali naudoti kitos komandos, pvz., antraštės, poraštės ir paieškos juostos.
Galite padalyti didelę svetainę į kelis puslapių tipus ir suteikti kiekvienam tipui konkrečiam personalui dirbti.
Tačiau daugelyje puslapių dažnai pasitaiko keletas komponentų, tokių kaip antraštės, poraštės, pasiūlymų blokai ir t. t. Pasiūlymų blokas, pavyzdžiui, gali būti įtrauktas į pagrindinį puslapį, išsamios produkto informacijos puslapį ar net atsiskaitymo puslapį.
Iš esmės komandos gali sukurti gabalus, kuriuos kitos komandos gali naudoti savo puslapiuose.
Tačiau mikro priekinės dalys gali būti diegiamos atskirai kaip skirtingi projektai, o ne pakartotinai naudojami komponentai.
Visa tai skamba fantastiškai, tačiau norint sukurti vieningą sąsają, puslapius ir fragmentus reikia kažkaip sujungti.
Tam reikalingas frontend integravimas, kurį galima atlikti naudojant įvairias strategijas, įskaitant maršruto parinkimą, sudėtį ir ryšį (žr. grafiką aukščiau).
Maršrutai
Kai paslauga iš puslapio, kurį valdo viena komanda, reikalinga norint pasiekti kitai komandai priklausantį puslapį, maršruto parinkimas yra naudingas integruojant puslapio lygiu.
Kiekviena mikro sąsaja yra tvarkoma kaip vieno puslapio programa. Maršrutui nustatyti gali būti naudojamos paprastos HTML nuorodos.
Vartotojas gali priversti naršyklę atsisiųsti tikslinį žymėjimą iš serverio ir pakeisti dabartinį puslapį nauju, spustelėdamas hipersaitus.
Programos apvalkalas yra HTML, CSS ir „JavaScript“ minimumas, kuris veikia vartotojo sąsajoje. Net jei iš serverio prašomi turinio duomenys vis dar laukia, vartotojas iškart gauna statinį rodomą puslapį. Centrinis programos apvalkalas yra pagrindinė įvairių komandų sukurtų vieno puslapio programų programa.
Nesvarbu, kokia biblioteka ar sistema yra naudojama, meta-frameworks leidžia sujungti įvairius puslapius į vieną.
Sudė‘tis
Kompozicija yra dalių išdėstymo procesas, kad jie tilptų į atitinkamas puslapio vietas. Daugeliu atvejų komanda, kuri įdiegia puslapį, ne iš karto gauna fragmento turinį.
Vietoj to jis įdeda rezervuotąją vietą arba žymeklį toje vietoje, kur fragmentas turėtų būti žymėjime.
Naudojant kitokį komponavimo procesą, baigiamas galutinis surinkimas. Kompoziciją galima suskirstyti į dvi pagrindines kategorijas: kliento ir serverio.
Kliento pusės kompozicija: žiniatinklio naršyklė naudojama HTML žymėjimui kurti ir redaguoti. Kiekviena mikro sąsaja turi galimybę keisti ir rodyti savo žymėjimą atskirai nuo likusio puslapio.
Pavyzdžiui, žiniatinklio komponentai leidžia atlikti tokio tipo statybas.
Planuojama kiekvieną fragmentą paversti žiniatinklio komponentu, kurį galima savarankiškai įdiegti kaip a.js failą, po kurio programos gali įkelti ir pateikti jas temos išdėstyme joms skirtose vietose.
Žiniatinklio komponentai priklauso nuo HTML ir DOM API, kurią gali naudoti kitos sąsajos sistemos, taip pat standartinio duomenų siuntimo ir gavimo per rekvizitus ir įvykius metodo.
Serverio pusės kompozicija: Naudojant šį dizainą, UI dalys sujungiamos serveryje, todėl visiškai suformuotas puslapis siunčiamas į kliento pusę, o tai pagreitina įkėlimą.
Surinkimą dažnai atlieka atskira paslauga, kuri yra tarp žiniatinklio naršyklės ir žiniatinklio serverių. CDN yra vienas paslaugos egzempliorius (turinio pristatymo tinklas).
Galite pasirinkti vieną arba dviejų derinį, priklausomai nuo jūsų poreikių.
Mikro frontend komunikacijos modeliai
Mikro priekinės dalies architektūra geriausiai veikia, kai tarp įvairių komponentų sąveika mažai arba visai nėra. „Micro frontends“ kartais turi pasikalbėti ir dalytis informacija. Štai keletas galimų modelių, kurie gali tai lemti.
- Interneto darbuotojai: Internetinis darbuotojas yra mechanizmas, leidžiantis žiniatinklio turiniui paleisti „JavaScript“ fone, nepriklausomai nuo kitų scenarijų ir nepaveikiant puslapio greičio. Kiekvienai mikro programai bus suteikta unikali darbuotojo API. Šis pranašumas yra tas, kad daug laiko reikalaujantį darbą galima atlikti kitoje gijoje, todėl vartotojo sąsajos gija gali tęstis nesulėtinant ar nesustabdant.
- Įvykių skleidėjas: Šiuo atveju daugelis komponentų bendrauja vienas su kitu, klausydami ir veikdami bet kokius komponentų, kurių jie yra prenumeruoti, būsenos pokyčius. Kitos mikro sąsajos, kurios užsiprenumeravo tą konkretų įvykį, reaguoja, kai mikro sąsaja suaktyvina tą įvykį. Įvykių skleidėjas, įtrauktas į kiekvieną mikro sąsają, leidžia tai padaryti.
- Atšaukimai ir rekvizitai: Šiame skyriuje apibrėžiate pagrindinį komponentą ir antrinius komponentus. Bendravimas organizuojamas į medį panašią struktūrą. Pirminiai komponentai naudoja rekvizitus, kad perteiktų duomenis kaip komponentų medį antriniams komponentams. Savo ruožtu vaikas gali veiksmingai įspėti tėvą, kai kas nors įvyksta jų būsenoje, reaguodamas į atgalinius skambučius. React naudoja šį režimą.
„Micro frontend“ pranašumai
Vystymasis greitai autonominėse komandose
Nepriklausoma komanda gali sukurti kiekvieną žiniatinklio programos ar svetainės dalį, naudodama mikro sąsajos metodą.
Kiekviena komanda yra visiškai savarankiška, o tai reiškia, kad ji yra atsakinga už visą komponentų kūrimo ciklą nuo sumanymo iki išleidimo ir po gamybos.
Be to, tai reiškia, kad įvairios komandos gali sklandžiai bendradarbiauti, tuo pat metu dirbdamos su tuo pačiu projektu.
Todėl išleidimo ciklai yra daug greitesni, nei būtų naudojant priekinius monolitus.
Mažesnės atskirų mikro sąsajų kodų bazės leidžia pasiekti švaresnį kodą
Monolitinės priekinės dalys turi dideles, sudėtingas kodų bazes, kurios laikui bėgant tampa vis chaotiškesnės ir sudėtingesnės.
Mikro sąsajos išsprendžia šią problemą. Kiekvienos mikro sąsajos šaltinio kodas yra lengviau valdomas, nes jis yra mažesnis, paprastesnis ir kompaktiškesnis.
Dėl to bendram žiniatinklio sprendimui naudingas švaresnis kodas.
Pagerintas programos stabilumas dėl laisvos jungties
Žiniatinklio sprendimas retai kada gali būti padalintas į visiškai nepriklausomas dalis. Todėl mikro sąsajos kalba viena su kita.
Tačiau kiekviena sąsaja tarp komponentų yra reikšminga, nepaisant laisvo ryšio.
Vieno komponento gedimas neturi jokios įtakos visų kitų komponentų veikimui, o tai užtikrina didesnį tinklo sprendimo stabilumą.
Atskirų funkcijų testavimas yra paprastesnis
Ši nauda atsiranda dėl mikro priekinių dalių savybių. Remiantis šiuo architektūriniu projektu, žiniatinklio sprendimo kliento pusė yra modulinė ir kiekvienas modulis yra savarankiškas.
Dėl to komandai lengviau įvertinti nedidelę vartotojo sąsajos dalį, nei išbandyti didžiulį monolitą.
Sumažėjęs rinkinio dydis leidžia greičiau įkelti puslapį
Viena iš pagrindinių uždelsto įkėlimo laiko priežasčių turinčiose daug funkcijų turinčiose monolitinėse žiniatinklio sistemose yra „JavaScript“ paketo dydis. Kita vertus, mikro sąsajos metodas leidžia lengviau sutrumpinti puslapio įkėlimo laiką.
Naršyklė neturi pakartotinai atsisiųsti nereikalingo kodo, nes tinklalapį sudaro keli maži paketai. Dėl to pagerėja puslapio našumas ir įkėlimo laikas.
Technologinė nepriklausomybė
Daugkartinis front-end karkasai kūrėjai gali naudoti kurdami vieną internetinį sprendimą su mikro sąsajos architektūra.
Kadangi kiekvienas komponentas yra savarankiškas, jį galima sukonstruoti naudojant technologiją, kuri geriausiai atitinka komandos užduotis.
Žinoma, programuotojai turėtų būti atsargūs rinkdamiesi sistemas programinės įrangos projektui, už kurį jie atsako, ir vis tiek primygtinai patartina konsultuotis su kitomis komandomis.
Tačiau nėra jokios tikimybės, kad visą programos veikimo laiką būsite priversti naudoti seną sistemą.
„Micro Frontend“ trūkumai
Visas sudėtingas žiniatinklio sprendimų testavimas
Išbandyti įvairius žiniatinklio sprendimo modulius lengva, kai naudojama mikro sąsajos architektūra. Tačiau tai skiriasi nuo visos žiniatinklio programos įvertinimo.
Prieš tęsdami patikrinkite, ar visos dalys veikia taip, kaip numatyta. Tai gali būti sudėtinga, nes mikro sąsajos veikia nepriklausomai ir turi atskirus pristatymo procesus.
Brangios pradinės investicijos
Mikro frontend plėtrai paprastai reikia didelių finansinių išlaidų. Brangu surinkti ir išlaikyti daugybę priekinių komandų.
Be to, jums reikės vadovaujančio personalo, kuris organizuotų darbą, užtikrins, kad viskas būtų suderinta ir garantuotų puikų komandos bendravimą.
Kūrimo ir diegimo sudėtingumas
Kūrimo ir diegimo procedūros gali tapti sudėtingesnės dėl mikro sąsajos dizaino.
Pvz., tame pačiame projekte dirbančios nepriklausomos kūrimo komandos sprendimas gali būti perkrautas per daug komponentų, o tai gali sukelti problemų diegimo etape.
Teisingas visų modulių surinkimas ir sklandus jų integravimas į bendrą schemą taip pat ne visada paprastas; Šiam darbui paprastai reikia gerai suprasti visas priklausomybes.
Problemos išlaikant vartotojo patirties nuoseklumą
Nuoseklios vartotojo sąsajos palaikymas yra sudėtingas, kai komandos dirba atskirai keliose programinės įrangos dalyse.
Žiniatinklio sprendimu turėtų dalytis visi projekto kūrėjai. Priešingu atveju kelyje gali kilti daug prieštaravimų.
Išvada
„Micro frontends“, šiuolaikinis architektūrinis dizainas, gali labai pagerinti didelio masto mikropaslaugomis pagrįstų žiniatinklio kūrimo projektų našumą.
Tai leidžia programuotojams padalinti visą sprendimą į atskiras dalis, kurias gali sukurti kelios savarankiškos komandos. Iš to gaunama daug privalumų, įskaitant greitesnį funkcijų diegimą, lengvesnį atskirų modulių testavimą ir sklandesnius atnaujinimus.
Tačiau yra tam tikrų sunkumų ir su mikro priekiniais įrenginiais.
Pavyzdžiui, visapusiškas programos testavimas gali būti sudėtingas.
Be to, kadangi reikalinga didelė inžinierių ir administratorių komanda, mikro frontend projektai yra labai brangūs.
Todėl prieš priimdami sprendimą turite atsižvelgti į visus savo verslo aspektus.
Vladimiras Čamajus
Kažkaip nesupratau, kokiu principu veikia komunikacija tarp atskirų komponentų frontendėje. Nesuprantu, kaip norima sujungti komponentus, sukurtus skirtingose sistemose. Straipsnyje apie tai nieko nėra. Įvykių ir klausytojų sistema man atrodo kaip pragaras žemėje. Kaip turėtume tai įsivaizduoti?