Zusammenfassung: Architektur von cloudeigenen Apps

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook, Architecting Cloud Native .NET Applications for Azure, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

Zusammenfassend sind hier wichtige Schlussfolgerungen aus diesem Leitfaden:

• Cloudnativ geht es darum, moderne Anwendungen zu entwerfen, die schnelle Veränderungen, große Mengen und Resilienz in modernen, dynamischen Umgebungen wie öffentliche, private und hybride Clouds umfassen.

• Die Cloud Native Computing Foundation (CNCF) ist ein einflussreiches Open-Source-Konsortium von über 300 großen Unternehmen. Es ist dafür verantwortlich, die Einführung von Cloud-nativem Computing über Technologie- und Cloudstapel hinweg zu fördern.

• CNCF-Richtlinien empfehlen, dass cloudeigene Anwendungen sechs wichtige Säulen umfassen, wie in Abbildung 11-1 dargestellt:

  

  Abbildung 11-1. Cloud-native Basispfeiler

• Zu diesen cloudeigenen Säulen gehören:

  • Die Cloud und das zugrunde liegende Dienstmodell
  • Moderne Designprinzipien
  • Microservices
  • Containerisierung und Container-Orchestrierung
  • Cloudbasierte Sicherungsdienste wie Datenbanken und Nachrichtenbroker
  • Automatisierung, einschließlich Infrastruktur als Code und Codebereitstellung

• Kubernetes ist die Hostingumgebung der Wahl für die meisten cloudeigenen Anwendungen. Kleinere, einfache Dienste werden manchmal auf serverlosen Plattformen gehostet, z. B. Azure Functions. Unter vielen wichtigen Automatisierungsfeatures bieten beide Umgebungen eine automatische Skalierung, um schwankende Workloadvolumen zu bewältigen.

• Die Dienstkommunikation wird zu einer wichtigen Entwurfsentscheidung beim Erstellen einer cloudeigenen Anwendung. Anwendungen machen in der Regel ein API-Gateway zum Verwalten der Front-End-Clientkommunikation verfügbar. Anschließend bemühen sich Back-End-Microservices, nach Möglichkeit mit einander zu kommunizieren, um asynchrone Kommunikationsmuster zu implementieren.

• gRPC ist ein modernes Hochleistungsframework, das das alte Remoteprozeduraufrufprotokoll (RPC) weiterentwickelt. Cloudeigene Anwendungen nutzen häufig gRPC, um Messaging zwischen Back-End-Diensten zu optimieren. gRPC verwendet als Transportprotokoll HTTP/2. Es kann bis zu 8-mal schneller als die JSON-Serialisierung sein und dabei 60–80 % kleinere Nachrichtengrößen generieren. gRPC ist Open Source und wird von der Cloud Native Computing Foundation (CNCF) verwaltet.

• Verteilte Daten sind ein Modell, das häufig von cloudeigenen Anwendungen implementiert wird. Anwendungen trennen Geschäftsfunktionen in kleine, unabhängige Microservices. Jeder Microservice kapselt seine eigenen Abhängigkeiten, Daten und Zustände. Das klassische gemeinsame Datenbankmodell entwickelt sich zu einer von vielen kleineren Datenbanken, die jeweils an einem Microservice ausgerichtet sind. Wenn sich der Rauch lichtet, kommen wir mit einem Entwurf zum Vorschein, der ein database-per-microservice-Modell bereitstellt.

• No-SQL Datenbanken beziehen sich auf leistungsfähige, nicht relationale Datenspeicher. Sie zeichnen sich durch ihre Benutzerfreundlichkeit, Skalierbarkeit, Resilienz und Verfügbarkeitsmerkmale aus. Dienste mit hohem Volumen, die sub second response time erfordern, bevorzugen NoSQL-Datenspeicher. Die Verbreitung von NoSQL-Technologien für verteilte cloudeigene Systeme kann nicht überstatiert werden.

• NewSQL ist eine neue Datenbanktechnologie, die die verteilte Skalierbarkeit von NoSQL und die ACID-Garantien einer relationalen Datenbank kombiniert. NewSQL-Datenbanken zielen auf Geschäftssysteme ab, die große Datenmengen über verteilte Umgebungen hinweg mit vollständiger Transaktions-/ACID-Compliance verarbeiten müssen. Die Cloud Native Computing Foundation (CNCF) verfügt über mehrere NewSQL-Datenbankprojekte.

• Resilienz ist die Fähigkeit Ihres Systems, auf Fehler zu reagieren und weiterhin funktionsfähig zu bleiben. Cloud-native Systeme nutzen eine verteilte Architektur, wo Fehler unvermeidlich sind. Anwendungen müssen so konstruiert werden, dass sie elegant auf Fehler reagieren und schnell in einen voll funktionsfähigen Zustand zurückkehren.

• Dienstgitter sind eine konfigurierbare Infrastrukturebene mit integrierten Funktionen zur Behandlung der Dienstkommunikation und anderer übergreifender Herausforderungen. Sie entkoppeln die querschnittsübergreifenden Verantwortlichkeiten von Ihrem Geschäftscode. Diese Verantwortlichkeiten gehen in einen Dienstproxy über. Als Sidecar pattern wird der Proxy in einem separaten Prozess bereitgestellt, um eine Isolation von Ihrem Geschäftscode zu gewährleisten.

• Observability ist eine wichtige Entwurfsüberlegung für cloudeigene Anwendungen. Da Dienste über einen Cluster von Knoten verteilt werden, werden zentralisierte Protokollierung, Überwachung und Warnungen obligatorisch. Azure Monitor ist eine Sammlung cloudbasierter Tools, die einen Einblick in den Zustand Ihres Systems bieten.

• Infrastruktur als Code ist eine allgemein akzeptierte Praxis, die die Plattformbereitstellung automatisiert. Ihre Infrastruktur und Bereitstellungen sind automatisiert, konsistent und wiederholbar. Tools wie Azure Resource Manager, Terraform und azure CLI ermöglichen es Ihnen, die erforderliche Cloudinfrastruktur deklarativ zu skripten.

• Die Codeautomatisierung ist eine Anforderung für cloudeigene Anwendungen. Moderne CI/CD-Systeme tragen dazu bei, diesen Grundsatz zu erfüllen. Sie stellen separate Build- und Bereitstellungsschritte bereit, die einen konsistenten und qualitätsbasierten Code gewährleisten. Die Buildstufe wandelt den Code in ein binäres Artefakt um. Die Veröffentlichungsphase übernimmt das binäre Artefakt, wendet die Konfiguration der externen Umgebung an und stellt es in einer angegebenen Umgebung bereit. Azure DevOps und GitHub sind umfassende DevOps-Umgebungen.

Vorhergehend