Aupa Habr!

Koronabirusaren eraginez egungo gertaerak kontuan hartuta, Interneteko zerbitzu batzuk karga handitzen hasi dira. Adibidez, Erresuma Batuko txikizkako kateetako batek lineako eskaerak egiteko gunea gelditu besterik ez zuen egin., edukiera nahikorik ez zegoelako. Eta ez da beti posible zerbitzari bat bizkortzea ekipo indartsuagoak gehituz, baina bezeroen eskaerak prozesatu behar dira (edo lehiakideengana joango dira).

Artikulu honetan zerbitzu azkarra eta akatsekiko tolerantzia sortzeko aukera emango duten praktika ezagunei buruz hitz egingo dut laburki. Hala ere, garapen eskem posibleetatik, gaur egun daudenak bakarrik hautatu ditut erabiltzeko erraza. Elementu bakoitzeko, prest dauden liburutegiak dituzu, edo arazoa hodeiko plataforma bat erabiliz konpontzeko aukera duzu.

Eskalatze horizontala

Punturik errazena eta ezagunena. Ohikoki, karga banatzeko bi eskema ohikoenak eskalatze horizontala eta bertikala dira. Lehenengo kasuan zerbitzuak paraleloan exekutatzeko aukera ematen dizu, horrela karga haien artean banatuz. Bigarrenean zerbitzari indartsuagoak eskatzen dituzu edo kodea optimizatzen duzu.

Adibidez, hodeiko fitxategien biltegiratze abstraktuak hartuko ditut, hau da, OwnCloud, OneDrive eta abarren analogo batzuk.

Horrelako zirkuitu baten irudi estandarra behean dago, baina sistemaren konplexutasuna besterik ez du erakusten. Azken finean, zerbitzuak nolabait sinkronizatu behar ditugu. Zer gertatzen da erabiltzaileak fitxategi bat tabletetik gordetzen badu eta gero telefonotik ikusi nahi badu?

Planteamenduen arteko aldea: eskalatze bertikalean, nodoen potentzia handitzeko prest gaude, eta eskala horizontalean, karga banatzeko nodo berriak gehitzeko prest.

CQRS

Aginduen Kontsulta Erantzukizunen Segregazioa Eredu nahiko garrantzitsua, bezero ezberdinei zerbitzu desberdinetara konektatzeaz gain, gertaeren korronte berdinak jasotzeko aukera ematen baitu. Bere onurak ez dira hain agerikoak aplikazio sinple baterako, baina oso garrantzitsua da (eta sinplea) zerbitzu okupatu baterako. Bere funtsa: sarrerako eta irteerako datu-fluxuek ez dute gurutzatu behar. Hau da, ezin duzu eskaerarik bidali eta erantzun bat espero; horren ordez, eskaera bat bidaliko duzu A zerbitzura, baina B zerbitzutik erantzuna jasotzen duzu.

Ikuspegi honen lehen bonusa eskaera luze bat exekutatzen den bitartean konexioa (hitzaren zentzu zabalean) hausteko gaitasuna da. Adibidez, har dezagun sekuentzia gutxi-asko estandarra:

1. Bezeroak eskaera bat bidali zion zerbitzariari.
2. Zerbitzariak prozesatzeko denbora luzea hasi zuen.
3. Zerbitzariak emaitzarekin erantzun zion bezeroari.

Pentsa dezagun 2. puntuan konexioa eten zela (edo sarea berriro konektatu zela, edo erabiltzailea beste orri batera joan zela, konexioa eten). Kasu honetan, zaila izango da zerbitzariak erabiltzaileari erantzun bat bidaltzea zehazki prozesatu denari buruzko informazioarekin. CQRS erabiliz, sekuentzia zertxobait desberdina izango da:

1. Bezeroak eguneratzeetara harpidetu da.
2. Bezeroak eskaera bat bidali zion zerbitzariari.
3. Zerbitzariak "eskaera onartuta" erantzun zuen.
4. Zerbitzariak emaitzarekin erantzun zuen "1" puntuko kanalaren bidez.

Ikus dezakezunez, eskema apur bat konplexuagoa da. Gainera, eskaera-erantzun ikuspegi intuitiboa falta da hemen. Hala ere, ikus dezakezun bezala, eskaera bat prozesatzen ari den bitartean konexio eten batek ez du errorerik ekarriko. Gainera, erabiltzailea hainbat gailutatik (adibidez, telefono mugikor batetik eta tablet batetik) konektatuta badago zerbitzura, erantzuna bi gailuetara datorrela ziurtatu dezakezu.

Interesgarria da, sarrerako mezuak prozesatzeko kodea berdina bihurtzen da (ez % 100ean) bai bezeroak berak eragina izan duten ekitaldietarako, bai beste ekitaldi batzuetarako, beste bezero batzuenak barne.

Hala ere, errealitatean hobari gehigarri bat lortzen dugu, norabide bakarreko fluxua estilo funtzional batean kudeatu daitekeelako (RX eta antzekoak erabiliz). Eta hori jada abantaila larria da, funtsean aplikazioa guztiz erreaktiboa egin daitekeelako eta ikuspegi funtzional bat erabiliz. Gantz programetarako, horrek garapen eta laguntza baliabideak nabarmen aurreztu ditzake.

Ikuspegi hau eskalatze horizontalarekin konbinatzen badugu, hobari gisa zerbitzari bati eskaerak bidaltzeko eta beste baten erantzunak jasotzeko gaitasuna izango dugu. Horrela, bezeroak komeni zaion zerbitzua aukeratu dezake eta barruan dagoen sistemak gertaerak behar bezala prozesatu ahal izango ditu oraindik.

Ekitaldien horniketa

Dakizuenez, sistema banatu baten ezaugarri nagusietako bat denbora arruntik ez izatea da, atal kritiko komun bat. Prozesu baterako, sinkronizazio bat egin dezakezu (mutex berdinetan), eta horren barruan ziur zaude beste inork ez duela kode hau exekutatzen. Hala ere, hori arriskutsua da sistema banatu batentzat, gainkostuak beharko baititu, eta eskalatzearen edertasun guztia ere hilko duelako; osagai guztiak oraindik baten zain egongo dira.

Hemendik datu garrantzitsu bat lortzen dugu: banatutako sistema azkar bat ezin da sinkronizatu, orduan errendimendua murriztuko dugulako. Bestalde, askotan osagaien arteko koherentzia jakin bat behar dugu. Eta horretarako planteamendua erabil dezakezu behin betiko koherentzia, non bermatzen den datu-aldaketarik ez badago azken eguneraketaren ondoren («azkenean») denbora tarte batean, kontsulta guztiek azken eguneratutako balioa itzuliko dutela.

Garrantzitsua da ulertzea datu-base klasikoetarako nahiko maiz erabiltzen dela koherentzia sendoa, non nodo bakoitzak informazio bera duen (askotan lortzen da transakzioa bigarren zerbitzariak erantzun ondoren bakarrik ezarrita jotzen den kasuan). Hemen erlaxazio batzuk daude isolamendu mailak direla eta, baina ideia orokorrak berdin jarraitzen du: mundu guztiz harmonizatu batean bizi zaitezke.

Hala ere, itzul gaitezen jatorrizko zereginera. Sistemaren zati bat eraiki badaiteke behin betiko koherentzia, orduan hurrengo diagrama eraiki dezakegu.

Ikuspegi honen ezaugarri garrantzitsuak:

• Jasotako eskaera bakoitza ilara batean jartzen da.
• Eskaera bat prozesatzen ari den bitartean, zerbitzuak beste ilara batzuetan ere jar ditzake zereginak.
• Sarrerako gertaera bakoitzak identifikatzaile bat du (beharrezkoa dena desbikoizketa egiteko).
• Ilarak ideologikoki funtzionatzen du "atxikitzeko soilik" eskemaren arabera. Ezin dituzu elementuak kendu edo berrantolatu.
• Ilarak FIFO eskemaren arabera funtzionatzen du (barkatu tautologiagatik). Exekuzio paraleloa egin behar baduzu, momentu batean objektuak ilara ezberdinetara eraman beharko dituzu.

Gogorarazten dizut lineako fitxategiak biltegiratzeko kasua aztertzen ari garela. Kasu honetan, sistema honen itxura izango da:

Garrantzitsua da diagramako zerbitzuek zerbitzari bereizi bat ez izatea nahitaez. Nahiz eta prozesua berdina izan daiteke. Garrantzitsua da beste gauza bat: ideologikoki, gauza hauek bereizten dira eskala horizontala erraz aplikatzeko moduan.

Eta bi erabiltzailerentzat diagrama honen itxura izango da (erabiltzaile ezberdinentzako zuzendutako zerbitzuak kolore ezberdinez adierazten dira):

Halako konbinaziotik hobariak:

• Informazioa tratatzeko zerbitzuak bereizten dira. Ilarak ere bereizten dira. Sistemaren errendimendua handitu behar badugu, zerbitzari gehiagotan zerbitzu gehiago abiarazi beharko ditugu.
• Erabiltzaile baten informazioa jasotzen dugunean, ez dugu datuak guztiz gorde arte itxaron beharrik. Aitzitik, “ondo” erantzun behar dugu eta gero pixkanaka lanean hasi. Aldi berean, ilarak gailurrak leuntzen ditu, objektu berri bat gehitzea azkar gertatzen baita, eta erabiltzaileak ez du ziklo osoan zehar igarotzeko itxaron beharrik.
• Adibide gisa, fitxategi berdinak bateratzen saiatzen den desduplicazio zerbitzu bat gehitu dut. Kasuen %1ean denbora luzez funtzionatzen badu, bezeroak ez du ia nabarituko (ikus goian), eta hori abantaila handia da, jada ez baitugu %XNUMXeko abiadura eta fidagarritasuna izatea eskatzen.

Hala ere, desabantailak berehala ikusten dira:

• Gure sistemak koherentzia zorrotza galdu du. Horrek esan nahi du, adibidez, zerbitzu ezberdinetara harpidetzen bazara, teorikoki beste egoera bat lor dezakezula (zerbitzuetako batek baliteke barneko ilararen jakinarazpen bat jasotzeko denborarik ez izatea). Beste ondorio gisa, orain sistemak ez du denbora arruntik. Hau da, ezinezkoa da, adibidez, gertaera guztiak iristeko orduaren arabera ordenatzea, zerbitzarien arteko erlojuak agian ez direla sinkronoak (gainera, bi zerbitzarietako ordu bera utopia da).
• Orain ezin da gertaerarik atzera egin (datu-base batekin egin litekeen bezala). Horren ordez, gertaera berri bat gehitu behar duzu − konpentsazio-gertaera, azken egoera behar den egoerara aldatuko duena. Antzeko eremu bateko adibide gisa: historia berridatzi gabe (kasu batzuetan txarra da), ezin duzu git-en konpromezu bat atzera egin, baina berezi bat egin dezakezu. atzera botatzeko konpromisoa, funtsean, egoera zaharra itzultzen duena. Hala ere, bai konpromezu okerra eta baita atzera egitea ere historian geratuko dira.
• Baliteke datu-eskema bertsio batetik bestera aldatzea, baina gertaera zaharrak ezin izango dira estandar berrira eguneratu (gertaerak ezin baitira aldatu printzipioz).

Ikus dezakezunez, Event Sourcing-ek ondo funtzionatzen du CQRS-ekin. Gainera, ilara eraginkor eta erosoak dituen sistema bat ezartzea, baina datu-fluxuak bereizi gabe, dagoeneko zaila da berez, ilararen efektu positibo osoa neutralizatuko duten sinkronizazio puntuak gehitu beharko dituzulako. Bi ikuspegiak aldi berean aplikatuz, beharrezkoa da programaren kodea apur bat doitzea. Gure kasuan, fitxategi bat zerbitzarira bidaltzean, erantzuna "ongi" dator, hau da, "fitxategia gehitzeko eragiketa gorde egin zela" esan nahi du. Formalki, horrek ez du esan nahi datuak beste gailu batzuetan eskuragarri daudenik (adibidez, desduplicazio zerbitzuak indizea berreraiki dezakeenik). Hala ere, denbora pixka bat igaro ondoren, bezeroak jakinarazpen bat jasoko du "X fitxategia gorde da" estiloan.

Hori dela eta:

• Fitxategiak bidaltzeko egoera kopurua gero eta handiagoa da: "fitxategia bidali" klasikoaren ordez, bi lortzen ditugu: "fitxategia zerbitzariko ilaran gehitu da" eta "fitxategia biltegian gorde da". Azken honek esan nahi du beste gailu batzuk jada fitxategia jasotzen has daitezkeela (ilarak abiadura ezberdinetan funtzionatzen dutelako egokituta).
• Bidalketa informazioa orain bide ezberdinetatik datorrelako, fitxategiaren prozesamendu egoera jasotzeko irtenbideak asmatu behar ditugu. Horren ondorioz: eskaera-erantzun klasikoa ez bezala, fitxategia prozesatzen ari den bitartean bezeroa berrabiarazi daiteke, baina prozesamendu honen egoera bera zuzena izango da. Gainera, elementu honek, funtsean, kutxatik kanpo funtzionatzen du. Ondorioz: orain porrotekiko toleranteagoak gara.

Zatitzea

Goian azaldu bezala, gertaeren hornikuntza-sistemek ez dute koherentzia zorrotza. Horrek esan nahi du hainbat biltegiratze erabil ditzakegula haien arteko sinkronizaziorik gabe. Gure arazoari helduz, honako hau egin dezakegu:

• Bereizi fitxategiak motaren arabera. Adibidez, irudiak/bideoak deskodetu eta formatu eraginkorragoa hauta daiteke.
• Banatu kontuak herrialdeka. Lege asko direla eta, hori beharrezkoa izan daiteke, baina arkitektura-eskema honek aukera hori automatikoki ematen du

Datuak biltegiratze batetik bestera transferitu nahi badituzu, baliabide estandarrak ez dira nahikoak. Zoritxarrez, kasu honetan, ilara gelditu, migrazioa egin eta gero hasi behar duzu. Kasu orokorrean, datuak ezin dira "bere momentuan" transferitu, hala ere, gertaeren ilara guztiz gordetzen bada eta aurreko biltegiratze-egoeren argazkiak badituzu, gertaerak honela errepikatu ditzakegu:

• Gertaeren iturburuan, gertaera bakoitzak bere identifikatzailea du (egokiena, ez da gutxitzen). Horrek esan nahi du eremu bat gehi dezakegula biltegian - prozesatutako azken elementuaren id-a.
• Ilara bikoizten dugu, gertaera guztiak hainbat biltegiratze independentetarako prozesatu ahal izateko (lehena datuak dagoeneko gordeta daudena da, eta bigarrena berria, baina oraindik hutsik). Bigarren ilara, noski, oraindik ez da prozesatzen ari.
• Bigarren ilara abiarazten dugu (hau da, gertaerak errepikatzen hasten gara).
• Ilara berria nahiko hutsik dagoenean (hau da, elementu bat gehitzearen eta hura berreskuratzearen arteko batez besteko denbora-aldea onargarria da), irakurleak biltegiratze berrira aldatzen has zaitezke.

Ikusten duzuenez, ez genuen koherentzia zorrotzik gure sisteman, eta oraindik ez dugu. Behin-behineko koherentzia besterik ez dago, hau da, gertaerak ordena berean (baina agian atzerapen ezberdinekin) prozesatzeko bermea. Eta, hau erabiliz, datuak nahiko erraz transferi ditzakegu sistema munduaren beste aldera gelditu gabe.

Horrela, fitxategien lineako biltegiratzeari buruzko gure adibidearekin jarraituz, horrelako arkitektura batek hobari batzuk ematen dizkigu dagoeneko:

• Erabiltzaileengana hurbildu ditzakegu objektuak modu dinamikoan. Horrela zerbitzuaren kalitatea hobetu dezakezu.
• Baliteke datu batzuk enpresetan gordetzea. Adibidez, Enterprise erabiltzaileek maiz eskatzen dute euren datuak kontrolatutako datu-zentroetan gordetzea (datuen ihesak ekiditeko). Zatiketaren bidez erraz onartzen dugu hau. Eta zeregina are errazagoa da bezeroak hodei bateragarri bat badu (adibidez, Azure auto-ostatatua).
• Eta garrantzitsuena da ez dugula hau egin behar. Azken finean, hasteko, nahiko pozik egongo ginateke biltegiratze bakarra kontu guztietarako (bizkor lanean hasteko). Eta sistema honen funtsezko ezaugarria da hedagarria den arren, hasierako fasean nahiko erraza dela. Ez duzu berehala idatzi beharrik milioi bat ilara independenterekin funtzionatzen duen kodea, etab. Beharrezkoa bada, etorkizunean egin daiteke.

Eduki estatikoen ostalaritza

Puntu hau nahiko begi-bistakoa dirudi, baina oraindik beharrezkoa da kargatutako aplikazio estandar gutxi gorabehera. Bere funtsa sinplea da: eduki estatiko guztia ez da aplikazioa dagoen zerbitzari beretik banatzen, zeregin horretara bereziki dedikatzen diren berezietatik baizik. Ondorioz, eragiketa hauek azkarrago egiten dira (nginx baldintzatuak fitxategiak Java zerbitzari batek baino azkarrago eta merkeago zerbitzatzen ditu). Gainera CDN arkitektura (Content Delivery Network) gure fitxategiak azken erabiltzaileengandik hurbilago kokatzeko aukera ematen digu, eta horrek eragin positiboa du zerbitzuarekin lan egiteko erosotasunean.

Eduki estatikoen adibiderik errazena eta estandarrena webgune baterako script eta irudi multzo bat da. Horiekin dena erraza da: aldez aurretik ezagutzen dira, gero artxiboa CDN zerbitzarietara igotzen da, eta handik azken erabiltzaileei banatzen zaie.

Hala ere, errealitatean, eduki estatikorako, lambda arkitekturaren antzeko ikuspegia erabil dezakezu. Itzuli gaitezen gure zereginera (fitxategiak linean biltegiratzea), bertan fitxategiak erabiltzaileei banatu behar dizkiegu. Irtenbiderik errazena, erabiltzaileen eskaera bakoitzerako beharrezko egiaztapen guztiak (baimenak, etab.) egiten dituen zerbitzu bat sortzea da, eta ondoren fitxategia gure biltegitik zuzenean deskargatzen duena. Ikuspegi honen desabantaila nagusia da eduki estatikoa (eta berrikuspen jakin bat duen fitxategi bat, hain zuzen ere, eduki estatikoa) negozio-logika duen zerbitzari berberak banatzen duela. Horren ordez, diagrama hau egin dezakezu:

• Zerbitzariak deskarga URL bat eskaintzen du. Fitxategi_id + gakoa modukoa izan daiteke, non gakoa hurrengo XNUMX orduetan baliabidera sartzeko eskubidea ematen duen sinadura digital txiki bat den.
• Fitxategia nginx sinpleak banatzen du aukera hauekin:
  • Edukien cachean gordetzea. Zerbitzu hau zerbitzari bereizi batean kokatu daitekeenez, etorkizunerako erreserba utzi dugu deskargatutako azken fitxategi guztiak diskoan gordetzeko aukerarekin.
  • Gakoa egiaztatzea konexioa sortzeko unean
• Aukerakoa: streaming edukien prozesatzea. Adibidez, zerbitzuko fitxategi guztiak konprimitzen baditugu, modulu honetan zuzenean deskonprimitu ahal izango dugu. Ondorioz: IO eragiketak dagokien lekuan egiten dira. Java-ko artxibo batek memoria gehigarri asko esleituko du erraz, baina negozio-logika duen zerbitzu bat Rust/C++ baldintzapean berridaztea ere ez da eraginkorra izan. Gure kasuan, prozesu desberdinak (edo baita zerbitzuak ere) erabiltzen dira, eta, beraz, nahiko modu eraginkorrean bereiz ditzakegu negozio logika eta IO eragiketak.

Eskema hau ez da eduki estatikoa banatzearen oso antzekoa (ez baitugu pakete estatiko osoa nonbait kargatzen), baina, egia esan, ikuspegi hau datu aldaezinak banatzeari dagokio hain zuzen. Gainera, eskema hau edukia estatiko hutsa ez den beste kasu batzuetara orokortu daiteke, baizik eta aldaezin eta ezaba ezin diren blokeen multzo gisa irudika daiteke (nahiz eta gehitu daitezkeen).

Beste adibide gisa (indartzeko): Jenkins/TeamCity-rekin lan egin baduzu, badakizu bi soluzioak Javan idatzita daudela. Biak ala biak eraikitzeko orkestrazioa eta edukien kudeaketa kudeatzen dituen Java prozesu bat dira. Bereziki, biek dute "fitxategi/karpeta bat zerbitzaritik transferitu" bezalako zereginak. Adibide gisa: artefaktuak igortzea, iturburu-kodea transferitzea (agenteak kodea zuzenean biltegitik deskargatzen ez duenean, baina zerbitzariak berak egiten du), erregistroetarako sarbidea. Zeregin hauek guztiak IO kargan desberdinak dira. Hau da, negozio-logika konplexuaz arduratzen den zerbitzariak aldi berean gai izan behar duela datu-fluxu handiak bere baitan eraginkortasunez bultzatzeko. Eta interesgarriena da eragiketa hori nginx berari delega daitekeela eskema beraren arabera (eskaerari datu-gakoa gehitu behar zaiola izan ezik).

Hala ere, gure sistemara itzultzen bagara, antzeko diagrama bat lortuko dugu:

Ikus dezakezunez, sistema erabat konplexuagoa bihurtu da. Orain ez da fitxategiak lokalean gordetzen dituen prozesu txiki bat. Orain behar dena ez da laguntza sinpleena, API bertsioen kontrola, etab. Horregatik, diagrama guztiak marraztu ondoren, hobe da zehatz-mehatz ebaluatzea hedagarritasunak kostua merezi duen ala ez. Hala ere, sistema zabaldu ahal izan nahi baduzu (are erabiltzaile kopuru handiagoarekin lan egiteko barne), orduan antzeko irtenbideak bilatu beharko dituzu. Baina, ondorioz, sistema arkitektonikoki prest dago karga handitzeko (ia osagai guztiak klonatu daitezke eskalatze horizontalerako). Sistema gelditu gabe eguneratu daiteke (eragiketa batzuk apur bat motelduko dira besterik gabe).

Hasieran esan dudan bezala, orain Interneteko zerbitzu batzuk karga areagotzen hasi dira. Eta horietako batzuk, besterik gabe, behar bezala funtzionatzeari uzteari ekin zioten. Izan ere, sistemak huts egin zuten negozioak dirua irabazi behar zuen unean hain zuzen. Hau da, bidalketa geroratu beharrean, bezeroei "planifikatu zure entrega datozen hilabeteetarako" iradoki beharrean, sistemak "joan zure lehiakideengana" besterik ez du esan. Izan ere, hauxe da produktibitate baxuaren prezioa: galerak irabaziak handienak izango zirenean gertatuko dira hain zuzen.

Ondorioa

Planteamendu horiek guztiak aurretik ezagutzen ziren. VK bera aspalditik erabiltzen da eduki estatikoen ostalaritzaren ideia irudiak bistaratzeko. Lineako joko askok Sharding eskema erabiltzen dute jokalariak eskualdetan banatzeko edo jokoen kokapenak bereizteko (mundua bera bada). Ekitaldien hornikuntzaren ikuspegia modu aktiboan erabiltzen da posta elektronikoan. Datuak etengabe jasotzen diren merkataritza-aplikazio gehienak CQRS ikuspegi batean eraikita daude jasotako datuak iragazi ahal izateko. Bada, eskala horizontala zerbitzu askotan erabili izan da denbora luzez.

Hala ere, garrantzitsuena, eredu horiek guztiak aplikazio modernoetan aplikatzeko oso erraz bihurtu dira (egokiak badira, noski). Hodeiek zatiketa eta eskalatze horizontala eskaintzen dituzte berehala, eta hori askoz errazagoa da datu-zentro desberdinetan zerbitzari dedikatu desberdinak eskatzea baino. CQRS askoz errazagoa bihurtu da, RX bezalako liburutegien garapena dela eta. Duela 10 urte inguru, webgune arraro batek hau onar lezake. Gertaeren sorkuntza ere oso erraza da konfiguratzen Apache Kafkarekin prest egindako edukiontziei esker. Duela 10 urte hau berrikuntza bat izango zen, orain ohikoa da. Berdin gertatzen da Eduki Estatikoen Hosting-arekin: teknologia erosoagoak direla eta (dokumentazio zehatza eta erantzunen datu-base handia dagoela barne), ikuspegi hau are sinpleagoa bihurtu da.

Ondorioz, arkitektura-eredu konplexu samarrak ezartzea askoz errazagoa bihurtu da, eta horrek esan nahi du hobe dela aldez aurretik hurbilagotik begiratzea. Hamar urteko aplikazio batean goiko soluzioetako bat inplementazioaren eta funtzionamenduaren kostu handia dela-eta alde batera utzi bazen, orain, aplikazio berri batean, edo birfactorizatu ondoren, dagoeneko arkitektonikoki hedagarria izango den zerbitzu bat sor dezakezu ( errendimenduari dagokionez) eta bezeroen eskaera berriei aurre egiteko prest (adibidez, datu pertsonalak lokalizatzeko).

Eta garrantzitsuena: mesedez, ez erabili ikuspegi hauek aplikazio sinple bat baduzu. Bai, ederrak eta interesgarriak dira, baina 100 pertsonako bisitaldi gorena duen gune baterako, askotan monolito klasiko batekin atera zaitezke (kanpotik behintzat, barruan dagoen guztia modulutan banatu daiteke, etab.).

Iturria: www.habr.com