Empfehlungen für das Entwerfen von 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

Wichtige Entwurfsstrategien

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 Features und Flexibilität bieten, kann sich jedoch auf die Zuverlässigkeit der Arbeitsauslastung auswirken, da sie mehr Koordination, Kommunikation und Verwaltung von 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.

Zusammenarbeit mit Projektbeteiligten an Entwurfsübungen

Arbeiten Sie mit Projektbeteiligten zusammen, um:

• Definieren und Zuweisen einer Kritischen Ebene zu den Benutzerflüssen und Systemflüssen Ihrer Workload. Konzentrieren Sie sich auf kritische Abläufe, um die erforderlichen Komponenten und den besten Ansatz zu ermitteln, um die erforderliche Resilienzstufe zu erreichen.

• 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 Flüsse, um die Architektur Ihrer Workload zu informieren. Zu den Geschäftsmetriken gehören Ziele auf Serviceebene (SLOs), Vereinbarungen auf Serviceebene (SLAs), mean time to recover (MTTR), mean time between failure (MTF), Recovery Time Objectives (RTOs) und Recovery Point Objectives (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 unter Empfehlungen zum Definieren 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 over engineering oder under engineering Ihre Lösung. Wenn Sie ihren Code beispielsweise in mehrere kleine Funktionen aufteilen, ist es schwer zu verstehen, zu testen und zu verwalten.

• Verketten Sie, dass sich alle erfolgreichen Anwendungen im Laufe der Zeit ändern, ob Fehler behoben, neue Features oder Technologien implementiert werden sollen, oder vorhandene Systeme skalierbarer und stabiler 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.

• Verwenden Sie asynchrones Messaging , 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.

• Lagern Sie Funktionen in einen separaten Dienst aus, falls Probleme durch Überschneidungen zu erwarten sind. Minimieren Sie die Notwendigkeit, Code über verschiedene Funktionen hinweg zu duplizieren, bevor Sie Dienste mit gut definierten Schnittstellen wiederverwenden, die einfach von verschiedenen Komponenten 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 Flüsse, um diese Funktionalität 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 beim Schreiben normalisieren und für das Schema 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 Grundlegendes zu Datenspeichermodellen.

• 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 polyglot Persistenz oder Lösungen, die eine Kombination aus Datenspeichertechnologien verwenden.

• 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.

• Priorisieren Der Verfügbarkeit gegenüber 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 mehrsprachige Persistenz bietet Vorteile, kann aber auch zu weit gehen. Es erfordert neue Fähigkeiten, um eine neue Datenspeichertechnologie zu übernehmen. Um die Technologie optimal zu erreichen, muss Ihr Entwicklungsteam Folgendes ausführen:

  • 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-Erleichterung

Azure bietet die folgenden Dienste:

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

• Azure Logic Apps ist eine serverlose Workflowintegrationsplattform, die Sie zum Erstellen der Orchestrierung mit einer GUI oder durch Bearbeiten einer Konfigurationsdatei verwenden können.

• Azure Event Grid ist ein hochgradig skalierbarer, vollständig verwalteter Nachrichtenverteilungsdienst, der flexible Nachrichtennutzungsmuster 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:

• Auswählen eines Azure-Computediensts
• Auswählen einer Computeoption für Microservices
• Überprüfen Ihrer Datenoptionen

Beispiel

Ein Beispielworkload, der Komponenten und deren Features basierend auf den Anforderungen bestimmt, finden Sie unter "Zuverlässiges Web App-Muster".

Verwandte Links

• Azure Serverless
• Cloudnative Anwendungen
• Datenbanktypen in Azure

Zuverlässigkeitsprüfliste

Lesen Sie den vollständigen Satz von Empfehlungen.