Hey Habr!

Di ronahiya bûyerên heyî yên ji ber coronavirus de, hejmarek karûbarên Înternetê dest bi wergirtina barkirina zêde kirine. Bo nimûne, Yek ji zincîreyên kirrûbirra Keyaniya Yekbûyî tenê malpera xweya fermana serhêl rawestand., ji ber ku kapasîteya têr nebû. Û her gav ne gengaz e ku meriv serverek bi tenê pêvekirina alavên bihêztir zûtir bike, lê divê daxwazên xerîdar bêne pêvajo kirin (an jî ew ê biçin pêşbazan).

Di vê gotarê de ez ê bi kurtasî li ser pratîkên populer biaxivim ku dê bihêle ku hûn karûbarek bilez û toleransê biafirînin. Lêbelê, ji nexşeyên pêşkeftina gengaz, min tenê yên ku niha ne hilbijart bikaranîna wê hêsan e. Ji bo her babetekê, we an pirtûkxaneyên amade hene, an jî we derfet heye ku hûn pirsgirêkê bi karanîna platformek ewr çareser bikin.

Pîvana Horizontal

Xala herî hêsan û herî naskirî. Bi konvansiyonel, du pileyên belavkirina barkirinê yên herî gelemperî pîvana horizontî û vertîkal in. Di bûyera yekem de hûn destûrê didin karûbaran ku paralel bimeşînin, bi vî rengî barkirinê di navbera wan de belav dikin. Di ya duyem de hûn serverên bihêztir ferman dikin an kodê xweşbîn dikin.

Mînakî, ez ê hilanîna pelê cloudê ya razber, ango hin analoga OwnCloud, OneDrive, û hwd.

Wêneyek standard a dorpêçek wusa li jêr e, lê ew tenê tevliheviya pergalê destnîşan dike. Beriya her tiştî, em hewce ne ku bi rengek karûbaran hevdeng bikin. Ger bikarhêner pelek ji tabletê hilîne û dûv re bixwaze wê ji têlefonê bibîne çi dibe?

Cûdahiya di navbera nêzîkbûnan ​​de: di pîvana vertîkal de, em amade ne ku hêza girêkan zêde bikin, û di pîvandina horîzontal de, em amade ne ku girêkên nû lê zêde bikin da ku barkirinê belav bikin.

CQRS

Fermana Query Berpirsiyariya Veqetandinê Nimûneyek pir girîng, ji ​​ber ku ew dihêle xerîdarên cûda ne tenê bi karûbarên cihêreng ve girêbidin, lê di heman demê de heman rûdanên bûyerê jî bistînin. Feydeyên wê ji bo serîlêdanek hêsan ne ew qas eşkere ne, lê ji bo karûbarek mijûl pir girîng e (û hêsan). Esasê wê: Pêdivî ye ku herikîna daneya ketin û derketinê li hev nekeve. Ango, hûn nikarin daxwazek bişînin û li benda bersivekê bin; li şûna wê, hûn daxwazek ji karûbarê A re dişînin, lê bersivek ji karûbarê B distînin.

Bonusa yekem a vê nêzîkbûnê şiyana şikandina pêwendiyê (di wateya berfireh a peyvê de) dema ku daxwazek dirêj pêk tîne. Mînakî, em rêzek standard kêm-zêde bigirin:

1. Xerîdar daxwazek ji serverê re şand.
2. Pêşkêşkar demek dirêj a pêvajoyê dest pê kir.
3. Server bi encamê re bersiv da muwekîlê.

Werin em bifikirin ku di xala 2-ê de pêwendî qut bû (an tor ji nû ve hat girêdan, an jî bikarhêner çû rûpelek din, pêwendiyê qut kir). Di vê rewşê de, dê ji bo serverê dijwar be ku bersivek ji bikarhênerê re bi agahdariya li ser tiştê ku bi rastî hatî pêvajo kirin bişîne. Bi karanîna CQRS, rêzik dê hinekî cûda be:

1. Xerîdar ji nûvekirinan re bûye abone.
2. Xerîdar daxwazek ji serverê re şand.
3. Server bersiv da "daxwaz qebûl kirin."
4. Pêşkêşkar bi riya kanala ji xala "1" bi encam bersiv da.

Wekî ku hûn dikarin bibînin, plan hinekî tevlihevtir e. Digel vê yekê, nêzîkatiya daxwaz-bersiv a intuitive li vir winda ye. Lêbelê, wekî ku hûn dikarin bibînin, dema ku daxwazek pêvajoy dike, qutbûna pêwendiyê dê bibe sedema xeletiyekê. Wekî din, heke bi rastî bikarhêner ji çend cîhazan ve bi karûbarê ve girêdayî ye (mînakî, ji têlefonek desta û ji tabletek), hûn dikarin pê ewle bibin ku bersiv ji her du cîhazan re tê.

Balkêş e, koda ji bo hilanîna peyamên hatinî hem ji bo bûyerên ku ji hêla xerîdar bixwe ve bandor bûne, hem jî ji bo bûyerên din, tevî yên ji xerîdarên din, yek dibe (ne 100%).

Lêbelê, di rastiyê de em ji ber vê yekê ku herikîna yekalî dikare bi şêwazek fonksiyonel (bikaranîna RX û mîna wan) were rêve kirin, bonusek zêde werdigire. Û ev jixwe plusek ciddî ye, ji ber ku di eslê xwe de serîlêdan dikare bi tevahî reaktîf were çêkirin, û di heman demê de nêzîkatiyek fonksiyonel jî bikar bîne. Ji bo bernameyên qelew, ev dikare bi girîngî pêşveçûn û çavkaniyên piştgirî xilas bike.

Ger em vê nêzîkatiyê bi pîvana horizontî re bikin yek, wê hingê em wekî bonusek jêhatîbûnê digirin ku daxwazan ji serverek re bişînin û bersivan ji yekî din werbigirin. Bi vî rengî, xerîdar dikare karûbarê ku ji bo wî rehet e hilbijêrin, û pergala hundur dê hîn jî karibe bûyeran rast bişopîne.

Event Sourcing

Wekî ku hûn dizanin, yek ji taybetmendiyên sereke yên pergala belavkirî nebûna demek hevpar, beşek rexnegir a hevpar e. Ji bo yek pêvajoyek, hûn dikarin hevdengiyek (li ser heman mutexes) bikin, ku di hundurê wê de hûn pê ewle ne ku kesek din vê kodê bicîh nake. Lêbelê, ev ji bo pergalek belavkirî xeternak e, ji ber ku ew ê sermayê hewce bike, û di heman demê de dê hemî bedewiya pîvandinê jî bikuje - hemî pêkhate hîn jî dê li benda yekê bisekinin.

Ji vir em rastiyek girîng digirin - pergalek belavkirî ya bilez nayê hevdem kirin, ji ber ku wê hingê em ê performansê kêm bikin. Ji hêla din ve, em pir caran hewceyê hevrêziyek di navbera pêkhateyan de ne. Û ji bo vê yekê hûn dikarin nêzîkatiya bi kar bînin hevgirtina dawî, ku tê garantî kirin ku heke piştî nûvekirina paşîn ("di dawiyê de") ji bo demekî guheztina daneyan nebin, hemî pirs dê nirxa nûvekirî ya paşîn vegerînin.

Girîng e ku meriv fêm bike ku ji bo databasên klasîk ew pir caran tê bikar anîn hevgirtina xurt, ku her girêk xwedan heman agahdarî ye (ev bi gelemperî di doza ku danûstendin tenê piştî ku servera duyemîn bersiv dide sazkirî tête peyda kirin). Li vir ji ber astên îzolasyonê hin rihetî hene, lê ramana gelemperî heman dimîne - hûn dikarin di cîhanek bi tevahî hevgirtî de bijîn.

Lêbelê, em vegerin karê bingehîn. Ger beşek ji sîstemê dikare bi avakirin hevgirtina dawî, hingê em dikarin diyagrama jêrîn ava bikin.

Taybetmendiyên girîng ên vê rêbazê:

• Her daxwazek hatî di yek dorê de tê danîn.
• Dema ku daxwazek hilberandin, dibe ku karûbar di heman demê de peywiran di rêzên din de bi cîh bike.
• Her bûyerek gihîştî xwedan nasnameyek e (ku ji bo veqetandinê hewce ye).
• Rêz ji hêla îdeolojîk ve li gorî nexşeya "tenê pêvek" dixebite. Hûn nikarin hêmanan jê derxînin an wan ji nû ve saz bikin.
• Rêz li gorî nexşeya FIFO dixebite (bibore ji bo tatolojiyê). Ger hewce be ku hûn darvekirina paralel bikin, wê hingê di qonaxek de divê hûn tiştan biguhezînin rêzên cûda.

Bihêle ez ji we re bi bîr bînim ku em doza hilanîna pelên serhêl dinirxînin. Di vê rewşê de, pergal dê tiştek wusa xuya bike:

Girîng e ku karûbarên di diagramê de ne hewce ne ku serverek veqetandî be. Dibe ku pêvajo jî heman be. Tiştek din jî girîng e: Ji hêla îdeolojîk ve, ev tişt bi vî rengî têne veqetandin ku pîvana horizontî bi hêsanî were sepandin.

Û ji bo du bikarhêneran diagram dê bi vî rengî xuya bike (karûbarên ku ji bo bikarhênerên cûda têne armanc kirin bi rengên cûda têne destnîşan kirin):

Bonusên ji berhevokek weha:

• Karûbarên hilberandina agahdariyê ji hev têne veqetandin. Rêz jî ji hev vediqetin. Ger hewce be ku em guheztina pergalê zêde bikin, wê hingê em tenê hewce ne ku bêtir karûbaran li ser bêtir serveran bidin destpêkirin.
• Dema ku em ji bikarhênerek agahdarî distînin, ne hewce ye ku em li bendê bin heya ku dane bi tevahî xilas bibin. Berevajî vê, divê em tenê bersiva "ok" bidin û dûv re hêdî hêdî dest bi xebatê bikin. Di heman demê de, rêz lûtkeyan sivik dike, ji ber ku lê zêdekirina tiştek nû zû çêdibe, û bikarhêner ne hewce ye ku li benda derbasbûnek bêkêmasî ya tevahiya çerxê bimîne.
• Wek nimûne, min karûbarek deduplication ku hewl dide pelên yeksan bi hev re bike lê zêde kir. Ger ew di 1% bûyeran de ji bo demek dirêj bixebite, dê xerîdar wê bi zorê ferq bike (li jor binêre), ku ev yek plusek mezin e, ji ber ku êdî ne hewce ye ku em XNUMX% bilez û pêbawer bin.

Lêbelê, dezavantajên yekser têne xuyang kirin:

• Sîstema me hevgirtina xwe ya hişk winda kiriye. Ev tê vê wateyê ku heke, mînakî, hûn bibin aboneya karûbarên cihêreng, wê hingê bi teorîkî hûn dikarin dewletek cûda bistînin (ji ber ku yek ji karûbaran dibe ku dem tune ku ji rêza hundurîn agahdariyek werbigire). Wekî encamek din, pergalê niha demek hevpar tune. Ango, ne mimkûn e, bo nimûne, meriv hemî bûyeran bi tenê dema gihîştinê birêkûpêk bike, ji ber ku demjimêrên di navbera serveran de dibe ku ne hevdem bin (digel vê yekê, heman demê li ser du serveran utopyayek e).
• Naha ti bûyer nekarin bi hêsanî paşde werin vegerandin (wek ku dikare bi databasek were kirin). Di şûna wê de, hûn hewce ne ku bûyerek nû lê zêde bikin - bûyera tezmînatê, ku dê dewleta paşîn bi ya pêdivî biguhezîne. Wek mînakek ji deverek bi vî rengî: bêyî ji nû ve nivîsandina dîrokê (ku di hin rewşan de xirab e), hûn nikarin di git de peywirek paşde vegerînin, lê hûn dikarin taybetmendiyek çêbikin. rollback commit, ku di bingeh de tenê dewleta kevn vedigere. Lêbelê, hem kirinên xelet û hem jî paşveçûn dê di dîrokê de bimînin.
• Dibe ku şemaya daneyê ji serbestberdanê heya serbestberdanê biguhezîne, lê bûyerên kevin dê êdî nikaribin li standarda nû werin nûve kirin (ji ber ku bûyer di prensîbê de nayên guhertin).

Wekî ku hûn dibînin, Çavkaniya Bûyer bi CQRS re baş dixebite. Digel vê yekê, bicîhkirina pergalek bi rêzikên bikêr û hêsan, lê bêyî veqetandina herikên daneyê, jixwe bi serê xwe dijwar e, ji ber ku hûn neçar in ku xalên hevdemkirinê zêde bikin ku dê tevahiya bandora erênî ya rêzan bêbandor bike. Bi yekcarî sepandina her du nêzîkatiyan, pêdivî ye ku meriv koda bernameyê hinekî rast bike. Di rewşa me de, dema ku pelek ji serverê re dişîne, bersiv tenê "ok" tê, ku tenê tê vê wateyê ku "operasyona zêdekirina pelê xilas bû." Bi fermî, ev nayê vê wateyê ku dane ji berê ve li ser cîhazên din hene (mînakek, karûbarê jêbirinê dikare navnîşê ji nû ve ava bike). Lêbelê, piştî demekê, dê xerîdar agahdariyek bi şêwaza "pelê X hate tomarkirin" werbigire.

Di encamê da:

• Hejmara statûyên şandina pelan zêde dibe: Li şûna "pelê şandî" ya klasîk, em du distînin: "pel li rêza serverê hate zêdekirin" û "pel li hilanînê hate tomarkirin." Ya paşîn tê vê wateyê ku cîhazên din dikarin berê dest bi wergirtina pelê bikin (ji bo rastiya ku rêz bi leza cihêreng tevdigerin hatine sererast kirin).
• Ji ber vê yekê ku agahdariya radestkirinê naha bi kanalên cihêreng tê, pêdivî ye ku em ji bo wergirtina rewşa pêvajoyê ya pelê çareyan peyda bikin. Di encama vê yekê de: Berevajî daxwaz-bersiva klasîk, dema ku pelê hildiweşîne, xerîdar dikare ji nû ve were destpêkirin, lê rewşa vê pêvajoyê bixwe dê rast be. Digel vê yekê, ev tişt, bi bingehîn, ji qutîkê dixebite. Di encamê de: em niha li hember têkçûnan bêtir tolerans in.

Shading

Wekî ku li jor hatî behs kirin, pergalên çavkaniyê yên bûyeran domdariya hişk tune. Ev tê vê wateyê ku em dikarin çend depoyan bêyî hevdemkirinê di navbera wan de bikar bînin. Bi nêzîkbûna pirsgirêka xwe, em dikarin:

• Pelên li gorî celebê veqetînin. Mînakî, wêne/vîdyo dikarin werin deşîfrekirin û formatek bikêrtir were hilbijartin.
• Hesabên cuda li gorî welat. Ji ber gelek qanûnan, dibe ku ev pêdivî be, lê ev plansaziya mîmarî bixweber fersendek wusa peyda dike

Ger hûn dixwazin daneyan ji depoyek din veguhezînin, wê hingê wateyên standard êdî têrê nakin. Mixabin, di vê rewşê de, hûn hewce ne ku rêzê rawestînin, koçberiyê bikin, û paşê wê dest pê bikin. Di rewşa gelemperî de, dane nekarin "li ser firînê" werin veguheztin, lêbelê, heke rêza bûyerê bi tevahî were hilanîn, û we dîmenên dewletên hilanînê yên berê hebin, wê hingê em dikarin bûyeran bi vî rengî dubare bikin:

• Di Çavkaniya Bûyerê de, her bûyer xwedan nasnameya xwe ye (bi îdeal, ne kêm dibe). Ev tê vê wateyê ku em dikarin zeviyek li hilanînê zêde bikin - nasnameya hêmana paşîn a pêvajoyî.
• Em rêzê dubare dikin da ku hemî bûyer ji bo çend depoyên serbixwe bêne pêvajo kirin (ya yekem ew e ku data tê de berê hatî hilanîn, û ya duyemîn nû ye, lê dîsa jî vala ye). Rêza duyemîn, bê guman, hêj nayê pêvajo kirin.
• Em rêza duyemîn didin destpêkirin (ango, em dest bi dubarekirina bûyeran dikin).
• Gava ku rêza nû nisbeten vala be (ango, ferqa dema navînî ya di navbera lêzêdekirina hêmanek û vegerandina wê de tê pejirandin), hûn dikarin dest bi guheztina xwendevanan li hilana nû bikin.

Weke ku hûn jî dibînin, di pergala me de lihevhatinek hişk nebû û hîn jî tune. Tenê domdariya dawîn heye, ango garantiyek ku bûyer bi heman rêzê têne pêvajo kirin (lê dibe ku bi derengiyên cûda). Û, bi karanîna vê yekê, em dikarin bi rehetî daneyan veguhezînin bêyî sekinandina pergalê li aliyê din ê cîhanê.

Bi vî rengî, berdewamkirina mînaka me ya di derbarê hilanîna serhêl ji bo pelan de, mîmariyek weha jixwe gelek bonusan dide me:

• Em dikarin tiştan bi rengek dînamîk nêzî bikarhêneran bikin. Bi vî awayî hûn dikarin kalîteya karûbarê çêtir bikin.
• Dibe ku em hin daneyan di nav pargîdaniyan de hilînin. Mînakî, bikarhênerên Enterprise bi gelemperî hewce dikin ku daneyên wan li navendên daneya kontrolkirî werin hilanîn (ji bo ku ji lehiyên daneyan dûr nekevin). Bi parvekirinê em dikarin bi hêsanî piştgiriyê bidin vê. Û heke xerîdar xwedan ewrek lihevhatî be, peywir hê hêsantir e (mînak, Azure xwe hosted).
• Û ya herî girîng ev e ku em neçar in ku vê yekê bikin. Beriya her tiştî, ji bo destpêkê, em ê bi yek hilanînê ji bo hemî hesaban pir kêfxweş bibin (da ku zû dest bi xebatê bikin). Û taybetmendiya sereke ya vê pergalê ev e ku her çend ew berfireh be jî, di qonaxa destpêkê de ew pir hêsan e. Hûn ne hewce ne ku tavilê kodek binivîsin ku bi mîlyon rêzên serbixwe yên cihêreng re dixebite, hwd. Ger hewce be, ev dikare di pêşerojê de were kirin.

Mêvandariya Naveroka Statîk

Dibe ku ev xal pir eşkere xuya bike, lê dîsa jî ji bo serîlêdanek barkirî ya standard kêm-zêde pêdivî ye. Esasê wê hêsan e: hemî naveroka statîk ne ji heman servera ku serîlêdanê lê ye, lê ji yên taybetî yên ku bi taybetî ji bo vê peywirê hatine veqetandin têne belav kirin. Wekî encamek, van operasyonan zûtir têne kirin (nginx şertî pelan ji serverek Java-ê zûtir û bihatir peyda dike). Plus mîmariya CDN (Tora Content Network) destûrê dide me ku em pelên xwe nêzîkê bikarhênerên dawîn bibînin, ku bandorek erênî li ser rehetiya xebata bi karûbarê re dike.

Mînaka herî hêsan û standard a naveroka statîk ji bo malperek komek nivîsar û wêneyan e. Her tişt bi wan re hêsan e - ew di pêş de têne zanîn, paşê arşîv li serverên CDN-ê têne barkirin, ji wir ew li bikarhênerên dawîn têne belav kirin.

Lêbelê, di rastiyê de, ji bo naveroka statîk, hûn dikarin nêzîkatiyek hinekî mîna mîmariya lambda bikar bînin. Ka em vegerin ser peywira xwe (hilanîna pelê serhêl), ku tê de pêdivî ye ku em pelan li bikarhêneran belav bikin. Çareseriya herî hêsan ev e ku meriv karûbarek biafirîne ku, ji bo her daxwazek bikarhêner, hemî kontrolên pêwîst (destûrkirin, hwd.) bike, û dûv re pelê rasterast ji hilana me dakêşîne. Kêmasiya sereke ya vê nêzîkbûnê ev e ku naveroka statîk (û pelek bi revîzyonek diyarkirî, bi rastî, naverok statîk e) ji hêla heman serverê ve ku mantiqa karsaziyê vedihewîne, tê belav kirin. Di şûna wê de, hûn dikarin diagrama jêrîn çêbikin:

• Server URL-ya dakêşanê peyda dike. Ew dikare ji forma file_id + key be, ku key îmzeyek mînî-dîjîtal e ku mafê gihîştina çavkaniyê di 24 demjimêrên pêş de dide.
• Pelê ji hêla nginx-a hêsan ve bi vebijarkên jêrîn ve tê belav kirin:
  • Cachkirina naverokê. Ji ber ku ev karûbar dikare li ser serverek cihêreng were bicîh kirin, me ji xwe re rezervek ji bo pêşerojê bi şiyana hilanîna hemî pelên herî dawî yên dakêşandî li ser dîskê hiştiye.
  • Kontrolkirina mifteyê di dema afirandina girêdanê de
• Vebijarkî: hilberandina naverokê. Mînakî, heke em hemî pelên di karûbarê de tevlihev bikin, wê hingê em dikarin rasterast di vê modulê de vekêşanê bikin. Wekî encamek: Operasyonên IO li ku derê ne têne kirin. Arşîvkerek li Java-ê dê bi hêsanî gelek bîranînek zêde veqetîne, lê dibe ku ji nû ve nivîsandina karûbarek bi mantiqa karsaziyê di şertên Rust / C ++ de jî bêbandor be. Di doza me de, pêvajoyên cihêreng (an jî karûbar) têne bikar anîn, û ji ber vê yekê em dikarin bi rengek bi bandor mantiqa karsaziyê û operasyonên IO-yê ji hev veqetînin.

Ev nexşe ne pir dişibihe belavkirina naveroka statîk (ji ber ku em tevahî pakêta statîk li cîhek bar nakin), lê di rastiyê de, ev nêzîkatî bi rastî bi belavkirina daneyên neguhêrbar re têkildar e. Wekî din, ev nexşe dikare ji rewşên din re were gelemperî kirin ku naverok ne tenê statîk e, lê dikare wekî komek blokên neguhêrbar û ne-hilweşîn were temsîl kirin (her çend ew dikarin werin zêdekirin).

Wekî mînakek din (ji bo bihêzkirinê): heke we bi Jenkins / TeamCity re xebitî, wê hingê hûn dizanin ku her du çareserî di Java de têne nivîsandin. Her du jî pêvajoyek Java-yê ne ku hem orkestrasyonê û hem jî rêveberiya naverokê pêk tîne. Bi taybetî, wan her du peywirên mîna "pel / peldankek ji serverê veguhezînin" hene. Wek mînak: derxistina berheman, veguheztina koda çavkaniyê (gava ku ajan kodê rasterast ji depoyê dakêşîne, lê server wê ji wî re dike), gihîştina têketinê. Van hemî peywiran di barkirina IO-ya xwe de cûda dibin. Ango, derdikeve holê ku servera ku berpirsiyarê mantiqa karsaziya tevlihev e, di heman demê de pêdivî ye ku bi bandorkerî herikînên mezin ên daneyê di nav xwe de derxîne. Û ya herî balkêş ev e ku operasyonek wusa dikare li gorî heman nexşeyê ji heman nginx re were veguheztin (ji bilî ku divê mifteya daneyê li daxwazê ​​were zêdekirin).

Lêbelê, heke em vegerin pergala xwe, em diagramek wusa distînin:

Wekî ku hûn dikarin bibînin, sîstem bi awayekî radîkal tevlihevtir bûye. Naha ew ne tenê pêvajoyek piçûk e ku pelan li herêmî hilîne. Naha ya ku tê xwestin ne piştgirîya herî hêsan e, kontrolkirina guhertoya API, hwd. Ji ber vê yekê, piştî ku hemî diagram hatin xêz kirin, çêtirîn e ku meriv bi hûrgulî binirxîne ka berfirehbûn hêjayî lêçûn e. Lêbelê, heke hûn dixwazin ku hûn bikaribin pergalê berfireh bikin (tevî ku hûn bi hejmareke pirtir bikarhêneran re bixebitin), wê hingê hûn neçar in ku biçin çareseriyên bi vî rengî. Lê, wekî encamek, pergal ji hêla mîmarî ve ji bo barkirina zêde amade ye (hema hema her pêkhat dikare ji bo pîvandina horizontî were klon kirin). Pergal dikare bêyî rawestandina wê were nûve kirin (bi tenê hin operasyon dê hinekî hêdî bibin).

Wekî ku min di destpêkê de got, naha hejmarek karûbarên Înternetê dest bi wergirtina barkirina zêde kirine. Û hin ji wan bi tenê dest bi rawestandina xebata rast kirin. Bi rastî, pergal tam di dema ku karsazî diviyabû drav bikira têk çûn. Ango, li şûna radestkirina taloqkirî, li şûna ku ji xerîdaran re pêşniyar bike "radestkirina xwe ji bo mehên pêş plansaz bike", pergalê bi tenê got "herin pêşbazên xwe." Di rastiyê de, ev bihayê hilberîna kêm e: winda dê bi rastî dema ku qezenc dê herî zêde be.

encamê

Ev hemû nêzîkatî berê dihatin zanîn. Heman VK ev demek dirêj e ku ramana Naveroka Static Hosting bikar tîne da ku wêneyan nîşan bide. Pir lîstikên serhêl nexşeya Sharding bikar tînin da ku lîstikvanan li herêman dabeş bikin an cîhên lîstikê ji hev veqetînin (heke cîhan bixwe yek be). Nêzîkatiya Çavkaniya Bûyerê di e-nameyê de bi rengek çalak tê bikar anîn. Piraniya serîlêdanên bazirganiyê yên ku dane bi domdarî têne wergirtin bi rastî li ser nêzîkatiyek CQRS têne çêkirin da ku karibin daneyên hatine wergirtin fîlter bikin. Welê, pîvana horizontî di gelek karûbaran de ji bo demek dirêj ve hatî bikar anîn.

Lêbelê, ya herî girîng, hemî van nimûneyan di serîlêdanên nûjen de pir hêsan bûne (heke ew guncan bin, bê guman). Ewr tavilê pîvazkirina Sharding û horizontî pêşkêşî dike, ku ji fermankirina serverên cihêreng ên veqetandî li navendên daneyên cihêreng bixwe hêsantir e. CQRS pir hêsantir bûye, heke tenê ji ber pêşkeftina pirtûkxaneyên wekî RX. Nêzîkî 10 sal berê, malperek hindik dikare vê yekê piştgirî bike. Bi saya konteynerên amadekirî yên bi Apache Kafka ve, Çavkaniya Bûyerê jî pir hêsan e ku were saz kirin. 10 sal berê ev dê nûbûnek bûya, niha ew gelemperî ye. Ew bi Mêvandariya Naveroka Statîk re jî wiha ye: ji ber teknolojiyên hêsantir (tevî rastiya ku belgeyên hûrgulî û databasek mezin a bersivan heye), ev nêzîkatî hê hêsantir bûye.

Wekî encamek, pêkanîna hejmarek nimûneyên mîmarî yên tevlihev naha pir hêsan bûye, ku tê vê wateyê ku çêtir e ku meriv berê xwe ji nêz ve lê binêre. Ger di serîlêdanek deh-salî de yek ji çareseriyên li jor ji ber lêçûna bilind a pêkanîn û xebitandinê hate terikandin, naha, di serîlêdanek nû de, an piştî vesazkirinê, hûn dikarin karûbarek biafirînin ku dê jixwe ji hêla mîmarî ve hem berfirehtir be ( di warê performansê de) û ji daxwazên nû yên xerîdar re amade ne (mînakî, ji bo herêmîkirina daneyên kesane).

Û ya herî girîng: ji kerema xwe heke serîlêdanek weya hêsan hebe van nêzîkatiyan bikar neynin. Erê, ew xweşik û balkêş in, lê ji bo malperek bi serdanek lûtkeya 100 kesan, hûn pir caran dikarin bi monolîtek klasîk re derbas bibin (qet nebe li derve, her tiştê hundur dikare li modulan were dabeş kirin, hwd.).

Source: www.habr.com