Heus Habr!

In luce rerum eventus ob coronavirus, plura officia interretialem augeri onere accipere coepta sunt. Exempli gratia Una in UK vincula scrutans simpliciter interclusit locum suum online ordinans.quod satis non erat capacitatis. Et non semper fieri potest ut servo accelerare solum addito potentiori instrumento, sed petitiones client discursum esse (vel ad competitores ibunt).

In hoc articulo de popularibus exercitiis breviter dicam, quae jejunium et culpam patientem obsequium creare te sinet. Tamen ex technis evolutionis possibilibus eas tantum delegi quae nunc sunt securus utor. Pro singulis item, vel bibliothecas paratas habes, vel occasionem solvendi problema utens nubem suggestam habes.

Horizontalis scaling

Simplicissimum et notissimum punctum. Conventione, communissima duo pondera distributionis technae sunt scandendi horizontalis et verticalis. In primo casu, officia in parallela permittitis currere, onus inter ea distribuere. secundus iubes potentiores servientibus vel optimize codicem.

Exempli gratia, nubem abstractam limam repositionis ducam, id est, analoga quaedam OwnCloud, OneDrive, et sic porro.

Imago talis circuli vexillum inferius est, sed solum multiplicitatem systematis demonstrat. Ceterum opus est aliquo modo officia synchronize. Quid accidit si usor limam e tabula servat et deinde eam e telephonum inspicere vult?

Discrimen inter accessus: in scalis verticalibus, potestatem nodis augere parati sumus, et in scalis horizontalibus parati sumus novos nodos addere ad onus distribuendum.

CQRS

Mandatum Query Cura Segregationis Magis momenti exemplum, cum clientes diversos permittit non solum ad diversa officia coniungere, sed etiam ad eundem eventum rivos recipere. Eius beneficia non tam perspicua sunt pro simplici applicatione, sed magni momenti (et simplex) ob officium negotiosum. Essentia eius: notitia advenientis et exitu fluit non secet. Hoc est, non potes petitionem mittere et responsionem exspectare, sed petitionem ad ministerium A mittes, responsionem ab officio B accipias.

Primum bonum accessionis huius est facultas frangendi nexum (lato sensu verbi) dum longam petitionem exsequens. Exempli gratia: vexillum plus minusve sumamus;

1. Cliens petentibus servo misit.
2. Distributorium longum processui tempus incepit.
3. Servus respondit clienti cum effectu.

Fingamus in puncto 2 nexum fractum esse (vel retiaculum connexum, vel usor ad aliam paginam ivit, nexum solvens). In hoc casu difficile erit servo responsionem usori mittere cum informatione de quidnam expediatur. Utens CQRS, sequentia inmutata erit;

1. Cliens subscripsit updates.
2. Cliens petentibus servo misit.
3. Servo respondit "precationem accepit."
4. Servo per canalem a puncto respondit "1".

Ut vides, schema est paulo implicatius. Deest praeterea accessus responsionis intuitivae postulationis. Nihilominus, ut vides, nexus intermissus dispensando petitio errorem non inducit. Praeterea si ex pluribus machinis (exempli gratia, e telephono mobili et ex tabula) utens ad servitium coniungitur, efficere potes ut ad utramque responsionem veniat.

Interestingly, signum processus nuntii advenientis idem fit (non 100%) tum pro eventibus quae ab ipso cliente movebantur, tum pro aliis eventibus, etiam ab aliis clientibus.

Attamen re vera accessus additur bonus ex eo quod fluxus unidirectionalis tractari potest in stilo utilitatis (RX similibusque adhibitis). Et hoc iam plus est grave, quia applicatio essentialiter omnino reactiva fieri potest, ac etiam accessione utilitatis utens. Pro programmatibus pinguibus, hoc signanter potest evolutionem servare et facultates sustentare.

Si hunc accessum cum scalis horizontalibus coniungimus, tunc ut bonus facultas petitiones mittendi uni servo et responsa ab alio accipimus. Ita client eligere potest obsequium quod sibi commodum est, et ratio intus adhuc recte procedere poterit.

Event Sorting

Ut nostis, una ratio principalis notae distributae est absentia temporis communis, sectione critica communis. Pro uno processu, synchronisationem (in eisdem muticis) facere potes, intra quod scias neminem alium hunc codicem exsequi. Sed hoc periculosum est distributa ratio, cum supra caput requiret, et etiam omnes scalas pulchritudines occidet - omnia membra adhuc unum exspectant.

Hinc res magni momenti habetur - ratio distributa ieiunium congruere non potest, quia tunc perficientur reducemus. Contra, saepe quadam compositione inter partes indigemus. Et ad hoc uti potes accessu constantiae eventualubi cavetur, si datae mutationes non sint per aliquod temporis spatium post ultimam renovationem (“tandem”), omnes interrogationes renovatum valorem reversurum esse.

Refert intellegere quod in databases classicis satis saepe usus est fortis constantia, ubi uterque nodi easdem habet informationes (quod saepe obtinetur in casu quo res gesta censetur tantum postquam secundo servo respondet). Sunt hic aliquae relaxationes propter gradus segregationis, sed idea communis manet eadem - in mundo perfecto concordato vivere potes.

Sed ad negotium originale revertamur. Si pars systematis aedificari potest constantiae eventualergo sequens schema construere possumus.

Magni momenti lineamenta huius aditus:

• Quaelibet petitio advenientis ponitur in una queue.
• In petitione dispensando, officium etiam officia in aliis queues ponere potest.
• Uniuscuiusque eventus advenientis identificantem habet (quod ad deduplicationem necessarium est).
• Queue ideologice operatur secundum schema "tantum appendendi". Elementa ab ea removere non potes nec eas ordinare.
• Queue operatur secundum schema FIFO (paenitet de tautologia). Si parallela exsecutio facere debes, in uno statu moveas objecta ad diversa queues.

Fac me admonere te de repositionis fasciculi online considerare. In hoc casu ratio huius modi aliquid spectabit;

Magni interest ut officia in schemate servi separatum non necessario significent. Etiam ut ipsum est. Alia res magni momenti est: ideologia, haec ita separantur ut scala horizontalis facile applicari possit.

Et pro duobus utentibus schemate hoc simile erit (officia diversis utentibus destinata diversis coloribus indicantur);

Bonuses ex tali compositione;

• Informationes processus officia separata sunt. Queues etiam separantur. Si opus est ut ratio perput augeatur, iustus opus est plura officia in servientibus mittere.
• Cum informationes ex utente accipimus, non exspectandum est donec notitia perfecte servata sit. E contra, oportet respondere "ok" et paulatim incipit operari. Eodem tempore, queue cacumina exaequat, quia addito novo obiecto cito fit, et utens per totum currendi transitum non expectat.
• Exempli causa, servitium deduplicationem adiunxi quae identificas tabulas iungi conatur. Si diu in 1% casuum agit, cliens illud (vide supra), quod magnum plus est, vix observabit, cum non amplius requirimus ut XNUMX velocitas et certa sint.

Sed incommoda statim apparent;

• Nostra ratio constantiam suam severam amisit. Id est, si, exempli gratia, diversis officiis subscribas, tum speculatione alium statum habere potes (cum una officia tempus non habeat notitiam ab interna queue recipiendi). Alia consequentia ratio nunc temporis nullum habet tempus. Id est, impossibile est, exempli gratia, omnia eventa simpliciter tempore adventus disponere, cum horologia inter ministrantes synchrona esse non possit (praeterea idem tempus duobus ministris utopia est).
• Nullae eventus nunc simpliciter revolvi possunt (sicut fieri potuit cum database). Potius, novum eventum addere debes ultricies resquae ultimam ad debitam rem mutabit. Exemplum ex simili area: sine historia (quod malum est in quibusdam casibus) revolvere non potes in git, sed singularem facere potes. reverti committerequae per se tantum redit ad veterem statum. Sed tam erroneum perpetrare, et reverti in historia remanebit.
• Schema data a solutione mutare potest, at eventus vetus non amplius renovari ad novum vexillum (quia eventus in principio mutari non potest).

Ut videre potes, Eventus Sourcing bene operatur cum CQRS. Praeterea ratio exsequens cum queues efficiente et convenienti, sed sine notitia separato fluit, iam per se difficile est, quia addere debebis synchronisationi puncta quae totum effectum positivum queues corrumpunt. Utraque statim applicando, necesse est ut codicem programmatis leviter accommodes. In casu nostro, cum limam ad servo mittens, responsio "ok" tantum venit, quod solum significat "operationem tabellae addendi servatam esse". Formaliter, hoc non significat notitias in aliis machinis iam paratas esse (exempli gratia, deductio muneris indicem reficere potest). Tamen, post aliquod tempus, cliens notificationem accipiet in stilo "file X servatus est."

Igitur:

• Numerus tabellae mittens statuses augetur: loco classic "file missi" duo accipimus: "tabella addita queue in calculonis" et "tabella in reposita servata est". Hoc significat quod alia machinis accepta tabella iam incipere possunt (accommodatum est ad hoc quod queues diversis velocitatibus agunt).
• Ob quod informationes submissionis nunc per varias vias venit, necesse est cum solutionibus ascendere ut tabellae statum processus recipiat. Consequenter hoc: dissimilis responsionis petitionis classicae, cliens tabellam in dispensando reprimi potest, sed status ipsius processus ipsius rectus erit. Hoc autem opus essentialiter e archa. Accidit ut nunc peccata tolerabiliores sumus.

sharding

Ut supra dictum est, eventus transmissionis systemata stricte constantia caret. Hoc pacto varias schedulas uti possumus sine ulla synchronisatione inter eos. Ad quaestionem nostram accedere possumus:

• Separate lima per genus. Exempli causa, imagines/videos decoqui possunt et forma efficacior sumi potest.
• Rationes separatae a patria. Ob multas leges, hoc requiri potest, sed haec ratio architecturae talem facultatem automatice praebet

Si notitias ex una tabula in aliam transferre voles, tunc media vexillum iam satis non sunt. In hoc casu, debes prohibere queue, facere migrationem, et tunc committitur. In universali casu, notitia "in musca" transferri non potest, tamen, si res queue penitus recondita est, et snapshots statuum tabularum praecedentium habes, tunc eventa sic referre possumus:

• In eventu, unusquisque eventus suum identificativum habet (speciem, non decrescentem). Hoc modo campum repositioni addere possumus - id postremi elementi processus.
• Queue duplicamus ita ut omnes res per plures tabulas independentes discursum possint (primum est illud in quo notitia iam recondita est, et secunda nova, sed adhuc vacua est). Secunda queue, scilicet, nondum processit.
• Secundam queue deprimimus (id est, eventus rependere incipimus).
• Cum nova queue relative vacua est (hoc est, mediocris temporis differentia inter additamentum elementi et acceptabile recuperandum), inire potes lectores commutatione ad novum tabularium.

Ut vides, non habuimus, nec adhuc non habemus constantiam in nostra ratione. Sola est constantia eventualis, id est, cautio quod eventa eodem ordine procedunt (sed fortasse diversis dilationibus). Et hoc utentes, notitias faciliter transferre possumus sine intermissione systematis in alteram partem globi.

Ita, exemplum nostrum de repositione tabulariorum online continuando, talis architectura iam plures bonoses nobis tribuit:

• Obiecta propius ad usores movere modo dynamico possumus. Hoc modo operae pretium facere potes.
• Data in societates aliquas reponere possumus. Exempli gratia, Incepti utentes saepe data sua requirunt ut in regentia data centra reponantur (ad vitandum notitiarum perstillabit). Per hanc communicationem facile possumus sustinere. Et negotium etiam facilius est si nubes compatibilis emptorem habet (exempli gratia: Caeruleus sui hosted).
• Et maximum est quod hoc facere non debemus. Post omnes, imprimis, satis felices essemus una tabula pro omnibus rationibus (ut cito incipias operari). Atque haec ratio praecipua est, quod quamvis expansibile sit, initio plane simplex est. Modo non debes statim codicem scribere, qui cum decies centena millia separatorum queues independentium operatur, etc. Si opus est, in futurum fieri potest.

Static Content Hosting

Hoc punctum satis evidens videri potest, sed adhuc necessarium est ad applicationem vexillum plus minusve oneratum. Simplex essentia eius est: omne statice contentus non ab eodem servo ubi applicatio collocatur distribuitur, sed a specialibus ad hoc munus specialiter dicatis. Quam ob rem, hae operationes citius peraguntur (nginx conditionalis imagini magis ac minus sumptuose servit quam Java servo). Plus CDN architectura (Content Delivery Network) tabellas nostras propius ad finem usorum collocare permittit, qui effectum positivum habet in commodo operandi cum ministerio.

Simplicissimum ac vexillum exemplum contenti statice scriptorum et imaginum statuta est pro website. Omnia cum illis simplicia sunt - praecognita sunt, tunc archivum ad CDN servientibus impositum est, unde ad finem utentium distribuuntur.

Sed re vera, ad static contentus, accessione aliquantum simili ad architecturae lambda uti potes. Redeamus ad nostrum munus (reposita tabularia online), in quibus opus est tabellas utentibus distribuere. Simplicissima solutio est servitium creare quod, pro unoquoque usore petitionem, omnia necessaria compescit (auctorationis, etc.), et tunc tabellam directe ex tabulario nostro inmittit. Praecipuum huius accessionis incommodum est, quod static contentum (et fasciculus cum quadam recognitione, immo static contentus) ab eodem servo distribuitur in quo negotium logice continet. Potius, sequenti schemate facere potes:

• Servo download URL praebet. Formae file_id + clavis esse potest, ubi clavis est subscriptio mini-digitalis quae dat ius subsidii accessuri proximis 24 horis.
• Scapus simplicium nginx distribuitur cum sequentibus optionibus;
  • Contentus caching. Cum hoc officium in servo separato collocari possit, nobis subsidia in futurum reliquimus cum facultate ut omnes tabulas recentissimas in orbe receptaculas reponendi.
  • Reperiens clavem in tempore iunctio creatio
• Libitum: stream content processui. Exempli gratia, si omnes fasciculi in officio comprimimus, in hoc modulo directe inexhaustus facere possumus. Unde: IO operationes fiunt ubi sunt. Archivum in Java facile multum extra memoriam collocabit, sed munus rescribens logicae negotii in Rust/C ++ conditionale etiam inefficax esse. In casu nostro, variae processus (vel etiam officia) adhibentur, et propterea negotium logicum et IO operationes satis efficaciter separare possumus.

Hoc schema non multum simile est ad contentum staticum distribuendum (quia non totam sarcinam staticam alicubi iniungimus), sed re vera accessus hic praecise versatur circa notitias immutabiles distribuendas. Hoc autem schema generaliter aliis casibus potest in quibus materia non est simpliciter stabilis, sed repraesentari potest ut praefinitus impedimentorum immutabilium et non-delebilium (etsi addi possunt).

Ut alterum exemplum (ad supplementum): si cum Jenkins/TeamCity functus es, scias utramque solutionem in Java scripta esse. Ambae processus Javae sunt qui tractat et orchestrationem et administrationem contentus. Praesertim operas habent uterque sicut "tabellam/folder a servo transferre". Exempli gratia: artificialia emittentes, fons codicem transferens (cum agens non directe codicem e repositorio mittit, sed ministrans ei facit), accessum ad tigna. Haec omnia IO onere differunt. Hoc est, evenit ut ministri responsalis logicae negotiis implicatis simul magnas fluxiones notitiarum per se efficaciter impellere possint. Et quod maxime interesting est quod talis operatio eidem nginx delegari potest secundum prorsus idem schema (nisi ut clavis notitiae petitioni adiciatur).

Sed si ad rationem nostram revertamur, simile schema accipimus;

Ut videre potes, systema radicaliter magis implicata facta est. Nunc non solum mini-processus est, qui locum imagini reponit. Nunc quod opus est non est simplicissimum subsidium, api litera potestate, etc. Itaque, omnibus schematis extractis, optimum est singillatim perpendere utrum extensio quanti pretii sit. Attamen si vis systematis augere (incluso labore maiore numero usorum), tunc habebis solutiones similes ire. Sed, consequenter, systema architecturae ad onus augendum parata est (omne fere componentes ad scalam horizontalem ligari possunt). Systema renovari potest sine mora (solum operationes aliquae leviter retardari).

Ut in primordio dixi, nunc plures interretiales officia augeri oneris accipere inceperunt. Et quidam ex eis simpliciter bene operari coeperunt. Re quidem vera, eo ipso tempore defecerunt quo negotia pecunia comparare existimabatur. Hoc est, pro differtur partus, pro clientibus "pronuntiationem tuam pro venturis mensibus" ratio simpliciter dixit "ire ad competitores tuos". Reapse hoc pretium est humilitatis fructibus: damna evenient, cum fructus summa esset.

conclusio,

Omnes hi fandi prius erant cogniti. Idem VK iam diu idea Static Content Hosting ad imagines ostentandas usus est. Multus interretinales ludi utuntur ad schema Sharding ad scaenicos in regiones dividendas vel ad loca ludi separanda (si mundus ipse unus est). Eventus Sourcing accessus active usus est in email. Pleraque applicationes negotiantes ubi data constanter recipiuntur, actu aedificata sunt in accessu CQRS ut data accepta eliquare possint. Bene, scansio horizontalis in multis servitiis satis diu adhibita est.

Attamen, praesertim, omnia haec exemplaria facillime facta sunt in applicationibus hodiernis (si sane opportuna sunt). Nubes Sharding et scalam horizontalem ilicet offerunt, quod multo facilius est quam ordinare diversos ministratores in diversis centris teipso datas. CQRS multo facilior facta est, si modo propter evolutionem bibliothecarum ut RX. Circiter ante annos X, pagina rara hoc loco sustinere potuit. Eventus Sourcing etiam incredibilis est gratiarum actionis paratae continentia cum Apache Kafka constituere. Hoc abhinc X annos innovatum fuisset, nunc est commune. Idem est cum Static Content Hosting: ob commodiores technologias (including quod documenta accurata et magna responsabilitas datorum) hic aditus etiam simplicior factus est.

Quam ob rem exsecutio plurium exemplarium architecturae magis implicatorum factae sunt multo simpliciores, quae significat melius esse ut in antecessum propius inspiciamus. Si in applicationem solutionum decem annorum una relicta est propter summam exsecutionem et operationem, nunc in nova applicatione vel post refactorem, ministerium creare potes quod iam architecturae sive extensibile erit (. in terminis faciendis) et paratas ad novas petitiones clientium (exempli gratia, ad personales notitias locales).

Maximeque: his ne accessionibus utere quaeso si simplex applicationis habes. Imo pulchra et iucunda sunt, sed pro situ ad apicem visitationis 100 hominum, saepe cum monolitho classico (saltem extrinsecus, omnia intus in modulos dividi possunt, etc.).

Source: www.habr.com