Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Serviceerkennung
Das Frontend-Discovery-Pattern verbessert die Entwicklungserfahrung bei der Entwicklung, dem Testen und der Bereitstellung von Mikro-Frontends. Das Pattern verwendet eine gemeinsam nutzbare Konfiguration, die den Einstiegspunkt von Mikro-Frontends beschreibt. Die gemeinsam nutzbare Konfiguration umfasst auch zusätzliche Metadaten, die mithilfe von Canary-Releases für sichere Bereitstellungen in jeder Umgebung verwendet werden.
Moderne Frontend-Entwicklung beinhaltet die Verwendung einer Vielzahl von Tools und Bibliotheken, um die Modularität während der Entwicklung zu unterstützen. Traditionell bestand dieser Prozess aus der Bündelung von Code in einzelnen Dateien, die in einem CDN gehostet werden konnten, mit dem Ziel, die Netzwerkaufrufe während der Laufzeit auf ein Minimum zu beschränken, einschließlich des anfänglichen Ladens (wenn eine App in einem Browser geöffnet wird) und der Nutzung (wenn ein Kunde Aktionen wie das Auswählen von Schaltflächen oder das Einfügen von Informationen ausführt).
Bündel aufteilen
Mikro-Frontend-Architekturen lösen die Leistungsprobleme, die durch sehr große Pakete verursacht werden, die durch die individuelle Bündelung einer Vielzahl von Funktionen generiert werden. Beispielsweise kann eine sehr große E-Commerce-Website in einer 6-MB-Datei gebündelt werden. JavaScript Trotz der Komprimierung kann sich die Größe dieser Datei negativ auf die Benutzererfahrung beim Laden der App und beim Herunterladen der Datei von einem Edge-optimierten CDN auswirken.
Wenn Sie die App in Startseite, Produktdetails und Warenkorb-Mikrofrontends aufteilen, können Sie mithilfe eines Bündelungsmechanismus drei individuelle 2-MB-Bundles erstellen. Durch diese Änderung kann die Leistung beim ersten Laden um 300 Prozent verbessert werden, wenn Benutzer die Startseite aufrufen. Die Produkt- oder Warenkorb-Mikrofrontend-Pakete werden nur dann asynchron geladen, wenn der Benutzer die Produktseite für einen Artikel besucht und sich für den Kauf entscheidet.
Viele Frameworks und Bibliotheken sind auf der Grundlage dieses Ansatzes verfügbar, und es gibt sowohl für Kunden als auch für Entwickler Vorteile. Um Geschäftsgrenzen zu identifizieren, die zur Entkopplung von Abhängigkeiten im Code führen können, können Sie verschiedene Geschäftsfunktionen mehreren Teams zuordnen. Die verteilte Eigentümerschaft sorgt für Unabhängigkeit und Agilität.
Wenn Sie Build-Pakete aufteilen, können Sie eine Konfiguration verwenden, um Mikro-Frontends zuzuordnen und die Orchestrierung für das erste Laden und für die Navigation nach dem Laden zu steuern. Dann kann die Konfiguration während der Laufzeit und nicht während der Build-Zeit verwendet werden. Beispielsweise kann der clientseitige Frontend-Code oder der serverseitige Backend-Code einen ersten Netzwerkaufruf an eine API tätigen, um die Liste der Mikro-Frontends dynamisch abzurufen. Es ruft auch die Metadaten ab, die für die Zusammenstellung und Integration erforderlich sind. Sie können Failover-Strategien und Caching konfigurieren, um Zuverlässigkeit und Leistung zu gewährleisten. Die Zuordnung der Mikro-Frontends trägt dazu bei, dass einzelne Bereitstellungen von Mikro-Frontends von zuvor bereitgestellten Mikro-Frontends, die von einer Shell-App orchestriert werden, auffindbar sind.
Veröffentlichungen auf Canary
Eine Canary-Version ist ein etabliertes und beliebtes Muster für die Bereitstellung von Mikrodiensten. Bei Canary-Releases werden die Zielbenutzer einer Version in mehrere Gruppen aufgeteilt, und Release-Änderungen werden schrittweise vorgenommen, im Gegensatz zu einer sofortigen Ersetzung (auch bekannt als blaue/grüne Implementierung). Ein Beispiel für eine Release-Strategie von Canary besteht darin, eine neue Änderung für 10 Prozent der Zielbenutzer einzuführen und jede Minute 10 Prozent hinzuzufügen, mit einer Gesamtdauer von 10 Minuten, um 100 Prozent zu erreichen.
Das Ziel einer Canary-Version besteht darin, frühzeitig Feedback zu den Änderungen zu erhalten und das System zu überwachen, um die Auswirkungen von Problemen zu reduzieren. Sobald die Automatisierung eingeführt ist, können Geschäfts- oder Systemkennzahlen durch ein internes System überwacht werden, das die Bereitstellung stoppen oder ein Rollback einleiten kann.
Beispielsweise kann eine Änderung zu einem Fehler führen, der in den ersten Minuten einer Version zu Umsatzeinbußen oder Leistungseinbußen führt. Durch automatisiertes Monitoring kann ein Alarm ausgelöst werden. Mit dem Diensterkennungsmuster kann dieser Alarm die Bereitstellung stoppen und sofort rückgängig machen, sodass nur 20 Prozent der Benutzer betroffen sind, anstatt 100 Prozent. Das Unternehmen profitiert vom geringeren Umfang des Problems.
Eine Beispielarchitektur, die DynamoDB als Speicher für die Implementierung einer REST-Admin-API verwendet, finden Sie in der Frontend Service Discovery on AWS-Lösung
