Architekturstrategien für Einfachheit und Effizienz

Gilt für diese Empfehlung für die Zuverlässigkeitsprüfliste des Azure Well-Architected Framework:

In diesem Leitfaden werden die Empfehlungen beschrieben, um unnötige Komplexität und Mehraufwand zu minimieren, um Ihre Workloads einfach und effizient zu halten. Wählen Sie die besten Komponenten aus, um die erforderlichen Workloadaufgaben auszuführen, um die Zuverlässigkeit Ihrer Workload zu optimieren. Um Ihre Entwicklungs- und Verwaltungslasten zu mindern, nutzen Sie die Effizienz, die von der Plattform bereitgestellte Dienste anbieten. Mit diesem Design können Sie eine Workloadarchitektur erstellen, die robust, wiederholbar, skalierbar und verwaltbar ist.

Definitionen

Ein wichtiger Bestandteil des Entwurfs für Zuverlässigkeit ist es, die Dinge einfach und effizient zu halten. Konzentrieren Sie sich beim Entwurf Ihrer Workload auf die Erfüllung der Geschäftsanforderungen, um das Risiko unnötiger Komplexität oder eines übermäßigen Mehraufwands zu verringern. Berücksichtigen Sie die Empfehlungen in diesem Artikel, um Entscheidungen über Ihr Design zu treffen, um eine schlanke, effiziente und zuverlässige Arbeitsauslastung zu schaffen. Für Workloads gelten unter Umständen unterschiedliche Anforderungen in Bezug auf die Verfügbarkeit, Skalierbarkeit, Datenkonsistenz und Notfallwiederherstellung.

Sie müssen jede Entwurfsentscheidung mit einer geschäftlichen Anforderung rechtfertigen. Dieses Designprinzip mag offensichtlich erscheinen, aber es ist für die Arbeitsauslastungsgestaltung von entscheidender Bedeutung. Unterstützt Ihre Anwendung Millionen von Benutzern oder ein paar Tausend? Gibt es Datenverkehrsspitzen? Oder ist die Workload gleichmäßig? Welche Anwendungsausfallstufe ist akzeptabel? Die Geschäftsanforderungen fördern diese Entwurfsüberlegungen.

Kompromiss: Eine komplexe Lösung kann mehr Funktionen und Flexibilität bieten, kann jedoch die Zuverlässigkeit der Workload beeinträchtigen, da sie mehr Koordination, Kommunikation und Verwaltung der Komponenten erfordert. Alternativ kann eine einfachere Lösung die Erwartungen der Benutzer nicht vollständig erfüllen, oder sie wirkt sich negativ auf Skalierbarkeit und Erweiterbarkeit aus, da sich die Workload weiterentwickelt.

Arbeiten Sie bei Designübungen mit Stakeholdern zusammen

Arbeiten Sie mit Projektbeteiligten zusammen, um:

• Definieren und weisen Sie den Benutzer- und Systemabläufen Ihrer Workload eine Kritikalitätsstufe zu. Konzentrieren Sie Ihren Entwurf auf kritische Abläufe, um die erforderlichen Komponenten und den besten Ansatz zu bestimmen, mit dem das erforderliche Resilienzniveau erreicht werden kann.

• Definieren Sie funktionale und nicht funktionale Anforderungen. Berücksichtigen Sie funktionale Anforderungen, um festzustellen, ob eine Anwendung eine Aufgabe ausführt. Berücksichtigen Sie nicht funktionsfähige Anforderungen, um zu bestimmen, wie gut die Anwendung eine Aufgabe ausführt. Stellen Sie sicher, dass Sie nicht funktionsfähige Anforderungen wie Skalierbarkeit, Verfügbarkeit und Latenz kennen. Diese Anforderungen haben Einfluss auf Entwurfsentscheidungen und die Technologieauswahl.

• Dekompilieren Sie Workloads in Komponenten. Priorisieren Sie Einfachheit, Effizienz und Zuverlässigkeit in Ihrem Design. Ermitteln Sie die Komponenten, die Sie zur Unterstützung Ihrer Flüsse benötigen. Einige Komponenten unterstützen mehrere Flüsse. Ermitteln Sie, welche Herausforderung eine Komponente konzeptuell behandelt, und erwägen Sie, eine Komponente aus einzelnen Flüssen zu entfernen, um das Gesamtdesign zu vereinfachen und gleichzeitig die volle Funktionalität bereitzustellen. Weitere Informationen finden Sie unter Empfehlungen zur Durchführung einer Fehlermodusanalyse.

• Verwenden Sie die Fehlermodusanalyse , um einzelne Fehlerpunkte und potenzielle Risiken zu identifizieren. Überlegen Sie, ob Sie unwahrscheinliche Situationen berücksichtigen müssen, z. B. ein geografisches Gebiet, das eine große Naturkatastrophe erlebt, die sich auf alle Verfügbarkeitszonen in der Region auswirkt. Es ist teuer und beinhaltet erhebliche Kompromisse, um diese ungewöhnlichen Risiken zu mindern. Verstehen Sie die Toleranz Ihres Unternehmens für Risiken deutlich. Weitere Informationen finden Sie unter Empfehlungen zur Durchführung einer Fehlermodusanalyse.

• Definieren Sie Verfügbarkeits- und Wiederherstellungsziele für Ihre Abläufe, um die Architektur Ihrer Workload entsprechend auszurichten. Zu den Geschäftsmetriken gehören Service-Level-Ziele (SLOs), Service-Level-Vereinbarungen (SLAs), die mittlere Wiederherstellungszeit (MTTR), die mittlere Zeit zwischen Ausfällen (MTBF), Wiederherstellungszeitziele (RTOs) und Wiederherstellungspunktziele (RPOs). Definieren Sie Zielwerte für diese Metriken. Diese Übung erfordert möglicherweise Kompromisse und gegenseitiges Verständnis zwischen Technologie- und Geschäftsteams, um sicherzustellen, dass die Ziele jedes Teams geschäftsziele erfüllen und realistisch sind. Weitere Informationen finden Sie in Empfehlungen zur Definition von Zuverlässigkeitszielen.

Einfachere Designoptionen bevorzugen

Sie können die folgenden Empfehlungen ohne Engagement der Beteiligten ausführen:

• Bemühen Sie sich um Einfachheit und Klarheit in Ihrem Design. Verwenden Sie die entsprechende Abstraktion und Granularität für Ihre Komponenten und Dienste. Vermeiden Sie es, Ihre Lösung zu über- oder unterdimensionieren. Wenn Sie ihren Code beispielsweise in mehrere kleine Funktionen aufteilen, ist es schwer zu verstehen, zu testen und zu verwalten.

• Erkennen Sie an, dass sich alle erfolgreichen Anwendungen im Laufe der Zeit verändern, sei es, um Fehler zu beheben, neue Funktionen oder Technologien zu implementieren oder bestehende Systeme skalierbarer und robuster zu machen.

• Verwenden Sie plattform as a Service (PaaS)-Optionen anstelle der Infrastruktur als Dienst (IaaS), wenn möglich. IaaS können Sie sich wie eine Kiste mit Einzelteilen vorstellen. Sie können beliebige Dinge bauen, aber Sie müssen alles selbst zusammensetzen. PaaS-Optionen können einfacher konfiguriert und verwaltet werden. Sie müssen keine VMs oder virtuelle Netzwerke einrichten. Sie müssen auch keine Wartungsaufgaben ausführen, z. B. das Installieren von Patches und Updates.

• Reduzieren Sie eng gekoppelte Abhängigkeiten zwischen Workloadkomponenten, um das Risiko von Kaskadierenden Fehlern während teilweiser Ausfälle zu verringern. Beispielsweise ist asynchrones Messaging ein guter Ansatz, um den Nachrichtenhersteller vom Verbraucher zu entkoppeln.

• Abstrahieren Sie die Infrastruktur weg von der Domänenlogik. Stellen Sie sicher, dass die Domänenlogik keine Infrastrukturfunktionen beeinträchtigt, z. B. Messaging oder Persistenz.

• Querschnittsfunktionen in einen separaten Dienst auslagern. Minimieren Sie die Notwendigkeit, Code in verschiedenen Funktionen zu duplizieren, und bevorzugen Sie die Wiederverwendung von Diensten mit klar definierten Schnittstellen, die von verschiedenen Komponenten einfach genutzt werden können. Wenn beispielsweise mehrere Dienste Anforderungen authentifizieren müssen, können Sie diese Funktionalität in einen eigenen Dienst verschieben. Anschließend können Sie den Authentifizierungsdienst weiterentwickeln. Sie können z. B. einen neuen Authentifizierungsfluss hinzufügen, ohne die Dienste zu berühren, die sie verwenden.

• Bewerten Sie die Eignung allgemeiner Muster und Praktiken für Ihre Bedürfnisse. Vermeiden Sie die folgenden Trends oder Empfehlungen, die für Ihren Kontext oder Ihre Anforderungen möglicherweise nicht am besten geeignet sind. Beispielsweise sind Microservices nicht die beste Option für jede Anwendung, da sie Komplexitäts-, Overhead- und Abhängigkeitsprobleme verursachen können.

Entwickeln Sie nur genügend Code

Die Prinzipien der Einfachheit, Effizienz und Zuverlässigkeit gelten auch für Ihre Entwicklungspraktiken. Bestimmen Sie in einer lose gekoppelten, komponentenisierten Workload die Von einer Komponente bereitgestellte Funktionalität. Entwickeln Sie Ihre Workflows, um diese Funktion zu nutzen. Berücksichtigen Sie die folgenden Empfehlungen für Ihre Entwicklungsmethoden:

• Verwenden Sie Plattformfunktionen, wenn sie Ihren Geschäftlichen Anforderungen entsprechen. Um z. B. Entwicklung und Verwaltung zu entladen, verwenden Sie Low-Code-, No-Code- oder serverlose Lösungen, die Ihr Cloudanbieter anbietet.

• Verwenden Sie Bibliotheken und Frameworks.

• Führen Sie paarprogrammierungs- oder dedizierte Codeüberprüfungssitzungen als Entwicklungspraxis ein.

• Implementieren Sie einen Ansatz zum Identifizieren von inaktiven Code. Seien Sie skeptisch vom Code, den Ihre automatisierten Tests nicht abdecken.

Auswählen des richtigen Datenspeichers

In der Vergangenheit haben viele Organisationen alle ihre Daten in großen relationalen SQL-Datenbanken gespeichert. Relationale Datenbanken bieten atomare, konsistente, isolierte und dauerhafte Garantien (ACID) für relationale Datentransaktionen. Diese Datenbanken haben jedoch Nachteile:

• Abfragen können teure Verknüpfungen (Joins) erfordern.

• Sie müssen die Daten normalisieren und sie für Schema-on-Write neu strukturieren.

• Sperrkonflikte können die Leistung beeinträchtigen.

Alternativen zu relationalen Datenbanken

In einer großen Lösung erfüllt eine einzelne Datenspeichertechnologie wahrscheinlich nicht alle Ihre Anforderungen. Alternativen zu relationalen Datenbanken umfassen:

• Schlüssel-Wert-Speicher

• Dokumentdatenbanken

• Suchmaschinen-Datenbanken

• Zeitreihendatenbanken

• Spaltenbasierte Datenbanken

• Graphdatenbanken

Jede Option hat Vor- und Nachteile. Verschiedene Datentypen eignen sich besser für unterschiedliche Datenspeichertypen. Wählen Sie die Speichertechnologie aus, die am besten für Ihre Daten und Ihre Verwendungsweise der Daten geeignet ist.

Einen Produktkatalog sollten Sie z. B. in einer Dokumentdatenbank wie Azure Cosmos DB speichern, die ein flexibles Schema unterstützt. Jede Produktbeschreibung ist ein eigenständiges Dokument. Um Abfragen im gesamten Katalog durchführen zu können, können Sie den Katalog indizieren und den Index in Azure Cognitive Search speichern. Der Produktbestand kann in eine SQL-Datenbank eingehen, da diese Daten ACID-Garantien erfordern.

Empfehlungen

• Berücksichtigen Sie andere Datenspeicher. Relationale Datenbanken sind nicht immer geeignet. Weitere Informationen finden Sie unter Datenspeichermodelle verstehen.

• Denken Sie daran, dass zu den Daten mehr gehört als nur die dauerhaft gespeicherten Anwendungsdaten. Daten umfassen auch Anwendungsprotokolle, Ereignisse, Nachrichten und Caches.

• Nutzen Sie polyglotte Persistenz oder Lösungen, die eine Kombination aus Datenspeichertechnologien einsetzen.

• Berücksichtigen Sie den Datentyp, den Sie haben. Speichern Sie z. B. Folgendes:

  • Transaktionsdaten in einer SQL-Datenbank.

  • JSON-Dokumente in einer Dokumentdatenbank.

  • Telemetrie in einer Zeitreihendatenbank.

  • Anwendungsprotokolle in Azure Cognitive Search.

  • Blobs in Azure Blob Storage.

• Stellen Sie die Verfügbarkeit über die Konsistenz. Die GAP-Theorem impliziert, dass Sie kompromisse zwischen Verfügbarkeit und Konsistenz in einem verteilten System machen müssen. Sie können keine Netzwerkpartitionen vollständig vermeiden, was die andere Komponente des CAP-Theors ist. Sie können jedoch ein späteres Konsistenzmodell einführen, um eine höhere Verfügbarkeit zu erzielen.

• Berücksichtigen Sie die Qualifikationen Ihres Entwicklungsteams. Die Nutzung von Polyglot Persistence bietet Vorteile, aber man kann es auch übertreiben. Es erfordert neue Fähigkeiten, um eine neue Datenspeichertechnologie zu übernehmen. Um das Beste aus der Technologie herauszuholen, muss Ihr Entwicklungsteam Folgendes tun:

  • Optimieren von Abfragen

  • Optimieren der Leistung.

  • Arbeiten Sie mit den entsprechenden Verwendungsmustern.

Berücksichtigen Sie diese Faktoren, wenn Sie eine Speichertechnologie auswählen:

• Verwenden Sie ausgleichende Transaktionen. Bei polyglot persistenz kann eine einzelne Transaktion Daten in mehrere Speicher schreiben. Wenn ein Fehler auftritt, verwenden Sie Ausgleichstransaktionen, um alle abgeschlossenen Schritte rückgängig zu machen.

• Berücksichtigen Sie gebundene Kontexte, bei denen es sich um ein domänengesteuertes Designkonzept handelt. Eine Kontextgrenze ist eine explizite Grenze um ein Domänenmodell. Ein gebundener Kontext definiert, auf welche Teile der Domäne das Modell angewendet wird. Idealerweise wird eine Kontextgrenze einer Subdomäne der Geschäftsdomäne zugeordnet. Berücksichtigen Sie die Polyglotpersistenz für gebundene Kontexte in Ihrem System. Beispielsweise können Produkte in der Unterdomäne des Produktkatalogs und in der Unterdomäne des Produktbestands angezeigt werden. Am wahrscheinlichsten ist es aber, dass diese beiden Unterdomänen unterschiedliche Anforderungen an das Speichern, Aktualisieren und Abfragen von Produkten haben.

Azure-Unterstützung

Azure bietet die folgenden Dienste:

• Azure Functions ist ein serverloser Computedienst, den Sie zum Erstellen von Orchestrierungen mit minimalem Code verwenden können.

• Azure Logic Apps ist eine serverlose Plattform für die Workflowintegration, mit der Sie Orchestrierungen über eine grafische Benutzeroberfläche oder durch Bearbeiten einer Konfigurationsdatei erstellen können.

• Azure Event Grid ist ein hochgradig skalierbarer, vollständig verwalteter Publish/Subscribe-Nachrichtenverteilungsdienst, der flexible Muster für den Nachrichtenverbrauch bietet, die die MQTT- und HTTP-Protokolle verwenden. Mit Event Grid können Sie Datenpipelinen mit Gerätedaten erstellen, ereignisgesteuerte serverlose Architekturen erstellen und Anwendungen integrieren.

Weitere Informationen finden Sie unter:

• Wählen Sie einen Azure-Computerdienst aus
• Wählen Sie eine Compute-Option für Microservices aus
• Überprüfen Sie Ihre Datenoptionen

Beispiel

Ein Beispiel für eine Arbeitslast, die Komponenten und ihre Funktionen basierend auf Anforderungen bestimmt, finden Sie unter Zuverlässiges Web-App-Muster.

Verwandte Links

• Azure serverless
• Cloud-native Anwendungen
• Datenbanktypen in Azure

Zuverlässigkeitsprüfliste

Lesen Sie den vollständigen Satz von Empfehlungen.