Geschicht vun der Dodo IS Architektur: De Back Office Path

Habr ännert d'Welt. Mir bloggen zënter méi wéi engem Joer. Virun ongeféier sechs Méint krute mir e ganz logesche Feedback vun den Awunner vu Khabrovsk: "Dodo, Dir sot iwwerall datt Dir Ären eegene System hutt. Wéi eng Zort System ass dëst? A firwat brauch d'Pizzeriakette et?

Mir souzen a geduecht a realiséiert datt Dir Recht hutt. Mir probéieren alles mat eise Fangeren z'erklären, awer et kënnt an zerräissene Stécker eraus an et gëtt keng komplett Beschreiwung vum System iwwerall. Sou huet eng laang Rees ugefaang fir Informatioun ze sammelen, no Auteuren ze sichen an eng Serie vun Artikelen iwwer Dodo IS ze schreiwen. A lass!

Unerkennung: Merci datt Dir Äre Feedback mat eis deelt. Dank him hu mir endlech de System beschriwwen, en Technoradar zesummegestallt a geschwënn eng grouss Beschreiwung vun eise Prozesser ausrollen. Ouni iech wiere mir nach 5 Joer esou souz.

Serie vun Artikelen "Wat ass Dodo IS?" erzielt iwwer:

1. Fréi Monolith am Dodo IS (2011-2015). (A Beaarbechtung...)
2. Backoffice Wee: separat Basen a Bus. (Du bass hei)
3. De Client Säit Wee: Fassad iwwer d'Basis (2016-2017). (A Beaarbechtung...)
4. D'Geschicht vun real microservices. (2018-2019). (A Beaarbechtung...)
5. Fäerdeg Säge vum Monolith a Stabiliséierung vun der Architektur. (A Beaarbechtung...)

Wann Dir interesséiert sidd eppes anescht ze léieren, schreift an de Kommentarer.

Meenung iwwer d'chronologesch Beschreiwung vum Auteur
Ech halen regelméisseg eng Reunioun fir nei Mataarbechter zum Thema "Systemarchitektur". Mir nennen et "Intro zu Dodo IS Architecture" an et ass Deel vum Onboarding Prozess fir nei Entwéckler. Schwätzen an enger Form oder aner iwwer eis Architektur, iwwer seng Fonctiounen, hunn ech eng gewëssen historesch Approche zu der Beschreiwung entwéckelt.

Traditionell kucke mir e System als eng Rei vu Komponenten (technesch oder méi héich), Geschäftsmoduler déi matenee interagéieren fir e puer Ziler z'erreechen. A wann esou eng Vue fir Design gerechtfäerdegt ass, ass et net ganz gëeegent fir Beschreiwung a Verständnis. Et gi verschidde Grënn:

• D'Realitéit ass anescht wéi op Pabeier. Net alles klappt wéi geplangt. A mir interesséieren eis wéi alles eigentlech erausgaang ass a funktionnéiert.
• Konsequent Presentatioun vun Informatioun. Tatsächlech kënnt Dir chronologesch vun Ufank un an den aktuellen Zoustand goen.
• Vun einfach bis komplex. Net universell, awer an eisem Fall ass et esou. D'Architektur ass vun méi einfachen Approche op méi komplex geplënnert. Dacks, duerch Komplikatioun, Problemer vun der Implementéierungsgeschwindegkeet a Stabilitéit, souwéi Dosende vun aneren Eegeschaften aus der Lëscht vun net-funktionnellen Ufuerderungen (hei gutt geschwat iwwer kontrastéierend Komplexitéit mat aneren Ufuerderungen).

Am Joer 2011 huet d'Dodo IS Architektur esou ausgesinn:

Bis 2020 ass et e bësse méi komplizéiert ginn a gouf esou:

Wéi ass dës Evolutioun geschitt? Firwat sinn verschidden Deeler vum System néideg? Wéi eng architektonesch Entscheedunge goufen geholl a firwat? Loosst eis an dëser Serie vun Artikelen erausfannen.

Déi éischt Problemer vun 2016: Firwat sollen Servicer de Monolith verloossen?

Déi éischt Artikelen an der Serie wäerten iwwer d'Servicer sinn, déi als éischt aus dem Monolith getrennt waren. Fir Iech an de Kontext ze setzen, wäert ech Iech soen, wéi eng Problemer mir Ufank 2016 am System haten, datt mir mat der Trennung vun de Servicer ze dinn hunn.

Eng eenzeg MySql Datebank, an där all Applikatiounen, déi zu där Zäit am Dodo IS existéiert hunn, hir Rekorder geschriwwen hunn. D'Konsequenze waren:

• Schwéier Belaaschtung (mat 85% vun Ufroe gelies).
• D'Basis war wuessen. Wéinst dësem, Käschten an Ënnerstëtzung gouf en Thema.
• Eenzege Punkt vun Echec. Wann eng Applikatioun déi an d'Datebank schreift op eemol ugefaang huet méi aktiv ze maachen, dann hunn aner Applikatiounen den Impakt gefillt.
• Ineffizienz am Späicheren an Ufroen. Dacks goufen d'Donnéeën an enger Struktur gespäichert déi bequem war fir e puer Szenarie awer net fir anerer. Indexen beschleunegen e puer Operatiounen, awer kënnen anerer verlangsamen.
• E puer vun de Probleemer goufen duerch séier gemaach Cache a Lies-Repliken op Datenbanken geléist (dëst gëtt an engem separaten Artikel diskutéiert), awer si hunn eis nëmmen erlaabt Zäit ze gewannen an hunn de Problem net grondsätzlech geléist.

De Problem war d'Präsenz vum Monolith selwer. D'Konsequenze waren:

• Eenzegaarteg a rar Verëffentlechungen.
• D'Schwieregkeet ass an der kollaborativ Entwécklung vun enger grousser Zuel vu Leit.
• Onméiglechkeet nei Technologien aféieren, nei Kaderen a Bibliothéiken.

Probleemer mat der Basis a Monolith goufen vill Mol beschriwwen, zum Beispill am Kontext vun Crashen am fréien 2018 (Ginn wéi Munch, oder e puer Wierder iwwer technesch Schold, Den Dag Dodo IS opgehalen. Asynchron Schrëft и D'Geschicht vum Dodo Vugel aus der Phoenix Famill. De Grousse Fall vun der Dodo IS), also wäert ech net ze vill wunnen. Loosst mech just soen, mir wollten méi Flexibilitéit ginn, wann Dir Servicer entwéckelt. Als éischt betrëfft dat déi, déi am meeschte gelueden an root am ganze System waren - Auth an Tracker.

De Back Office Path: Separat Basen a Bus

Kapitel Navigatioun

1. Schema vum Monolith 2016
2. Mir fänken un de Monolith ze entlaaschten: Trennung vun Auth a Tracker
   
3. Wat mécht Auth?
4. Wou kommen d'Laascht hier?
5. Ausluede Auth
6. Wat mécht Tracker?
7. Wou kommen d'Laascht hier?
8. Ausluede vum Tracker

Schema vum Monolith 2016

Hei sinn d'Haaptblocken vum 2016 Dodo IS Monolith, a just drënner ass en Decompte vun hiren Haaptaufgaben.

Liwwerung boer Büro schaffen. Comptablesmethod fir Courrieren, Bestellungen un Courrieren ausginn.
Kontakt Zentrum. Akzeptéieren Bestellungen duerch de Bedreiwer.
Site. Eis Websäite (dodopizza.ru, dodopizza.co.uk, dodopizza.by, etc.).
Auth. Autorisatioun an Authentifikatioun Service fir Backoffice.
Трекер. Kichen Uerdnung Tracker. Service fir d'Bereedschaftsstatus ze markéieren wann Dir eng Bestellung virbereet.
Restaurant boer Büro schaffen. Bestellungen an engem Restaurant huelen, Keesseberäicher Interfaces.
exportéieren. Eroplueden Berichter am 1C fir Comptabilitéit.
Alarmer a Rechnungen. Stëmmbefehl an der Kichen (zum Beispill "Nei Pizza ass ukomm") + Dréckerei vu Rechnungen fir Courrieren.
Verréckelung Manager. Schnëttplazen fir d'Aarbecht vun engem Verréckelung Manager: Lëscht vun Commanden, Produktivitéit Charts, Employéen zu Verréckelung bréngen.
Büro Manager. Interfaces fir d'Aarbecht vu Franchisee a Manager: Empfang vun Mataarbechter, Berichter iwwer d'Aarbecht vun der Pizzeria.
Restaurant Verwaltungsrot. Menue op Fernseher an Pizzeriaen weisen.
Admin. Astellunge fir eng spezifesch Pizzeria: Menü, Präisser, Comptabilitéit, Promotiouns Coden, Promotiounen, Bannere fir de Site, etc.
Employé perséinleche Kont. Employé Aarbecht Flugplang, Informatiounen iwwert Mataarbechter.
Kichen Motivatioun Verwaltungsrot. En getrennten Ecran deen an der Kichen hänkt an d'Geschwindegkeet vun de Pizzahersteller weist.
Kommunikatioun. Schéckt SMSen an E-Mail.
FileStorage. Eegent Service fir statesch Dateien z'empfänken an auszeginn.

Déi éischt Versuche fir Probleemer ze léisen hunn eis gehollef, awer si waren nëmmen eng temporär Erhuelung. Si sinn net zu Systemléisungen ginn, also war kloer, datt eppes mat de Basen misst gemaach ginn. Zum Beispill, deelen d'allgemeng Datebank an e puer méi spezialiséiert.

Mir fänken un de Monolith ze entlaaschten: Trennung vun Auth a Tracker

D'Haaptservicer déi dann aus der Datebank geschriwwen a gelies hunn méi wéi anerer:

1. Auth. Autorisatioun an Authentifikatioun Service fir Backoffice.
2. Tracker. Kichen Uerdnung Tracker. Service fir d'Bereedschaftsstatus ze markéieren wann Dir eng Bestellung virbereet.

Wat mécht Auth?

Auth ass e Service, duerch deen d'Benotzer an de Back Office aloggen (et gëtt e separaten onofhängege Login op der Client Säit). Et gëtt och an der Ufro referenzéiert fir sécherzestellen datt déi richteg Zougangsrechter präsent sinn an datt dës Rechter zënter dem leschte Login net geännert hunn. Apparater gitt Pizzeriaen duerch.

Zum Beispill wëlle mir e Display opmaachen mat dem Status vun ofgeschlossen Bestellungen um Fernseh, deen an der Hal hänkt. Da öffnen mir auth.dodopizza.ru, wielt "Login als Apparat", e Code erschéngt, deen an enger spezieller Säit um Computer vum Verréckelung Manager agefouert ka ginn, wat d'Art vum Apparat (Gerät) besot. De Fernseh selwer wäert op déi gewënscht Interface vu senger Pizzeria goen a fänkt do un d'Nimm vun de Clienten ze weisen, deenen hir Bestellunge fäerdeg sinn.

Wou kommen d'Laascht hier?

All ageloggte Backoffice Benotzer geet fir all Ufro an d'Datebank, op d'Benotzertabel, zitt de Benotzer vun do aus duerch eng sql Ufro eraus a kontrolléiert ob hien déi néideg Zougang a Rechter op dës Säit huet.

Jiddereng vun den Apparater mécht d'selwecht nëmme mam Apparat Dësch, kontrolléiert seng Roll a seng Zougang. Eng grouss Zuel vun Ufroen un d'Meeschtesch Datebank féiert zu senger Luede an Offall vun allgemengen Datebank Ressourcen op dës Operatiounen.

Ausluede Auth

Auth huet en isoléierten Domain, dat heescht Daten iwwer Benotzer, Login oder Apparater ginn an de Service (aktuell zukünfteg) a bleiwen do. Wann een se brauch, da geet hien op dëse Service fir daten.

WAR. De Workflow war ufanks esou:

Ech wéilt e bëssen erkläre wéi et geschafft huet:

1. Eng extern Ufro kënnt op de Backend (Asp.Net MVC do), bréngt e Sessiouns-Cookie mat, dee benotzt gëtt fir Sessiounsdaten vu Redis (1) ze kréien. Et enthält entweder Informatioun iwwer Zougang, an dann ass den Zougang zum Controller op (3,4), oder net.
2. Wann et keen Zougang ass, musst Dir duerch d'Autorisatiounsprozedur goen. Hei, fir Einfachheet, gëtt et als Deel vum Wee am selwechten Attribut gewisen, obwuel dëst en Iwwergang op d'Login Säit ass. Am Fall vun engem positiven Szenario kréie mir eng korrekt gefëllte Sessioun a gitt op de Backoffice Controller.
3. Wann et Daten ass, da musst Dir se fir d'Relevanz an der Benotzerdatenbank kontrolléieren. Huet seng Roll geännert, soll hien elo net op der Säit erlaabt ginn? An dësem Fall, nodeems Dir d'Sessioun (1) kritt hutt, musst Dir direkt an d'Datebank goen an den Zougang vum Benotzer iwwerpréift mat der Authentifikatiounslogikschicht (2). Als nächst gitt entweder op d'Login Säit oder gitt op de Controller. Dëst ass en einfache System, awer net ganz Standard.
4. Wann all Prozedure fäerdeg sinn, sprange mir weider an der Logik a Controller a Methoden.

D'Benotzerdaten gi vun allen aneren Donnéeën getrennt, se ginn an enger separater Memberschaftstabell gespäichert, Funktiounen aus der AuthService Logikschicht kënne gutt API Methoden ginn. D'Grenze vum Domain sinn ganz kloer definéiert: Benotzer, hir Rollen, Zougangsdaten, Emissioun a Réckzuch vum Zougang. Alles gesäit aus wéi wann et an e separaten Service geplënnert ka ginn.

GEWENNT. Dat ass wat se gemaach hunn:

Dës Approche huet eng Rei vu Problemer. Zum Beispill, eng Method an engem Prozess ze ruffen ass net datselwecht wéi en externe Service iwwer http ze ruffen. Latency, Zouverlässegkeet, Ënnerstëtzung an Transparenz vun der Operatioun si komplett anescht. Den Andrey Morevsky huet a sengem Bericht méi detailléiert iwwer genee dës Problemer geschwat "50 Nuancen vu Mikroservicer".

Den Authentifikatiounsservice an domat den Apparatservice gi fir Backoffice benotzt, dat heescht fir Servicer an Interfaces déi an der Produktioun benotzt ginn. Authentifikatioun fir Clientsservicer (wéi eng Websäit oder mobil Applikatioun) geschitt separat ouni Auth ze benotzen. D'Trennung huet ongeféier ee Joer gedauert, an elo schaffe mir erëm un dësem Thema, de System op nei Authentifikatiounsservicer (mat Standardprotokoller) iwwerdroen.

Firwat huet d'Trennung sou laang gedauert?
Et ware vill Problemer um Wee, déi eis verlangsamt hunn:

1. Mir wollten Donnéeën iwwer Benotzer, Apparater an Authentifikatioun aus Land Datenbanken an eng Transfert. Fir dëst ze maachen, hu mir all Dëscher a Gebrauch vum int Identifizéierer op de globale UUId Identifizéierer misse transferéieren (mir hunn dëse Code viru kuerzem ëmgebaut Roman Bukin "Uuid - déi grouss Geschicht vun enger klenger Struktur" an Open-Source Projet Primitiven). D'Späichere vu Benotzerdaten (well dëst perséinlech Informatioun ass) huet seng Aschränkungen a fir e puer Länner ass et néideg se separat ze späicheren. Mä et muss eng global Benotzer ID ginn.
2. Vill Dëscher an der Datebank hunn Auditinformatioun iwwer de Benotzer deen d'Operatioun gemaach huet. Dëst erfuerdert en zousätzleche Mechanismus fir d'Konsistenz ze garantéieren.
3. No der Schafung vun API-Servicer gouf et eng laang a graduell Period vum Transfer an en anere System. Schalter hu missen nahtlos fir Benotzer geschéien an erfuerderlech manuell Aarbecht.

Schema fir d'Aschreiwung vun engem Apparat an enger Pizzeria:

Allgemeng Architektur no der Trennung vun Auth an Devices Service:

Remarque. Fir 2020 schaffen mir un enger neier Versioun vun Auth, déi um OAuth 2.0 Autorisatiounsstandard baséiert. Dëse Standard ass zimmlech komplex, awer nëtzlech fir en End-to-End Authentifikatiounsservice z'entwéckelen. Am Artikel "Subtleties vun Autorisatioun: Iwwersiicht vun OAuth 2.0 Technologie» Mir Alexey Chernyaev probéiert iwwer de Standard sou einfach a kloer wéi méiglech ze schwätzen, sou datt Dir Zäit spuert fir se ze studéieren.

Wat mécht Tracker?

Elo iwwer déi zweet vun de geluedene Servicer. Den Tracker spillt eng duebel Roll:

• Engersäits ass et seng Aufgab, de Mataarbechter an der Kichen ze weisen, wéi eng Bestellunge momentan amgaang sinn, wéi eng Produkter elo musse virbereet ginn.
• Op der anerer Säit, digitaliséiert all Prozesser an der Kichen.

Wann en neit Produkt (zum Beispill Pizza) an enger Bestellung erschéngt, geet et op d'Trackerstatioun "Rolling". Op dëser Statioun gëtt et e Pizzahersteller, deen e Brout vun der erfuerderter Gréisst hëlt an erausrullt, duerno markéiert hien op der Tracker Tablet, datt hien seng Aufgab fäerdeg gemaach huet an déi ausgerullten Teigbasis op déi nächst Statioun passéiert - "Füllung" .

Do setzt den nächsten Pizzahersteller d'Pizza op, markéiert dann op der Tablet datt hien seng Aufgab fäerdeg gemaach huet a setzt d'Pizza an den Ofen (dëst ass och eng separat Statioun déi um Tablet markéiert muss ginn). Esou e System war vun Ufank un an Dodo a vun Ufank un Dodo IS. Et erlaabt Iech all Operatiounen voll ze verfolgen an ze digitaliséieren. Zousätzlech proposéiert de Tracker wéi een e bestëmmte Produkt virbereet, mécht all Produkttyp no hiren eegene Fabrikatiounsschemaen aus, späichert déi optimal Kachzäit fir de Produit, a verfollegt all Operatiounen um Produkt.

Dëst ass wéi den Tabletbildschierm op der Raskatka Tracker Station ausgesäit.

Wou kommen d'Laascht hier?

All Pizzeria huet ongeféier fënnef Pëllen mat engem Tracker. 2016 hate mir méi wéi 100 Pizzeriaen (an elo sinn et der méi wéi 600). Jiddereng vun den Pëllen mécht eng Ufro un de Backend all 10 Sekonnen a sammelt Daten aus der Bestellungstabell (Link mam Client an Adress), der Bestellungskompositioun (Link mam Produkt an Indikatioun vun der Quantitéit), an der Motivatiounstabell (et verfollegt) d'Zäit vum Drock). Wann e Pizza Hiersteller klickt op e Produit op der Tracker, records an all dësen Dëscher aktualiséiert. D'Bestellungstabell ass allgemeng; et enthält gläichzäiteg Insertiounen wann Dir eng Bestellung akzeptéiert, Updates vun aneren Deeler vum System, a vill Liesungen, zum Beispill op engem Fernseh deen an enger Pizzeria hänkt a fäerdeg Bestellungen u Clienten weist.

Wärend der Period vum Kampf mat Lasten, wann alles a jidderee gouf cachéiert an op eng asynchrone Replik vun der Datebank transferéiert, sinn dës Operatiounen mam Tracker weider an d'Master-Datebank goen. Et sollt keng Lag hei sinn, d'Donnéeën mussen aktuell sinn, aus Synchroniséierung ass inakzeptabel.

Och de Mangel vun eisen eegenen Dëscher an Indexen op hinnen huet eis net erlaabt méi spezifesch Ufroen ze schreiwen, déi fir eis Benotzung ugepasst sinn. Zum Beispill kann et effektiv sinn fir e Tracker en Index fir eng Pizzeria op sengem Bestellungsdësch ze hunn. Mir schrauwen ëmmer Pizzeria Bestellungen aus der Tracker Datebank. Zur selwechter Zäit, fir eng Bestellung ze akzeptéieren, ass et net sou wichteg an wéi eng Pizzeria et fällt, wat méi wichteg ass, wéi ee Client dës Bestellung gemaach huet. Dëst bedeit datt et en Index op de Client muss sinn. Et ass och net néideg fir den Tracker d'Id vun der gedréckter Empfang oder Bonus Promotiounen, déi mat der Bestellung an der Bestellungstabell verbonne sinn, ze späicheren. Eis Tracker Service ass net un dës Informatioun interesséiert. An enger gemeinsamer monolithescher Datebank kënnen Dëscher nëmmen e Kompromiss tëscht all Benotzer sinn. Dëst war ee vun den originelle Probleemer.

WAR. Am Ufank war d'Architektur esou:

Och nodeems se an getrennte Prozesser getrennt sinn, blouf déi meescht vun der Codebasis gemeinsam fir verschidde Servicer. Alles ënner de Controller gouf vereenegt a gelieft an engem Repository. Gemeinsam Methode vu Servicer, Repositories, an eng gemeinsam Datebank mat gemeinsamen Dëscher goufen benotzt.

Ausluede vum Tracker

Den Haaptproblem mam Tracker ass datt d'Donnéeën tëscht verschiddenen Datenbanken synchroniséiert musse ginn. Dëst ass och säin Haaptunterschied vun der Divisioun vum Auth-Service; d'Uerdnung a säi Status kënnen änneren a soll a verschiddene Servicer ugewise ginn.

Mir akzeptéieren Bestellungen am Restaurant Checkout (dëst ass e Service), et gëtt an der Datebank am Status "Akzeptéiert" gespäichert. Duerno sollt et op den Tracker goen, wou et nach e puer Mol säi Status ännert: vun "Kichen" op "Packed". An dësem Fall kënnen e puer extern Aflëss vum Keesseberäich oder dem Shift Manager Interface mat der Bestellung optrieden. Ech ginn d'Bestellungsstatus mat hiren Beschreiwungen an der Tabell:

D'Bestellungsstatus änneren Schema gesäit esou aus:

Status änneren tëscht verschiddene Systemer. An hei ass den Tracker net de finalen System an deem d'Donnéeën gespaart sinn. Mir hunn e puer méiglech Approche fir Trennung an esou engem Fall gesinn:

1. Mir konzentréieren all Bestellungsaktiounen an engem Service. An eisem Fall erfuerdert dës Optioun ze vill Service fir d'Bestellung ze veraarbecht. Wa mir do opgehalen hätten, wiere mer mat engem zweete Monolith opgehalen. Mir hätten d'Problemer net geléist.
2. Ee System rufft en aneren un. Déi zweet Optioun ass méi interessant. Awer mat et sinn Uruffketten méiglech (kaskadende Feeler), d'Konnektivitéit vun de Komponenten ass méi héich, an et ass méi schwéier ze managen.
3. Mir organiséieren Eventer, an all Service Austausch mat deem aneren duerch dës Evenementer. Als Resultat gouf déi drëtt Optioun gewielt, no deem all Servicer ufänken Eventer mateneen auszetauschen.

D'Tatsaach, datt mir déi drëtt Optioun gewielt hunn, huet gemengt, datt den Tracker seng eege Datebank hätt, a fir all Ännerung vun der Uerdnung en Event iwwer dëst ze schécken, op déi aner Servicer sech abonnéieren an déi och an der Master-Datebank opgeholl ginn. Fir dëst ze maachen, brauche mir e Service deen d'Liwwerung vu Messagen tëscht Servicer garantéiert.

Zu där Zäit hate mir schonn RabbitMQ am Stack, dofir déi definitiv Entscheedung et als Message Broker ze benotzen. D'Diagramm weist den Iwwergang vun enger Bestellung vum Restaurant Kassierer duerch den Tracker, wou et säi Status a seng Display op der Bestellungsinterface vum Manager ännert. GEWENNT:

Uerdnung Wee Schrëtt fir Schrëtt
Den Uerderwee fänkt bei engem vun den Uerderquellservicer un. Hei ass de Restaurant Caissier:

1. D'Bestellung ass komplett fäerdeg beim Kees, an et ass Zäit et un den Tracker ze schécken. Den Event op deen den Tracker abonnéiert ass gëtt geworf.
2. Den Tracker, akzeptéiert eng Bestellung, späichert se a senger eegener Datebank, mécht den Event "Order Accepted by Tracker" a schéckt se op RMQ.
3. Verschidde Handler si schonn op de personaliséierte Eventbus abonnéiert. Fir eis ass deen deen mat der monolithescher Datebank synchroniséiert ass wichteg.
4. Den Handler kritt d'Evenement, wielt dovunner d'Donnéeën aus, déi fir si bedeitend sinn: an eisem Fall ass dëst den Bestellungsstatus "Akzeptéiert vum Tracker" an aktualiséiert seng Bestellungsentitéit an der Haaptdatenbank.

Wann iergendeen eng Bestellung speziell aus der monolithescher Bestellungstabell brauch, da kann se se och vun do liesen. Zum Beispill, dat ass wat d'Bestellungen Interface am Shift Manager brauch:

All aner Servicer kënnen och abonnéieren fir Eventer vum Tracker ze bestellen fir se selwer ze benotzen.

Wann no enger Zäit eng Bestellung an d'Produktioun geholl gëtt, ännert säi Status als éischt a senger Datebank (Tracker Datebank), an dann gëtt den Event "OrderInWork" direkt generéiert. Et kënnt och an RMQ, vu wou et an enger monolithescher Datebank synchroniséiert gëtt an an aner Servicer geliwwert gëtt. Et kënne verschidde Probleemer op dësem Wee sinn; méi Detailer iwwer si kënnen am Bericht vum Zhenya Peshkov fonnt ginn iwwer d'Ëmsetzungsdetailer vum Eventuelle Konsistenz am Tracker.

Finale Architektur no Ännerungen an Auth an Tracker

Ze resuméieren: Am Ufank hat ech d'Iddi fir déi néng Joer Geschicht vum Dodo IS System an een Artikel ze packen. Ech wollt séier an einfach iwwer d'Etappe vun der Evolutioun schwätzen. Wéi och ëmmer, nodeems ech mech gesat hunn fir d'Material ze studéieren, hunn ech gemierkt datt alles vill méi komplex an interessant ass wéi et schéngt.

Reflektéieren iwwer d'Virdeeler (oder de Mangel dovun) vun esou Material, sinn ech zur Conclusioun komm datt eng kontinuéierlech Entwécklung onméiglech ass ouni vollwäerteg Chroniken vun Eventer, detailléierte Réckbléck an Analyse vun de fréiere Entscheedungen.

Ech hoffen Dir hutt et nëtzlech an interessant fonnt fir iwwer eis Rees ze léieren. Elo sinn ech mat engem Choix konfrontéiert wéi en Deel vum Dodo IS System am nächsten Artikel ze beschreiwen: an de Kommentarer schreiwen oder ofstëmmen.

Nëmme registréiert Benotzer kënnen un der Ëmfro deelhuelen. Umellen, wann ech glift.

Wéi en Deel vum Dodo IS wëllt Dir am nächsten Artikel léieren?

• 24,1%Fréi Monolith am Dodo IS (2011-2015)14

• 24,1%Éischt Problemer an hir Léisungen (2015-2016)14

• 20,7%Wee vum Client Deel: Fassad iwwer der Basis (2016-2017)12

• 36,2%Geschicht vun echte Mikroservicer (2018-2019)21

• 44,8%Ofgeschloss Ausschneiden vum Monolith a Stabiliséierung vun der Architektur26

• 29,3%Iwwer weider Pläng fir d'Entwécklung vum System17

• 19,0%Ech wëll näischt iwwer Dodo IS11 wëssen

58 Benotzer hunn gestëmmt. 6 Benotzer hu sech enthalen.

Source: will.com