Sa herë që ndërmerrni një detyrë të softuerit të mesëm të ndërmarrjes me sistemet ekzistuese të mbështetjes, do të zbuloni një ose dy fole në kuti. Por kur hasni në një softuer të ngadaltë, por kritik për misionin, që nuk mund të përmirësohet dhe as të zëvendësohet, ju e dini se keni goditur gralin e shenjtë të antimodeleve.
Sado e frikshme të jetë, nuk është pa ilaç. Dhe shpesh, një dizajn më pak i menduar mund ta bëjë situatën shumë më keq sesa është. Ajo që po përpiqem të propozoj këtu janë disa konsiderata të dizajnit që mund t'i provoni nëse gjendeni ndonjëherë në të njëjtën situatë fatkeqe.
A jemi akoma atje? — Caching i përgjigjes
Gjatë analizimit të trafikut të marrë nga shërbimi mbështetës, mund të vëreni disa kërkesa të përsëritura për pyetje që përdoren për të kontrolluar statusin e diçkaje. Për shembull, nëse merrni një bazë të shërbimit të klientit, mund të ketë kërkesa për të kontrolluar nëse klienti është aktiv? ose lloji i besnikërisë së klientit. Tani, ky informacion nuk ndryshon shpesh. Këto lloj kërkesash janë ideale për t'u ruajtur në memorien specifike.
Kryesisht, ne mund të mendojmë për dy mënyra se si mund të konfigurohet memoria e fshehtë. Opsioni i parë do të ishte më i thjeshtë dhe nuk ka varësi nga shërbimi backend. Kur nyja cache kërkohet për informacion që nuk ka, ajo do ta marrë atë nga prapavija e ngadaltë, do të përditësojë cache-in dhe do t'ia kthejë atë kërkuesit.
Opsioni i dytë është ku cache përditësohet sa herë që përditësohen të dhënat e backend. Kjo kërkon një integrim me shërbimin backend dhe shërbimi i backend-it duhet të jetë i pajisur ose për të thirrur një API në nyjen e memories ose duhet të ketë regjistra që mund të përpunohen për të nxjerrë informacionin e kërkuar.
Dhe natyrisht, zgjidhja ideale do të ishte një hibrid i këtyre dy opsioneve, por rrallë do të kishit një zgjidhje ideale.
Mund të marr një mesazh? Përdorimi i kthimeve të thirrjeve dhe lidhjeve të burimeve
Një gjë që do të kuptoni është se çdo gjë në jetë ka përparësinë e saj, dhe thirrjet API nuk janë të ndryshme. Jo të gjitha thirrjet API duhet të servisohen menjëherë. Ndonjëherë pranimi i thirrjes API dhe ofrimi i një mjeti për të gjurmuar statusin e shërbimit më vonë është mënyra më e mirë e veprimit.
Thirrjet dhe lidhjet e burimeve mund të përdoren të dyja për të arritur të njëjtin qëllim, megjithëse kthimet e thirrjeve janë aktive dhe lidhjet e burimeve janë pasive. Dhe të dy kanë të mirat dhe të këqijat e tyre të qenësishme.
Një callback është një URL nga ana e klientit e regjistruar në server. Shërbimi API pranon kërkesën e klientit, por nuk përgjigjet menjëherë me informacionin e kërkuar. Shërbimi API pret derisa shërbimi i ngadaltë mbështetës të jetë i disponueshëm dhe të përpunojë informacionin e kërkuar dhe ta shtyjë atë në URL-në e kthimit të thirrjes.
Lidhjet e burimeve janë faqeshënues të ofruar nga një shërbim për një burim të krijuar në anën e serverit. Dallimi kryesor midis një lidhjeje burimi në krahasim me një kthim kthimi është se klienti duhet të telefonojë lidhjen e burimit për të kontrolluar nëse operacioni i kërkuar është përfunduar.
Të dyja këto opsione funksionojnë në konceptin e mesazheve asinkrone.
Dështim i parashikueshëm - Ndërprerësit
Modeli i ndërprerësit e merr emrin e tij, siç e keni marrë me mend, një ndërprerës qarku!. Ndërprerësi i qarkut në shtëpinë tuaj funksionon bazuar në një shirit termo-magnetik që është projektuar të dështojë në një pikë të caktuar, duke mbrojtur shtëpinë tuaj nga një rritje e energjisë. Ky parim i projektimit quhet dështim i parashikueshëm.
Përfitimi kryesor i ndërprerësit në shtëpinë tuaj është të mbroni shtëpinë tuaj nga një rritje e papritur e energjisë. Modeli i ndërprerësit, megjithatë, është pak më ndryshe. Së pari, mund të vendosni bazuar në modelet e vonesës se cili është dështimi i parashikueshëm për ndërprerësin. Zakonisht, ekzistojnë dy parametra që merren parasysh për të vendosur për një pikë dështimi, numrin e kërkesave të dështuara dhe pragun e vonesës. Për hir të argumentit, le të themi se pragu i vonesës është 5000 ms dhe numri i dështimeve është 3. Kjo do të thotë se nëse 3 kërkesa kërkojnë më shumë se 5000 ms për t'u përgjigjur, ndërprerësi do të fiket. Një parametër tjetër është periudha e skadimit. Kur të arrihet periudha e skadimit, ndërprerësi do të lejojë një kërkesë të kalojë dhe do të kontrollojë nëse pjesa e pasme është e përgjegjshme. Nëse është kështu, ai do të rivendosë ndërprerësin ose do ta ndërpresë përsëri.
Imagjinoni që nuk ka një ndërprerës qarku dhe shërbimi mbështetës nuk reagon ose i ngadalshëm. Çdo kërkesë hyrëse do të duhet të presë 5000 ms për të ditur se kërkesa ka skaduar. Kjo përfundimisht do të çojë në shterjen e burimeve dhe do të mbyt sistemin. Ajo që bën ndërprerësi është të sigurojë një mjet për të dështuar shpejt dhe në mënyrë të parashikueshme.
Ndonjëherë, është mirë të humbasësh një ose dy poste nëse ende mund ta mbash fortesën.
Sistemet e prapambetura të ngadalta shpesh janë kafshë të keqkuptuara, paksa si Ogres. Arsyeja për ngadalësinë ose mosdisponueshmërinë e tyre shpesh varet nga kritika e tyre e biznesit. Këto sisteme janë të bombarduara me kërkesa më shumë sesa janë parashikuar për të trajtuar, duke rezultuar në këto sisteme të ngadalta ose të padisponueshme. Zgjidhjet që kam propozuar këtu bazohen në dy faktorë. Një, zvogëloni numrin e kërkesave që godasin fundin. Së dyti, shmangni ngarkimin e shërbimit mbështetës kur ai tashmë është i mbingarkuar (shmangni kohët e pikut).
Edhe pse mund të mos jeni në gjendje të hiqni qafe bishën, mund të mësoni të jetoni me të.
