Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Tipp
Dieser Inhalt ist ein Auszug aus dem eBook .NET Microservices Architecture for Containerized .NET Applications, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.
Microservices bieten große Vorteile, heben aber auch große neue Herausforderungen auf. Microservice-Architekturmuster sind grundlegende Säulen beim Erstellen einer mikroservicebasierten Anwendung.
Weiter oben in diesem Leitfaden haben Sie grundlegende Konzepte zu Containern und Docker kennengelernt. Diese Informationen waren das Minimum, das Sie für die ersten Schritte mit Containern benötigten. Auch wenn Container Ermöglicher sind und sich hervorragend für Microservices eignen, sind sie nicht obligatorisch für eine Microservice-Architektur. Viele Architekturkonzepte in diesem Architekturabschnitt können ohne Container angewendet werden. Dieser Leitfaden konzentriert sich jedoch auf die Schnittmenge beider, aufgrund der bereits eingeführten Bedeutung von Containern.
Unternehmensanwendungen können komplex sein und bestehen häufig aus mehreren Diensten anstelle einer einzigen dienstbasierten Anwendung. In diesen Fällen müssen Sie andere Architekturansätze verstehen, z. B. die Microservices und bestimmte Domain-Driven Design (DDD)-Muster sowie Container-Orchestrierungskonzepte. Beachten Sie, dass in diesem Kapitel nicht nur Microservices für Container, sondern auch für containerisierte Anwendungen beschrieben werden.
Designprinzipien für Container
Im Containermodell stellt eine Containerimageinstanz einen einzelnen Prozess dar. Indem Sie ein Containerimage als Prozessgrenze definieren, können Sie Grundtypen erstellen, die zum Skalieren oder Stapeln des Prozesses verwendet werden können.
Wenn Sie ein Containerimage entwerfen, wird eine ENTRYPOINT-Definition in der Dockerfile-Datei angezeigt. Diese Definition definiert den Prozess, dessen Lebensdauer die Lebensdauer des Containers steuert. Nach Abschluss des Prozesses endet der Containerlebenszyklus. Container stellen möglicherweise lange ausgeführte Prozesse wie Webserver dar, können aber auch kurzlebige Prozesse wie Batchaufträge darstellen, die früher als Azure WebJobs implementiert wurden.
Wenn der Prozess fehlschlägt, endet der Container, und der Orchestrator übernimmt. Wenn der Orchestrator so konfiguriert wurde, dass fünf Instanzen ausgeführt werden und ein Fehler auftritt, erstellt der Orchestrator eine weitere Containerinstanz, um den fehlgeschlagenen Prozess zu ersetzen. In einem Batchauftrag wird der Prozess mit Parametern gestartet. Nach Abschluss des Vorgangs ist die Arbeit abgeschlossen. Dieser Leitfaden geht zu einem späteren Zeitpunkt ausführlich auf Orchestratoren ein.
Möglicherweise finden Sie ein Szenario, in dem mehrere Prozesse in einem einzigen Container ausgeführt werden sollen. Da für dieses Szenario nur ein Einstiegspunkt pro Container vorhanden sein kann, können Sie ein Skript innerhalb des Containers ausführen, das beliebig viele Programme startet. Sie können beispielsweise Supervisor oder ein ähnliches Tool verwenden, um mehrere Prozesse in einem einzelnen Container zu starten. Obwohl Sie Architekturen finden können, die mehrere Prozesse pro Container enthalten, ist dieser Ansatz nicht sehr häufig.