In der heutigen schnelllebigen digitalen Welt, in der Agilität und Skalierbarkeit von entscheidender Bedeutung sind, suchen Unternehmen ständig nach Möglichkeiten, die Leistung und Wartbarkeit ihrer Webanwendungen zu verbessern.
Ein beliebter Ansatz zum Erreichen dieser Ziele ist die Migration von einer monolithischen Architektur zu einer verteilten Architektur (oder einem Mikro-Frontend). In dieser Artikelserie „Micro-Frontend Migration Journey“ teile ich meine persönlichen Erfahrungen mit der Durchführung einer solchen Migration während meiner Zeit bei AWS.
HAFTUNGSAUSSCHLUSS : Bevor wir beginnen, ist es wichtig zu beachten, dass dieser Artikel zwar meine persönlichen Erfahrungen wiedergibt, ich jedoch keine proprietären oder internen Details zu Tools, Technologien oder spezifischen Prozessen bei AWS oder einer anderen Organisation offenlegen kann.
Ich bin bestrebt, die rechtlichen Verpflichtungen einzuhalten und sicherzustellen, dass sich dieser Artikel ausschließlich auf die allgemeinen Konzepte und Strategien konzentriert, die mit der Micro-Frontend-Migration verbunden sind.
Der Zweck besteht darin, Erkenntnisse und gewonnene Erkenntnisse bereitzustellen, die in einem breiteren Kontext anwendbar sind, ohne dass vertrauliche Informationen preisgegeben werden.
Ich habe durch den Artikel auf Martin Fowlers Blog etwas über Mikro-Frontends gelernt (ich vermute, dass es viele von Ihnen auch tun). Es wurden verschiedene Möglichkeiten vorgestellt, eine Mikro-Frontend-Architektur auf Framework-unabhängige Weise zu erstellen.
Als ich mich eingehender mit dem Thema befasste, wurde mir klar, dass unsere bestehende monolithische Architektur zu einem erheblichen Engpass für die Produktivität unseres Teams wurde und die Gesamtleistung unserer Anwendung beeinträchtigte.
Einer der Schlüsselfaktoren, die mich dazu bewogen haben, über eine Migration nachzudenken, war die zunehmende Paketgröße unserer Anwendung.
Nachdem ich im Sommer 2020 eine gründliche Bundle-Analyse durchgeführt hatte, stellte ich fest, dass die Bundle-Größe (gzippt) seit der ersten Einführung Anfang 2019 von 450 KB auf 800 KB (geparst sind es fast 4 MB) angewachsen war – fast das Doppelte der ursprünglichen Größe.
Angesichts des Erfolgs unseres Dienstes und der Prognose seines weiteren Wachstums war klar, dass dieser Trend anhalten und sich weiter auf die Leistung und Wartbarkeit unserer Anwendung auswirken würde.
Obwohl ich vom Konzept der Mikro-Frontends begeistert war, erkannte ich auch, dass wir aufgrund spezifischer Herausforderungen, denen wir gegenüberstanden, noch nicht bereit waren, sie einzuführen:
Kleine Organisationsstruktur: Zum Zeitpunkt meiner Analyse war unsere Organisation relativ klein und ich war der einzige Vollzeit-Frontend-Ingenieur im Team. Die Migration auf eine Mikro-Frontend-Architektur erforderte erhebliche Investitionen in die Organisationsstruktur und die betrieblichen Grundlagen.
Es war von entscheidender Bedeutung, über eine ausgereifte Struktur zu verfügen, die die verteilte Architektur effektiv bewältigen und die Abhängigkeiten zwischen verschiedenen Frontend-Komponenten widerspiegeln kann.
Eingeschränkter Geschäftsbereich: Obwohl Mikro-Frontends basierend auf begrenzten Kontexten und Geschäftsfunktionen aufgeteilt werden können (mehr erfahren Sie im Beitrag „ Domänengesteuertes Design in der Mikro-Frontend-Architektur“ ), war unser Kerngeschäftsbereich nicht umfangreich genug, um eine vollständige Entkopplung zu rechtfertigen mehrere Mikro-Frontends. Es gab jedoch sichtbare Grenzen innerhalb der Anwendung, deren Herausarbeitung und Übergang zu einer verteilten Architektur sinnvoll war.
Angesichts dieser Faktoren wurde mir klar, dass ein schrittweiser Ansatz notwendig war. Anstelle einer vollständigen Migration auf Mikro-Frontends wollte ich bestimmte Bereiche innerhalb unserer Anwendung identifizieren, die von einer verteilten Architektur profitieren könnten.
Dies würde es uns ermöglichen, Leistungs- und Skalierbarkeitsprobleme anzugehen, ohne die gesamte Organisationsstruktur zu stören oder die Integrität unseres Geschäftsbereichs zu gefährden. Es würde uns auch etwas Zeit geben, das Team zu vergrößern und die Geschäftsrichtung zu beobachten.
Bitte beachten Sie, dass es möglicherweise nicht die beste Idee ist, das Leistungsproblem (Bundle-Größe) der App nur durch die Verwendung der Mciro-Frontend-Architektur zu lösen. Es wäre besser, mit einer verteilten Monolith-Architektur zu beginnen, die stattdessen Lazy Loading (dynamische Importe) nutzt.
Darüber hinaus denke ich, dass es Probleme mit der Bundle-Größe besser lösen würde als die Mikro-Frontend-Architektur, wenn man bedenkt, dass die Mikro-Frontend-Architektur höchstwahrscheinlich über einen gemeinsamen Code verfügt, der nicht in Anbieterblöcke aufgeteilt wäre, und dieser in das Anwendungspaket integriert wäre ( Das ist einer der Nachteile einer solchen verteilten Architektur – Sie müssen einen Kompromiss zwischen dem, was wann und wie geteilt werden soll, eingehen.
Allerdings lässt sich eine verteilte Monolith-Architektur nicht so gut skalieren wie ein Mikro-Frontend. Wenn Ihr Unternehmen schnell wächst, wird wahrscheinlich auch Ihr Team im gleichen Tempo wachsen.
Es wäre unbedingt erforderlich, die Codebasis in verschiedene Eigentumsbereiche aufzuteilen, die von verschiedenen Teams kontrolliert werden.
Und jedes Team muss seine eigenen Veröffentlichungszyklen haben, die unabhängig von anderen sind. Jedes Team wird es zu schätzen wissen, wenn sich seine Codebasis ausschließlich auf seine Domäne konzentriert und schnell erstellt wird (Code-Isolation -> bessere Wartbarkeit/weniger zu wartender Code). Build -> bessere Testbarkeit/weniger Tests für Wartung und Ausführung).
Um die Unterstützung der Führung zu gewinnen, habe ich ein überzeugendes technisches Visionsdokument erstellt, das eine umfassende Leistungsanalyse, einschließlich Web-Vital-Metriken, umfasste und die verschiedenen Phasen der Migration hin zu verteilten Frontends skizzierte.
Eine der Zwischenphasen dieser Migration bestand darin, eine verteilte monolithische Architektur zu etablieren, in der mehrere Module/Widgets asynchron über Lazy-Loading-Techniken bereitgestellt werden konnten, während gleichzeitig eine gemeinsame Infrastruktur wie ein S3-Bucket und CDN zwischen dem Kerndienst und den Widgets genutzt werden konnte .
Wie ich in meinem vorherigen Artikel dargelegt habe, besteht die Hauptidee dieser Art von Dokument darin, die Zukunft so zu beschreiben, wie man sie sich wünscht, sobald die Ziele erreicht und die größten Probleme gelöst sind. Es geht nicht um den Ausführungsplan!
Fast ein Jahr später war es endlich an der Zeit, meinen Micro-Frontend-Migrationsplan in die Tat umzusetzen. Mit der bevorstehenden Expansion in eine neue Domäne und einem größeren Team, das uns zur Verfügung stand, waren wir für die Durchführung der Migration gut gerüstet.
Es fühlte sich wie eine einmalige Gelegenheit an, die wir uns nicht entgehen lassen durften.
Denn wer auf die monolithische Architektur beschränkt bleiben würde, würde bedeuten, sich ständig mit deren Grenzen auseinanderzusetzen.
Der begrenzte Zeitrahmen für die Expansion in eine neue Domäne diente als Katalysator und trieb uns dazu, sofort eine skalierbarere und wartbarere Architektur aufzubauen, anstatt kurze und langsame Iterationen durchzuführen!
Um die Migration durchzuführen und gleichzeitig die Arbeit in der neuen Domäne zu erledigen, haben wir die Teams in zwei dedizierte Gruppen aufgeteilt. Die Feature-Arbeit, die eine höhere Priorität hatte, erforderte mehr Ressourcen und musste schneller iteriert werden.
Um die Integrität und das umfassende Verständnis des Migrationsprozesses sicherzustellen, war es sinnvoll, ein kleines, dediziertes Team speziell für die Abwicklung der Migration zu beauftragen.
Wir konnten jedoch nicht mit der Feature-Arbeit fortfahren, ohne zuvor sicherzustellen, dass sich das Micro-Frontend-Konzept als erfolgreich erweisen würde.
Um Risiken zu mindern und einen klaren Fahrplan bereitzustellen, war es von entscheidender Bedeutung, ein Entwurfsdokument auf niedriger Ebene zu erstellen, das präzise Schätzungen und eine gründliche Risikobewertung enthielt. Dieses Dokument diente als Blaupause und skizzierte die notwendigen Schritte und Überlegungen für die Migration.
Der entscheidende Meilenstein in diesem Prozess war die Entwicklung eines Proof-of-Concept, der die erfolgreiche Integration aller Komponenten gemäß dem Design demonstrieren sollte.
Dieser Meilenstein mit dem treffenden Namen „Point of no Return“ zielte darauf ab, die Machbarkeit und Wirksamkeit der Mikro-Frontend-Architektur zu validieren.
Obwohl ich hinsichtlich des Erfolgs der Migration optimistisch war, war es wichtig, sich auf Eventualitäten vorzubereiten. Deshalb habe ich einen Plan B entwickelt, der als Backup-Strategie für den Fall diente, dass das ursprüngliche Konzept nicht die gewünschten Ergebnisse brachte.
Dazu gehörte die Zuweisung zusätzlicher sieben Tage in den Kostenvoranschlägen, um mich ins Kissen weinen zu lassen, sowie ein paar Tage, um einen neuen Funktionsmoduleintrag per Lazy-Loading mit dem Kern zu verbinden (erinnern Sie sich an den verteilten Monolithen?).
Beim Entwerfen von Mikro-Frontends gibt es im Allgemeinen drei Kompositionsansätze, die sich jeweils darauf konzentrieren, wo die Laufzeit-App-Auflösung stattfindet. Das Schöne an diesen Ansätzen ist, dass sie sich nicht gegenseitig ausschließen und je nach Bedarf kombiniert werden können.
Die Grundidee besteht darin, einen Reverse-Proxy-Server zu nutzen, um Micro-Frontend-Bundles pro Seite aufzuteilen und einen harten Neuladen der Seite basierend auf der Routen-URL durchzuführen.
Vorteile:
Nachteile:
Der globale Status wird nicht zwischen den Micro-Frontend-Apps synchronisiert. Dies war für uns ein klarer No-Go-Punkt, da auf der Client-Seite langwierige Hintergrundoperationen durchgeführt wurden.
Man könnte argumentieren, dass wir einen Snapshot der „Warteschlange“ dieses Vorgangs im lokalen Speicher speichern und nach dem Neuladen daraus lesen könnten, aber aus Sicherheitsgründen konnten wir dies nicht implementieren.
Dies ist nur ein Beispiel für einen globalen Status, aber hier ist ein weiteres Beispiel dafür, wie er aussehen kann: Status der Seitennavigationsfelder (erweitert/reduziert), Toastnachrichten usw.
Ein weiterer Ansatz zur Mikro-Frontend-Komposition ist die Edge-Side-Komposition, bei der Mikro-Frontends auf der Randschicht, beispielsweise einem CDN, kombiniert werden. Beispielsweise unterstützt Amazon CloudFront die Lambda@Edge- Integration und ermöglicht die Verwendung eines gemeinsamen CDN zum Lesen und Bereitstellen der Micro-Frontend-Inhalte.
Vorteile:
Nachteile:
Die clientseitige Komposition ist ein weiterer Ansatz für die Mikro-Frontend-Architektur, der clientseitige Mikro-Frontend-Orchestrierungstechniken nutzt, die von der Serverimplementierung entkoppelt sind.
Der Hauptakteur in dieser Architektur ist eine Container-(Shell-)Anwendung, die die folgenden Verantwortlichkeiten hat:
Die allgemeine Idee besteht darin, dass jedes Micro-Frontend-Bundle zwei Arten von Asset-Dateien erzeugen würde:
{hash}/index.js: Dies dient als Einstiegspunkt für die Micro-Frontend-Anwendung, wobei der Hash eine eindeutige Kennung für den gesamten Build darstellt.
Der Hash fungiert als Präfixschlüssel für jedes Bundle im S3-Bucket. Es ist wichtig zu beachten, dass zwar mehrere Einstiegspunkte vorhanden sein können, der Hash jedoch für alle gleich bleibt.
manifest.json: Dies ist eine Manifestdatei, die Pfade zu allen Einstiegspunkten für die Micro-Frontend-Anwendung enthält. Diese Datei verbleibt immer im Stammverzeichnis des S3-Buckets, sodass der Container sie leicht erkennen kann.
Ich empfehle, die Versionierung dieser Datei im S3-Bucket zu aktivieren, um Änderungen besser beobachten zu können. Wenn Sie Webpack zum Erstellen Ihres Projekts verwenden, empfehle ich dringend WebpackManifestPlugin , das Ihnen die ganze schwere Arbeit abnimmt.
Der Container kennt nur die Micro-Frontend-Asset-Quelldomänen-URL (CDN-Ursprung) basierend auf der Stufe und der Region. Beim ersten Laden der Seite lädt der Container die Manifestdatei für jede Micro-Frontend-Anwendung herunter.
Die Manifestdatei ist sehr klein (ca. 100 Byte), um die Ladezeit der Seite nicht zu beeinträchtigen, und lässt sich auch dann gut skalieren, wenn mehrere Mikro-Frontends in einem Container zusammengefasst werden. Es ist wichtig, die Manifestdatei im Cache-Speicher des Browsers als unveränderlich zu betrachten, um aggressives Caching zu verhindern.
Die Auswahl der richtigen Orchestrierungsbibliothek stellt bei dieser Komposition die größte Herausforderung dar und wird im folgenden Kapitel besprochen.
Vorteile:
Nachteile:
Wie ich bereits in diesem Kapitel erwähnt habe, können alle diese Kompositionsmuster innerhalb derselben Shell-Anwendung gemischt und angepasst werden. Hier ist ein Beispiel, wie es aussehen kann:
Ich empfehle, zunächst mit einem homogenen Ansatz zu beginnen – wählen Sie ein Kompositionsmuster, das besser zu Ihnen passt, und beginnen Sie mit dem Aufbau der Infrastruktur darum herum.
Für uns war die clientseitige Komposition die beste Option, aber für die Zukunft haben wir darüber nachgedacht, einige Regionen auf die Edge-seitige Orchestrierung umzustellen (basierend auf der Verfügbarkeit von Lambda@Edge).
Wenn es um die Implementierung der clientseitigen Komposition in einer Mikro-Frontend-Architektur geht, ist die Auswahl der richtigen Orchestrierungsbibliothek eine entscheidende Entscheidung.
Die ausgewählte Bibliothek wird eine entscheidende Rolle bei der Verwaltung des dynamischen Ladens und der Koordination von Mikro-Frontends innerhalb der Containeranwendung spielen.
Es gibt mehrere beliebte Orchestrierungsbibliotheken, jede mit ihren eigenen Stärken und Überlegungen.
Single-spa ist eine weit verbreitete Orchestrierungsbibliothek, die einen flexiblen und erweiterbaren Ansatz für die Mikro-Frontend-Komposition bietet. Es ermöglicht Entwicklern, eine Shell-Anwendung zu erstellen, die das Laden und Entladen mehrerer Mikro-Frontends orchestriert.
Single-SPA bietet eine detaillierte Kontrolle über Lebenszyklusereignisse und unterstützt verschiedene Frameworks und Technologien.
Vorteile:
Nachteile:
Qiankun ist eine leistungsstarke Orchestrierungsbibliothek, die vom Team von Ant Financial (Alibaba) entwickelt wurde. Für die Komposition wird ein partieller HTML-Ansatz verwendet. Auf der Seite der Micro-Frontend-App wird ein einfaches HTML-Snippet mit allen zu ladenden Einstiegspunkten erstellt.
Nach der Nutzung dieser HTML-Datei übernimmt der Container die gesamte Orchestrierung und stellt die App bereit. In dieser Konfiguration spielt partielles HTML die Rolle einer Manifestdatei, über die ich im vorherigen Kapitel gesprochen habe.
Vorteile:
Nachteile:
Module Federation , eine von Webpack bereitgestellte Funktion, hat in der Webentwicklungs-Community große Aufmerksamkeit und Hype erregt. Diese Technologie ermöglicht es Entwicklern, Code zur Laufzeit zwischen mehreren Anwendungen auszutauschen, was sie zu einer attraktiven Option für die Erstellung von Mikro-Frontends macht.
Aufgrund seiner nahtlosen Integration mit Webpack und der Laufzeitflexibilität ist Module Federation zu einer beliebten Wahl für die Verwaltung und Orchestrierung von Mikro-Frontends geworden.
Vorteile:
Nachteile:
In diesem ersten Teil der Reihe „Micro-Frontend Migration Journey“ haben wir die Motivation hinter der Migration von einem Web-Monolithen zu einer verteilten Architektur und die ersten Schritte besprochen, die unternommen wurden, um die Idee der Führung zu verkaufen.
Wir haben die Bedeutung eines technischen Visionsdokuments untersucht, das eine detaillierte Leistungsanalyse präsentiert und die verschiedenen Phasen der Migration beschreibt.
Anschließend befassten wir uns mit den Designüberlegungen für Mikro-Frontends und diskutierten drei Ansätze: serverseitige Komposition, Edge-seitige Komposition und clientseitige Komposition.
Jeder Ansatz hat seine Vor- und Nachteile, und die Wahl hängt von verschiedenen Faktoren wie der Synchronisierung des globalen Status, dem Kundenerlebnis, der Komplexität der Infrastruktur und dem Caching ab.
Darüber hinaus haben wir beliebte Orchestrierungsbibliotheken wie Single-Spa, Qiankun und Module Federation untersucht und deren Funktionen, Vorteile und potenzielle Herausforderungen hervorgehoben.
Begleiten Sie mich in den nächsten Teilen der Serie, während wir unsere Reise zur Micro-Frontend-Migration fortsetzen und dabei weitere interessante und wertvolle Erkenntnisse gewinnen!
Ursprünglich veröffentlicht unter https://thesametech.com am 18. April 2023.
Sie können mir auch auf Twitter folgen und sich auf LinkedIn vernetzen , um Benachrichtigungen über neue Beiträge zu erhalten!