Oder jedes unglückliche Unternehmen mit einem Monolithen ist auf seine Weise unglücklich.
Die Entwicklung des Dodo IS-Systems begann sofort, wie auch das Dodo Pizza-Geschäft, im Jahr 2011. Es basierte auf der Idee einer vollständigen und vollständigen Digitalisierung von Geschäftsprozessen , was schon damals im Jahr 2011 für viele Fragen und Skepsis sorgte. Doch schon seit 9 Jahren gehen wir diesen Weg – mit einer eigenen Entwicklung, die mit einem Monolithen begann.
Dieser Artikel ist eine „Antwort“ auf die Frage „Warum die Architektur neu schreiben und so groß angelegte und langfristige Änderungen vornehmen?“ zurück zum vorherigen Artikel . Ich beginne damit, wie die Entwicklung von Dodo IS begann, wie die ursprüngliche Architektur aussah, wie neue Module auftauchten und aufgrund welcher Probleme umfangreiche Änderungen vorgenommen werden mussten.
Artikelserie „Was ist Dodo IS?“ erzählt über:
-
Früher Monolith in Dodo IS (2011–2015). (Sie sind hier)
-
.
-
Der kundenseitige Weg: Fassade über dem Sockel (2016-2017). (Im Gange...)
-
Die Geschichte echter Microservices. (2018-2019). (Im Gange...)
-
Fertiges Sägen des Monolithen und Stabilisierung der Architektur. (Im Gange...)
Ursprüngliche Architektur
Im Jahr 2011 sah die Dodo IS-Architektur so aus:
Das erste Modul in der Architektur ist die Auftragsannahme. Der Geschäftsprozess war:
-
der Kunde ruft in der Pizzeria an;
-
der Manager greift zum Telefon;
-
nimmt eine Bestellung per Telefon entgegen;
-
füllt es parallel in der Bestellannahmeschnittstelle aus: Es berücksichtigt Informationen über den Kunden, Daten zu Bestelldetails, Lieferadresse.
Die Schnittstelle des Informationssystems sah in etwa so aus ...
Erste Version vom Oktober 2011:
Die Ressourcen für die Entwicklung des ersten Auftragsannahmemoduls waren begrenzt. Wir mussten viel erledigen, schnell und mit einem kleinen Team. Ein kleines Team besteht aus zwei Entwicklern, die den Grundstein für das gesamte zukünftige System gelegt haben.
Ihre erste Entscheidung bestimmte das Schicksal des Technologie-Stacks:
-
Backend auf ASP.NET MVC, C#-Sprache. Die Entwickler waren dotnetchiki, dieser Stack war ihnen vertraut und angenehm.
-
Frontend auf Bootstrap und JQuery: Benutzeroberflächen auf selbstgeschriebenen Stilen und Skripten.
-
MySQL-Datenbank: keine Lizenzkosten, einfach zu bedienen.
-
Server auf Windows Server, da .NET dann nur unter Windows möglich wäre (auf Mono gehen wir nicht ein).
Körperlich drückte sich das alles in der „Widmung beim Gastgeber“ aus.
Architektur der Auftragseingangsanwendung
Damals waren Microservices bereits in aller Munde und SOA wurde 5 Jahre lang in großen Projekten eingesetzt, WCF wurde beispielsweise 2006 veröffentlicht. Doch dann entschieden sie sich für eine zuverlässige und bewährte Lösung.
Hier ist es.
Asp.Net MVC ist Razor, das auf Anfrage von einem Formular oder von einem Client eine HTML-Seite mit Server-Rendering rendert. Auf dem Client zeigen CSS- und JS-Skripte bereits Informationen an und führen bei Bedarf AJAX-Anfragen über JQuery aus.
Anfragen auf dem Server landen in den *Controller-Klassen, wo in der Methode die Verarbeitung und Generierung der finalen HTML-Seite erfolgt. Controller stellen Anfragen an eine Logikebene namens *Services. Jede der Dienstleistungen entsprach einem Aspekt des Geschäfts:
-
Beispielsweise gab DepartmentStructureService Informationen zu Pizzerien und zu Abteilungen heraus. Eine Abteilung ist eine Gruppe von Pizzerien, die von einem einzelnen Franchisenehmer betrieben werden.
-
ReceivingOrdersService hat die Zusammensetzung der Bestellung angenommen und berechnet.
-
Und SmsService sendete SMS, indem es API-Dienste aufrief, um SMS zu senden.
Die Dienste verarbeiten Daten aus der Datenbank und speichern die Geschäftslogik. Jeder Dienst verfügte über ein oder mehrere *Repositories mit dem entsprechenden Namen. Sie enthielten bereits Abfragen an gespeicherte Prozeduren in der Datenbank und eine Ebene von Mappern. Es gab Geschäftslogik in den Speichern, insbesondere in denen, die Berichtsdaten herausgaben. ORM wurde nicht verwendet, alle verließen sich auf handgeschriebenes SQL.
Es gab auch eine Ebene des Domänenmodells und allgemeine Hilfsklassen, beispielsweise die Order-Klasse, die die Bestellung speicherte. An der gleichen Stelle, im Layer, gab es einen Helfer zum Umrechnen des Anzeigetextes entsprechend der gewählten Währung.
All dies kann durch ein solches Modell dargestellt werden:
Bestellweg
Betrachten Sie eine vereinfachte anfängliche Möglichkeit, eine solche Bestellung zu erstellen.
Ursprünglich war die Website statisch. Darauf standen Preise und darüber eine Telefonnummer und die Aufschrift „Wenn Sie Pizza möchten, rufen Sie die Nummer an und bestellen Sie“. Zum Bestellen müssen wir einen einfachen Ablauf implementieren:
-
Der Kunde besucht eine statische Website mit Preisen, wählt Produkte aus und ruft die auf der Website aufgeführte Nummer an.
-
Der Kunde benennt die Produkte, die er der Bestellung hinzufügen möchte.
-
Gibt seine Adresse und seinen Namen an.
-
Der Betreiber nimmt die Bestellung an.
-
Die Bestellung wird in der Schnittstelle „Akzeptierte Bestellungen“ angezeigt.
Alles beginnt mit der Anzeige des Menüs. Ein angemeldeter Benutzer-Betreiber nimmt jeweils nur eine Bestellung an. Daher kann der Entwurfswagen in seiner Sitzung gespeichert werden (die Sitzung des Benutzers wird im Speicher gespeichert). Es gibt ein Cart-Objekt, das Produkte und Kundeninformationen enthält.
Der Kunde benennt das Produkt, der Betreiber klickt darauf + neben dem Produkt und eine Anfrage wird an den Server gesendet. Informationen zum Produkt werden aus der Datenbank entnommen und Informationen zum Produkt in den Warenkorb gelegt.
Beachten. Ja, hier kann man das Produkt nicht aus der Datenbank ziehen, sondern vom Frontend übertragen. Der Übersichtlichkeit halber habe ich jedoch genau den Pfad aus der Datenbank angezeigt.
Geben Sie als Nächstes die Adresse und den Namen des Kunden ein.
Wenn Sie auf „Bestellung erstellen“ klicken:
-
Die Anfrage wird an OrderController.SaveOrder() gesendet.
-
Wir erhalten den Warenkorb aus der Sitzung, es sind Produkte in der Menge vorhanden, die wir benötigen.
-
Wir ergänzen den Warenkorb mit Informationen über den Kunden und übergeben ihn an die AddOrder-Methode der ReceivingOrderService-Klasse, wo er in der Datenbank gespeichert wird.
-
Die Datenbank enthält Tabellen mit der Bestellung, der Zusammensetzung der Bestellung und dem Kunden, die alle miteinander verbunden sind.
-
Die Auftragsanzeigeschnittstelle ruft die neuesten Bestellungen ab und zeigt sie an.
Neue Module
Die Annahme der Bestellung war wichtig und notwendig. Sie können kein Pizzageschäft betreiben, wenn Sie keinen Auftrag zum Verkauf haben. Daher begann das System etwa von 2012 bis 2015 seine Funktionalität zu erlangen. In dieser Zeit erschienen viele verschiedene Blöcke des Systems, die ich nennen werde Module, im Gegensatz zum Konzept der Dienstleistung oder des Produkts.
Ein Modul ist eine Reihe von Funktionen, die durch ein gemeinsames Geschäftsziel verbunden sind. Gleichzeitig befinden sie sich physisch in derselben Anwendung.
Module können als Systemblöcke bezeichnet werden. Dies ist beispielsweise ein Berichtsmodul, Admin-Schnittstellen, , Autorisierung. Dies sind alles unterschiedliche Benutzeroberflächen, einige haben sogar unterschiedliche visuelle Stile. Gleichzeitig befindet sich alles im Rahmen einer Anwendung, eines laufenden Prozesses.
Technisch wurden die Module als Area konzipiert (eine solche Idee blieb sogar bestehen). ). Es gab separate Dateien für das Frontend, die Modelle sowie eigene Controller-Klassen. Infolgedessen wurde das System von diesem ... umgestaltet.
...das mögen:
Einige Module werden aufgrund einer völlig separaten Funktionalität und teilweise aufgrund einer etwas separaten, fokussierteren Entwicklung von separaten Sites (ausführbares Projekt) implementiert. Das:
-
Site - Website dodopizza.ru.
-
Exportieren: Hochladen von Berichten von Dodo IS für 1C.
-
Unsere - Persönliches Konto des Mitarbeiters. Es wurde separat entwickelt und verfügt über einen eigenen Einstiegspunkt und ein separates Design.
-
fs — ein Projekt zum Hosten von Statiken. Später sind wir davon abgewichen und haben die gesamte Statistik auf das Akamai CDN verschoben.
Die restlichen Blöcke befanden sich in der BackOffice-Anwendung.
Namenserklärung:
-
Kassierer - Restaurantkassierer.
-
ShiftManager – Schnittstellen für die Rolle „Shift Manager“: Betriebsstatistiken zu Pizzeriaverkäufen, die Möglichkeit, Produkte auf die Stoppliste zu setzen, die Reihenfolge zu ändern.
-
OfficeManager - Schnittstellen für die Rollen „Pizzeria-Manager“ und „Franchisenehmer“. Hier sind Funktionen zum Einrichten einer Pizzeria, deren Bonusaktionen, Empfang und Zusammenarbeit mit Mitarbeitern sowie Berichte zusammengefasst.
-
PublicScreens – Schnittstellen für Fernseher und Tablets, die in Pizzerien hängen. Fernseher zeigen Menüs, Werbeinformationen und den Bestellstatus bei Lieferung an.
Sie verwendeten eine gemeinsame Serviceschicht, einen gemeinsamen Dodo.Core-Domänenklassenblock und eine gemeinsame Basis. Manchmal könnten sie noch entlang der Übergänge zueinander führen. Einschließlich einzelner Websites wie dodopizza.ru oder personal.dodopizza.ru ging es um allgemeine Dienste.
Als neue Module erschienen, haben wir versucht, den bereits erstellten Code für Dienste, gespeicherte Prozeduren und Tabellen in der Datenbank maximal wiederzuverwenden.
Zum besseren Verständnis des Umfangs der im System hergestellten Module finden Sie hier ein Diagramm aus dem Jahr 2012 mit Entwicklungsplänen:
Bis 2015 war alles auf der Karte und noch mehr war in Produktion.
-
Die Auftragsannahme hat sich zu einem separaten Block des Contact Centers entwickelt, in dem die Bestellung vom Betreiber angenommen wird.
-
In Pizzerien hingen öffentliche Bildschirme mit Speisekarten und Informationen.
-
Die Küche verfügt über ein Modul, das automatisch die Sprachnachricht „Neue Pizza“ abspielt, wenn eine neue Bestellung eintrifft, und außerdem eine Rechnung für den Kurier ausdruckt. Dies vereinfacht die Abläufe in der Küche erheblich und ermöglicht es den Mitarbeitern, nicht durch eine Vielzahl einfacher Vorgänge abgelenkt zu werden.
-
Die Liefereinheit wurde zu einer separaten Lieferkasse, bei der die Bestellung an den Kurier ausgegeben wurde, der zuvor die Schicht übernommen hatte. Seine Arbeitszeit wurde bei der Lohnabrechnung berücksichtigt.
Parallel dazu traten von 2012 bis 2015 mehr als 10 Entwickler auf, eröffneten 35 Pizzerien, führten das System in Rumänien ein und bereiteten die Eröffnung von Filialen in den Vereinigten Staaten vor. Die Entwickler kümmerten sich nicht mehr um alle Aufgaben, sondern wurden in Teams aufgeteilt. Jeder spezialisierte sich auf seinen eigenen Teil des Systems.
Probleme
Auch wegen der Architektur (aber nicht nur).
Chaos in der Basis
Eine Basis ist praktisch. Konsistenz kann darin erreicht werden, und zwar auf Kosten der in relationalen Datenbanken integrierten Tools. Die Arbeit damit ist vertraut und komfortabel, insbesondere wenn nur wenige Tabellen und Daten vorhanden sind.
Aber im Laufe der vierjährigen Entwicklungszeit stellte sich heraus, dass die Datenbank etwa 4 Tabellen und 600 gespeicherte Prozeduren enthielt, von denen viele auch über Logik verfügten. Leider bringen gespeicherte Prozeduren bei der Arbeit mit MySQL keine großen Vorteile. Sie werden nicht von der Basis zwischengespeichert und das Speichern der Logik in ihnen erschwert die Entwicklung und das Debuggen. Auch die Wiederverwendung von Code ist schwierig.
Viele Tabellen verfügten nicht über geeignete IndizesIm Gegenteil, irgendwo gab es viele Indizes, die das Einfügen erschwerten. Es mussten etwa 20 Tabellen geändert werden – die Transaktion zum Erstellen einer Bestellung konnte etwa 3-5 Sekunden dauern.
Die Daten in den Tabellen waren nicht immer in der am besten geeigneten Form. Irgendwo war es notwendig, eine Denormalisierung durchzuführen. Ein Teil der regelmäßig empfangenen Daten lag in einer Spalte in Form einer XML-Struktur vor, was die Ausführungszeit erhöhte, die Abfragen verlängerte und die Entwicklung erschwerte.
Dazu wurden sehr viele Tische hergestellt heterogene Anfragen. Beliebte Tische litten besonders darunter, wie der oben erwähnte Tisch. Bestellungen oder Tische Pizzeria. Sie dienten zur Darstellung betrieblicher Schnittstellen in der Küche, Analytik. Eine andere Website hat sie kontaktiert (), wo jederzeit plötzlich viele Anfragen eingehen könnten.
Die Daten wurden nicht aggregiert und viele Berechnungen fanden spontan mithilfe der Basis statt. Dies führte zu unnötigen Berechnungen und zusätzlicher Belastung.
Oftmals wurde der Code in die Datenbank übernommen, obwohl dies nicht möglich war. Irgendwo gab es nicht genügend Massenoperationen, irgendwo wäre es notwendig, eine Anfrage über den Code auf mehrere aufzuteilen, um die Geschwindigkeit zu erhöhen und die Zuverlässigkeit zu erhöhen.
Zusammenhalt und Verschleierung im Code
Module, die für ihren Teil des Geschäfts verantwortlich sein sollten, haben es nicht ehrlich getan. Einige von ihnen hatten doppelte Funktionen für Rollen. Beispielsweise musste ein lokaler Vermarkter, der für die Marketingaktivitäten des Netzwerks in seiner Stadt verantwortlich ist, sowohl die „Admin“-Schnittstelle (um Werbeaktionen zu erstellen) als auch die „Büromanager“-Schnittstelle (um die Auswirkungen von Werbeaktionen auf das Unternehmen anzuzeigen) verwenden. Natürlich wurde in beiden Modulen derselbe Service genutzt, der auch mit Bonusaktionen funktionierte.
Dienste (Klassen innerhalb eines monolithischen Großprojekts) könnten sich gegenseitig aufrufen, um ihre Daten anzureichern.
Mit den Modellklassen selbst, die Daten speichern, Die Arbeit im Code wurde anders durchgeführt. Irgendwo gab es Konstruktoren, mit denen es möglich war, erforderliche Felder anzugeben. Irgendwo geschah dies über öffentliche Grundstücke. Natürlich war das Abrufen und Transformieren von Daten aus der Datenbank vielfältig.
Die Logik befand sich entweder in den Controllern oder in den Serviceklassen.
Dies scheinen geringfügige Probleme zu sein, aber sie verlangsamten die Entwicklung erheblich und minderten die Qualität, was zu Instabilität und Fehlern führte.
Die Komplexität einer großen Entwicklung
Bei der Entwicklung selbst traten Schwierigkeiten auf. Es war notwendig, verschiedene Blöcke des Systems parallel zu erstellen. Es wurde immer schwieriger, die Anforderungen jeder Komponente in einen einzigen Code zu integrieren. Es war nicht einfach, allen Beteiligten gleichzeitig zuzustimmen und sie zufrieden zu stellen. Hinzu kamen technische Einschränkungen, insbesondere im Hinblick auf Basis und Frontend. Es war notwendig, jQuery auf High-Level-Frameworks umzustellen, insbesondere im Hinblick auf Client-Dienste (Website).
In einigen Teilen des Systems könnten hierfür besser geeignete Datenbanken verwendet werden.. Später hatten wir beispielsweise den Anwendungsfall, von Redis zu CosmosDB zu wechseln, um einen Bestellkorb zu speichern.
Die in ihrem Bereich tätigen Teams und Entwickler wünschten sich eindeutig mehr Autonomie für ihre Dienste, sowohl in Bezug auf die Entwicklung als auch auf den Rollout. Konflikte zusammenführen, Probleme freigeben. Wenn dieses Problem für 5 Entwickler unbedeutend ist, dann würde mit 10 und noch mehr mit dem geplanten Wachstum alles ernster werden. Und vor uns stand die Entwicklung einer mobilen Anwendung (sie begann im Jahr 2017 und im Jahr 2018). ).
Verschiedene Teile des Systems erforderten unterschiedliche Stabilitätsniveaus, aber aufgrund der starken Konnektivität des Systems konnten wir dies nicht bereitstellen. Ein Fehler bei der Entwicklung einer neuen Funktion im Admin-Panel könnte durchaus bei der Annahme einer Bestellung auf der Seite passiert sein, denn der Code ist allgemein und wiederverwendbar, auch die Datenbank und die Daten sind gleich.
Diese Fehler und Probleme ließen sich im Rahmen einer solchen monolithisch-modularen Architektur vermutlich vermeiden: Verantwortlichkeiten aufteilen, sowohl den Code als auch die Datenbank umgestalten, die Schichten klar voneinander trennen, die Qualität täglich überwachen. Doch die gewählten Architekturlösungen und der Fokus auf eine schnelle Erweiterung der Funktionalität des Systems führten zu Problemen hinsichtlich der Stabilität.
Wie der Blog „Power of the Mind“ die Kassen in Restaurants einführte
Würde das Wachstum des Pizzerianetzes (und die Auslastung) im gleichen Tempo weitergehen, wären die Rückgänge nach einer Weile so groß, dass das System nicht mehr steigen würde. Hier ist eine solche Geschichte, die die Probleme veranschaulicht, mit denen wir ab 2015 konfrontiert waren.
Im Blog „„war ein Widget, das Daten zum Jahresumsatz des gesamten Netzwerks anzeigte. Das Widget hat auf die öffentliche Dodo-API zugegriffen, die diese Daten bereitstellt. Diese Statistik ist derzeit verfügbar unter . Das Widget wurde auf jeder Seite angezeigt und stellte alle 20 Sekunden zeitgesteuert Anfragen. Die Anfrage ging an api.dodopizza.ru und forderte:
-
die Anzahl der Pizzerien im Netzwerk;
-
Gesamter Netzwerkumsatz seit Jahresbeginn;
-
Einnahmen für heute.
Die Anfrage nach Umsatzstatistiken ging direkt an die Datenbank und begann, Daten zu Bestellungen anzufordern, Daten spontan zu aggregieren und den Betrag auszugeben.
Kassen in Restaurants gingen an denselben Bestelltisch, lud eine Liste der für heute eingegangenen Bestellungen ab und fügte neue Bestellungen hinzu. Registrierkassen stellten ihre Anfragen alle 5 Sekunden oder bei der Seitenaktualisierung.
Das Diagramm sah so aus:
Eines Herbstes schrieb Fjodor Owtschinnikow einen langen und beliebten Artikel auf seinem Blog. Viele Leute kamen zum Blog und begannen, alles sorgfältig zu lesen. Während jeder der Anwesenden den Artikel las, funktionierte das Umsatz-Widget ordnungsgemäß und forderte alle 20 Sekunden die API an.
Die API rief eine gespeicherte Prozedur auf, um die Summe aller Bestellungen seit Jahresbeginn für alle Pizzerien im Netzwerk zu berechnen. Die Aggregation basierte auf der sehr beliebten Auftragstabelle. Alle Kassen aller zu diesem Zeitpunkt geöffneten Restaurants gehen dorthin. Kassen reagierten nicht mehr, Bestellungen wurden nicht angenommen. Sie wurden auch nicht von der Website akzeptiert, erschienen nicht auf dem Tracker, der Schichtleiter konnte sie in seiner Benutzeroberfläche nicht sehen.
Dies ist nicht die einzige Geschichte. Im Herbst 2015 war die Belastung des Systems jeden Freitag kritisch. Mehrmals haben wir die öffentliche API abgeschaltet, und einmal mussten wir sogar die Website abschalten, weil nichts geholfen hat. Es gab sogar eine Liste von Diensten mit einer Abschaltanordnung bei hoher Belastung.
Von nun an beginnt unser Kampf mit Belastungen und um die Stabilisierung des Systems (von Herbst 2015 bis Herbst 2018). Da ist es passiert“". Darüber hinaus kam es manchmal auch zu Ausfällen, einige davon waren sehr empfindlich, doch die allgemeine Zeit der Instabilität kann mittlerweile als vorbei betrachtet werden.
Schnelles Geschäftswachstum
Warum konnte es nicht sofort erledigt werden? Schauen Sie sich einfach die folgenden Diagramme an.
Auch in den Jahren 2014-2015 gab es eine Eröffnung in Rumänien und eine Eröffnung in den USA war in Vorbereitung.
Das Netzwerk wuchs sehr schnell, neue Länder wurden erschlossen, neue Pizzeriaformate entstanden, zum Beispiel wurde eine Pizzeria am Food Court eröffnet. All dies erforderte besondere Aufmerksamkeit insbesondere für die Erweiterung der Dodo IS-Funktionen. Ohne all diese Funktionen, ohne die Nachverfolgung in der Küche, die Erfassung von Produkten und Verlusten im System, die Anzeige der Auftragserteilung in der Food-Court-Halle, würden wir kaum über die „richtige“ Architektur und die „richtige“ Vorgehensweise sprechen Entwicklung jetzt.
Ein weiteres Hindernis für die rechtzeitige Überarbeitung der Architektur und die allgemeine Berücksichtigung technischer Probleme war die Krise von 2014. Solche Dinge beeinträchtigen die Wachstumschancen von Teams erheblich, insbesondere für ein junges Unternehmen wie Dodo Pizza.
Schnelle Lösungen, die geholfen haben
Probleme brauchten Lösungen. Konventionell lassen sich Lösungen in 2 Gruppen einteilen:
-
Schnelle Maßnahmen, die das Feuer löschen, einen kleinen Sicherheitsspielraum bieten und uns Zeit zum Umziehen verschaffen.
-
Systemisch und daher lang. Reengineering einer Reihe von Modulen, Aufteilung einer monolithischen Architektur in separate Dienste (die meisten davon sind überhaupt keine Mikro-, sondern Makrodienste, und da ist etwas dran ).
Die trockene Liste der schnellen Änderungen lautet wie folgt:
Basismaster hochskalieren
Um die Belastung zu bewältigen, muss natürlich zunächst die Kapazität des Servers erhöht werden. Dies wurde für die Masterdatenbank und für Webserver durchgeführt. Leider ist dies nur bis zu einer gewissen Grenze möglich, dann wird es zu teuer.
Seit 2014 sind wir auf Azure umgestiegen, über dieses Thema haben wir damals auch im Artikel „". Doch nach einer Reihe von Servererhöhungen für die Basis mussten sie mit den Kosten rechnen.
Basisrepliken zum Lesen
Für den Sockel wurden zwei Nachbildungen angefertigt:
ReadReplica für Referenzanfragen. Es wird zum Lesen von Verzeichnissen, Typ, Stadt, Straße, Pizzeria, Produkten (langsam geänderte Domäne) und in solchen Schnittstellen verwendet, bei denen eine kleine Verzögerung akzeptabel ist. Es gab 2 dieser Repliken, wir haben ihre Verfügbarkeit auf die gleiche Weise wie die Master sichergestellt.
ReadReplica für Berichtsanfragen. Diese Datenbank hatte eine geringere Verfügbarkeit, aber alle Berichte gingen dorthin. Es kann sein, dass sie große Anforderungen an Neuberechnungen großer Datenmengen haben, die jedoch keine Auswirkungen auf die Hauptdatenbank und die Betriebsschnittstellen haben.
Caches im Code
Es gab (überhaupt) nirgendwo im Code Caches. Dies führte zu zusätzlichen, nicht immer notwendigen Anfragen an die geladene Datenbank. Caches befanden sich zunächst sowohl im Arbeitsspeicher als auch in einem externen Cache-Dienst, nämlich Redis. Alles wurde mit der Zeit ungültig, die Einstellungen wurden im Code angegeben.
Mehrere Backend-Server
Auch das Backend der Anwendung musste skaliert werden, um die erhöhte Arbeitslast bewältigen zu können. Es war notwendig, einen Cluster aus einem IIS-Server zu erstellen. Wir haben einen neuen Termin festgelegt vom Speicher zum RedisCache, was es ermöglichte, mehrere Server hinter einem einfachen Load Balancer mit Round Robin zu betreiben. Zunächst wurde das gleiche Redis wie für Caches verwendet, dann wurde es in mehrere aufgeteilt.
Dadurch ist die Architektur komplizierter geworden ...
… aber ein Teil der Spannung wurde beseitigt.
Und dann war es notwendig, die geladenen Komponenten zu wiederholen, was wir vorgenommen haben. Darüber werden wir im nächsten Teil sprechen.
Source: habr.com