Welchen Entwicklungspfad sollte ich wählen, wenn ein großes Produkt konzipiert wird oder eine kleine Software zu einem Leviathan heranwächst? Sollte ich alles von Grund auf neu schreiben oder die „historisch etablierten“ Traditionen fortsetzen? Wie auch immer, lohnt es sich, das Konzept der Architektur zu überarbeiten?
Hallo Khabrovites! Mein Name ist Konstantin und ich bin der Hauptentwickler eines ziemlich großen Systems, das einmal als Experiment begann. Eine kleine PHP-Site, die buchstäblich "am Knie" erstellt wurde, und natürlich ein Monolith. Im Laufe der Zeit wuchs die Website und stieß auf eine Reihe von Problemen, deren Lösung die Frage "und dann wie?" War.
Monolith oder Microservices? Was soll ich wählen? Der grundlegende Unterschied zwischen den Ansätzen besteht meiner Meinung nach darin, dass ein Monolith einen zentralisierten Zyklus für die Verarbeitung der Anforderung eines Benutzers und Mikrodienste - einen dezentralisierten - impliziert. Die gemeinsamen Vor- und Nachteile beider Ansätze sind allgemein bekannt und werden mehrmals aufgeführt (z. B.
hier ,
hier oder
hier ). Es gibt jedoch nicht so offensichtliche und offensichtliche Faktoren, die die Wahl der Architektur beeinflussen.
- Vollzeitbeschäftigte laden . Mit der rasanten Entwicklung des Produkts sammelt sich ein Pool von Aufgaben an, die nicht in einem akzeptablen Zeitrahmen gelöst werden können - jeder ist beschäftigt. Und wenn eine solche „Blockade“ einfach ist, macht es keinen Sinn, das Personal der Entwickler zu erweitern. Die naheliegende Lösung sind externe Auftragnehmer (Unternehmen oder Freiberufler). Aber wie kann man ihnen ein Stück des Produkts zum Arbeiten geben, ohne das Risiko einzugehen, es grob gesagt in eine OpenSource zu verwandeln? Bei Verwendung von Microservices ist diese Aufgabe viel einfacher zu lösen.
- Die Schwierigkeit des Tauchens . Je größer das Produkt, desto länger braucht ein neuer Mitarbeiter, um sich darin vertraut zu machen. Vor allem, wenn der Code viele verschiedene Standardeinstellungen enthält (ja, eine gute Dokumentation erleichtert den Vorgang erheblich, aber wenn nicht?) Und Anpassungen für einzelne Sonderfälle. Unter diesem Gesichtspunkt ist es viel einfacher, mit einem kleinen unabhängigen Teil umzugehen, als mit dem gesamten Produkt sofort.
- Ressourcen bei Spitzenlasten . In meiner Praxis gab es einen Fall, in dem die Auslastung der Server manchmal auf nicht akzeptable Werte anstieg (und wenn insbesondere der Arbeitsspeicher erschöpft war, ein Austausch aktiviert wurde und der Server für eine Weile zu einem Gemüse wurde), während der freien Arbeit den Rest der Zeit (die Auslastung betrug nicht mehr als 30% des Arbeitsspeichers ) Und solche Spitzen ereigneten sich unregelmäßig und mit langen Pausen. Im Fall eines Monolithen (wir glauben, dass es keinen Ort gibt, an dem der Code optimiert werden kann) wird nur die Verbindung neuer Server mit einer Kopie des gesamten Systems für den Lastausgleich gespeichert. Und im Fall von Microservices können Sie eine Verarbeitungswarteschlange organisieren (dies gilt natürlich nur für zeitkritische Vorgänge, die schnell sind und nicht erwartet werden, z. B. das Entladen einer Excel-Tabelle).
- Aufgaben im Hintergrund ausführen . Welche Art und Weise dieser Faktor das Boot „schüttelt“, hängt von seiner Größe und Komplexität ab. In der Regel reichen ein Monolith und ein Timer (Cron) aus. Wenn sich jedoch Aufgaben in großen Gruppen ansammeln, treten auch Probleme auf. Es ist notwendig, Cron-Aufgaben bereits auszugleichen. Microservices erleichtern diese Situation erheblich.
- Die Komplexität der Verfolgung . Bei Microservices werden die Anforderungen an die Wartung von Eisen erhöht - wo, was und wie sollte konfiguriert werden. Monolith - grob gesagt, einige Einstellungen für alle Knoten, Microservices - Einstellungen hängen von den Anforderungen bestimmter Microservices ab, die auf dem Knoten ausgeführt werden.
- Qualifikationsanforderungen . Je mehr Technologien der Zoo hat (und normalerweise wächst er, wenn das System ein Mikroservice ist), desto höher sind die Anforderungen an die Fähigkeiten und das Wissen der regulären Mitarbeiter. Wenn es Verbesserungen oder Probleme gibt, müssen sie diese bewältigen. Oder es werden mehr Fachkräfte benötigt, um den gesamten Stapel abzudecken.
Müssen Sie wählen? Ist das Spiel die Kerze wert? Ich denke auf jeden Fall wert. Aber man muss sich dem Problem mit einem kalten Kopf nähern. Andernfalls werden einige Probleme einfach durch andere ersetzt.
In meinem Fall kam ein Wendepunkt, als die Site nicht mehr in die Ressourcen eines Servers "passte". Dann wurde beschlossen, das System gemäß der meiner Meinung nach besten Option - einem Hybrid - neu zu schreiben. Im "Hybridfall" gibt es
allgemeine Empfehlungen für die Produktentwicklung. Aber ich möchte es mit ein paar Empfehlungen ergänzen.
Bei der Entwicklung eines Startermonolithen sollten die Möglichkeiten für eine weitere Verbindung externer Dienste sofort festgelegt werden. Erstellen Sie sofort eine Kommunikation zwischen Komponenten, als ob diese Komponenten bereits (oder fast bereits) „externe Dienste“ wären. Besonders wenn sie ressourcenintensiv sind.
Überlegen Sie sich sofort eine Richtlinie für die Arbeit mit Caches und Datenspeichern (Datenbanken und Dateien). Teilen Sie beispielsweise die Sitzung eines Benutzers.
Und das Wichtigste ist, nicht bis zum Äußersten zu eilen. Für mich selbst habe ich die folgende Formel für ein gutes Projekt abgeleitet: "Ein effektives System ist ein ausgewogenes System." Dies drückt sich insbesondere darin aus, dass ich in Microservices nur große, logisch isolierte Fragmente des Kernels herausnehme. Und dann nur, wenn mindestens eine der Bedingungen erfüllt ist:
- Lastbegrenzung und Prognose sind erforderlich, Zeitverzögerungen aufgrund der Ausführung von Aufgaben sind wiederum nicht kritisch
- Durch die Isolierung wird die Produktivität erheblich gesteigert.
Als Ergebnis dieses Ansatzes haben wir ein System erhalten, 95% der Funktionen befinden sich im Kernel und 5% in Microservices. Gleichzeitig macht der Kern nur 60% der Gesamtlast aus. Gleichzeitig können Sie sicherstellen, dass die Auslastung einzelner Server kritische Werte nicht überschreitet.
Microservices sind also (ab einer bestimmten Größe des Produkts) gut, wenn Sie sie nur verwenden, wenn dies unbedingt erforderlich ist, und nicht wegen der Mode oder "weil es cool ist". Es gibt große
Produkte , die erfolgreich als Monolith leben. Aber manchmal kann ein Monolith das Problem nicht lösen ...
Vielen Dank!