Habr verändert die Welt. Seit über einem Jahr führen wir unseren Blog. Vor etwa einem halben Jahr erhielten wir ein völlig logisches Feedback von den Habr-Nutzern: „Dodo, ihr sagt überall, dass ihr euer eigenes System habt. Was ist das für ein System? Und warum ist es für eine Pizzakette notwendig?“.
Wir haben uns zusammengesetzt, nachgedacht und verstanden, dass ihr recht habt. Wir versuchen, alles einfach zu erklären, aber es kommt in abgehackten Häppchen und es gibt nirgendwo eine vollständige Beschreibung des Systems. So begann ein langer Weg zur Informationssammlung, der Suche nach Autoren und dem Schreiben einer Reihe von Artikeln über Dodo IS. Lass uns loslegen!
Dankeschön: Vielen Dank, dass ihr euer Feedback mit uns teilt. Dank euch haben wir endlich das System beschrieben, einen Technologieradar erstellt und werden bald eine ausführliche Beschreibung unserer Prozesse veröffentlichen. Ohne euch säßen wir wahrscheinlich noch weitere 5 Jahre hier.
Die Artikelreihe «Was ist Dodo IS?» wird erzählen über:
- Früher Monolith in Dodo IS (2011-2015). (In Arbeit...)
- Der Weg des Backoffice: separate Datenbanken und ein Bus. (Du bist hier)
- Der Weg des Kundenbereichs: Fassade über der Datenbank (2016-2017 Jahre). (In Bearbeitung…)
- Die Geschichte echter Mikrodienste. (2018-2019 Jahre). (In Bearbeitung…)
- Vollendeter Schnitt des Monolithen und Stabilisierung der Architektur. (In Bearbeitung…)
Wenn du etwas anderes wissen möchtest, schreib uns in die Kommentare.
Meinung zur chronologischen Beschreibung vom Autor
Ich halte regelmäßig ein Treffen für neue Mitarbeiter zum Thema „Architektur des Systems“. Bei uns heißt es „Einführung in die Dodo IS-Architektur“ und ist Teil des Onboarding-Prozesses neuer Entwickler. Während ich in der einen oder anderen Form über unsere Architektur und ihre Besonderheiten spreche, entwickelte sich ein gewisser historischer Ansatz zur Beschreibung.
Traditionell betrachten wir das System als eine Ansammlung von Komponenten (technischen oder höherstufigen), Geschäftsmodulen, die miteinander interagieren, um ein bestimmtes Ziel zu erreichen. Und wenn ein solcher Blick für das Design gerechtfertigt ist, passt er nicht ganz zu Beschreibung und Verständnis. Dafür gibt es mehrere Gründe:
- Die Realität unterscheidet sich von dem, was auf Papier steht. Nicht alles, was geplant wurde, funktioniert auch so. Uns interessiert, wie es tatsächlich aussieht und funktioniert.
- Fortlaufende Darstellung von Informationen. Im Grunde kann man chronologisch vom Anfang bis zum aktuellen Zustand vorgehen.
- Von einfach zu komplex. Nicht universell, aber in unserem Fall genau so. Von einfacheren Ansätzen entwickelte sich die Architektur zu komplexeren. Oft wurden durch Verkomplizierungen Probleme bei der Umsetzungsgeschwindigkeit und Stabilität sowie Dutzende anderer Eigenschaften aus der Liste der nicht funktionalen Anforderungen gelöst ( gut erklärt zum Gegensatz von Komplexität zu anderen Anforderungen).
Im Jahr 2011 sah die Architektur von Dodo IS so aus:
Bis 2020 hatte es sich etwas verkompliziert und war so geworden:
Wie kam es zu dieser Evolution? Warum sind verschiedene Teile des Systems notwendig? Welche architektonischen Entscheidungen wurden getroffen und warum? Lassen Sie uns in dieser Artikelreihe klären.
Die ersten Probleme des Jahres 2016: Warum müssen Dienste aus dem Monolithen ausbrechen?
Die ersten Artikel der Reihe handeln von den Diensten, die als erste vom Monolithen getrennt wurden. Um Ihnen den Kontext zu geben, werde ich erläutern, welche Probleme wir zu Beginn des Jahres 2016 in unserem System hatten und was wir mit der Trennung der Dienste zu tun hatten.
Eine einzige MySql-Datenbank, in die alle Anwendungen, die zu diesem Zeitpunkt in Dodo IS existierten, ihre Einträge schrieben. Die Folgen waren folgende:
- Hohe Last (85 % der Anfragen entfielen auf das Lesen).
- Die Datenbank wuchs. Dadurch wurde ihre Kosten- und Wartung zu einem Problem.
- Einzelner Ausfallpunkt. Wenn eine Anwendung, die in die Datenbank schreibt, plötzlich aktiver wurde, spürten die anderen Anwendungen dies.
- Ineffizienz bei Speicherung und Abfragen. Oft wurden Daten in einer Struktur gespeichert, die für bestimmte Szenarien praktisch war, aber für andere nicht geeignet war. Indizes beschleunigten einige Operationen, konnten jedoch andere verlangsamen.
- Ein Teil der Probleme wurde durch hastig eingerichtete Caches und Read-Replikate auf den Datenbanken gelöst (darüber wird es einen separaten Artikel geben), aber sie schenkten uns nur Zeit und lösten das grundsätzliche Problem nicht.
Ein Problem war das Vorhandensein des Monolithen.Die Folgen waren folgende:
- Einheitliche und seltene Releases.
- Schwierigkeiten bei der gemeinsamen Entwicklung vieler Menschen.
- Unmöglichkeit, neue Technologien, neue Frameworks und Bibliotheken einzuführen.
Probleme mit der Datenbank und dem Monolithen wurden oft beschrieben, beispielsweise im Kontext von Ausfällen zu Beginn des Jahres 2018 (, und ), daher werde ich nicht weiter darauf eingehen. Ich kann nur sagen, dass wir mehr Flexibilität bei der Entwicklung der Dienste ermöglichen wollten. Dies galt insbesondere für die am stärksten belasteten und entscheidenden Dienste in unserem gesamten System — Auth und Tracker.
Der Weg des Backoffice: getrennte Datenbanken und Bus
Navigation im Kapitel
Schema des Monolithen aus dem Jahr 2016
Vor Ihnen liegen die Hauptblöcke des Dodo IS Monolithen aus dem Jahr 2016, und etwas weiter unten finden Sie die Erläuterung ihrer Hauptaufgaben.
Auslieferungsstelle. Verwaltung der Kuriere, Ausgabe der Bestellungen an die Kuriere.
Kontaktzentrum. Bestellannahme durch einen Operator.
Site. Unsere Websites (dodopizza.ru, dodopizza.co.uk, dodopizza.by usw.).
Auth. Authentifizierungs- und Autorisierungsservice für das Backoffice.
Tracker. Bestelltracker in der Küche. Dienst zur Statusmarkierung der Fertigstellung während der Zubereitung der Bestellung.
Restaurantkasse. Bestellannahme im Restaurant, Kassieroberflächen.
Export. Erstellung von Berichten für 1C für die Buchhaltung.
Benachrichtigungen und Belege. Sprachbefehle in der Küche (zum Beispiel: „Eine neue Pizza ist eingetroffen“) + Druck von Belegen für die Kuriere.
Schichtmanager. Oberflächen für die Arbeit des Schichtmanagers: Bestelllisten, Leistungsgrafiken, Mitarbeiteranzeigen für die Schicht.
Büromanagement. Oberflächen für die Arbeit der Franchisenehmer und Manager: Mitarbeiterverwaltung, Berichte über die Arbeit der Pizzeria.
Restaurantdisplay. Anzeige des Menüs auf Fernsehern in den Pizzerien.
Admin-Bereich. Einstellungen in der jeweiligen Pizzeria: Menü, Preise, Buchhaltung, Aktionscodes, Aktionen, Banner für die Website usw.
Mitarbeiter-Dashboard. Arbeitspläne der Mitarbeiter, Informationen über die Mitarbeiter.
Motivationsdisplay der Küche. Ein separater Bildschirm, der in der Küche hängt und die Arbeitsgeschwindigkeit der Pizzabäcker anzeigt.
Kommunikation. Versand von SMS und E-Mails.
Dateispeicher. Eigener Service zum Abrufen und Bereitstellen statischer Dateien.
Die ersten Versuche, Probleme zu lösen, haben uns geholfen, waren jedoch nur eine vorübergehende Lösung. Sie haben sich nicht als systematische Lösungen erwiesen, daher war klar, dass etwas mit den Datenbanken geschehen muss. Beispielsweise eine gemeinsame Datenbank in mehrere spezialisierte Datenbanken aufzuteilen.
Wir beginnen, den Monolithen zu entlasten: Trennung von Auth und Tracker
Die wichtigsten Dienste, die damals mehr als andere auf die Datenbank zugriffen:
- Auth. Authentifizierungs- und Autorisierungsservice für das Backoffice.
- Tracker. Bestelltracker in der Küche. Dienst zur Statusmarkierung der Fertigstellung während der Zubereitung der Bestellung.
Womit beschäftigt sich Auth?
Auth ist der Service, über den sich die Nutzer im Backoffice einloggen (auf der Kundenwebsite gibt es einen separaten, unabhängigen Zugang). Dieser Service wird auch in Anfragen genutzt, um sicherzustellen, dass die entsprechenden Zugriffsrechte vorhanden sind und dass sich diese Rechte seit dem letzten Login nicht geändert haben. Über diesen Service erfolgt auch der Zugang von Geräten in den Pizzerien.
Zum Beispiel möchten wir auf dem Fernseher im Wohnzimmer ein Display mit den Status bereitgestellter Bestellungen öffnen. Dann gehen wir zu auth.dodopizza.ru, wählen "Einloggen als Gerät", ein Code erscheint, den man auf einer speziellen Seite auf dem Computer des Schichtmanagers eingeben kann, wobei der Gerätetyp (Device) angeben werden muss. Der Fernseher wechselt automatisch zur richtigen Benutzeroberfläche seiner Pizzeria und beginnt, die Namen der Kunden anzuzeigen, deren Bestellungen bereit sind.
Woher kommen die Lasten?
Jeder eingeloggte Benutzer im Backoffice greift bei jeder Anfrage auf die Benutzerdatenbank zu, zieht über eine SQL-Abfrage den Benutzer heraus und überprüft, ob er die erforderlichen Zugriffsrechte für diese Seite hat.
Jedes Gerät macht dasselbe, aber mit der Gerätetabelle, indem es seine Rolle und Zugriffsrechte überprüft. Eine große Anzahl von Anfragen an die Masterdatenbank führt zu ihrer Belastung und zu einer Ressourcennutzung der gemeinsamen Datenbank für diese Vorgänge.
Entlastung von Auth
Auth hat eine isolierte Domain, das heißt, Daten über Benutzer, Logins oder Geräte gelangen in den (noch zukünftigen) Dienst und verbleiben dort. Wenn jemand sie benötigt, wird er sich an diesen Dienst wenden, um die Daten zu erhalten.
WAR. Der ursprüngliche Arbeitsablauf war folgender:
Ich möchte ein wenig erklären, wie das funktioniert hat:
- Eine Anfrage von außen kommt an das Backend (dort Asp.Net MVC) und bringt ein Cookie mit, das für den Zugriff auf die Sitzungsdaten aus Redis(1) verwendet wird. Entweder enthält es Informationen über Berechtigungen, dann ist der Zugriff zum Controller offen (3,4), oder nicht.
- Wenn kein Zugriff besteht, muss man das Autorisierungsverfahren durchlaufen. Hier wurde es zur Vereinfachung als Teil des Weges im gleichen Attribut dargestellt, obwohl es sich um einen Übergang zur Login-Seite handelt. Im positiven Fall erhalten wir eine richtig ausgefüllte Sitzung und gelangen in den Backoffice-Controller.
- Wenn Daten vorhanden sind, müssen diese auf Aktualität in der Benutzerdatenbank überprüft werden. Hat sich seine Rolle geändert, darf er nun nicht auf die Seite zugelassen werden? In diesem Fall muss nach dem Erhalt der Sitzung (1) direkt in die Datenbank gegangen und die Zugriffsrechte des Benutzers über die Authentifizierungsschicht (2) überprüft werden. Danach entweder zur Login-Seite oder direkt in den Controller. So ein einfaches System, aber nicht wirklich Standard.
- Wenn alle Verfahren durchlaufen sind, lassen wir weiter in der Logik der Controller und Methoden durch.
Benutzerdaten sind von allen anderen Daten getrennt und werden in einer separaten Tabelle gespeichert. Funktionen aus der Logikschicht AuthService können durchaus zu API-Methoden werden. Die Grenzen des Fachgebiets sind klar definiert: Benutzer, deren Rollen, Zugangsdaten, die Vergabe und Entziehung von Zugriffsrechten. Alles deutet darauf hin, dass es als separater Dienst ausgegliedert werden kann.
WURDE. Das haben wir auch gemacht:
Dieser Ansatz hat eine Reihe von Problemen. Zum Beispiel ist der Aufruf einer Methode im Prozess nicht dasselbe wie der HTTP-Aufruf eines externen Dienstes. Latenz, Zuverlässigkeit, Wartbarkeit und Transparenz der Operationen sind völlig anders. Über genau solche Probleme sprach Andrei Morevsky in seinem Vortrag .
Der Authentifizierungsdienst und der Dienst für Geräte werden für das Backoffice verwendet, also für die Dienste und Schnittstellen, die in der Produktion verwendet werden. Die Authentifizierung für Kundendienste (wie die Website oder die mobile App) erfolgt separat ohne Verwendung von Auth. Die Trennung dauerte etwa ein Jahr, und jetzt beschäftigen wir uns erneut mit diesem Thema, indem wir das System auf neue Authentifizierungsdienste (mit standardisierten Protokollen) umstellen.
Warum hat die Trennung so lange gedauert?
Auf dem Weg gab es viele Probleme, die den Prozess verlangsamt haben:
- Wir wollten die Daten über Benutzer, Geräte und Authentifizierung aus nationalen Datenbanken in eine einzige überführen. Dafür mussten alle Tabellen umgestellt werden, wobei die Verwendung von int-Identifikatoren auf globale UUID-Identifikatoren umgestellt wurde (dieser Code wurde kürzlich überarbeitet und ein Open-Source-Projekt ). Die Speicherung von Benutzerdaten (da es sich um persönliche Informationen handelt) hat ihre Einschränkungen, und für einige Länder müssen sie separat gespeichert werden. Aber eine globale Benutzer-ID muss vorhanden sein.
- Viele Tabellen in der Datenbank enthalten Audit-Informationen über den Benutzer, der die Operation durchgeführt hat. Das erforderte einen zusätzlichen Mechanismus, um die Konsistenz zu gewährleisten.
- Nach der Erstellung der API-Services begann eine lange und schrittweise Phase der Umstellung auf ein anderes System. Die Umstellungen mussten nahtlos für die Benutzer erfolgen und erforderten manuelle Arbeiten.
Das Schema zur Registrierung eines Geräts in der Pizzeria:
Die Gesamte Architektur nach der Ausgliederung des Auth- und Geräteservices:
Hinweis. Bis zum Jahr 2020 arbeiten wir an einer neuen Version von Auth, die auf dem Autorisierungsstandard OAuth 2.0 basiert. Dieser Standard ist ziemlich komplex, wird jedoch für die Entwicklung eines durchgängigen Authentifizierungsdienstes nützlich sein. Im Artikel „“ hat Alexey Chernyaev versucht, den Standard so einfach und verständlich wie möglich zu erklären, damit Sie Zeit beim Lernen sparen.
Womit beschäftigt sich der Tracker?
Jetzt zum zweiten der stark belasteten Dienste. Der Tracker hat eine doppelte Rolle:
- Auf der einen Seite besteht seine Aufgabe darin, den Mitarbeitern in der Küche zu zeigen, welche Bestellungen gerade bearbeitet werden und welche Produkte zubereitet werden müssen.
- Auf der anderen Seite dient er der Digitalisierung aller Prozesse in der Küche.
Wenn in einer Bestellung ein neues Produkt (zum Beispiel eine Pizza) erscheint, gelangt es zur Tracker-Station „Teig ausrollen“. An dieser Station steht ein Pizzabäcker, der einen Teigling der richtigen Größe nimmt und ihn ausrollt, anschließend auf dem Tracker-Tablet markiert, dass er seine Aufgabe erledigt hat, und den ausgerollten Pizzaboden zur nächsten Station „Füllen“ übergibt.
Dort füllt der nächste Pizzabäcker die Pizza, markiert dann auf dem Tablet, dass er seine Aufgabe erfüllt hat, und gibt die Pizza in den Ofen (dies ist auch eine separate Station, die auf dem Tablet markiert werden muss). Ein solches System gibt es seit den Anfängen von Dodo und der ersten Existenz von Dodo IS. Es ermöglicht eine vollständige Verfolgung und Digitalisierung aller Vorgänge. Darüber hinaus gibt der Tracker Hinweise, wie man das jeweilige Produkt zubereitet, führt jedes Produkt durch seine eigenen Herstellungspläne, speichert die optimale Zubereitungszeit des Produkts und verfolgt alle Vorgänge mit dem Produkt.
So sieht der Bildschirm des Tablets an der Tracker-Station „Teig ausrollen“ aus.
Woher kommen die Lasten?
In jeder Pizzeria gibt es etwa fünf Tablets mit einem Tracker. Im Jahr 2016 hatten wir über 100 Pizzerien (und jetzt sind es mehr als 600). Jedes der Tablets sendet alle 10 Sekunden eine Anfrage an das Backend und sammelt Daten aus der Bestelltabelle (verknüpft mit dem Kunden und der Adresse), der Bestellzusammensetzung (verknüpft mit dem Produkt und der Menge), der Motivationsdatenbank (in der die Klickzeiten erfasst werden). Wenn ein Pizzabäcker auf das Produkt im Tracker klickt, erfolgt eine Aktualisierung der Einträge in all diesen Tabellen. Die Bestelltabelle ist allgemein, in sie werden gleichzeitig Einfügungen bei der Annahme einer Bestellung, Aktualisierungen von anderen Teilen des Systems und zahlreiche Abfragen, zum Beispiel auf dem Fernseher, der in der Pizzeria hängt und den Kunden die fertigen Bestellungen anzeigt, eingetragen.
Während des Kampfes gegen die Lasten, als alles und jeder zwischengespeichert und auf eine asynchrone Replik der Datenbank umgestellt wurde, hielten diese Operationen mit dem Tracker weiterhin an die Master-Datenbank. Hier sollte es keine Verzögerung geben, die Daten müssen aktuell sein, eine Desynchronisation ist inakzeptabel.
Das Fehlen eigener Tabellen und Indizes erlaubte es außerdem nicht, spezifischere Anfragen zu formulieren, die auf die eigene Nutzung zugeschnitten sind. Zum Beispiel könnte es für den Tracker effizient sein, einen Index auf die Pizzeria in der Bestelltabelle zu haben. Wir rufen immer die Bestellungen nach Pizzeria aus der Tracker-Datenbank ab. In diesem Fall spielt es für die Annahme der Bestellung keine so große Rolle, in welche Pizzeria sie gelangt, wichtiger ist, welcher Kunde diese Bestellung aufgegeben hat. Das bedeutet, dass dort ein Index auf den Kunden benötigt wird. Außerdem muss der Tracker in der Bestelltabelle nicht unbedingt die ID des gedruckten Belegs oder die mit der Bestellung verbundenen Bonusaktionen speichern. Diese Informationen interessieren unseren Tracker-Service nicht. In der gemeinsamen monolithischen Datenbank konnten die Tabellen nur einen Kompromiss zwischen allen Nutzern darstellen. Das war eines der anfänglichen Probleme.
WAR. Ursprünglich war die Architektur so:
Selbst nach der Auslagerung in separate Prozesse blieb der größte Teil des Codebestands für verschiedene Services gemeinsam. Alles, was unterhalb der Controller liegt, war einheitlich und lebte in einem Repository. Es wurden gemeinsame Methoden von Services, Repositories sowie eine gemeinsame Datenbank verwendet, in der sich gemeinsame Tabellen befanden.
Entlastung des Trackers
Das Hauptproblem mit dem Tracker besteht darin, dass die Daten zwischen verschiedenen Datenbanken synchronisiert werden müssen. Das ist auch das Hauptunterscheidungsmerkmal im Vergleich zur Trennung des Auth-Dienstes; die Bestellung und deren Status können sich ändern und müssen in verschiedenen Diensten angezeigt werden.
Wir nehmen die Bestellung an der Restaurantkasse entgegen (das ist der Dienst), sie wird in der Datenbank mit dem Status "Angenommen" gespeichert. Danach muss sie zum Tracker gelangen, wo ihr Status noch mehrere Male geändert wird: von "Küche" bis "Verpackt". Dabei können mit der Bestellung externe Einflüsse von der Kasse oder der Benutzeroberfläche des Schichtmanagers auftreten. Ich werde in der Tabelle die Bestellstatus mit ihren Beschreibungen anführen:
Das Schema zur Änderung der Bestellstatus sieht folgendermaßen aus:
Die Status wechseln zwischen verschiedenen Systemen. Und hier ist der Tracker nicht das endgültige System, in dem die Daten zusammenlaufen. Wir haben einige mögliche Ansätze für die Trennung in einem solchen Fall gesehen:
- Alle Aktionen der Bestellung in einem einzigen Dienst konzentrieren. In unserem Fall erfordert diese Option einen zu großen Dienst zur Bearbeitung der Bestellung. Hätten wir uns dafür entschieden, wäre es ein zweites Monolith geworden. Die Probleme wären nicht gelöst worden.
- Ein System ruft ein anderes auf. Die zweite Option ist bereits interessanter. Aber dabei sind Kettenaufrufe möglich (), die Komponenten sind stärker miteinander verbunden, das Management hiervon ist schwieriger.
- Wir organisieren Ereignisse, und jeder Dienst tauscht sich über diese Ereignisse aus. Letztendlich wurde genau die dritte Option gewählt, nach der alle Dienste beginnen, Ereignisse miteinander auszutauschen.
Die Wahl der dritten Option bedeutet, dass der Tracker eine eigene Datenbank haben wird und bei jeder Änderung der Bestellung ein Ereignis darüber sendet, auf das sich andere Dienste abonnieren und das auch in die Master-Datenbank gelangt. Zu diesem Zweck benötigten wir einen Dienst, der die Nachrichtenzustellung zwischen den Diensten ermöglicht.
Zu diesem Zeitpunkt hatten wir bereits RabbitMQ in unserem Stack, daher die endgültige Entscheidung, es als Nachrichtenbroker zu verwenden. Das Diagramm zeigt den Übergang der Bestellung von der Restaurantkasse über den Tracker, wo sie ihre Status ändert und ihre Anzeige in der Benutzeroberfläche der Bestellungen des Managers. GEWORDEN:
Der Weg der Bestellung in Schritten
Der Weg der Bestellung beginnt bei einem der Quellendienste für die Bestellung. Hier ist es die Restaurantkasse:
- An der Kasse ist die Bestellung vollständig bereit, und es ist Zeit, sie an den Tracker zu senden. Ein Ereignis wird ausgelöst, auf das der Tracker abonniert ist.
- Der Tracker speichert die Bestellung in seiner eigenen Datenbank, während er das Ereignis „BestellungVomTrackerAkzeptiert“ generiert und an RMQ sendet.
- In der Ereignisbus sind bereits mehrere Handler für die Bestellung abonniert. Für uns ist der Handler wichtig, der die Synchronisation mit der monolithischen Datenbank vornimmt.
- Der Handler empfängt das Ereignis, extrahiert die für ihn relevanten Daten: In unserem Fall ist dies der Bestellstatus „VomTrackerAkzeptiert“ und aktualisiert sein Bestellobjekt in der Hauptdatenbank.
Wenn jemand eine Bestellung genau aus der monolithischen Tabelle orders benötigt, kann man sie auch dort abrufen. Zum Beispiel wird das für die Benutzeroberfläche Bestellungen im Schichtmanager benötigt:
Alle anderen Dienste können sich ebenfalls auf die Bestellereignisse des Trackers abonnieren, um diese für sich zu nutzen.
Wenn die Bestellung nach einiger Zeit in Bearbeitung genommen wird, ändert sich ihr Status zunächst in ihrer eigenen Datenbank (Tracker-Datenbank) und sofort wird das Ereignis „BestellungInArbeit“ generiert. Auch dieses gelangt in RMQ, von wo aus es mit der monolithischen Datenbank synchronisiert und an andere Dienste geliefert wird. Auf diesem Weg können verschiedene Probleme auftauchen, die genauer im Bericht von Jewgeni Peshkov betrachtet werden können. .
Die endgültige Architektur nach Änderungen im Auth und Tracker
Zusammenfassend: Zunächst hatte ich die Idee, die neunjährige Geschichte des Dodo IS-Systems in einem Artikel zusammenzufassen. Ich wollte schnell und einfach über die Entwicklungsphasen berichten. Doch als ich mich an das Material setzte, wurde mir klar, dass alles viel komplexer und interessanter ist, als es scheint.
Während ich über den Nutzen (oder dessen Fehlen) eines solchen Materials nachdachte, kam ich zu dem Schluss, dass kontinuierliche Entwicklung ohne vollständige Chroniken der Ereignisse, umfassende Retrospektiven und Analysen eigener früherer Entscheidungen unmöglich ist.
Ich hoffe, es war für Sie interessant und nützlich, mehr über unseren Weg zu erfahren. Jetzt stehe ich vor der Wahl, welchen Teil des Dodo IS-Systems ich im nächsten Artikel beschreiben soll: Schreiben Sie in die Kommentare oder stimmen Sie ab.
Nur registrierte Benutzer können an der Umfrage teilnehmen. .
Über welchen Teil von Dodo IS möchten Sie im nächsten Artikel mehr erfahren?
24,1%Früherer Monolith in Dodo IS (2011-2015 Jahre)14
24,1%Die ersten Probleme und deren Lösungen (2015-2016 Jahre)14
20,7%Der Weg des Client-Teils: Fassade über der Datenbank (2016-2017 Jahre)12
36,2%Die Geschichte echter Mikrodienste (2018-2019 Jahre)21
44,8%Vollständiger Schnitt des Monolithen und Stabilisierung der Architektur26
29,3%Über die weiteren Pläne zur Entwicklung des Systems17
19,0%Ich möchte nichts über Dodo IS11 wissen
58 Benutzer haben abgestimmt. 6 Benutzer haben sich enthalten.
Quelle: habr.com
