Oder jedes unglückliche Unternehmen ist auf seine eigene Weise unglücklich.
Die Entwicklung des Dodo IS-Systems begann gleichzeitig mit dem Geschäft von Dodo Pizza — im Jahr 2011. Im Kern stand die Idee der vollständigen und totalen Digitalisierung von Geschäftsprozessen, wobei , was bereits 2011 viele Fragen und Skepsis aufwarf. Doch nun sind wir seit 9 Jahren auf diesem Weg — mit einer eigenen Entwicklung, die als Monolith begann.
Dieser Artikel ist eine „Antwort“ auf die Fragen „Warum die Architektur neu schreiben und solch umfangreiche und langwierige Änderungen vornehmen?“ auf den vorherigen Artikel . Ich beginne damit, wie die Entwicklung von Dodo IS begann, wie die ursprüngliche Architektur aussah, wie neue Module entstanden und welche Probleme zu umfangreichen Änderungen führten.
Die Artikelserie „Was ist Dodo IS?“ wird erzählen über:
Der frühe Monolith in Dodo IS (2011-2015 Jahre). (Hier sind Sie)
.
Der Weg des Kundenbereichs: Fassade über der Datenbank (2016-2017). (In Bearbeitung…)
Die Geschichte echter Mikrodienste. (2018-2019). (In Bearbeitung…)
Abgeschlossene Zerlegung des Monolithen und Stabilisierung der Architektur. (In Bearbeitung…)
Die ursprüngliche Architektur
Im Jahr 2011 sah die Architektur von Dodo IS so aus:
Das erste Modul in der Architektur ist die Bestellannahme. Der Geschäftsprozess war folgendermaßen:
Der Kunde ruft die Pizzeria an;
der Manager nimmt das Telefon ab;
nimmt die Bestellung am Telefon entgegen;
gleichzeitig gibt er sie im Bestellannahme-Interface ein: Die Informationen über den Kunden, die Bestelldetails und die Lieferadresse werden erfasst.
Das Interface des Informationssystems sah ungefähr so aus…
Die erste Version von Oktober 2011:
Die Ressourcen für die Entwicklung des ersten Moduls zur Bestellannahme waren begrenzt. Es musste viel, schnell und mit einem kleinen Team erledigt werden. Ein kleines Team bedeutet 2 Entwickler, die das Fundament des gesamten zukünftigen Systems gelegt haben.
Ihre erste Entscheidung prägte das weitere Schicksal des technologischen Stacks:
Backend auf ASP.NET MVC, Sprache C#. Die Entwickler waren .NET-Experten, dieser Stack war ihnen vertraut und angenehm.
Frontend auf Bootstrap und JQuery: Nutzeroberflächen mit selbstgeschriebenen Stilen und Skripten.
Datenbank MySQL: ohne Lizenzkosten, einfach zu bedienen.
Server auf Windows Server, da .NET damals nur unter Windows verfügbar war (Mono lassen wir außen vor).
Physisch äußerte sich das alles in einem dedizierten Server beim Anbieter.
Architektur der Bestellannahme-Anwendung
Damals sprach jeder von Mikroservices, während SOA bereits seit etwa 5 Jahren in großen Projekten verwendet wurde. Zum Beispiel wurde WCF 2006 eingeführt. Dennoch entschied man sich für eine bewährte und zuverlässige Lösung.
Hier ist es.
Asp.Net MVC ist Razor, das auf Anfrage von einem Formular oder vom Client eine HTML-Seite mit serverseitigem Rendering liefert. Auf dem Client werden CSS und JS-Skripte eingesetzt, um Informationen darzustellen und bei Bedarf AJAX-Anfragen über JQuery auszuführen.
Serveranfragen gelangen in Klassen *Controller, wo die Verarbeitung und Generierung der finalen HTML-Seite in einer Methode erfolgt. Die Controller stellen Anfragen an die Logikschicht, die *Services genannt wird. Jeder dieser Services ist für einen bestimmten Aspekt des Geschäfts zuständig:
Zum Beispiel lieferte der DepartmentStructureService Informationen über Pizzerien und Abteilungen. Eine Abteilung ist eine Gruppe von Pizzerien, die von einem Franchisenehmer verwaltet wird.
ReceivingOrdersService nahm die Bestellungen entgegen und berechnete deren Inhalt.
Der SmsService versendete SMS, indem er API-Services für den SMS-Versand aufrief.
Die Dienste verarbeiteten Daten aus der Datenbank und speicherten die Geschäftslogik. Jeder Dienst verfügte über ein oder mehrere *Repository mit entsprechenden Bezeichnungen. Darin befanden sich bereits Abfragen für gespeicherte Prozeduren in der Datenbank sowie eine Mapper-Schicht. In den Speicherprozeduren war die Geschäftslogik implementiert, insbesondere in denjenigen, die Berichtsdaten auslieferten. ORM wurde nicht verwendet; alle vertrauten auf selbstgeschriebenen SQL-Code.
Es gab auch eine Schicht der Domänenmodellierung und allgemeine Hilfsklassen, wie z.B. die Klasse Order, die den Auftrag speicherte. Auch in dieser Schicht befand sich ein Helfer zur Umwandlung des Darstellungstextes je nach gewählter Währung.
All dies kann durch folgendes Modell veranschaulicht werden:
Bestellweg
Betrachten wir den vereinfachten ursprünglichen Prozess zur Erstellung einer solchen Bestellung.
Ursprünglich war die Website statisch. Dort waren die Preise aufgeführt, und oben stand eine Telefonnummer mit dem Hinweis „Willst du Pizza? Ruf die Nummer an und bestelle.“ Für die Bestellung müssen wir einen einfachen Ablauf umsetzen:
Der Kunde besucht die statische Website mit den Preisen, wählt Produkte aus und ruft die Nummer an, die auf der Website angegeben ist.
Der Kunde nennt die Produkte, die er zur Bestellung hinzufügen möchte.
Er nennt seine Adresse und seinen Namen.
Der Operator nimmt die Bestellung entgegen.
Die Bestellung wird in der Benutzeroberfläche der angenommenen Bestellungen angezeigt.
Alles beginnt mit der Anzeige des Menüs. Ein angemeldeter Benutzer-Operator kann zu einem bestimmten Zeitpunkt nur eine Bestellung annehmen. Daher kann der Entwurf-Warenkorb in seiner Sitzung gespeichert werden (die Benutzersitzung wird im Speicher gehalten). Darin befindet sich das Objekt Cart, das Produkte und Informationen über den Kunden enthält.
Der Kunde nennt das Produkt, der Operator klickt auf + neben dem Produkt, und eine Anfrage wird an den Server gesendet. Die Informationen zu dem Produkt werden aus der Datenbank abgerufen und die Produktinformationen werden dem Warenkorb hinzugefügt.
Hinweis. Ja, hier kann das Produkt auch über das Frontend übergeben werden, aber zur Veranschaulichung habe ich den Weg über die Datenbank gezeigt.
Anschließend geben wir die Adresse und den Namen des Kunden ein.
Beim Drücken von „Auftrag erstellen“:
Wird die Anfrage an OrderController.SaveOrder() gesendet.
Wir erhalten den Cart aus der Sitzung, dort liegen die Produkte in der benötigten Menge.
Wir ergänzen den Cart mit den Informationen des Kunden und übergeben ihn an die Methode AddOrder der Klasse ReceivingOrderService, wo er in der Datenbank gespeichert wird.
In der Datenbank gibt es Tabellen mit der Bestellung, dem Bestellinhalt, dem Kunden, und diese sind alle miteinander verbunden.
Die Benutzeroberfläche zur Anzeige der Bestellung ruft die letzten Bestellungen ab und zeigt sie an.
Neue Module
Die Annahme von Bestellungen war wichtig und notwendig. Ein Pizzaverkauf ohne Bestellannahme ist nicht möglich. Daher begann das System, sich zwischen 2012 und 2015 weiterzuentwickeln. In dieser Zeit entstanden viele verschiedene Systemblöcke, die ich als Module, im Gegensatz zum Konzept eines Dienstes oder Produkts, bezeichnen werde.
Ein Modul ist eine Funktionseinheit, die mit einem gemeinsamen Geschäftsziel verknüpft ist. Physisch befinden sie sich jedoch in einer Anwendung.
Module können als Systemblöcke betrachtet werden. Zum Beispiel gibt es ein Modul für Berichte, Admin-Interfaces, , Authentifizierung. All diese sind unterschiedliche Benutzeroberflächen, einige haben sogar verschiedene visuelle Stile. Dennoch sind sie alle Teil einer einzigen Anwendung und eines gemeinsamen Prozesses.
Technisch wurden die Module als Area gestaltet (diese Idee findet sich sogar in ). Hier gab es separate Dateien für das Frontend, Modelle sowie eigene Controller-Klassen. Schließlich wandelte sich das System von einem…
…zu einem solchen:
Einige Module werden von separaten Websites (ausführbares Projekt) realisiert, aufgrund völlig unterschiedlicher Funktionen und teilweise wegen einer fokussierter entwickelten Umsetzung. Dies sind:
Website — der Website dodopizza.ru.
Export: Export von Berichten aus Dodo IS für 1C.
Personal — persönliches Mitarbeiter-Dashboard. Wurde separat entwickelt und hat einen eigenen Zugang sowie ein individuelles Design.
fs — Projekt für das Hosting von statischen Inhalten. Später haben wir davon abgesehen und alle statischen Inhalte auf das CDN Akamai migriert.
Die anderen Blöcke waren in der BackOffice-Anwendung untergebracht.
Erklärung zu den Bezeichnungen:
Cashier — Kasse des Restaurants.
ShiftManager — Schnittstellen für die Rolle "Schichtmanager": оперативная Statistiken über den Verkauf der Pizzeria, die Möglichkeit, Produkte auf die Stop-Liste zu setzen, Bestellung zu ändern.
OfficeManager — Schnittstellen für die Rollen "Pizzeria-Manager" und "Franchisenehmer". Hier sind die Funktionen zur Einrichtung der Pizzeria, ihrer Bonusaktionen sowie zur Verwaltung und Berichterstattung über Mitarbeiter gesammelt.
PublicScreens — Schnittstellen für Fernseher und Tablets, die in Pizzerien hängen. Auf den Fernsehern wird das Menü, Werbeinformationen und der Status der Bestellungen angezeigt.
Sie verwendeten eine gemeinsame Service-Schicht, einen gemeinsamen Block von Domain-Klassen Dodo.Core sowie eine gemeinsame Datenbank. Manchmal konnten sie auch zwischen den einzelnen Modulen hin und her navigieren, einschließlich des Zugriffs auf gemeinsame Dienste von separaten Websites wie dodopizza.de oder personal.dodopizza.de.
Bei der Einführung neuer Module wurde versucht, den bereits erstellten Code von Diensten, gespeicherten Prozeduren und Tabellen in der Datenbank maximal wiederzuverwenden.
Um das Ausmaß der in der System entwickelten Module besser zu verstehen, sehen Sie hier ein Schema aus dem Jahr 2012 mit Entwicklungsplänen:
Bis 2015 war alles im Schema und sogar mehr in der Produktion.
Die Bestellannahme entwickelte sich zu einem separaten Block des Kontaktcenters, in dem die Bestellungen von einem Operator entgegengenommen werden.
Es wurden öffentliche Bildschirme mit Menüs und Informationen eingerichtet, die in den Pizzerien aufgehängt sind.
In der Küche gibt es ein Modul, das automatisch die sprachliche Nachricht „Neue Pizza“ abspielt, wenn eine neue Bestellung eingeht, und auch einen Lieferschein für den Kurier druckt. Dies vereinfacht die Prozesse in der Küche erheblich und ermöglicht es den Mitarbeitern, sich nicht mit einer Vielzahl von einfachen Aufgaben ablenken zu lassen.
Der Zustellblock wurde zu einer separaten Lieferkasse, wo die Bestellung an den Kurier übergeben wurde, der sich zuvor für seine Schicht gemeldet hatte. Seine Arbeitszeit wurde zur Gehaltsabrechnung berücksichtigt.
Parallel dazu entstanden zwischen 2012 und 2015 mehr als 10 Entwickler, 35 Pizzerien wurden eröffnet, das System wurde in Rumänien implementiert und die Eröffnung von Standorten in den USA vorbereitet. Die Entwickler waren nicht mehr mit allen Aufgaben betraut, sondern in Teams aufgeteilt, wobei jedes Team sich auf seinen Teil des Systems spezialisierte.
Die Probleme
Weshalb auch aufgrund der Architektur (aber nicht nur).
Chaos in der Datenbank
Eine Datenbank ist praktisch. Man kann Konsistenz erreichen, insbesondere durch Mittel, die in relationale Datenbanken integriert sind. Die Arbeit mit ihr ist gewohnt und angenehm, besonders wenn es wenige Tabellen und wenig Daten gibt.
Aber nach 4 Jahren Entwicklung gab es in der Datenbank etwa 600 Tabellen und 1500 gespeicherte Prozeduren, viele davon enthielten sogar Logik. Leider bringen gespeicherte Prozeduren bei der Arbeit mit MySQL keine besonderen Vorteile. Sie werden nicht von der Datenbank zwischengespeichert, und die Speicherung von Logik darin erschwert die Entwicklung und das Debugging. Die Wiederverwendung von Code ist ebenfalls erschwert.
Viele Tabellen hatten keine geeigneten Indizes., wo es viele Indizes gab, die das Einfügen erschwerten. Etwa 20 Tabellen mussten modifiziert werden – die Transaktion zur Erstellung einer Bestellung konnte etwa 3-5 Sekunden in Anspruch nehmen.
Die Daten in den Tabellen waren nicht immer in der geeignetsten Form.. An einigen Stellen war eine Denormalisierung erforderlich. Ein Teil der regelmäßig abgerufenen Daten lag in einer XML-Struktur in einer Spalte vor, was die Ausführungszeit verlängerte, die Abfragen komplizierter machte und die Entwicklung erschwerte.
Für dieselben Tabellen wurden sehr heterogene Abfragen. Besonders litten die beliebten Tabellen, wie die erwähnte Tabelle orders oder die Tabelle pizzeria. Sie wurden für die Anzeige von operativen Schnittstellen in der Küche und für Analysen verwendet. Auch die Website, die jederzeit unerwartet viele Anfragen erhalten konnte.
Die Daten waren nicht aggregiert und viele Berechnungen fanden in Echtzeit mit Mitteln der Datenbank statt. Das erzeugte überflüssige Berechnungen und zusätzliche Last.
Oft wurde die Datenbank aufgerufen, obwohl dies nicht notwendig war. An einigen Stellen fehlten Bulk-Operationen, an anderen hätte man eine Anfrage auf mehrere verteilen müssen, um die Geschwindigkeit zu erhöhen und die Zuverlässigkeit zu verbessern.
Zusammenhang und Verwirrung im Code
Module, die für ihren Geschäftsbereich verantwortlich sein sollten, haben dies nicht ordnungsgemäß getan.. Einige von ihnen hatten funktionale Überschneidungen für verschiedene Rollen. Zum Beispiel musste der lokale Marketingmitarbeiter, der für die Marketingaktivitäten im Netzwerk in seiner Stadt zuständig war, sowohl die Admin-Schnittstelle (für die Erstellung von Aktionen) als auch die Schnittstelle des Büromanager (für die Auswertung der Auswirkungen von Aktionen auf das Geschäft) nutzen. Natürlich verwendeten beide Module intern denselben Service, der mit den Bonusaktionen arbeitete.
Die Services (Klassen innerhalb eines monolithischen großen Projekts) konnten sich gegenseitig aufrufen, um ihre Daten anzureichern.
Mit den Klassenmodellen, die Daten speichern, wurde im Code unterschiedlich gearbeitet.. An manchen Stellen gab es Konstruktoren, über die man die Pflichtfelder angeben konnte. An anderen Stellen geschah dies über öffentliche Eigenschaften. Natürlich war das Abrufen und Verarbeiten von Daten aus der Datenbank unterschiedlich.
Die Logik lag entweder in den Controllern oder in den Serviceklassen.
Das mögen kleine Probleme erscheinen, aber sie haben die Entwicklung stark verlangsamt und die Qualität gesenkt, was zu Instabilität und Fehlern führte.
Die Komplexität großer Entwicklungen.
Es gab Herausforderungen bereits in der Entwicklung selbst.. Es musste an verschiedenen Systemblöcken gleichzeitig gearbeitet werden. Die Bedürfnisse jedes einzelnen Bausteins in einen einheitlichen Code zu integrieren, wurde immer schwieriger. Es war nicht einfach, sich zu einigen und allen Komponenten gleichzeitig gerecht zu werden. Hinzu kamen technologische Einschränkungen, insbesondere im Hinblick auf die Datenbank und das Frontend. Wir mussten aufhören, JQuery zu verwenden und auf hochrangige Frameworks umzusteigen, insbesondere im Bereich der Client-Services (Website).
In einigen Teilen des Systems hätten Datenbanken verwendet werden können, die besser geeignet wären.. Zum Beispiel hatten wir später einen Fall, in dem wir von Redis zu CosmosDB gewechselt sind, um den Warenkorb zu speichern.
Teams and developers in their respective fields clearly sought greater autonomy for their services, both in terms of development and deployment. Merge conflicts and issues during releases became prevalent. While this may not have been a significant problem for five developers, it escalated with ten, especially in light of planned growth. Ahead lay the development of a mobile application (which started in 2017 and in 2018 there was ).
Different parts of the system required different stability metrics, but due to the strong interconnectivity of the system, we were unable to ensure this. An error during the development of a new feature in the admin panel could easily affect order processing on the website, since the code is shared and reusable, and the database and data are also unified.
Es wäre wahrscheinlich möglich gewesen, innerhalb einer solchen monolithisch-modularen Architektur diese Fehler und Probleme zu vermeiden: Verantwortlichkeiten klar zu trennen, sowohl den Code als auch die Datenbank regelmäßig zu refaktorisieren, die Schichten klar voneinander zu halten und täglich auf die Qualität zu achten. Doch die getroffenen architektonischen Entscheidungen und der Fokus auf eine schnelle Erweiterung der Systemfunktionen führten zu Stabilitätsproblemen.
Wie der Blog "Kraft des Geistes Kassen in Restaurants eingebracht hat"
Wäre das Wachstum des Pizza-Netzwerks (und der Last) im gleichen Tempo weitergegangen, wären die Ausfälle irgendwann so gravierend geworden, dass das System nicht mehr hochgefahren werden könnte. Eine anschauliche Geschichte, die die Herausforderungen verdeutlicht, mit denen wir ab 2015 konfrontiert waren.
Im Blog "" gab es ein Widget, das die Einnahmen der gesamten Kette für das Jahr anzeigte. Das Widget griff auf die öffentliche API von Dodo zu, die diese Daten bereitstellt. Jetzt ist diese Statistik verfügbar unter . Das Widget wurde auf jeder Seite angezeigt und machte alle 20 Sekunden Anfragen. Die Anfrage wurde an api.dodopizza.ru gesendet und fragte nach:
der Anzahl der Pizzerien im Netzwerk;
den Gesamteinnahmen des Netzwerks seit Jahresbeginn;
den Einnahmen von heute.
Die Anfrage nach den Einnahmen wurde direkt an die Datenbank gesendet, um die Bestelldaten zu sammeln und diese in Echtzeit zu aggregieren und die Summe auszugeben.
In dieselbe Bestelltabelle importierten die Kassen in den Restaurants die Liste der heute angenommenen Bestellungen, und neue Bestellungen wurden ebenfalls hinzugefügt. Die Kassen führten ihre Anfragen alle 5 Sekunden oder bei einer Seitenaktualisierung durch.
Das Schema sah so aus:
Eines Herbsts schrieb Fjodor Owtschinnikow einen langen und beliebten Artikel in seinem Blog. Viele Menschen besuchten den Blog und lasen aufmerksam alles. Während jeder der Besucher den Artikel las, arbeitete das Widget zur Einnahmenüberprüfung und forderte alle 20 Sekunden die API an.
Die API rief eine gespeicherte Prozedur auf, um die Summe aller Bestellungen seit Jahresbeginn in allen Pizzerien der Kette zu berechnen. Die Aggregation erfolgte über die Tabelle 'orders', die sehr beliebt ist. Außerdem greifen alle Kassen aller zu diesem Zeitpunkt geöffneten Restaurants auf diese zu. Die Kassen hörten auf zu reagieren, Bestellungen wurden nicht angenommen. Sie wurden auch nicht über die Website angenommen und erschienen nicht im Tracker; der Schichtleiter konnte sie in seiner Benutzeroberfläche nicht sehen.
Dies ist nicht die einzige Geschichte. Bis zum Herbst 2015 war die Systemlast jeden Freitag kritisch. Mehrfach mussten wir die öffentliche API deaktivieren, und einmal mussten wir sogar die Website abschalten, da nichts mehr half. Es gab sogar eine Liste von Diensten mit einer Reihenfolge der Abschaltung bei schwerwiegenden Lasten.
Von diesem Zeitpunkt an begann unser Kampf gegen die Lasten und für die Stabilisierung des Systems (von Herbst 2015 bis Herbst 2018). Genau dann kam es zu der "". Auch danach gab es gelegentlich Ausfälle, einige waren ziemlich empfindlich, aber die allgemeine Phase der Instabilität kann jetzt als überwunden betrachtet werden.
Starkes Unternehmenswachstum
Warum konnte man nicht "von Anfang an alles richtig machen"? Ein Blick auf die folgenden Grafiken reicht aus.
Außerdem gab es 2014-2015 eine Eröffnung in Rumänien und die Vorbereitung einer Eröffnung in den USA.
Das Netzwerk entwickelte sich sehr schnell, neue Länder wurden erschlossen, neue Formate von Pizzerien kamen hinzu, wie zum Beispiel die Eröffnung einer Pizzeria in einer Food Hall. All dies erforderte erhebliche Aufmerksamkeit für die Weiterentwicklung der Dodo IS-Funktionen. Ohne all diese Funktionen, ohne Küchen-Tracking, Berücksichtigung von Produkten und Verlusten im System, sowie die Anzeige der Auftragsausgabe im Food-Hall-Bereich, wäre es wahrscheinlich nicht möglich gewesen, über die "richtige" Architektur und den "richtigen" Ansatz bei der Entwicklung zu diskutieren.
Ein weiteres Hindernis für eine zeitnahe Überprüfung der Architektur und generell für die Aufmerksamkeit auf technische Probleme war die Krise im Jahr 2014. Solche Ereignisse wirken sich stark auf das Wachstumspotenzial der Teams aus, besonders für ein junges Unternehmen wie Dodo Pizza.
Schnelle Lösungen, die geholfen haben
Die Probleme verlangten nach Lösungen. Man kann die Lösungen grob in zwei Gruppen unterteilen:
Schnelle Lösungen, die das Feuer löschen und einen kleinen Puffer bieten, um uns Zeit für Änderungen zu gewinnen.
Systemische und daher langwierige Lösungen. Die Neugestaltung verschiedener Module, die Aufteilung der monolithischen Architektur in separate Dienste (die meisten von ihnen sind eher Makro- als Mikrodienste, und darüber gibt es) ).
Die Übersicht der schnellen Änderungen lautet wie folgt:
Master-Datenbank skalieren
Natürlich ist der erste Schritt zur Bewältigung von Lasten die Erhöhung der Serverleistung. Dies wurde sowohl für die Master-Datenbank als auch für die Web-Server durchgeführt. Leider ist dies nur bis zu einem gewissen Punkt möglich, danach werden die Kosten zu hoch.
Seit 2014 haben wir auf Azure umgestellt, darüber haben wir zu dieser Zeit auch in dem Artikel "" geschrieben. Nach einer Reihe von Servererhöhungen für die Datenbank sind die Kosten an eine Grenze gestoßen.
Lese-Replikate der Datenbank
Es wurden zwei Replikate für die Datenbank erstellt:
ReadReplica für Abfragen von Verzeichnissen. Es wird verwendet, um Verzeichnisse zu lesen, wie zum Beispiel Städte, Straßen, Pizzerien, Produkte (langsam geänderter Bereich), und in solchen Schnittstellen, wo eine kleine Verzögerung akzeptabel ist. Diese Replikate waren zwei, wir haben ihre Verfügbarkeit genauso sichergestellt wie die der Master-Datenbank.
ReadReplica für Berichtsanfragen. Bei dieser Datenbank war die Verfügbarkeit geringer, aber sie hatte alle Berichte. Auch wenn sie schwere Abfragen für enorme Datenberechnungen haben, wirken sie sich nicht auf die Hauptdatenbank und die operativen Schnittstellen aus.
Caches im Code
Im Code gab es keine Caches (überhaupt). Dies führte zu zusätzlichen, nicht immer erforderlichen Anfragen an die stark belastete Datenbank. Die Caches waren zunächst sowohl im Speicher als auch in einem externen Cache-Dienst, dem Redis, vorhanden. Alle wurden zeitgesteuert invalidiert, die Einstellungen waren im Code angegeben.
Mehrere Server für das Backend
Das Backend der Anwendung musste ebenfalls skaliert werden, um höheren Lasten standzuhalten. Es war notwendig, aus einem IIS-Server ein Cluster zu bilden. Wir haben vom Speicher auf RedisCache umgestellt, was die Einrichtung mehrerer Server hinter einem einfachen Load-Balancer mit Round Robin ermöglichte. Zunächst wurde derselbe Redis wie für die Caches verwendet, später wurde er auf mehrere verteilt.
Letztendlich hat sich die Architektur kompliziert …
…aber ein Teil der Anspannung konnte abgebaut werden.
Als Nächstes mussten die stark belasteten Komponenten überarbeitet werden, wofür wir uns auch eingesetzt haben. Darüber werden wir im nächsten Teil berichten.
Quelle: habr.com
