Hey Habr!

Am Liicht vun den aktuellen Eventer wéinst dem Coronavirus hunn eng Zuel vun Internetservicer ugefaang eng erhéicht Belaaschtung ze kréien. Zum Beispill, Eng vun de UK Retail Ketten huet einfach seng Online Bestellung Site gestoppt., well et net genuch Kapazitéit war. An et ass net ëmmer méiglech e Server ze beschleunegen andeems se einfach méi mächteg Ausrüstung bäidroen, awer Client Ufroe musse veraarbecht ginn (oder se ginn un d'Konkurrenten).

An dësem Artikel wäert ech kuerz iwwer populär Praktiken schwätzen, déi Iech erlaben e séieren a Feeler-tolerante Service ze kreéieren. Wéi och ëmmer, aus de méiglechen Entwécklungsschemaen, hunn ech nëmmen déi ausgewielt déi am Moment sinn einfach ze benotzen. Fir all Element hutt Dir entweder fäerdeg Bibliothéiken, oder Dir hutt d'Méiglechkeet de Problem mat enger Cloud Plattform ze léisen.

Horizontal Skala

Deen einfachsten a bekanntste Punkt. Konventionell sinn déi meescht üblech zwee Lastverdeelungsschemaen horizontal a vertikal Skala. Am éischte Fall Dir erlaabt Servicer parallel ze lafen, doduerch d'Laascht tëscht hinnen ze verdeelen. An der zweeter Dir bestellt méi mächteg Serveren oder optiméiert de Code.

Zum Beispill wäert ech abstrakt Cloud Dateilagerung huelen, dat ass e puer Analog vun OwnCloud, OneDrive, a sou weider.

E Standardbild vun esou engem Circuit ass hei ënnen, awer et weist nëmmen d'Komplexitéit vum System. No allem musse mir d'Servicer iergendwéi synchroniséieren. Wat geschitt wann de Benotzer eng Datei vun der Tablet späichert an se dann vum Telefon wëllt gesinn?

Den Ënnerscheed tëscht den Approchen: an der vertikaler Skaléierung si mir bereet fir d'Kraaft vun de Wirbelen z'erhéijen, an an der horizontaler Skaléierung si mir bereet fir nei Wirbelen ze addéieren fir d'Laascht ze verdeelen.

CQRS

Kommando Query Responsabilitéit Segregatioun E zimlech wichtegt Muster, well et erlaabt verschidde Clienten net nëmme mat verschiddene Servicer ze verbannen, awer och déiselwecht Event Streams ze kréien. Seng Virdeeler sinn net sou offensichtlech fir eng einfach Applikatioun, awer et ass extrem wichteg (an einfach) fir e beschäftegt Service. Seng Essenz: Entréeën an erausginn Datestroum däerfen net intersectéieren. Dat ass, Dir kënnt keng Ufro schécken an eng Äntwert erwaarden; amplaz schéckt Dir eng Ufro un de Service A, awer kritt eng Äntwert vum Service B.

Den éischte Bonus vun dëser Approche ass d'Fäegkeet d'Verbindung ze briechen (am breede Sënn vum Wuert) wärend eng laang Ufro ausféiert. Zum Beispill, loosst eis eng méi oder manner Standard Sequenz huelen:

1. De Client huet eng Ufro un de Server geschéckt.
2. De Server huet eng laang Veraarbechtungszäit ugefaang.
3. De Server huet dem Client mam Resultat geäntwert.

Loosst eis virstellen datt am Punkt 2 d'Verbindung gebrach ass (oder d'Netzwierk nees ugeschloss ass, oder de Benotzer ass op eng aner Säit gaang an d'Verbindung gebrach). An dësem Fall wäert et schwéier sinn fir de Server eng Äntwert un de Benotzer ze schécken mat Informatioun iwwer wat genee veraarbecht gouf. Mat CQRS wäert d'Sequenz liicht anescht sinn:

1. De Client huet op Updates abonnéiert.
2. De Client huet eng Ufro un de Server geschéckt.
3. De Server huet geäntwert "Ufro akzeptéiert."
4. De Server huet mam Resultat duerch de Kanal vum Punkt "1" geäntwert.

Wéi Dir kënnt gesinn, ass de Schema e bësse méi komplex. Ausserdeem fehlt déi intuitiv Ufro-Äntwert Approche hei. Wéi och ëmmer, wéi Dir gesitt, wäert eng Verbindungsbrek beim Veraarbechtung vun enger Ufro net zu engem Feeler féieren. Ausserdeem, wann de Benotzer tatsächlech vu verschiddenen Apparater mam Service ugeschloss ass (zum Beispill vun engem Handy a vun engem Tablet), kënnt Dir sécher sinn datt d'Äntwert op béid Apparater kënnt.

Interessanterweis gëtt de Code fir d'Veraarbechtung vun erakommen Messagen déiselwecht (net 100%) souwuel fir Eventer déi vum Client selwer beaflosst goufen, wéi och fir aner Eventer, och déi vun anere Clienten.

Wéi och ëmmer, a Wierklechkeet kréie mir en zousätzleche Bonus wéinst der Tatsaach datt unidirektional Flow an engem funktionnelle Stil gehandhabt ka ginn (mat RX an ähnlech). An dëst ass schonn e seriöse Plus, well am Wesentlechen d'Applikatioun komplett reaktiv gemaach ka ginn, an och eng funktionell Approche benotzt. Fir Fett Programmer kann dëst däitlech spueren Entwécklung an Ënnerstëtzung Ressourcen.

Wa mir dës Approche mat horizontaler Skala kombinéieren, da kréie mir als Bonus d'Fäegkeet fir Ufroen op ee Server ze schécken an Äntwerte vun engem aneren ze kréien. Sou kann de Client de Service wielen, dee fir him bequem ass, an de System bannen wäert ëmmer nach fäeg sinn d'Evenementer korrekt ze veraarbechten.

Event Sourcing

Wéi Dir wësst, ass eng vun den Haaptmerkmale vun engem verdeelte System d'Feele vun enger gemeinsamer Zäit, eng gemeinsam kritesch Sektioun. Fir ee Prozess kënnt Dir eng Synchroniséierung maachen (op déiselwecht Mutexes), an där Dir sécher sidd datt keen aneren dëse Code ausféiert. Wéi och ëmmer, dëst ass geféierlech fir e verdeelt System, well et Overhead erfuerdert, a wäert och all d'Schéinheet vun der Skala ëmbréngen - all Komponente waarden nach ëmmer op een.

Vun hei kréie mir e wichtege Fakt - e séier verdeelt System kann net synchroniséiert ginn, well da wäerte mir d'Performance reduzéieren. Op der anerer Säit brauche mir dacks eng gewësse Konsistenz tëscht Komponenten. A fir dës kënnt Dir d'Approche benotzen mat eventuell Konsequenz, wou et garantéiert ass, datt wann et keng Daten Ännerungen fir eng Zäit no der leschter Aktualiséierung opgetrueden ("schlussendlech"), all Ufroen de leschten aktualiséiert Wäert zréck.

Et ass wichteg ze verstoen datt fir klassesch Datenbanken et zimlech oft benotzt gëtt staark Konsequenz, wou all Node déi selwecht Informatioun huet (dëst ass oft erreecht am Fall wou d'Transaktioun als etabléiert ass nëmmen no der zweeter Server reagéiert). Et ginn e puer Entspanungen hei wéinst den Isolatiounsniveauen, awer déi allgemeng Iddi bleift déiselwecht - Dir kënnt an enger komplett harmoniséierter Welt liewen.

Wéi och ëmmer, loosst eis zréck op déi ursprénglech Aufgab. Wann en Deel vum System kann mat gebaut ginn eventuell Konsequenz, da kënne mir de folgenden Diagramm konstruéieren.

Wichteg Fonctiounen vun dëser Approche:

• All erakommen Ufro gëtt an enger Schlaang gesat.
• Beim Veraarbechtung vun enger Ufro kann de Service och Aufgaben an aner Schlaangen setzen.
• All erakommen Event huet en Identifizéierer (wat fir Entduplikatioun néideg ass).
• D'Schlaang funktionéiert ideologesch no dem Schema "nëmmen addéieren". Dir kënnt Elementer net ewechhuelen oder se nei arrangéieren.
• D'Schlaang funktionnéiert nom FIFO Schema (entschëllegt fir d'Tautologie). Wann Dir parallel Ausféierung maache musst, da sollt Dir op enger Etapp Objeten a verschidde Schlaangen réckelen.

Loosst mech Iech drun erënneren datt mir de Fall vun der Online Dateilagerung berücksichtegen. An dësem Fall wäert de System esou ausgesinn:

Et ass wichteg datt d'Servicer am Diagramm net onbedéngt e separaten Server bedeiten. Och de Prozess kann d'selwecht sinn. Eng aner Saach ass wichteg: ideologesch sinn dës Saache sou getrennt datt d'horizontale Skaléierung einfach applizéiert ka ginn.

A fir zwee Benotzer wäert d'Diagramm esou ausgesinn (Servicer, déi fir verschidde Benotzer geduecht sinn, ginn a verschiddene Faarwen uginn):

Bonus vun esou enger Kombinatioun:

• Informatiounsveraarbechtungsservicer sinn getrennt. D'Schlaangen sinn och getrennt. Wa mir de Systemduerchgang musse erhéijen, da musse mir just méi Servicer op méi Server lancéieren.
• Wa mir Informatioune vun engem Benotzer kréien, musse mir net waarden bis d'Donnéeën komplett gespäichert sinn. Am Géigendeel, mir brauche just "ok" ze äntweren an dann lues a lues ufänken ze schaffen. Zur selwechter Zäit glatt d'Schlaang d'Peaks aus, well d'Addéiere vun engem neien Objet séier geschitt, an de Benotzer muss net op e komplette Pass duerch de ganzen Zyklus waarden.
• Als Beispill hunn ech en Deduplikatiounsservice bäigefüügt, dee probéiert identesch Dateien ze fusionéieren. Wann et an 1% vun de Fäll laang funktionnéiert, wäert de Client et kaum bemierken (kuckt hei uewen), wat e grousse Plus ass, well mir net méi verlaangt sinn XNUMX% Geschwindegkeet an zouverlässeg ze sinn.

Allerdéngs sinn d'Nodeeler direkt sichtbar:

• Eise System huet seng strikt Konsequenz verluer. Dëst bedeit datt wann Dir zum Beispill verschidde Servicer abonnéiert, da kënnt Dir theoretesch en anere Staat kréien (well ee vun de Servicer vläicht keng Zäit huet fir eng Notifikatioun vun der interner Schlaang ze kréien). Als aner Konsequenz huet de System elo keng gemeinsam Zäit. Dat ass, et ass onméiglech, zum Beispill, all Eventer einfach no Arrivée Zäit ze sortéieren, well d'Auer tëscht Serveren vläicht net synchron sinn (ausserdeem ass déiselwecht Zäit op zwee Server eng Utopie).
• Keng Eventer kënnen elo einfach zréckgezunn ginn (wéi et mat enger Datebank gemaach ka ginn). Amplaz musst Dir en neit Event derbäi setzen - Kompensatioun Event, déi de leschte Staat op déi néideg ännert. Als e Beispill aus engem ähnleche Beräich: ouni d'Geschicht ëmzeschreiwen (wat an e puer Fäll schlecht ass), kënnt Dir net eng Verpflichtung am Git zréckrollen, awer Dir kënnt e spezielle maachen rollback engagéieren, wat am Fong just den ale Staat zréckkënnt. Wéi och ëmmer, souwuel de falschen Engagement wéi d'Rollback bleiwen an der Geschicht.
• D'Dateschema kann vu Verëffentlechung op Verëffentlechung änneren, awer al Eventer kënnen net méi op den neie Standard aktualiséiert ginn (well d'Evenementer am Prinzip net geännert kënne ginn).

Wéi Dir gesitt, funktionnéiert Event Sourcing gutt mat CQRS. Ausserdeem, e System mat effizienten a praktesche Schlaangen ëmzesetzen, awer ouni Datefloss ze trennen, ass scho schwéier an sech selwer, well Dir musst Synchroniséierungspunkte addéieren, déi de ganze positiven Effekt vun de Schlaangen neutraliséieren. Wann Dir béid Approche gläichzäiteg applizéiert, ass et néideg de Programmcode liicht unzepassen. An eisem Fall, wann Dir eng Datei op de Server schéckt, kënnt d'Äntwert nëmmen "ok", dat heescht nëmmen datt "d'Operatioun fir d'Datei derbäizeféieren gouf gespäichert." Formell heescht dat net datt d'Donnéeën schonn op aneren Apparater verfügbar sinn (zum Beispill kann den Entduplikatiounsservice den Index nei opbauen). Wéi och ëmmer, no enger Zäit kritt de Client eng Notifikatioun am Stil vun "Datei X gouf gespäichert."

Als Resultat vun:

• D'Zuel vun de Dateie-Send-Status geet erop: amplaz vum klassesche "Datei geschéckt", kréie mir zwee: "d'Datei ass an d'Schlaang um Server bäigefüügt" an "d'Datei gouf an der Späichere gespäichert." Dat lescht bedeit datt aner Apparater scho kënnen ufänken d'Datei ze kréien (ugepasst fir d'Tatsaach datt d'Schlaangen mat verschiddene Geschwindegkeete funktionnéieren).
• Wéinst der Tatsaach datt d'Soumissiounsinformatioun elo duerch verschidde Kanäl kënnt, musse mir mat Léisunge kommen fir den Veraarbechtungsstatus vun der Datei ze kréien. Als Konsequenz dovunner: Am Géigesaz zu der klassescher Ufro-Äntwert, kann de Client während der Veraarbechtung vun der Datei nei gestart ginn, awer de Status vun dëser Veraarbechtung selwer wäert richteg sinn. Ausserdeem funktionnéiert dësen Artikel am Wesentlechen aus der Këscht. Als Konsequenz: Mir sinn elo méi tolerant géint Echec.

Schied

Wéi uewen beschriwwen, feelen Eventsourcing Systemer strikt Konsistenz. Dëst bedeit datt mir verschidde Späichere benotze kënnen ouni Synchroniséierung tëscht hinnen. Eise Problem Approche, kënne mir:

• Trennt Dateien no Typ. Zum Beispill kënne Biller / Videoe dekodéiert ginn an e méi effizient Format ka gewielt ginn.
• Trennt Konten no Land. Wéinst ville Gesetzer kann dëst erfuerderlech sinn, awer dëst Architekturschema bitt esou eng Chance automatesch

Wann Dir wëllt Daten vun engem Stockage an en anert Transfermaart, da Standard Moyene sinn net méi genuch. Leider, an dësem Fall, musst Dir d'Schlaang stoppen, d'Migratioun maachen, an dann starten. Am allgemenge Fall kënnen d'Donnéeën net "on the fly" transferéiert ginn, awer wann d'Evenementschlaang komplett gespäichert ass, an Dir hutt Schnappschëss vu fréiere Späicherzoustand, da kënne mir d'Evenementer wéi follegt widderhuelen:

• An Event Source huet all Event säin eegenen Identifizéierer (am Idealfall, net erofgoen). Dëst bedeit datt mir e Feld an d'Späichere kënne addéieren - d'Id vum leschte veraarbechten Element.
• Mir duplizéieren d'Schlaang sou datt all Eventer fir e puer onofhängeg Späichere veraarbecht kënne ginn (déi éischt ass deen an deem d'Donnéeën scho gespäichert sinn, an déi zweet ass nei, awer nach ëmmer eidel). Déi zweet Schlaang gëtt natierlech nach net veraarbecht.
• Mir starten déi zweet Schlaang (dat ass, mir fänken un d'Evenementer ze spillen).
• Wann déi nei Schlaang relativ eidel ass (dat ass, den Duerchschnëttszäitdifferenz tëscht derbäisetzen vun engem Element an zréckzéien ass akzeptabel), kënnt Dir d'Lieser op déi nei Späichere wiesselen.

Wéi Dir gesitt, hu mir keng strikt Konsequenz an eisem System, an nach ëmmer net. Et gëtt nëmmen eventuell Konsistenz, dat heescht eng Garantie datt d'Evenementer an der selwechter Uerdnung veraarbecht ginn (awer méiglecherweis mat verschiddene Verspéidungen). A mat dësem kënne mir relativ einfach Daten transferéieren ouni de System op déi aner Säit vum Globus ze stoppen.

Also, weider eist Beispill iwwer Online Späichere fir Dateien, esou eng Architektur gëtt eis schonn eng Rei vu Bonus:

• Mir kënnen Objekter méi no bei de Benotzer op eng dynamesch Manéier réckelen. Op dës Manéier kënnt Dir d'Qualitéit vum Service verbesseren.
• Mir kënnen e puer Daten bannent Firmen späicheren. Zum Beispill, Enterprise Benotzer erfuerderen dacks datt hir Donnéeën a kontrolléierten Datezentren gespäichert ginn (fir Datenleckungen ze vermeiden). Duerch Sharding kënne mir dëst einfach ënnerstëtzen. An d'Aufgab ass nach méi einfach wann de Client eng kompatibel Cloud huet (zum Beispill, Azure selwer gehost).
• An dat Wichtegst ass datt mir dat net musse maachen. No allem, fir unzefänken, wiere mir ganz zefridden mat enger Späichere fir all Konten (fir séier ze schaffen). An de Schlëssel Fonktioun vun dësem System ass, datt obwuel et erweidert ass, an der éischter Etapp ass et relativ einfach. Dir musst just net direkt Code schreiwen deen mat enger Millioun getrennten onofhängege Schlaangen funktionnéiert, etc. Wann néideg, kann dat an Zukunft gemaach ginn.

Static Content Hosting

Dëse Punkt kann zimmlech offensichtlech schéngen, awer et ass nach ëmmer néideg fir eng méi oder manner Standard gelueden Applikatioun. Seng Essenz ass einfach: all statesch Inhalt gëtt net vum selwechte Server verdeelt wou d'Applikatioun läit, mee vu speziellen déi speziell fir dës Aufgab gewidmet sinn. Als Resultat ginn dës Operatiounen méi séier gemaach (bedingt nginx servéiert Dateien méi séier a manner deier wéi e Java Server). Plus CDN Architektur (Inhalt Liwwerung Network) erlaabt eis eis Dateie méi no bei den Endbenotzer ze lokaliséieren, wat e positiven Effekt op d'Bequemlechkeet vum Service huet.

Dat einfachst a meescht Standard Beispill vu statesche Inhalt ass eng Rei vu Scripten a Biller fir eng Websäit. Alles ass einfach mat hinnen - si sinn am Viraus bekannt, da gëtt d'Archiv op CDN Server eropgelueden, vu wou se un d'Endbenotzer verdeelt ginn.

Wéi och ëmmer, a Wierklechkeet, fir statesch Inhalter, kënnt Dir eng Approche benotzen e bësse ähnlech wéi d'Lambda Architektur. Komme mer zréck op eis Aufgab (Online Dateilagerung), an där mir Dateien un d'Benotzer musse verdeelen. Déi einfachst Léisung ass e Service ze kreéieren dee fir all Benotzerufro all déi néideg Kontrollen mécht (Autorisatioun, asw.), an dann d'Datei direkt vun eisem Späicher eroflueden. Den Haaptnodeel vun dëser Approche ass datt statesch Inhalt (an e Fichier mat enger gewësser Versioun ass tatsächlech statesch Inhalt) vum selwechte Server verdeelt gëtt deen d'Geschäftslogik enthält. Amplaz kënnt Dir déi folgend Diagramm maachen:

• De Server bitt eng Download URL. Et kann aus der Form file_id + Schlëssel sinn, wou Schlëssel eng mini-digital Ënnerschrëft ass, déi d'Recht gëtt fir op d'Ressource fir déi nächst 24 Stonnen ze kommen.
• D'Datei gëtt duerch einfach nginx mat de folgenden Optiounen verdeelt:
  • Inhalt Caching. Zënter dësem Service kann op engem separaten Server lokaliséiert ginn, hu mir eis eng Reserve fir d'Zukunft hannerlooss mat der Fäegkeet all déi lescht erofgeluede Dateien op Disk ze späicheren.
  • Iwwerpréift de Schlëssel am Moment vun der Verbindung Kreatioun
• Optional: Streaming Inhaltsveraarbechtung. Zum Beispill, wa mir all Dateien am Service kompriméieren, da kënne mir direkt an dësem Modul unzipping maachen. Als Konsequenz: IO Operatiounen ginn gemaach wou se gehéieren. En Archiver am Java wäert ganz einfach vill extra Gedächtnis allocéieren, awer e Service mat Geschäftslogik ëmzeschreiwen an Rust / C ++ Konditioune kann och net effikass sinn. An eisem Fall gi verschidde Prozesser (oder souguer Servicer) benotzt, an dofir kënne mir ganz effektiv Geschäftslogik an IO Operatiounen trennen.

Dëse Schema ass net ganz ähnlech wéi statesch Inhalter ze verdeelen (well mir net de ganze statesche Package iergendwou eroplueden), awer a Wierklechkeet ass dës Approche genee beschäftegt mat der Verdeelung vun onverännerbaren Donnéeën. Ausserdeem kann dëst Schema op aner Fäll generaliséiert ginn, wou den Inhalt net einfach statesch ass, mee kann als Set vun onverännerbaren an net-läsche Blocken duergestallt ginn (och wann se derbäi kënne ginn).

Als en anert Beispill (fir Verstäerkung): wann Dir mat Jenkins / TeamCity geschafft hutt, da wësst Dir datt béid Léisungen am Java geschriwwe sinn. Béid vun hinnen sinn e Java-Prozess dee souwuel d'Bauorkestratioun an d'Inhaltsmanagement handhabt. Besonnesch si hunn allebéid Aufgaben wéi "e Fichier / Dossier vum Server transferéieren." Als Beispill: d'Ausstellung vun Artefakte, d'Iwwerdroung vun de Quellcode (wann den Agent de Code net direkt vum Repository erofluet, awer de Server mécht et fir hien), Zougang zu Logbicher. All dës Aufgaben ënnerscheeden sech an hirer IO Belaaschtung. Dat heescht, et stellt sech eraus datt de Server, deen fir komplex Geschäftslogik verantwortlech ass, gläichzäiteg fäeg ass, grouss Datenflëss duerch sech selwer ze drécken. A wat am meeschten interessant ass, ass datt sou eng Operatioun un deeselwechten nginx delegéiert ka ginn no genau deemselwechte Schema (ausser datt den Dateschlëssel op d'Ufro bäigefüügt gëtt).

Wéi och ëmmer, wa mir an eise System zréckkommen, kréie mir en ähnlechen Diagramm:

Wéi Dir kënnt gesinn, ass de System radikal méi komplex ginn. Elo ass et net nëmmen e Mini-Prozess deen Dateien lokal späichert. Elo wat erfuerderlech ass net déi einfachst Ënnerstëtzung, API Versiounskontroll, etc. Dofir, nodeems all d'Diagrammer gezeechent sinn, ass et am beschten am Detail ze evaluéieren ob d'Extensibilitéit d'Käschte wäert ass. Wéi och ëmmer, wann Dir de System ausbaue wëllt (och fir mat enger nach méi grousser Zuel vu Benotzer ze schaffen), da musst Dir fir ähnlech Léisunge goen. Awer, als Resultat ass de System architektonesch prett fir erhéicht Belaaschtung (bal all Komponent ka fir horizontale Skala gekloont ginn). De System kann aktualiséiert ginn ouni et ze stoppen (einfach e puer Operatioune ginn liicht verlangsamt).

Wéi ech am Ufank gesot hunn, hunn elo eng Rei vun Internetservicer ugefaang méi Belaaschtung ze kréien. An e puer vun hinnen hunn einfach ugefaang richteg ze schaffen. Tatsächlech hunn d'Systemer genee de Moment gescheitert, wou d'Geschäft Sue verdénge sollt. Dat ass, amplaz vun der Liwwerung ausgestallt, anstatt de Clienten ze proposéieren "Är Liwwerung fir déi nächst Méint ze plangen", sot de System einfach "Gitt op Är Konkurrenten." Tatsächlech ass dëst de Präis vun enger gerénger Produktivitéit: Verloschter wäerte genee optrieden wann d'Beneficer héchst sinn.

Konklusioun

All dës Approche waren virdru bekannt. Deeselwechte VK huet laang d'Iddi vu Static Content Hosting benotzt fir Biller ze weisen. Vill Online Spiller benotzen de Sharding Schema fir Spiller a Regiounen opzedeelen oder Spillplazen ze trennen (wann d'Welt selwer eng ass). Event Sourcing Approche gëtt aktiv an der E-Mail benotzt. Déi meescht Handelsapplikatioune wou Daten dauernd opgeholl ginn, sinn tatsächlech op enger CQRS Approche gebaut fir d'Daten ze filteren déi kritt ginn. Gutt, horizontal Skala gouf a ville Servicer fir eng zimlech laang Zäit benotzt.

Wéi och ëmmer, am wichtegsten sinn all dës Mustere ganz einfach ginn an modernen Uwendungen z'applizéieren (wann se natierlech passend sinn). D'Wolleke bidden direkt Sharding an horizontale Skaléieren, wat vill méi einfach ass wéi verschidde dedizéierten Serveren a verschiddenen Datenzenteren selwer ze bestellen. CQRS ass vill méi einfach ginn, wann nëmmen wéinst der Entwécklung vu Bibliothéiken wéi RX. Virun ongeféier 10 Joer konnt eng rar Websäit dëst ënnerstëtzen. Event Sourcing ass och onheemlech einfach ze konfiguréieren dank fäerdege Container mat Apache Kafka. Virun 10 Joer wier dat eng Innovatioun gewiescht, elo ass et allgemeng. Et ass d'selwecht mat Static Content Hosting: duerch méi praktesch Technologien (och d'Tatsaach datt et detailléiert Dokumentatioun an eng grouss Datebank vun Äntwerten gëtt), ass dës Approche nach méi einfach ginn.

Als Resultat ass d'Ëmsetzung vun enger Rei vun zimlech komplexen architektonesche Musteren elo vill méi einfach ginn, wat heescht datt et besser ass am Viraus méi genau ze kucken. Wann an enger zéng Joer aler Applikatioun eng vun den uewe genannte Léisungen opginn gouf wéinst den héije Käschte vun der Implementatioun an der Operatioun, elo, an enger neier Applikatioun, oder no der Refactoring, kënnt Dir e Service erstellen deen schonn architektonesch souwuel erweiterbar ass ( wat d'Leeschtung ugeet) a prett fir nei Ufroe vu Clienten (zum Beispill fir perséinlech Donnéeën ze lokaliséieren).

An am wichtegsten: benotzt w.e.g. dës Approche net wann Dir eng einfach Applikatioun hutt. Jo, si si schéin an interessant, awer fir e Site mat engem Héichpunkt vun 100 Leit, kënnt Dir dacks mat engem klassesche Monolith duerchgoen (op d'mannst op der Äussewelt, alles bannen kann a Moduler opgedeelt ginn, etc.).

Source: will.com