Habr verändert die Welt. Wir bloggen nun schon seit über einem Jahr. Vor etwa sechs Monaten erhielten wir eine völlig logische Rückmeldung von Chabrowiten: „Dodo, du sagst überall, dass du dein eigenes System hast. Und was ist dieses System? Und warum braucht eine Pizzakette das?
Wir saßen da, dachten nach und erkannten, dass Sie Recht haben. Wir versuchen, alles an unseren Fingern zu erklären, aber es kommt in zerrissenen Teilen heraus und nirgends gibt es eine vollständige Beschreibung des Systems. Damit begann eine lange Reise des Sammelns von Informationen, der Suche nach Autoren und dem Schreiben einer Artikelserie über Dodo IS. Lass uns gehen!
Danksagungen: Vielen Dank, dass Sie Ihr Feedback mit uns geteilt haben. Dank ihm haben wir das System endlich beschrieben, einen technischen Radar erstellt und werden in Kürze eine umfassende Beschreibung unserer Prozesse veröffentlichen. Ohne Sie hätten wir noch weitere 5 Jahre dort gesessen.
Artikelserie „Was ist Dodo IS?“ erzählt über:
- Früher Monolith in Dodo IS (2011–2015). (Im Gange…)
- Der Backoffice-Weg: separate Stützpunkte und Bus. (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...)
Wenn Sie noch etwas wissen möchten, schreiben Sie in die Kommentare.
Meinung des Autors zur chronologischen Beschreibung
Ich veranstalte regelmäßig ein Treffen für neue Mitarbeiter zum Thema „Systemarchitektur“. Wir nennen es „Einführung in die Dodo IS-Architektur“ und es ist Teil des Onboarding-Prozesses für neue Entwickler. Indem ich in der einen oder anderen Form über unsere Architektur und ihre Merkmale berichte, habe ich einen gewissen historischen Ansatz für die Beschreibung entwickelt.
Traditionell betrachten wir das System als eine Reihe von Komponenten (technischer oder höherer Ebene), Geschäftsmodule, die miteinander interagieren, um ein bestimmtes Ziel zu erreichen. Und wenn eine solche Sichtweise gestalterisch gerechtfertigt ist, dann ist sie für die Beschreibung und das Verständnis nicht ganz geeignet. Hier gibt es mehrere Gründe:
- Die Realität unterscheidet sich von dem, was auf dem Papier steht. Nicht alles klappt wie geplant. Und uns interessiert, wie es tatsächlich geworden ist und funktioniert.
- Konsistente Darstellung von Informationen. Tatsächlich können Sie chronologisch vom Anfang bis zum aktuellen Stand vorgehen.
- Von einfach bis komplex. Nicht überall, aber in unserem Fall ist es so. Die Architektur entwickelte sich von einfacheren zu komplexeren Ansätzen. Durch Komplikationen wurden oft Probleme der Implementierungsgeschwindigkeit und -stabilität sowie Dutzende anderer Eigenschaften aus der Liste der nichtfunktionalen Anforderungen gelöst ( gut über die Gegenüberstellung von Komplexität und anderen Anforderungen berichtet).
Im Jahr 2011 sah die Dodo IS-Architektur so aus:
Bis 2020 ist es etwas komplizierter geworden und sieht so aus:
Wie kam es zu dieser Entwicklung? Warum werden verschiedene Teile des Systems benötigt? Welche architektonischen Entscheidungen wurden getroffen und warum? Finden wir es in dieser Artikelserie heraus.
Die ersten Probleme des Jahres 2016: Warum sollten Dienstleistungen den Monolithen verlassen?
In den ersten Artikeln des Zyklus geht es um die Dienste, die sich als erste vom Monolithen lösten. Um Sie in den Kontext zu bringen, erzähle ich Ihnen, welche Probleme wir Anfang 2016 im System hatten, dass wir uns mit der Trennung von Diensten auseinandersetzen mussten.
Eine einzige MySql-Datenbank, in der alle Anwendungen, die zu diesem Zeitpunkt in Dodo IS existierten, ihre Datensätze schrieben. Die Folgen waren:
- Hohe Auslastung (85 % der Anfragen entfielen auf das Lesen).
- Die Basis ist gewachsen. Aus diesem Grund wurden die Kosten und der Support zu einem Problem.
- Der Punkt des Versagens. Wenn eine Anwendung, die in die Datenbank schreibt, dies plötzlich aktiver macht, spüren andere Anwendungen dies.
- Ineffizienz bei Speicherung und Abfragen. Oftmals wurden die Daten in einer Struktur gespeichert, die für einige Szenarien praktisch, für andere jedoch nicht geeignet war. Indizes beschleunigen einige Vorgänge, können andere jedoch verlangsamen.
- Einige der Probleme wurden durch hastig erstellte Caches und Lesereplikate für die Basen behoben (dies wird ein separater Artikel sein), aber sie ermöglichten ihnen nur einen Zeitgewinn und lösten das Problem nicht grundlegend.
Das Problem war die Anwesenheit des Monolithen selbst. Die Folgen waren:
- Einzelne und seltene Veröffentlichungen.
- Schwierigkeiten bei der gemeinsamen Entwicklung einer großen Anzahl von Menschen.
- Unfähigkeit, neue Technologien, neue Frameworks und Bibliotheken einzuführen.
Probleme mit der Basis und dem Monolithen wurden mehrfach beschrieben, beispielsweise im Zusammenhang mit Unfällen Anfang 2018 (, и ), also werde ich nicht zu lange darauf eingehen. Lassen Sie mich nur sagen, dass wir bei der Entwicklung von Dienstleistungen mehr Flexibilität bieten wollten. Dies betraf zunächst diejenigen, die im gesamten System am stärksten belastet und am stärksten verwurzelt waren – Auth und Tracker.
Der Backoffice-Pfad: Getrennte Stützpunkte und Bus
Kapitelnavigation
Monolith-Schema 2016
Hier sind die Hauptblöcke des Dodo IS 2016-Monolithen und direkt darunter eine Abschrift ihrer Hauptaufgaben.
Lieferung an die Kasse. Buchhaltung für Kuriere, Erteilung von Aufträgen an Kuriere.
Kontaktcenter. Annahme von Bestellungen durch den Betreiber.
Site. Unsere Websites (dodopizza.ru, dodopizza.co.uk, dodopizza.by usw.).
Auth. Autorisierungs- und Authentifizierungsdienst für das Backoffice.
Трекер. Bestell-Tracker in der Küche. Service zur Markierung des Bereitschaftsstatus bei der Vorbereitung einer Bestellung.
Kasse des Restaurants. Bestellungen in einem Restaurant entgegennehmen, Kassiererschnittstellen.
Exportieren. Hochladen von Berichten in 1C für die Buchhaltung.
Benachrichtigungen und Rechnungen. Sprachbefehle in der Küche (zum Beispiel „Neue Pizza eingetroffen“) + Rechnungsdruck für Kuriere.
Schichtführer. Schnittstellen für die Arbeit des Schichtleiters: Auftragsliste, Leistungsdiagramme, Überstellung der Mitarbeiter in die Schicht.
Büroleiter. Schnittstellen für die Arbeit des Franchisenehmers und des Managers: Empfang der Mitarbeiter, Berichte über die Arbeit der Pizzeria.
Restaurantanzeigetafel. Menüanzeige auf Fernsehern in Pizzerien.
Administrator. Einstellungen in einer bestimmten Pizzeria: Menü, Preise, Buchhaltung, Aktionscodes, Werbeaktionen, Website-Banner usw.
Persönliches Konto des Mitarbeiters. Arbeitspläne der Mitarbeiter, Informationen über Mitarbeiter.
Motivationstafel für die Küche. Ein separater Bildschirm, der in der Küche hängt und die Geschwindigkeit der Pizzabäcker anzeigt.
Kommunikation. Senden von SMS und E-Mail.
Dateispeicher. Eigener Dienst zum Empfangen und Ausgeben statischer Dateien.
Die ersten Versuche, die Probleme zu lösen, haben uns geholfen, waren aber nur eine vorübergehende Erleichterung. Da es sich nicht um Systemlösungen handelte, war klar, dass mit den Stützpunkten etwas gemacht werden musste. Zum Beispiel, um die allgemeine Datenbank in mehrere spezialisiertere zu unterteilen.
Beginn des Entladens des Monolithen: Auth- und Tracker-Trennung
Die wichtigsten Dienste, die dann mehr als andere aufzeichneten und aus der Datenbank ausliesten:
- Auth. Autorisierungs- und Authentifizierungsdienst für das Backoffice.
- Tracker. Bestell-Tracker in der Küche. Service zur Markierung des Bereitschaftsstatus bei der Vorbereitung einer Bestellung.
Was macht Auth?
Auth ist ein Dienst, über den sich Benutzer im Backoffice anmelden (auf der Clientseite gibt es einen separaten unabhängigen Eingang). In der Anfrage wird außerdem aufgefordert, sicherzustellen, dass die erforderlichen Zugriffsrechte vorhanden sind und sich diese Rechte seit der letzten Anmeldung nicht geändert haben. Dadurch gelangen Geräte in die Pizzeria.
Beispielsweise möchten wir auf dem im Flur hängenden Fernseher eine Anzeige mit den Status abgeschlossener Bestellungen öffnen. Dann öffnen wir auth.dodopizza.ru, wählen „Als Gerät anmelden“, es erscheint ein Code, der auf einer speziellen Seite auf dem Computer des Schichtleiters eingegeben werden kann und den Gerätetyp (Gerät) angibt. Der Fernseher selbst wechselt zur gewünschten Oberfläche seiner Pizzeria und beginnt mit der Anzeige der Namen der Kunden, deren Bestellungen dort bereitstehen.
Woher kommen die Ladungen?
Jeder angemeldete Benutzer des Backoffice geht für jede Anfrage in die Datenbank, in die Benutzertabelle, ruft den Benutzer über eine SQL-Abfrage ab und prüft, ob er über die erforderlichen Zugriffsrechte und Rechte für diese Seite verfügt.
Jedes der Geräte macht dasselbe, nur mit der Gerätetabelle, indem es seine Rolle und seinen Zugriff überprüft. Eine große Anzahl von Anfragen an die Masterdatenbank führt zu deren Überlastung und zur Verschwendung von Ressourcen der gemeinsamen Datenbank für diese Vorgänge.
Auth entladen
Auth hat eine isolierte Domäne, das heißt, Daten über Benutzer, Logins oder Geräte gelangen (vorerst) in den Dienst und bleiben dort. Wenn jemand sie benötigt, wird er sich an diesen Dienst wenden, um Daten zu erhalten.
WAR. Das ursprüngliche Arbeitsschema sah wie folgt aus:
Ich möchte ein wenig erklären, wie es funktioniert hat:
- Eine Anfrage von außen kommt an das Backend (es gibt Asp.Net MVC) und bringt ein Sitzungscookie mit sich, das zum Abrufen von Sitzungsdaten von Redis(1) verwendet wird. Es enthält entweder Informationen über Zugriffe und dann ist der Zugriff auf den Controller offen (3,4) oder nicht.
- Wenn kein Zugriff besteht, müssen Sie das Autorisierungsverfahren durchlaufen. Der Einfachheit halber wird es hier als Teil des Pfads im selben Attribut angezeigt, obwohl es sich um einen Übergang zur Anmeldeseite handelt. Im positiven Fall erhalten wir eine korrekt abgeschlossene Sitzung und gehen zum Backoffice Controller.
- Wenn Daten vorhanden sind, müssen Sie diese auf Relevanz in der Benutzerdatenbank überprüfen. Hat sich seine Rolle geändert, sollte er jetzt nicht auf der Seite zugelassen werden? In diesem Fall müssen Sie nach Erhalt der Sitzung (1) direkt zur Datenbank gehen und den Zugriff des Benutzers mithilfe der Authentifizierungslogikschicht (2) überprüfen. Als nächstes gehen Sie entweder zur Anmeldeseite oder zum Controller. So ein einfaches System, aber nicht ganz Standard.
- Wenn alle Prozeduren bestanden sind, springen wir weiter in die Logik in Controllern und Methoden.
Benutzerdaten werden von allen anderen Daten getrennt und in einer separaten Mitgliedertabelle gespeichert. Funktionen aus der AuthService-Logikschicht können durchaus zu API-Methoden werden. Die Domänengrenzen sind ganz klar definiert: Benutzer, ihre Rollen, Zugangsdaten, Gewährung und Widerruf des Zugriffs. Alles sieht so aus, dass es in einem separaten Service herausgenommen werden kann.
WERDEN. Also taten sie:
Dieser Ansatz weist eine Reihe von Problemen auf. Beispielsweise ist der Aufruf einer Methode innerhalb eines Prozesses nicht dasselbe wie der Aufruf eines externen Dienstes über http. Latenz, Zuverlässigkeit, Wartbarkeit und Transparenz des Betriebs sind völlig unterschiedlich. Andrey Morevskiy ging in seinem Bericht ausführlicher auf solche Probleme ein. .
Der Authentifizierungsdienst und damit der Gerätedienst werden für das Backoffice, also für in der Produktion eingesetzte Dienste und Schnittstellen, eingesetzt. Die Authentifizierung für Client-Dienste (wie eine Website oder eine mobile Anwendung) erfolgt separat ohne Verwendung von Auth. Die Trennung hat etwa ein Jahr gedauert, nun beschäftigen wir uns erneut mit diesem Thema und stellen das System auf neue Authentifizierungsdienste (mit Standardprotokollen) um.
Warum hat die Trennung so lange gedauert?
Unterwegs gab es viele Probleme, die uns ausbremsten:
- Wir wollten Benutzer-, Geräte- und Authentifizierungsdaten aus länderspezifischen Datenbanken in eine übertragen. Dazu mussten wir alle Tabellen und Verwendungen von der int-Kennung in die globale UUId-Kennung übersetzen (dieser Code wurde kürzlich überarbeitet). und Open-Source-Projekt ). Die Speicherung von Benutzerdaten (da es sich um personenbezogene Daten handelt) hat ihre Grenzen und in einigen Ländern ist eine separate Speicherung erforderlich. Aber die globale ID des Benutzers muss sein.
- Viele Tabellen in der Datenbank enthalten Prüfinformationen über den Benutzer, der den Vorgang ausgeführt hat. Dies erforderte einen zusätzlichen Mechanismus für die Konsistenz.
- Nach der Schaffung von API-Diensten gab es eine lange und schrittweise Übergangsphase zu einem anderen System. Der Wechsel musste für die Benutzer reibungslos erfolgen und erforderte manuelle Arbeit.
Geräteregistrierungsschema in einer Pizzeria:
Allgemeine Architektur nach der Extraktion des Authentifizierungs- und Gerätedienstes:
Beachten. Für 2020 arbeiten wir an einer neuen Version von Auth, die auf dem Autorisierungsstandard OAuth 2.0 basiert. Dieser Standard ist recht komplex, aber für die Entwicklung eines Pass-Through-Authentifizierungsdienstes nützlich. Im Artikel "» Wir, Alexey Chernyaev, haben versucht, den Standard so einfach und klar wie möglich zu beschreiben, damit Sie Zeit beim Lernen sparen.
Was macht Tracker?
Nun zum zweiten der geladenen Dienste. Der Tracker übernimmt eine Doppelrolle:
- Seine Aufgabe besteht einerseits darin, den Mitarbeitern in der Küche zu zeigen, welche Aufträge gerade in Bearbeitung sind, welche Produkte jetzt gekocht werden müssen.
- Zum anderen, alle Prozesse in der Küche zu digitalisieren.
Wenn in einer Bestellung ein neues Produkt auftaucht (z. B. Pizza), gelangt es zur Tracker-Station Rollout. An dieser Station steht ein Pizzabäcker, der ein Brötchen in der benötigten Größe nimmt und ausrollt, anschließend auf dem Tracker-Tablet vermerkt, dass er seine Aufgabe erledigt hat und den ausgerollten Teigboden zur nächsten Station – „Initiierung“ – weitergibt. .
Dort füllt der nächste Pizzabäcker die Pizza, vermerkt dann auf dem Tablet, dass er seine Aufgabe erledigt hat und schiebt die Pizza in den Ofen (auch das ist eine eigene Station, die auf dem Tablet vermerkt werden muss). Ein solches System gab es in Dodo von Anfang an und seit Beginn der Existenz von Dodo IS. Damit können Sie alle Transaktionen vollständig verfolgen und digitalisieren. Darüber hinaus schlägt der Tracker vor, wie ein bestimmtes Produkt zubereitet werden soll, leitet jeden Produkttyp entsprechend seinem Herstellungsschema an, speichert die optimale Garzeit für das Produkt und verfolgt alle Vorgänge am Produkt.
So sieht der Bildschirm des Tablets an der Station des Trackers „Raskatka“ aus
Woher kommen die Ladungen?
In jeder Pizzeria gibt es etwa fünf Tablets mit Tracker. Im Jahr 2016 hatten wir mehr als 100 Pizzerien (und jetzt sind es mehr als 600). Jedes der Tablets stellt alle 10 Sekunden eine Anfrage an das Backend und kratzt Daten aus der Bestelltabelle (Verbindung mit dem Kunden und der Adresse), der Bestellzusammensetzung (Verbindung mit dem Produkt und Angabe der Menge), der Motivationsabrechnungstabelle (die der Presszeitpunkt wird darin vermerkt). Wenn ein Pizzabäcker auf dem Tracker auf ein Produkt klickt, werden die Einträge in allen diesen Tabellen aktualisiert. Die Bestelltabelle ist allgemein gehalten, sie enthält auch Einfügungen bei der Annahme einer Bestellung, Aktualisierungen aus anderen Teilen des Systems und zahlreiche Messwerte, beispielsweise auf einem Fernseher, der in einer Pizzeria hängt und den Kunden fertige Bestellungen zeigt.
Während der Zeit des Kampfes mit Lasten, als alles und jedes zwischengespeichert und auf die asynchrone Replik der Basis übertragen wurde, gingen diese Vorgänge mit dem Tracker weiterhin an die Masterbasis. Es sollte keine Verzögerung geben, die Daten sollten aktuell sein, eine Synchronisierung ist nicht akzeptabel.
Außerdem war es aufgrund des Fehlens eigener Tabellen und Indizes nicht möglich, spezifischere, auf ihre Verwendung zugeschnittene Abfragen zu schreiben. Beispielsweise könnte es für einen Tracker effizient sein, einen Index für eine Pizzeria auf einer Bestelltabelle zu haben. Wir entfernen Pizzeria-Bestellungen immer aus der Tracker-Datenbank. Gleichzeitig ist es für den Erhalt einer Bestellung nicht so wichtig, in welche Pizzeria sie gelangt, sondern vielmehr, welcher Kunde diese Bestellung aufgegeben hat. Und bedeutet, dass dort der Index auf dem Client erforderlich ist. Es ist auch nicht erforderlich, dass der Tracker die ID des gedruckten Belegs oder der mit der Bestellung verbundenen Bonusaktionen in der Bestelltabelle speichert. Diese Informationen sind für unseren Tracker-Dienst nicht von Interesse. In einer gemeinsamen monolithischen Datenbank könnten Tabellen nur ein Kompromiss zwischen allen Benutzern sein. Dies war eines der ursprünglichen Probleme.
WAR. Die ursprüngliche Architektur war:
Auch nach der Aufteilung in separate Prozesse blieb der Großteil der Codebasis für verschiedene Dienste gleich. Alles unterhalb der Controller war einzeln und befand sich im selben Repository. Wir verwendeten gemeinsame Dienstmethoden, Repositorys und eine gemeinsame Basis, in der gemeinsame Tabellen abgelegt waren.
Entlade-Tracker
Das Hauptproblem des Trackers besteht darin, dass die Daten zwischen verschiedenen Datenbanken synchronisiert werden müssen. Dies ist auch der wesentliche Unterschied zur Trennung des Auth-Dienstes, die Reihenfolge und ihr Status können sich ändern und sollten in verschiedenen Diensten angezeigt werden.
Wir nehmen eine Bestellung an der Kasse des Restaurants an (dies ist ein Service), sie wird in der Datenbank im Status „Akzeptiert“ gespeichert. Danach sollte er zum Tracker gelangen, wo er seinen Status noch mehrmals ändern wird: von „Küche“ auf „Verpackt“. Gleichzeitig kann es bei der Bestellung zu einigen externen Einflüssen durch die Kasse oder die Schichtleiterschnittstelle kommen. Die Bestellstatus gebe ich mit ihrer Beschreibung in der Tabelle an:
Das Schema zum Ändern des Bestellstatus sieht folgendermaßen aus:
Status ändern sich zwischen verschiedenen Systemen. Und hier ist der Tracker kein endgültiges System, in dem die Daten geschlossen sind. Wir haben in einem solchen Fall mehrere mögliche Ansätze zur Partitionierung gesehen:
- Wir bündeln alle Bestellvorgänge in einer Dienstleistung. In unserem Fall erfordert diese Option zu viel Service, um mit der Bestellung zu arbeiten. Wenn wir dabei aufhören würden, würden wir den zweiten Monolithen bekommen. Wir würden das Problem nicht lösen.
- Ein System ruft ein anderes an. Die zweite Option ist bereits interessanter. Aber damit sind Anrufketten möglich () ist die Konnektivität der Komponenten höher und schwieriger zu verwalten.
- Wir organisieren Veranstaltungen und jeder Dienst kommuniziert über diese Veranstaltungen miteinander. Infolgedessen wurde die dritte Option gewählt, nach der alle Dienste beginnen, Ereignisse untereinander auszutauschen.
Die Tatsache, dass wir die dritte Option gewählt haben, bedeutete, dass der Tracker über eine eigene Datenbank verfügen würde und bei jeder Änderung in der Reihenfolge ein Ereignis darüber senden würde, das andere Dienste abonnieren und das auch in die Masterdatenbank fällt. Dazu benötigten wir einen Dienst, der die Zustellung von Nachrichten zwischen Diensten sicherstellt.
Zu diesem Zeitpunkt hatten wir RabbitMQ bereits im Stack, daher die endgültige Entscheidung, es als Nachrichtenbroker zu verwenden. Das Diagramm zeigt den Übergang einer Bestellung von der Restaurantkasse durch den Tracker, wo sie ihren Status und ihre Anzeige auf der Schnittstelle „Manager-Bestellungen“ ändert. STAHL:
Bestellpfad Schritt für Schritt
Der Bestellpfad beginnt bei einem der Bestellquellendienste. Hier ist die Kassiererin des Restaurants:
- An der Kasse ist die Bestellung vollständig fertig und es ist Zeit, sie an den Tracker zu senden. Das Ereignis, das der Tracker abonniert hat, wird ausgelöst.
- Der Tracker nimmt eine Bestellung für sich selbst an, speichert sie in seiner eigenen Datenbank, erstellt das Ereignis „Bestellung vom Tracker angenommen“ und sendet sie an RMQ.
- Pro Bestellung sind bereits mehrere Handler für den Event-Bus abonniert. Für uns ist es wichtig, dass die Synchronisierung mit einer monolithischen Basis erfolgt.
- Der Handler empfängt ein Ereignis, wählt daraus für ihn bedeutsame Daten aus: In unserem Fall ist dies der Status der Bestellung „Vom Tracker akzeptiert“ und aktualisiert seine Bestellentität in der Hauptdatenbank.
Wenn jemand eine Bestellung aus der monolithischen Tabelle Bestellungen benötigt, kann er diese auch dort lesen. Die Auftragsschnittstelle im Schichtmanager benötigt beispielsweise Folgendes:
Auch alle anderen Dienste können Order-Events des Trackers abonnieren und diese für sich nutzen.
Wenn die Bestellung nach einiger Zeit in Arbeit genommen wird, ändert sich zunächst ihr Status in ihrer Datenbank (Tracker-Datenbank) und dann wird sofort das Ereignis „OrderIn Progress“ generiert. Es gelangt auch in RMQ, von wo aus es in einer monolithischen Datenbank synchronisiert und an andere Dienste bereitgestellt wird. Unterwegs kann es zu verschiedenen Problemen kommen. Weitere Einzelheiten dazu finden Sie im Bericht von Zhenya Peshkov .
Endgültige Architektur nach Änderungen in Auth und Tracker
Das Zwischenergebnis zusammenfassend: Ursprünglich hatte ich die Idee, die neunjährige Geschichte des Dodo IS-Systems in einen Artikel zu packen. Ich wollte schnell und einfach über die Stufen der Evolution sprechen. Als ich mich jedoch mit dem Material beschäftigte, wurde mir klar, dass alles viel komplizierter und interessanter ist, als es scheint.
Als ich über den Nutzen (oder Mangel davon) solchen Materials nachdachte, kam ich zu dem Schluss, dass eine kontinuierliche Weiterentwicklung ohne umfassende Ereignisaufzeichnungen, detaillierte Rückblicke und Analysen meiner früheren Entscheidungen unmöglich ist.
Ich hoffe, dass es für Sie nützlich und interessant war, mehr über unseren Weg zu erfahren. Jetzt stehe ich vor der Wahl, welchen Teil des Dodo IS-Systems ich im nächsten Artikel beschreiben möchte: in die Kommentare schreiben oder abstimmen.
An der Umfrage können nur registrierte Benutzer teilnehmen. bitte.
Über welchen Teil von Dodo IS möchten Sie im nächsten Artikel mehr erfahren?
-
24,1%Früher Monolith in Dodo IS (2011–2015)14
-
24,1%Erste Probleme und ihre Lösungen (2015-2016)14
-
20,7%Der kundenseitige Weg: Fassade über Sockel (2016-2017)12
-
36,2%Die Geschichte echter Microservices (2018-2019)21
-
44,8%Vollständiges Sägen des Monolithen und Stabilisierung der Architektur26
-
29,3%Über weitere Pläne zur Entwicklung des Systems17
-
19,0%Ich möchte nichts über Dodo IS11 wissen
58 Benutzer haben abgestimmt. 6 Benutzer enthielten sich der Stimme.
Source: habr.com