Enhavtabelo[Kaŝi][Montri]
La ideo de mikroservoj gajnis multan atenton lastatempe, kaj multaj firmaoj uzas ĝin por forigi grandajn monolitajn backends.
Iri la saman vojon kun la fasado ankoraŭ estas defio por multaj entreprenoj, eĉ se ĉi tiu distribuita maniero konstrui la servilflankon de retprogramoj estas pli-malpli fidinda laŭ esplorado kaj ekzekuto.
Pro ĝia proksima dependeco, la klientflanka monolito tipe malfaciligas integri novajn ecojn, adopti novajn teknologiojn kaj skali individuajn komponentojn.
Ĉi tiuj kaj aliaj defioj instigis programistojn de fasado esplori uzi mikroservojn.
Kiel rezulto, novega arkitektura strategio konata kiel mikro fasado estis evoluigita por krei la antaŭfinan tavolon de retejoj kaj ret-bazitaj aplikoj.
La esprimo unue estis uzita en 2016, kaj ekde tiam, ĝi rikoltis multe da atento por bona afero.
Ĉi tiu artikolo donos ĝeneralan komprenon pri kio estas mikrofinadoj kaj la aferoj, kiujn ili traktas. ĝi funkcias, same kiel avantaĝoj kaj malavantaĝoj.
Enkonduko al mikro-antaŭa arkitekturo
Nuntempa metodo de frontend-evoluigo nomata mikro-frontend-arkitekturo dividas a TTT-aplikaĵo en malgrandajn, sendependajn partojn.
Al la finuzanto, ĉi tiuj partoj ŝajnas esti unu unuo eĉ se ili estis konstruitaj sendepende kaj poste kunmetitaj.
Kun la diferenco, ke mikro fasadoj apartenas al la klienta flanko, ne al la servila flanko, de interretaj solvoj, la raciaĵo subesta ilin estas identa al tiu de mikroservoj.
Fari kompleksajn ret-bazitajn produktojn havas la plej sencon kiam oni uzas mikrofontan aliron.
Mikrofinaj fasadoj, kontraste al pli konvencia antaŭfina monolito, ebligas multajn teamojn kunlabori aparte pri diversaj programaj projektoj.
Programistoj povas krei retprogramojn pli rapide kaj kun pli granda skaleblo kaj konservebleco uzante ĉi tiun arkitekturan dezajnon.
Por diri simple, ĉiu mikrofando estas nur peco de kodo por aparta komponanto de la retpaĝo.
Ĉi tiuj funkcioj estas kontrolitaj de apartaj teamoj, ĉiu el kiuj specialiĝas pri certa industrio aŭ celo.
Monolita vs Mikroservoj vs Mikrofada arkitekturo
Pensu pri translokiĝo. Ĉu estos pli simple por vi organizi ĉion en kelkajn malgrandajn, sperte etikeditajn skatolojn kaj transloki ĉiun unuope aŭ paki la tutan personaron en unu grandegan skatolon kaj transporti ĝin al nova loko?
La evidenta solvo estas tie.
Ĉi tiu analogio komparas la du apartajn interretajn aplikaĵarkitekturojn, monolitojn kaj mikroservojn (ankaŭ konatajn kiel mikrofinadoj).
Monolita arkitekturo
Vi eble povos rememori la "bonajn malnovajn tagojn" kiam kompleta aplikaĵo estis kreita kiel ununura, kohezia ento. Tia metodo nomiĝas monolito, kiu estas malnova termino por granda ŝtonbloko.
Ĉi tio havas sencon.
Monolitaj sistemoj havas interdependajn elementojn. Tial, se vi volas modifi ion aŭ aldoni novan funkcion, eble la tuta sistemo rompiĝos.
Kvankam ĝi estas malnoviĝinta, ĝi foje ankoraŭ ekzistas. Jes, ni konscias pri via nuna esprimo.
La koncipa divido de la kodbazo en du malsamajn komponentojn - fasado (kliento-flanko) kaj backend (servilo-flanko) - iĝis neevitebla kiam novaj teknologioj formiĝis kaj softvaraĵoj iĝis pli komplikaj.
La plej populara metodo de operacio nun estas la apartigo de zorgoj inter la prezenta tavolo, kun kiu fina uzanto interagas, kaj ĉio, kio okazas en la fono.
Ĝi bezonas du programajn inĝenierajn teamojn, kun la antaŭa teamo konstruanta la vidajn komponentojn kaj la malantaŭa teamo konstruanta la retservojn, komercan logikon, datumaliron, integriĝojn, ktp.
Tamen, malgraŭ ĉi tiu disiĝo, ĉi tiu strategio ankoraŭ restas monolita nature.
La ĉefa ŝanĝo estas, ke ni nun havas du konsiderindajn blokojn de kodo—la fasado kaj la backend—anstataŭ unu grandega aplikaĵo. Monolitaj arkitekturoj ne devas esti teruraj; ili havas kelkajn avantaĝojn, inkluzive
- Simpla kaj rapida evoluo por etaj aplikoj kun ununura fontkodbazo kaj tre simpla dezajno;
- Testado kaj senararigado estas tre simplaj ĉar ĉiu kodo estas en unu loko, faciligante al teamo spuri la fluon de peto kaj identigi cimojn;
- Frue en la evoluo de aplikaĵo, elspezoj estas pli malmultekostaj ĉar nek infrastrukturkostoj nek disvolvaj kostoj estas faritaj ĝis novaj funkcioj estas aldonitaj.
La malavantaĝoj de ĉi tiu strategio estas reflektitaj en
- Restriktita deploja fleksebleco - teamoj devas atendi se estas nur manpleno da ili laborantaj en la projekto kaj nova deplojo estas postulata ĉiufoje kiam vi ĝisdatigas la kodon;
- Adopti novajn teknologiojn estas malfacila ĉar fari tion necesigas reverki signifan parton, se ne la tutan projekton.
- Kiam la nombro da programistoj pliiĝas, sistemo de kodo fariĝas proksime ligita, komplika kaj malfacile administrebla kaj komprenebla.
- Organizaj aferoj - ĉiu grupano devas uzi la saman version de bibliotekoj kaj raporti ajnajn ŝanĝojn se multaj teamoj laboras pri monolita projekto.
- Konzernoj kun skaleblo - ĉar la komponentoj de la projekto estas interligitaj, grimpi ilin aparte prezentas malfacilaĵojn kiuj rezultigas signifan malfunkcion kaj pli altajn elspezojn.
- La kompleksa logiko de la projekto povus esti malfacile komprenebla por novaj teamanoj, precipe se la inĝenieroj kiuj origine laboris pri ĝi ne plu estas dungitaj.
La evoluo de mikroservoj kaj iliaj proksimaj parencoj, kaj mikro fasadoj, traktis la primarajn problemojn kun monolitaj sistemoj.
Arkitekturo de mikroservoj
La arkitektura metodo konata kiel mikroservoj permesas la kreadon de multaj loze ligitaj kaj sendepende deplojeblaj pli malgrandaj komponentoj, aŭ servoj, kiuj konsistigas aplikaĵon.
Ĉiu servo havas sian propran kodbazon, CI/KD-duktojn, DevOps-procedurojn kaj procezojn por funkcii ilin.
Vi povas vidi, ke la monolita backend-teamo estas dividita en apartajn teamojn rigardante la supran bildon.
Ĉiu temigas individue malsaman aspekton de la aplikaĵo (kiel la produktoservo, serĉservo kaj pagservo).
Komunikado inter la servoj okazas per establitaj protokoloj konataj kiel APIoj, kiel ekzemple la malpeza REST API-protokolo kiu uzas sinkronajn peto-respondajn ŝablonojn.
Alia opcio estas uzi nesinkronan komunikadon uzante programaron kiel Kafka, kiu ofertas publikigi/aboni komunikajn strukturojn kaj eventojn.
Mikroservoj integriĝas kun la fasado per backend por la servo (BFF) aŭ API-Enirejo tra la reto. BFF ofertas personecigitan API por ĉiu kliento, dum API-Enirejoj donas ununuran punkton de aliro por kolekto de mikroservoj.
Sed eĉ kun aŭtonomaj backend-komponentoj kaj ĉiuj avantaĝoj kiujn ili provizas, la fasado ankoraŭ estas monolito.
Tial, ĉi tie estas utilaj mikroaj fasadoj.
Mikrofinaj arkitekturo
Simile al mikroservoj, kie malloze ligitaj komponantoj estas administritaj de pluraj teamoj, la mikro-interfada arkitekturo aplikas la koncepton al la retumilo.
Ĉi tiuj interfacoj de uzant-aplikaj retejoj sekvas ĉi tiun strukturon, kiu konsistas el iom aŭtonomaj komponantoj.
Teamoj ankaŭ estas kreitaj laŭ klientbezonoj aŭ uzkazoj prefere ol speciala kompetenteco aŭ teknologio.
Sekve, teamoj estas implikitaj en mikroservoj kaj mikrofinaj projektoj.
- vertikale tranĉitaj — ĉar ekzistas fasadprogramistoj, datumaj fakuloj, backend-inĝenieroj, QA-inĝenieroj, ktp. laborantaj en la sama projekto ankaŭ, ili kreas siajn funkciojn el la interfaco de uzanto al datumbazoj; kaj
- transfunkcia - ĉiu grupano kontribuas sian kompetentecon al la grupo.
Teamoj ankaŭ povas elekti la teknikan stakon, kiu plej konvenas al sia aparta linio de komerco.
Unu teamo povas uzi React por programi ĝian fragmenton. Alia teamo kreas novan Angular-version. Vue.js estas unu tia ekzemplo.
Mikrofinadoj estas uzataj kune kun rilataj mikroservoj por trakti problemojn kiujn evoluteamoj kutime havas kun monolitoj. La strategio ofertas la jenajn avantaĝojn.
- Teknologia libereco: Frontend-inĝenieroj povas elekti alternativajn JavaScript-kadrojn, rultempajn mediojn kaj tutajn teknologiajn stakojn depende de la bezonoj de la kompanio. Krom la malmoderna arkitekturo, freŝa kadro povus esti aplikata.
- Pli granda grado da fleksebleco estas ebla ĉar ĉiu mikrofina fasado estas memstara kaj povas esti evoluigita, testita, deplojita kaj ĝisdatigita aparte. Kiel rezulto, se unu teamo laboras pri funkcio kaj puŝis cimsolvon, kaj alia teamo devas aldoni sian propran funkcion, ili ne bezonas atendi ke la unua teamo plenumos sian taskon.
- Aŭtonomaj teamoj kaj sistemoj: Ĉiu produktteamo, kaj sekve ĉiu funkcio, povas funkcii kun malmulte da dependeco de aliaj, kio ebligas al ĝi daŭre funkcii eĉ kiam la proksimaj komponantoj ne estas disponeblaj.
- Multoblaj, pli malgrandaj kodbazoj: Ĉiu el la mikrofinadoj havos sian propran, pli regeblan, pli malgrandan kodbazon. Malpli da homoj koncentriĝos pri specifa UI-komponento, simpligos kodajn recenzojn kaj plibonigos ĝeneralan organizon.
- Simpla aplikaĵo-skalado: Alia avantaĝo de mikro-interfadoj estas la kapablo skali ĉiun funkcion individue. Male al monolitoj, kie la tuta programo devas esti skalita ĉiufoje kiam nova funkcio estas aldonita, tio igas la tutan procezon pli efika laŭ tempo kaj mono.
Kiel funkcias mikro fasado?
Kiel ni antaŭe diris, teamoj estas vertikale organizitaj ene de la mikrofadenda arkitekturo, kio signifas, ke ili estas apartigitaj per domajna scio aŭ celo kaj respondecas de komenco ĝis fino por specifa produkto.
Ĝi povas havi unu aŭ du malantaŭajn mikroservojn same kiel malgrandan fasadon. Pli detale, ni ekzamenu la karakterizaĵojn de ĉi tiu vida elemento, interagojn kun aliaj UI-komponentoj kaj enkorpiĝon en la hejmpaĝon.
Mikra fasado povas esti
- tuta paĝo (ekz., produkta detala paĝo) aŭ
- sekcioj de la paĝo uzeblaj de aliaj teamoj, kiel la kaplinioj, piedlinioj kaj serĉbretoj.
Vi povas dividi grandan retejon en plurajn paĝajn specojn kaj doni ĉiun tipon al specifa personaro por labori.
Tamen, pluraj komponantoj ofte okazas en multaj paĝoj, kiel kaplinioj, piedlinioj, sugestoblokoj, ktp. Sugestobloko, ekzemple, povas esti inkluzivita en hejmpaĝo, produkta detala paĝo aŭ eĉ la pagpaĝo.
Esence, teamoj povas krei pecojn, kiujn aliaj teamoj povas uzi sur siaj paĝoj.
La mikroaj fasadoj, tamen, povas esti deplojitaj aparte kiel malsamaj projektoj kontraste al la reuzeblaj komponantoj.
Ĉio ĉi sonas mirinda, sed por krei unuigitan interfacon, paĝoj kaj fragmentoj devas esti iel kombinitaj.
Ĉi tio postulas fasan integriĝon, kiu povas esti plenumita per diversaj strategioj, inkluzive de vojigo, komponado kaj komunikado (vidu la supran grafikon).
vojigo
Kiam servo de paĝo kontrolita de unu teamo estas postulata por aliri paĝon posedata de alia teamo, vojigo estas utila por paĝnivela integriĝo.
Ĉiu mikro fasado estas pritraktata kiel unupaĝa aplikaĵo. Simplaj HTML-ligoj povas esti uzataj por provizi vojigon.
Uzanto povas devigi la retumilon elŝuti la celmarkon de servilo kaj anstataŭigi la nunan paĝon per la nova klakante sur hiperligiloj.
La aplikaĵoŝelo estas la nura minimumo de HTML, CSS kaj JavaScript kiu funkciigas UI. Eĉ se la enhavaj datumoj petitaj de la servilo ankoraŭ atendas, la uzanto tuj ricevas senmovan montritan paĝon. La centra aplikaĵoŝelo funkcias kiel gepatra aplikaĵo por la unupaĝaj programoj kreitaj de la diversaj teamoj.
Ne gravas la biblioteko aŭ kadro kiu estas uzata, meta-kadroj ebligas la kunfandiĝon de diversaj paĝoj en unu solan.
kunmetaĵo
Kunmetaĵo estas la procezo aranĝi la pecojn por konveni ilin en la taŭgajn spacojn sur paĝo. Plejofte, la teamo kiu disvastigas la paĝon ne tuj prenas la enhavon de la fragmento.
Anstataŭe, ĝi metas lokokupilon aŭ markilon kie la fragmento devus esti en la markado.
Uzante malsaman komponan procezon, la fina asembleo estas plenumita. La komponado povas esti dividita en du bazajn kategoriojn: klient-flanko kaj servil-flanko.
Kliento-flanka komponado: La TTT-legilo estas uzata por krei kaj redakti HTML-markadon. Ĉiu mikro fasado havas la kapablon ŝanĝi kaj montri sian markadon aparte de la resto de la paĝo.
Retaj Komponantoj, ekzemple, permesas al vi efektivigi ĉi tiun tipon de konstruo.
La plano estas igi ĉiun fragmenton en TTT-komponenton kiu povas esti sendepende instalita kiel a.js-dosiero, post kio la programoj povas ŝargi kaj redoni ilin en la spacoj destinitaj por ili en la temo-aranĝo.
Retaj komponantoj dependas de la HTML kaj DOM API, kiujn aliaj fasadkadroj povas uzi, same kiel norma metodo de sendado kaj ricevado de datumoj per teatrorekvizitoj kaj eventoj.
Servilflanka komponado: Kun ĉi tiu dezajno, la UI-pecoj estas kombinitaj sur la servilo, kio rezultigas tute formitan paĝon sendita al la kliento-flanko, akcelante ŝarĝon.
La asembleo ofte estas efektivigita de aparta servo, kiu sidas inter la TTT-legilo kaj la TTT-serviloj. CDN estas unu okazo de la servo (enhava livera reto).
Vi povus elekti unu aŭ kombinaĵon de la du, depende de viaj bezonoj.
Mikrofinaj komunikadaj ŝablonoj
La mikro-frontend-arkitekturo funkcias plej bone kiam ekzistas malmulte al neniu interagado inter la diversaj komponentoj. Mikrofinadoj foje bezonas paroli unu kun la alia kaj dividi informojn. Jen kelkaj eblaj ŝablonoj, kiuj povus konduki al tio.
- Retaj laboristoj: Interreta laboristo estas mekanismo kiu ebligas retenhavon ruli JavaScript en la fono, sendepende de aliaj skriptoj, kaj sen influi la rapidecon de la paĝo. Unika laborista API estos provizita por ĉiu mikroprogramo. Ĉi tiu avantaĝo estas, ke tempopostula laboro povas esti farita en malsama fadeno, ebligante la UI-fadenon daŭrigi sen esti malrapidigita aŭ haltita.
- Event-elsendilo: En ĉi tiu kazo, multaj komponantoj komunikas unu kun la alia aŭskultante kaj agante pri ajnaj statoŝanĝoj en la komponentoj al kiuj ili estas abonitaj. Aliaj mikro fasadoj kiuj abonis tiun specifan eventon respondas kiam mikro fasado lanĉas tiun okazaĵon. Eventelsendilo kiu estis enkondukita en ĉiu mikro-frontend faras tion realigebla.
- Revokoj kaj apogiloj: En ĉi tiu sekcio, vi difinas gepatran komponanton kaj filajn komponantojn. La komunikado estas organizita en arb-similan strukturon. Gepatrokomponentoj utiligas apogilojn por peri la datenojn kiel funkciojn laŭ la komponentarbo al la infankomponentoj. Siavice, la infano povas efike atentigi la gepatron kiam io okazas en ilia stato respondante al revokoj. React uzas ĉi tiun reĝimon.
Avantaĝoj de Micro fasado
Evoluo en Rapide Aŭtonomaj Teamoj
Sendependa teamo povas krei ĉiun parton de TTT-apliko aŭ retejo kiam vi uzas mikrofontan metodon.
Ĉiu teamo estas tute aŭtonoma, kio signifas, ke ĝi respondecas pri la tuta komponenta evoluciklo, de koncepto ĝis liberigo kaj postproduktado.
Aldone, ĝi implicas, ke diversaj teamoj povas kunlabori perfekte dum samtempe laboras pri la sama projekto.
Tial, eldoncikloj estas sufiĉe pli rapidaj ol ili estus kun antaŭfinaj monolitoj.
Pli Malgrandaj Kodbazoj de Individuaj Mikro-Fandaĵoj Gvidas al Pli Pura Kodo
Monolitaj antaŭaj finaĵoj havas grandajn, maloportunajn kodbazojn kiuj iĝas ĉiam pli kaosaj kaj malfacilaj administri kun la tempo.
Mikrofinadoj traktas ĉi tiun problemon. La fontkodo de ĉiu mikroa fasado estas pli regebla ĉar ĝi estas pli malgranda, pli simpla kaj pli kompakta.
La ĝenerala retejo-solvo profitas de pli pura kodo kiel konsekvenco.
Plibonigita app-stabileco Pro Malfiksa Kunligo
Reta solvo malofte povas esti dividita en tute sendependajn pecojn. Sekve, mikroaj fasadoj ja parolas unu al la alia.
Tamen, ĉiu ligo inter la komponantoj estas signifa malgraŭ la malfiksa konektebleco.
La fiasko de unu komponento havas malmulte al neniu efiko al la operacio de ĉiuj aliaj komponentoj, kiu disponigas la plibonigitan stabilecon de interreta solvo.
Testado de Individuaj Trajtoj fariĝas pli simpla
Ĉi tiu profito rezultas de la karakterizaĵoj de mikroaj fasadoj. Surbaze de ĉi tiu arkitektura dezajno, la klientflanko de interreta solvo estas modula kaj ĉiu modulo estas aŭtonoma.
Kiel rezulto, taksi malgrandan parton de la uzantinterfaco per si mem estas pli facile por teamo fari ol provi masivan monoliton.
Reduktita Paka Grandeco Kondukas al Pli Rapida Paĝa Ŝarĝo
Unu el la ĉefaj kaŭzoj de prokrastaj ŝarĝotempoj en trajto-riĉaj monolitaj retsistemoj estas la grandeco de JavaScript-fasko. Aliflanke, mikrofadenda aliro faciligas redukti paĝan ŝarĝan tempon.
Retumilo ne devas elŝuti nebezonatan kodon plurfoje ĉar retpaĝo konsistas el pluraj etaj pakaĵoj. Kiel rezulto, paĝa rendimento kaj ŝarĝotempoj pliiĝas.
Teknologia Sendependeco
multoblaj antaŭfinaj kadroj povas esti uzata de programistoj por krei ununuran retan solvon kun mikro-frontend-arkitekturo.
Ĉar ĉiu komponento estas sendependa, ĝi povas esti konstruita uzante kian ajn teknologion konvenas al la taskoj de la teamo plej bone.
Kompreneble, programistoj devas singarde elekti kadrojn por la programaro, kiun ili respondecas, kaj konsultoj kun aliaj teamoj ankoraŭ estas forte konsilitaj.
Tamen, estas nula ŝanco, ke vi estos devigita uzi heredan kadron dum la daŭro de la vivodaŭro de la programo.
Malavantaĝoj de Micro Frontend
Kompleksa TTT-solvotestado en ĝia tuteco
Testi la diversajn modulojn de interreta solvo estas facila kiam ĝi uzas mikro-frontend-arkitekturon. Tamen ĝi diferencas de taksado de TTT-apliko entute.
Kontrolu ke ĉiuj partoj funkcias kiel celite antaŭ daŭrigi. Ĉi tio povus esti malfacila ĉar mikroaj fasadoj funkcias sendepende kaj havas apartajn liverajn procezojn.
Multkostaj Komencaj Investoj
Mikrofinaj evoluoj kutime postulas grandajn financajn elspezojn. Estas multekoste kunveni kaj konservi multajn antaŭajn teamojn.
Aldone, vi bezonos administran personan por organizi la laboron, certigi, ke ĉio estas kunordigita kaj garantii bonegan teaman komunikadon.
La komplekseco de Evoluo kaj Deplojo
La evoluaj kaj deplojproceduroj povas iĝi pli komplikaj kiel rezulto de mikro-frontend dezajno.
Solvo povus esti malorda de tro da komponentoj fare de sendependaj evoluigaj teamoj laborantaj pri la sama projekto, ekzemple, kio povus kaŭzi problemojn ĉe la deplojfazo.
La ĝusta muntado de ĉiuj moduloj kaj ilia glata integriĝo en la ĝeneralan skemon ankaŭ ne ĉiam estas simpla; ĉi tiu laboro kutime postulas ĝisfundan komprenon de ĉiuj dependecoj.
Problemoj pri Konservado de Kohereco en la Uzanto-Sperto
Subteni konsekvencan uzantinterfacon estas malfacila kiam teamoj laboras aparte pri pluraj partoj de la programaro.
La TTT-solvo devas esti dividita de ĉiuj programistoj de la projekto. Alie, povas esti multaj kontraŭdiroj laŭ la vojo.
konkludo
Mikrofinadoj, nuntempa arkitektura dezajno, povas multe plibonigi la agadon de grandskalaj mikroservo-bazitaj retdisvolvaj projektoj.
Ĝi ebligas al programistoj dividi la kompletan solvon en diskretajn partojn, kiuj povas esti kreitaj de pluraj aŭtonomaj teamoj. Multnombraj avantaĝoj sekvas el tio, inkluzive de pli rapida lanĉo de funkcioj, pli facila testado de individuaj moduloj kaj pli perfektaj ĝisdatigoj.
Sed ankaŭ estas iuj malfacilaĵoj kun mikro-interfadoj.
La ampleksa testado de aplikaĵo, ekzemple, povus esti malfacila.
Aldone, ĉar necesas granda teamo de inĝenieroj kaj administrantoj, mikroprojektoj estas tre multekostaj.
Sekve, antaŭ ol decidi, vi devas konsideri ĉiujn komponantojn de via komerca kazo.
Vladimír Čamaj
Iel mi ne komprenis laŭ kiu principo funkcias la komunikado inter unuopaj komponantoj ĉe la fasado. Mi ne komprenas kiel vi volas konekti komponantojn kreitajn en malsamaj kadroj. Estas nenio en la artikolo pri ĝi. La sistemo de eventoj kaj aŭskultantoj aspektas al mi kiel infero sur la tero. Kiel ni imagu ĝin?